[MLton-devel] Re: release of MLton with MLton.Finalizable and _export

[Stephen Weeks]

> Cool.  Because I can't compile MLton from CVS these days.  I get the
> following error:
...
>   MLton raised in 0.21 + 0.00 (0% GC)
>   newIn ../lib/mlton-stubs/int-inf.sml: No such file or directory
> ---
> 
> I guess it is a case of not getting the mlton-stub files updated like
> last time.

Yeah.  I've checked in the fixed CM files.  Sorry about that.  Feel
free to send mail whenever you're not able to build from CVS.  We try
to always keep things in a working state, and it's the responsibility
of whoever does a checkin to make sure things work.

> Today, I managed to open my first window with a button using the mlton
> port :-)

Great!

> But I get a strange error as soon as I click the button:
> 
>    unhandled exception: Thread.atomicEnd with no atomicBegin
> 
> (or if I do anything else that will result in an SML callback being
> called).  Any idea what I'm doing wrong, or how to debug this?

That was due to a bug in our implementation of callbacks, which have
to be careful to avoid race conditions in threaded programs.  I have
checked in a fix.

> To compile the helloworld example I use the following command:
>         mlton -output helloworld -verbose 2 helloworld-mlton.cm \
>  -I/home/kfl/programming/ml/mlton-20030625/install/usr/lib/mlton/self/include\
>       `pkg-config --cflags gtk+-2.0` mgtk-mlton.c `pkg-config --libs gtk+-2.0`

This is an incorrect way to call MLton.  It happens to sort of work,
but is undocumented.  Here is the correct way to call MLton:

	mlton [option ...] file.{cm|sml|c|o} [file.{c|S|o} ...] [library ...]

What is happening in your call above is the -I is not of the form
file.{c|S|o}, and so the rest of the line is assumed to be libraries
to be fed to the link phase of MLton.  You can verify this by seeing
everything from after the -I is passed to gcc when MLton says "Link
starting".  This also answers your question

>   * Why do I have to supply the long -I flag with the path to mlton
>     myself?

MLton supplies the correct -I for .c files in the "Compile C and
Assemble" phase, but not for the "Link" phase.  Since MLton thinks
it's linking, no include files are necessary.

>   * It is really annoying the exported .h is named the same as the
>     first .cm or .sml file.  Because it means that I have to make a
>     new mgtk-mlton.c file for each program that uses mgtk.  We would
>     like to distribute mgtk as a bunch of .sml files an single .c file
>     and a .cm file.  How can we do that?

I think the correct thing to do is to build a .o file by compiling
mgtk-mlton.c with gcc, not with mlton, and passing the .o to the call
to mlton.

I see that this is still a problem with MLton creating a new .h file
on every compile.  There's really no reason your users should have to
deal with this file.  Also, it doesn't change every time they build
their program, it only changes (possibly) when you rebuild mlgtk.  So,
the best solution that I can see is to have MLton output the .h file
only on demand, not every time a program with _export is compiled.
I've added a new option to mlton

    -export-header {false|true}		output header file for _export's

Now, MLton outputs the prototypes to stdout when you use
-export-header.

>   * If you search for GValue in MiniGtk-mlton.sml you'll find the
>     following code segment:
> 
>         type GValues = word
>         type GValue = word
>                 
>     I first wrote this as:
> 
>         type GValues = MLton.pointer
>         type GValue = MLton.pointer
> 
>     But then I get the error:
> 
>         MiniGtk-mlton.sml:153.10-154.72 
>         Error: invalid type for exported function: 
>            ((int32 * pointer * pointer * int32) -> unit)
>  
>     Why?

MLton.pointer is the correct thing to use for C pointers.  This will
allow us to someday compile code with 64 bit pointers but 32 bit
words.  The error is due to an oversight in the implementation of
_export.  I have checked in a fix so that _export now allows
MLton.pointer to be passed between SML and C.

With all of the above changes, I am able to compile and run your
mini-gtk example.  Here is how the calls to mlton look:

	mlton -export-header true mgtk.cm >mgtk-mlton.h
	gcc -c \
		-I/usr/lib/mlton/self/include \
		`pkg-config --cflags gtk+-2.0` \
		mgtk-mlton.c
	mlton \
		-output helloworld 	\
		-verbose 1 		\
		helloworld-mlton.cm 	\
		mgtk-mlton.o		\
		`pkg-config --libs gtk+-2.0`

With this, I can run helloworld and repeatedly click on the button to
see the "Hello World" message!

The one remaining ugliness to my eyes is the fact that the gcc call
needs to have the -I line

	-I/usr/lib/mlton/self/include

This is not so bad, because anyone who is using mgtk for MLton will
have this directory (somewhere).  But it's still ugly that they have
to know about it.  The reason for the -I is that the export header
file includes "types.h", which comes with the MLton runtime and
defines all the various types (Int32, Word8, ...).  The best fix that
I can think of would be to include the contents of types.h in the
generated header file.  But I'm not sure that's the right thing to do,
plus one still has to do the other messiness with pkg-config, so it's
not clear to me that the -I is really a problem.  I'm open to
suggestions.

Anyways, it looks like really good progress to me and I am excited to
see more.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel