Bugs report

[Stephen Weeks]

> Both of these bugs have been fixed in our internal working version and
> will 
> appear in the next release of MLton.  This should appear within the next
> few 
> weeks.  If you need a fix sooner, I can patch 20000906-2 and make that 
> available.
> 
> I would appreciate this very much. At this point, the workaround I
> implemented consists in changing the Main macro so that we add 32 bytes
> to the passed parameter. It seems to do the trick on my application but
> this is rather unelegant and fragile. 

I thought of another alternative that is easier for me than patching 20000906-2,
and may be acceptable to you.  I can make an rpm of our current internal version
and let you use that until the public release becomes available.  As long as
you're not doing anything too exotic with command line switches (those have
changed a lot) and are willing to live with documentation that is not yet up to
date, it should be fine.   If you're just doing "mlton foo.sml" it should still
work.

> Apart from the bugs refered to earlier, there was a third problem which
> I fixed: your runtime refuses to swap ! More precisely it prefers
> suicide to growing heap beyond actual RAM. 

Hmmm.  MLton is supposed to restrict itself to .85 times the RAM size (as seen
in /proc/meminfo) unless you give the runtime system command line arguments.
What was your fix?  Did you figure out why the RAMslop code in gc.c wasn't
working?

Another simple fix is to manually limit the amount of RAM by using @MLton
fixed-heap or @MLton max-heap runtime system arguments.

> Is your company using MLTON for industrial products ? Are there plans
> for selling MLTON ? 

No. I use SML/NJ and MLton for some prototyping internally, but it is purely on
my own initiative.  There are no plans for selling MLton.  I am of course always 
happy to accept lucrative MLton consulting contracts as they arise :-)