Bugs report

[Stephen Weeks]

Hi Alain. 

We put up an RPM of a recent internal working version of MLton at 

	http://www.sourcelight.com/MLton/EXPERIMENTAL/index.html

Feel free to try it out.  It should at least fix the two bugs you encountered.
Like I said, the documentation is really out of date, so it's probably not worth 
your time reporting any errors in that.  However, we would appreciate hearing
about any bugs you find in the compiler.

> Another question: your stop and copy GC performs breadth first copying. Wouln't
> something more depth first be more cache friendly ?

Possibly.  We haven't experimented with that.  It's a simple enough system that
it should be possible to build a depth-first version in a couple of weeks.  But I
don't have the time.  Perhaps another of the MLton developers does, or perhaps
you know someone who might be willing to try?  We are always happy to provide
assistance.

> Last question, is there any convenient way of tracing down the source of an uncaught
> exception ?

I think SML/NJ does a good job of this.

There is an undocumented command line option to MLton that causes the compiled
executable to print out a message (approximately) on entry and exit of every
function.  This will of course output a lot of data and may cause things to
execute too slowly or break tail recursion.  But it just might work.  Try 

	mlton -print-at-fun-entry file

... hmmm .. in looking at the MLton sources, I see it should be pretty easy to
keep track of the file position of the raise expression that raised the
exception and print that as part of the unhandled exception message.  That would 
be useful in some cases.  But for things like Subscript, it probably wouldn't
help.  I guess you want some sort of backtrace, which is harder.  I'll think
about it for a future release.


Did you have any luck tracking down why the runtime was growing the heap beyond
RAM size?