[MLton] OpenGL

Mike Thomas mike.thomas@brisbane.paradigmgeo.com
Tue, 27 Jan 2004 13:05:15 +1000


Hi Stephen.

All suggestions implemented now, thanks.

Cheers

Mike Thomas.

| -----Original Message-----
| From: mlton-admin@mlton.org [mailto:mlton-admin@mlton.org]On Behalf Of
| Stephen Weeks
| Sent: Saturday, 24 January 2004 8:31 AM
| To: MLton@mlton.org
| Subject: RE: [MLton] OpenGL
| 
| 
| 
| > The second was that I am considering adding GL.cm, GLU.cm and
| > GLUT.cm to deal with each of the corresponding pairs of SML source
| > files (GL.sig, GL.sml and so on) - I thought this might be a way
| > around the kludge I have used of #including GL.sig etc in
| > ../glu/glu.sml and ../glut/glut.sml.
| 
| The seems reasonable to me if you ever need to have just one of the
| libraries.  If you put the .sig and .sml in a .cm file and always
| refer to that, MLton, just as CM, will make sure that the code only
| occurs once in the program.
| 
| > If this is a workable method, then I would need to ask you (please)
| > to manually remove from your CVS repository any evidence that
| > "Gl.cm" or "GL.cm" ever existed to get around the Cygwin bug.
| 
| Done.
| 
| 
| I have a few minor tweaks for Makefile, and one for spin_cube.sml.
| 
| Regarding the Makefile, wouldn't it make more sense to pass GL_c.o and
| GLUT_c.o to each call to mlton instead of using GL_c.c and GLUT_c.c?
| 
| You have a lot of calls to "mlton" that should be to $(mlton).
| 
| To keep CVS quiet, I've found it nice to put all the stuff that you
| currently have in your clean target into the .cvsignore, and then have
| make clean use that file.  That way all the information about what's
| junk is in once place.  You can have the clean target call our
| bin/clean script, which is what we do in most of our other Makefiles.
| 
| Finally, I need to request a change to spin_cube.sml.  There need to
| be type annotations (: Real32.real list) on the declarations of
| whiteLight, sourceLight, and lightPos.  The latest MLton will actually
| report an error if you don't have them.  The reason is that the new
| (correct) handling of topdecs resolves overloading of constants on
| those declarations before looking at the uses of whiteLight, etc,
| which means that it resolves them as "real list", not "Real32.real
| list".   So, the change is
| 
| val whiteLight: Real32.real list =  [0.5, 0.5, 0.5, 1.0]
| val sourceLight: Real32.real list =  [0.8, 0.8, 0.8, 1.0]
| val lightPos: Real32.real list =  [0.0, 0.0, 0.0, 1.0]
| 
| Another alternative would be to make sure there are no semicolons
| (like the one on line 9) that cause the program to be split into
| topdecs, although I'd prefer the annotations, which would be more
| robust (and informative).
| 
| _______________________________________________
| MLton mailing list
| MLton@mlton.org
| http://www.mlton.org/mailman/listinfo/mlton
| 
|