For your viewing pleasure :)

[ANOQ of the Sun]

"Stephen Weeks" wrote:
> Very cool!  It seems to work on my machine (assuming there isn't
> suposed to be user input yet).

Well, you can close the Window - right? This is an event
handled explicitly in the ML code :)
But there isn't any other input in the version I sent...

> BTW, you might be interested in a couple of switches that you can feed
> the executable to get information about the gc.  Try out
>         Game @MLton gc-messages gc-summary --
> This will print a message at every gc, as well as a summary of gc
> information upon program termination.  When I ran it, it said 1% of
> the time was spent in gc.

Thanks!

> > And the sopen command in saveWorld: should it be
> > append or create file?
> 
> create

I have just found out that, maybe I shouldn't use the Windows
sopen command (it stands for shared open...). It seems that
your sopen stands for safe open and that it is a function
you wrote explicitly (and not part of the linux/posix API).

So I think this will be just fine after renaming to safeopen :)

> 
> > ... But the most serious problem right now is that
> > I can't run mlton after having recompiled
> > libmlton.a and libgmp.a
> > so, do you have any ideas as to how one
> > makes mlton run with one library version and link
> > applications with another?
> 
> I am confused.  The MLton executable is statically linked with
> libmlton.a and libgmp.a.  I don't understand how recompiling them
> breaks MLton.  In any case you can control what flags mlton passes to
> gcc (and hence what libraries apps are linked with) by editing the
> bin/mlton script.

Thanks! I didn't realize that this was a script... It seems that
the compilation of the 2 libraries also relinked the compiler
itself. I just changed the call to mlton in the script to
my pure linux version of mlton, and it tries to crosscompile
just fine now...

> 
> > Also for Windows applications, it should not link
> > with -lm  so how can I change this?
> 
> The bin/mlton script has the default linker flags that are passed
> along to gcc on line 18.  Just change that line to suit your needs.

Thanks again... much better now...

> 
> BTW, when you are ready to start debugging the GC, I recommend
> compiling sml programs with the -g and -DGC_EVERY_CHECK.  The former
> will cause the gc to do a lot of consistency checking and the latter
> will cause a gc to occur at every limit check point, which will slow
> things down a lot, but will help find any bugs.

Debug? I didn't change very much, and I think that either it will
crash very badly or just work fine :) But I'll try it...

> On a couple of procedural notes, there is no need to send mail to me
> that you send to MLton, since I receive all mail sent to MLton.  Also,
> for large email, if it's not too much trouble, I would prefer to
> receive a pointer to an ftp/http site so I can download the files at
> my leisure.  Thanks.

OK... It's a little trouble just for a couple of files, and I just
couldn't help it :) I might send a windows exe and SDL-dib.dll too
if I get it to work soon, but that should be all I'm going to
send... (as for big files at least...)



Current status:
The linker complains about a few "missing" functions which _are_
_there_... also I found it very weird that the crosscompiler
complains about a line like this:

state->environ = (uint)environ;

It says something like: Syntax error before (

Even after changing it to:

state->environ = 0;

It still complains about that parenthesis, even though
there isn't any! But those EGCS compilers have always seemed
quite buggy to me (and the crosscompiler is built from egcs).

But I feel that I'm very close now :)


Cheers
-- 
http://www.HardcoreProcessing.com