From t-johrep at microsoft.com Fri Sep 5 02:27:50 2008 From: t-johrep at microsoft.com (John Reppy) Date: Fri Sep 5 05:07:38 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista Message-ID: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> I've installed the 20070826 MinGW version of MLton (statically linked), but when I Run it from a MSYS bash shell, it immediately dumps core $ /c/mingw/bin/mlton 0 [main] bash 4476 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump Is this a known problem? Should I be using a different version of MLton? - John P.S. I'm not normally a windows user, but I'm spending the Autumn at MSRC. From wesley at terpstra.ca Fri Sep 5 05:45:38 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Sep 5 05:46:12 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> On Fri, Sep 5, 2008 at 11:27 AM, John Reppy wrote: > I've installed the 20070826 MinGW version of MLton (statically linked), but > when I > Run it from a MSYS bash shell, it immediately dumps core > > $ /c/mingw/bin/mlton > 0 [main] bash 4476 open_stackdumpfile: Dumping stack trace to > bash.exe.stackdump > > Is this a known problem? Should I be using a different version of MLton? > I don't know of anyone who has tried MLton/MinGW on Vista yet. Tom Murphy reported problems using MLton/cygwin on Vista, but I don't know if this was ever resolved. You could >try< a newer MLton, for example the msi installer on mlton.org/Experimental, but I doubt it will work either. I would be happy to look into this for you, as it seems I am currently the MinGW port maintainer. :-) However, as I don't have Vista, it would be very slow going. I would suggest using a non-Vista machine to build a debug version of hello-world (compiled with -g and linked to the -dbg libraries). Then, run that hello world in gdb and report back to us the stack trace. Or, convince your employers to buy a MLton developer a copy of Vista. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/2f4e25f9/attachment.html From Bernard.Berthomieu at laas.fr Fri Sep 5 06:21:36 2008 From: Bernard.Berthomieu at laas.fr (Bernard Berthomieu) Date: Fri Sep 5 06:25:02 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <48C13260.8080407@laas.fr> Hi John, John Reppy wrote: > I've installed the 20070826 MinGW version of MLton (statically linked), but when I > Run it from a MSYS bash shell, it immediately dumps core > > $ /c/mingw/bin/mlton > 0 [main] bash 4476 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump > > Is this a known problem? Should I be using a different version of MLton? > I built this particular version, on an XP machine. I never tried it on Vista though, and there are no Vista machine around to check, unfortunately. However, I could check that (my) applications built with that compiler on XP, run fine on Vista. I'd suggest you to try the same: compile on XP then run on Vista ... Bernard. From t-johrep at microsoft.com Fri Sep 5 06:38:23 2008 From: t-johrep at microsoft.com (John Reppy) Date: Fri Sep 5 06:39:02 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> Message-ID: <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> Thanks for the pointer. The r6811 msi version works better for me, although it installs its own copy of MSYS and MinGW, which seems strange. The problem that I'm hitting now is that MLton is reporting a syntax error on a mlb file (the file in question has been used successfully on both Linux and Mac OS X systems). $ make /bin/mlton -const 'Exn.keepHistory true' -mlb-path-map /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map -link-opt '-L/c/Users/t-johrep/Work/sml3d/windows/lib -lglut32 -lglu32 -lopengl32 /c/Users/t-johrep/Work/sml3d/src/glut/glut-glue.o' -output ortho main.mlb Error: main.mlb 27.0. Parse error. compilation aborted: parseAndElaborate reported errors make: *** [ortho] Error 1 The MLB file is 1 (* main.mlb 2 * 3 * COPYRIGHT (c) 2008 John Reppy (http://www.cs.uchicago.edu/~jhr) 4 * All rights reserved. 5 * 6 * Ortho2d test 7 *) 8 9 local 10 11 $(SML_LIB)/basis/basis.mlb 12 $(SML_LIB)/smlnj-lib/Util/smlnj-lib.mlb 13 $(SML_LIB)/basis/mlton.mlb 14 15 $(SMLXD_LIB)/common/sml3d-common.mlb 16 $(SMLXD_LIB)/glut/glut.mlb 17 $(SMLXD_LIB)/util/util.mlb 18 19 main.sml 20 21 in 22 23 structure Main 24 25 end 26 So the error is at the end of the file. - John From: Wesley W. Terpstra [mailto:wesley@terpstra.ca] Sent: 05 September 2008 13:46 To: John Reppy; mlton-user@mlton.org Subject: Re: [MLton-user] Using MinGW version of MLton on Vista On Fri, Sep 5, 2008 at 11:27 AM, John Reppy > wrote: I've installed the 20070826 MinGW version of MLton (statically linked), but when I Run it from a MSYS bash shell, it immediately dumps core $ /c/mingw/bin/mlton 0 [main] bash 4476 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump Is this a known problem? Should I be using a different version of MLton? I don't know of anyone who has tried MLton/MinGW on Vista yet. Tom Murphy reported problems using MLton/cygwin on Vista, but I don't know if this was ever resolved. You could >try< a newer MLton, for example the msi installer on mlton.org/Experimental, but I doubt it will work either. I would be happy to look into this for you, as it seems I am currently the MinGW port maintainer. :-) However, as I don't have Vista, it would be very slow going. I would suggest using a non-Vista machine to build a debug version of hello-world (compiled with -g and linked to the -dbg libraries). Then, run that hello world in gdb and report back to us the stack trace. Or, convince your employers to buy a MLton developer a copy of Vista. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/f5e2a816/attachment.htm From brianpo at cmu.edu Fri Sep 5 06:53:57 2008 From: brianpo at cmu.edu (Brian P. O'Hanlon) Date: Fri Sep 5 06:54:30 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> On Fri, Sep 5, 2008 at 9:38 AM, John Reppy wrote: > Thanks for the pointer. The r6811 msi version works better for me, although > it installs its own copy of MSYS and MinGW, > > which seems strange. The problem that I'm hitting now is that MLton is > reporting a syntax error on a mlb file (the file in > > question has been used successfully on both Linux and Mac OS X systems). > > > > $ make > > /bin/mlton -const 'Exn.keepHistory true' -mlb-path-map > /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map -link-opt > '-L/c/Users/t-johrep/Work/sml3d/windows/lib ?lglut32 -lglu32 -lopengl32 > /c/Users/t-johrep/Work/sml3d/src/glut/glut-glue.o' -output ortho main.mlb > > Error: main.mlb 27.0. > > Parse error. > > compilation aborted: parseAndElaborate reported errors > > make: *** [ortho] Error 1 > > > > The MLB file is > > > 26 > > > > So the error is at the end of the file. > Try opening the file in a windows text editor, deleting the last line, and then re-adding an empty line. It is probably choking on the UNIX EOF character, which is not the same as the Windows EOF character. -Brian From wesley at terpstra.ca Fri Sep 5 07:09:46 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Sep 5 07:09:50 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809050709q2d662ca8x1a7db1bdda562efb@mail.gmail.com> On Fri, Sep 5, 2008 at 3:38 PM, John Reppy wrote: > Thanks for the pointer. The r6811 msi version works better for me, > although it installs its own copy of MSYS and MinGW, which seems strange. > The idea is to make MLton easy for Joe-average windows user. Bundling a known-good mingw with MLton means the user doesn't have anything else to setup (MinGW isn't a very easy install) and we avoid problems where mingw changes something mlton depends on (this has happened in the past). > The problem that I'm hitting now is that MLton is reporting a syntax error > on a mlb file (the file in question has been used successfully on both Linux > and Mac OS X systems). > If what Brian suggested already doens't help, I notice there are two changes to the mlb lexer made on November 22, 2007 (r6195 and r6196). That MSI installer gave you a bleeding edge MLton. You may be affected by still other changes made since the 20070826 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/bc0d2485/attachment.html From t-johrep at microsoft.com Fri Sep 5 07:16:27 2008 From: t-johrep at microsoft.com (John Reppy) Date: Fri Sep 5 07:17:13 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> Message-ID: <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> Unix doesn't have an EOF character (and I did an od to check that there wasn't anything funny at the end of the file; just a newline). Regular sml files created with a Unix editor (vi) go through MLton w/o problems. The problem appears to be related to my pathmap, which is pretty simple: $ cat /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map SMLXD_LIB /c/Users/t-johrep/Work/sml3d/src If I remove references to $(SMLXD_LIB) from my mlb file, then I don't get the parse error anymore. - John -----Original Message----- From: brainpo@gmail.com [mailto:brainpo@gmail.com] On Behalf Of Brian P. O'Hanlon Sent: 05 September 2008 14:54 To: John Reppy Cc: mlton-user@mlton.org Subject: Re: [MLton-user] Using MinGW version of MLton on Vista On Fri, Sep 5, 2008 at 9:38 AM, John Reppy wrote: > Thanks for the pointer. The r6811 msi version works better for me, although > it installs its own copy of MSYS and MinGW, > > which seems strange. The problem that I'm hitting now is that MLton is > reporting a syntax error on a mlb file (the file in > > question has been used successfully on both Linux and Mac OS X systems). > > > > $ make > > /bin/mlton -const 'Exn.keepHistory true' -mlb-path-map > /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map -link-opt > '-L/c/Users/t-johrep/Work/sml3d/windows/lib ?lglut32 -lglu32 -lopengl32 > /c/Users/t-johrep/Work/sml3d/src/glut/glut-glue.o' -output ortho main.mlb > > Error: main.mlb 27.0. > > Parse error. > > compilation aborted: parseAndElaborate reported errors > > make: *** [ortho] Error 1 > > > > The MLB file is > > > 26 > > > > So the error is at the end of the file. > Try opening the file in a windows text editor, deleting the last line, and then re-adding an empty line. It is probably choking on the UNIX EOF character, which is not the same as the Windows EOF character. -Brian From wesley at terpstra.ca Fri Sep 5 07:42:17 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Sep 5 07:42:51 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809050742vb248111hcdfab5b75337730a@mail.gmail.com> On Fri, Sep 5, 2008 at 4:16 PM, John Reppy wrote: > Unix doesn't have an EOF character (and I did an od to check that there > wasn't anything funny at the end of the file; just a newline). Regular > sml files created with a Unix editor (vi) go through MLton w/o problems. > > The problem appears to be related to my pathmap, which is pretty simple: > > $ cat /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map > SMLXD_LIB /c/Users/t-johrep/Work/sml3d/src > > If I remove references to $(SMLXD_LIB) from my mlb file, then I don't get > the parse error anymore. > You realize that the path "/c/foo/..." is a fiction? MLton is a native windows program and expects paths like c:\foo\bar. When you run something from the msys command line, it automatically translates /c/foo/bar into c:\foo\bar. c:/foo/bar will work too, though. Looking over the relevant code, I see (yet another) bug to do with spaces in path names. So don't use c:/My Documents/foo in the mlb file either. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/1cd5dee8/attachment.htm From t-johrep at microsoft.com Fri Sep 5 08:16:51 2008 From: t-johrep at microsoft.com (John Reppy) Date: Fri Sep 5 08:17:28 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <162de7480809050742vb248111hcdfab5b75337730a@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050742vb248111hcdfab5b75337730a@mail.gmail.com> Message-ID: <405C473125D4EC4C9DDD1143225286720A98952409@EA-EXMSG-C332.europe.corp.microsoft.com> From: Wesley W. Terpstra [mailto:wesley@terpstra.ca] Sent: 05 September 2008 15:42 To: John Reppy Cc: Brian P. O'Hanlon; mlton-user@mlton.org Subject: Re: [MLton-user] Using MinGW version of MLton on Vista On Fri, Sep 5, 2008 at 4:16 PM, John Reppy > wrote: Unix doesn't have an EOF character (and I did an od to check that there wasn't anything funny at the end of the file; just a newline). Regular sml files created with a Unix editor (vi) go through MLton w/o problems. The problem appears to be related to my pathmap, which is pretty simple: $ cat /c/Users/t-johrep/Work/sml3d/src/sml3d-path-map SMLXD_LIB /c/Users/t-johrep/Work/sml3d/src If I remove references to $(SMLXD_LIB) from my mlb file, then I don't get the parse error anymore. You realize that the path "/c/foo/..." is a fiction? MLton is a native windows program and expects paths like c:\foo\bar. When you run something from the msys command line, it automatically translates /c/foo/bar into c:\foo\bar. c:/foo/bar will work too, though. I think that the problem is with the path in the pathmap file. Switching to "c:\Users\..." got rid of the parse error. By using `pwd -W` in my autoconf script, I'm able to get working pathnames. Now I just need to figure out my linking errors with glut. BTW: I was not able to get the latest version of mlton to build from svn using this version of mlton. There are illegal characters in the generated C files. - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/0b89aabb/attachment.htm From wesley at terpstra.ca Fri Sep 5 08:52:54 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Sep 5 08:53:00 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720A98952409@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050742vb248111hcdfab5b75337730a@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A98952409@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809050852g40f1856bwf0d365960381165d@mail.gmail.com> On Fri, Sep 5, 2008 at 5:16 PM, John Reppy wrote: > I think that the problem is with the path in the pathmap file. Switching > to "c:\Users\..." got rid of the parse error. By using `pwd ?W` in my > autoconf script, I'm able to get working pathnames. Now I just need to > figure out my linking errors with glut. > Sorry I wasn't very clear. The pathmap is read directly by MLton. It doesn't come from the msys command-line. Therefore there is no translation applied by msys to turn /c/foo into c:/foo as MLton expects. So, yes, you need to use c:/foo in your mlb-path-map. Any place in SML code where you use paths, you >must< use "c:/foo". MLton and MLton-compiled programs have no idea about this "/c/foo" stuff. Those paths only work when you use them on the msys/bash command-line where msys will auto-translates them. That means any config or data files you refer to within your source must not be using strings like "/c/bar" -- that file doesn't exist (unless you have a directory called 'c'). Similarly, mlb files, mlb-path-maps, and the names of invoked/piped helper program must not use the /c/ notation. In fact, ideally, even msys command-line invocation shouldn't use this notation, so as to avoid confusion. Just try to use c:/foo/bar everywhere. That said, a parse error pointing at the bottom of the mlb file is a very unhelpful and misleading error message, and someone familiar with that part of the code should probably improve this. And, again be warned that MLton on Vista is 100% untested! > BTW: I was not able to get the latest version of mlton to build from svn > using this version of mlton. There are illegal characters in the generated > C files. > That's strange. I've been compiling it without problems. There was a recent change committed that modified a few IntInf macro names and broke my unclean build. However, a clean build of svn/HEAD with the r6811 msi install should work (on XP/2003/etc). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080905/45e12d23/attachment.html From fluet at tti-c.org Fri Sep 5 15:19:38 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Fri Sep 5 14:28:43 2008 Subject: [MLton-user] Using MinGW version of MLton on Vista In-Reply-To: <162de7480809050852g40f1856bwf0d365960381165d@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720A9895210A@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050545m450b4854x3002aae580ccf344@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A9895235B@EA-EXMSG-C332.europe.corp.microsoft.com> <267c13260809050653x367e0e75ifde926689d2740b6@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A989523AA@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050742vb248111hcdfab5b75337730a@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720A98952409@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809050852g40f1856bwf0d365960381165d@mail.gmail.com> Message-ID: On Fri, 5 Sep 2008, Wesley W. Terpstra wrote: > On Fri, Sep 5, 2008 at 5:16 PM, John Reppy wrote: >> I think that the problem is with the path in the pathmap file. Switching >> to "c:\Users\..." got rid of the parse error. By using `pwd ?W` in my >> autoconf script, I'm able to get working pathnames. Now I just need to >> figure out my linking errors with glut. > > That said, a parse error pointing at the bottom of the mlb file is a very > unhelpful and misleading error message, and someone familiar with that part > of the code should probably improve this. Indeed. I think what's going on is that the bogus paths in the path-map caused an exception to be raised (probably in the code to expand and regularize paths), which was then caught by the exception handler wrapping the parser. > And, again be warned that MLton on Vista is 100% untested! > >> BTW: I was not able to get the latest version of mlton to build from svn >> using this version of mlton. There are illegal characters in the generated >> C files. >> > That's strange. Yes. If it continues to persist, more details would be helpful. From t-johrep at microsoft.com Mon Sep 8 05:20:53 2008 From: t-johrep at microsoft.com (John Reppy) Date: Mon Sep 8 05:21:29 2008 Subject: [MLton-user] Minor issues Message-ID: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> A couple of minor issues that I noticed while trying to debug linking on Vista: 1) The FFI documentation suggests that one can specify an attribute to _symbol specifications, but doesn't explain what these might be. 2) I thought that "stdcall" might be such an attribute, but I get an error message Error: c:\users\t-johrep\work\sml3d\src\glut\glut.sml 687.49. Invalid attributestdcall. Note the missing " " between "attributes" and "stdcall". From t-johrep at microsoft.com Mon Sep 8 05:29:18 2008 From: t-johrep at microsoft.com (John Reppy) Date: Mon Sep 8 05:29:57 2008 Subject: [MLton-user] Linking issues with FFI on Vista Message-ID: <405C473125D4EC4C9DDD1143225286720E8E9E1857@EA-EXMSG-C332.europe.corp.microsoft.com> I have the following SML code for handling the display callback in GLUT: val exportDisplay = _export "glutDisplayCB" stdcall : (unit -> unit) -> unit; val glutDisplayCB = _address "glutDisplayCB" : Ptr.t; val glutDisplayFunc = _import "glutDisplayFunc" stdcall : Ptr.t -> unit; fun displayFunc (SOME f) = ( exportDisplay f; glutDisplayFunc glutDisplayCB) | displayFunc NONE = glutDisplayFunc Ptr.null When I compile and link this code on Vista (using MinGW), I get C:\Users\t-johrep\AppData\Local\Temp\fileQXimuh.o:main.0.S:(.text+0x1a95): undefined reference to `_imp__glutDisplayCB' The source of this error is code generated by MLton: $ grep glutDisplayCB main* main.0.S: movl (__imp__glutDisplayCB+0x0),%ebp main.3.c:EXPORTED void __attribute__ ((stdcall)) glutDisplayCB () { This code builds and runs fine on Linux and Mac OS X. - John From wesley at terpstra.ca Mon Sep 8 05:59:54 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Sep 8 06:00:03 2008 Subject: [MLton-user] Linking issues with FFI on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720E8E9E1857@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1857@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809080559p6712ea30j89bb93eb9a39bbeb@mail.gmail.com> On Mon, Sep 8, 2008 at 2:29 PM, John Reppy wrote: > I have the following SML code for handling the display callback in GLUT: > > val exportDisplay = _export "glutDisplayCB" stdcall : (unit -> > unit) -> unit; > val glutDisplayCB = _address "glutDisplayCB" : Ptr.t; In newer versions of MLton (like svn/HEAD), that code is in error. The _export has an implied symbol scope of "public", but the _address as you've use it has an implied symbol scope of "external". Because it's external it is trying to import the _address from a DLL. The code it generated is correct for this purpose. What you need to do is this: _export "glutDisplayCB" private : (unit -> unit) -> unit; _address "glutDisplayCB" private : Ptr.t; This makes the symbol scope agree in both cases as being private. You could also use public, if you liked. I don't know if you need 'stdcall' or not. Check the OpenGL docs. If you do, it will probably segfault when it tries to run the callback. ;-) Unfortunately, symbol scopes are not yet documented. They've only recently been implemented. Except for the case of taking the address of an exported function, though, it shouldn't be necessary to know how it works. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080908/81e08415/attachment.html From t-johrep at microsoft.com Mon Sep 8 06:27:47 2008 From: t-johrep at microsoft.com (John Reppy) Date: Mon Sep 8 06:28:26 2008 Subject: [MLton-user] Minor issues In-Reply-To: <162de7480809080603o29abcf42x1cbb1f2347a9e72a@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809080603o29abcf42x1cbb1f2347a9e72a@mail.gmail.com> Message-ID: <405C473125D4EC4C9DDD1143225286720E8E9E1926@EA-EXMSG-C332.europe.corp.microsoft.com> From: Wesley W. Terpstra [mailto:wesley@terpstra.ca] Sent: 08 September 2008 14:04 To: John Reppy Subject: Re: [MLton-user] Minor issues 2) I thought that "stdcall" might be such an attribute, but I get an error message Stdcall is a calling convention and has nothing to with data symbols, so it is invalid in this context. The point I was making is that the error message is missing a space character. - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080908/412ce052/attachment.htm From t-johrep at microsoft.com Mon Sep 8 06:49:24 2008 From: t-johrep at microsoft.com (John Reppy) Date: Mon Sep 8 06:50:05 2008 Subject: [MLton-user] Linking issues with FFI on Vista In-Reply-To: <162de7480809080559p6712ea30j89bb93eb9a39bbeb@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1857@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809080559p6712ea30j89bb93eb9a39bbeb@mail.gmail.com> Message-ID: <405C473125D4EC4C9DDD1143225286720E8E9E196A@EA-EXMSG-C332.europe.corp.microsoft.com> Thanks for the information. With the addition of "public" annotations, I can now get the program to link, but I get some strange warnings: Warning: resolving _glutDisplayCB by linking to _glutDisplayCB@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _glutReshapeCB by linking to _glutReshapeCB@8 Warning: resolving _glutKeyboardCB by linking to _glutKeyboardCB@12 Warning: resolving _glutVisibilityCB by linking to _glutVisibilityCB@4 Unfortunately, the program dies almost immediately. What debugger does one use to track this issues down? The MinGW stuff that comes with MLton has gcc, but not gdb. Also, I'm guessing that adding "public" attributes will break on 20070826? Is there any chance for a new release sometime soon? - John From: Wesley W. Terpstra [mailto:wesley@terpstra.ca] Sent: 08 September 2008 14:00 To: John Reppy Cc: mlton-user@mlton.org Subject: Re: [MLton-user] Linking issues with FFI on Vista On Mon, Sep 8, 2008 at 2:29 PM, John Reppy > wrote: I have the following SML code for handling the display callback in GLUT: val exportDisplay = _export "glutDisplayCB" stdcall : (unit -> unit) -> unit; val glutDisplayCB = _address "glutDisplayCB" : Ptr.t; In newer versions of MLton (like svn/HEAD), that code is in error. The _export has an implied symbol scope of "public", but the _address as you've use it has an implied symbol scope of "external". Because it's external it is trying to import the _address from a DLL. The code it generated is correct for this purpose. What you need to do is this: _export "glutDisplayCB" private : (unit -> unit) -> unit; _address "glutDisplayCB" private : Ptr.t; This makes the symbol scope agree in both cases as being private. You could also use public, if you liked. I don't know if you need 'stdcall' or not. Check the OpenGL docs. If you do, it will probably segfault when it tries to run the callback. ;-) Unfortunately, symbol scopes are not yet documented. They've only recently been implemented. Except for the case of taking the address of an exported function, though, it shouldn't be necessary to know how it works. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080908/84a4bc08/attachment-0001.html From fluet at tti-c.org Mon Sep 8 07:47:03 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 8 06:56:15 2008 Subject: [MLton-user] Minor issues In-Reply-To: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: On Mon, 8 Sep 2008, John Reppy wrote: > A couple of minor issues that I noticed while trying to debug linking on Vista: > > 1) The FFI documentation suggests that one can specify an attribute to _symbol specifications, > but doesn't explain what these might be. Which documentation? The documentation at http://mlton.org/ForeignFunctionInterfaceSyntax seems clear on the subject. (Modulo the fact that the documentation is up-to-date with respect to 20070826, not SVN HEAD.) > 2) I thought that "stdcall" might be such an attribute, but I get an error message > > Error: c:\users\t-johrep\work\sml3d\src\glut\glut.sml 687.49. > Invalid attributestdcall. > > Note the missing " " between "attributes" and "stdcall". Thanks. Fixed. From fluet at tti-c.org Mon Sep 8 08:05:50 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 8 07:15:02 2008 Subject: [MLton-user] Linking issues with FFI on Vista In-Reply-To: <405C473125D4EC4C9DDD1143225286720E8E9E196A@EA-EXMSG-C332.europe.corp.microsoft.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1857@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809080559p6712ea30j89bb93eb9a39bbeb@mail.gmail.com> <405C473125D4EC4C9DDD1143225286720E8E9E196A@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: On Mon, 8 Sep 2008, John Reppy wrote: > Thanks for the information. With the addition of "public" annotations, I can now get the program to link, but I get some strange warnings: > > Warning: resolving _glutDisplayCB by linking to _glutDisplayCB@0 > Use --enable-stdcall-fixup to disable these warnings > Use --disable-stdcall-fixup to disable these fixups > Warning: resolving _glutReshapeCB by linking to _glutReshapeCB@8 > Warning: resolving _glutKeyboardCB by linking to _glutKeyboardCB@12 > Warning: resolving _glutVisibilityCB by linking to _glutVisibilityCB@4 val exportDisplay = _export "glutDisplayCB" stdcall : (unit -> unit) -> unit; val glutDisplayCB = _address "glutDisplayCB" : Ptr.t; By _export-ing "glutDisplayCB" as a stdcall function, the C compiler name-mangles it so that in the object file it has the symbol "glutDisplayCB@0". MLton (nor gcc) has any reason to name-mangle the "glutDisplayCB" symbol in the _address expression, so there is a symbol mismatch. Obviously, it is common enough that the MinGW linker attempts to fix them automatically. > Also, I'm guessing that adding "public" attributes will break on 20070826? They will be a syntax error, yes. > Is there any chance for a new release sometime soon? Hopefully after the shared library stuff that Wesley added is stable and documented. From twm at andrew.cmu.edu Sun Sep 14 10:07:33 2008 From: twm at andrew.cmu.edu (Tom 7) Date: Sun Sep 14 10:07:38 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: Hey, I'm trying to debug a problem with using mlton+mingw+SDL on windows. Everything works fine when I run my app from the mingw command line, but when I run it from the DOS prompt or by clicking it in explorer, it terminates immediately and silently. I spent some time whittling it down and it happens even when I'm not using SDL. I reduced it to the following small oddity. Here's the scenario. With these two lines: val mb_ = _import "MessageBoxA" : MLton.Pointer.t * string * string * MLton.Pointer.t -> unit ; val () = mb_(MLton.Pointer.null, "Click.\000", "\000", MLton.Pointer.null) in a file called clicktest.sml compiled with the command line mlton @MLton max-heap 512m -- -cc-opt "-I/usr/local/include" -keep g -keep o -verbose 3 -cc-opt "-g -DDEBUG_X86CODEGEN" -link-opt "-L/usr/local/lib -lmingw32 -mwindows" -output clicktest.exe -default-ann 'allowFFI true' clicktest.sml runs from the mingwin prompt, DOS prompt, and double-clicking in explorer, and produces a message box as expected. But these three lines: val mb_ = _import "MessageBoxA" : MLton.Pointer.t * string * string * MLton.Pointer.t -> unit ; val () = mb_(MLton.Pointer.null, "Click.\000", "\000", MLton.Pointer.null) fun g s = print s produces a program that runs from the mingw prompt as before, but when run from DOS or by double-clicking, does nothing. (By adding debugging output as messageboxes in x86-main.h I'm able to see that it gets as far as the call to MLton_jumpToSML, but I don't know what happens then.) The only difference is the mention of the 'print' function in dead code. My guess is that this causes some I/O part of the Basis to be included (But then not eliminated?), which creates some more initialization steps (binding to stdout, perhaps) that abort the program when run in the click environment rather than the mingw command line environment. Does this sound plausible? If so, what code should I look at? Or is there some simple fix? =) BTW, I'm doing this development on Vista, but I get the same behavior on XP (though I have not delved as deep there). - Tom [ NEW! : http://tom7.org/ ] [ OLD! : http://fonts.tom7.com/ ] From wesley at terpstra.ca Mon Sep 15 02:39:59 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Sep 15 02:40:39 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> On Sun, Sep 14, 2008 at 7:07 PM, Tom 7 wrote: > I'm trying to debug a problem with using mlton+mingw+SDL on windows. > Everything works fine when I run my app from the mingw command line, but > when I run it from the DOS prompt or by clicking it in explorer, it > terminates immediately and silently. I have reproduced this problem with r6841 on win2003/x64. val mb_ = _import "MessageBoxA" : MLton.Pointer.t * string * string * > MLton.Pointer.t -> unit ; > This needed to be changed to _import "MessageBoxA" stdcall, though. The problem persists with this simplified compile line: > mlton -link-opt "-mwindows" -default-ann 'allowFFI true' clicktest.sml Once the -mwindows is removed, the test program works. I'm currently investigating what '-mwindows' does to the program. Do you need it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080915/38659642/attachment.htm From wesley at terpstra.ca Mon Sep 15 04:30:00 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Sep 15 04:30:12 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> Message-ID: <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> On Mon, Sep 15, 2008 at 11:39 AM, Wesley W. Terpstra wrote: > On Sun, Sep 14, 2008 at 7:07 PM, Tom 7 wrote: > >> I'm trying to debug a problem with using mlton+mingw+SDL on windows. >> Everything works fine when I run my app from the mingw command line, but >> when I run it from the DOS prompt or by clicking it in explorer, it >> terminates immediately and silently. > > > I have reproduced this problem with r6841 on win2003/x64. > The problem is that -mwindows removes the stdin/out/err file descriptors from the program. When you reference print, that forces the basis to create the stdOut variable. As you suspected, this does some initialization. Specifically, it checks if it's a tty, fstats it, then setmode/text's it. The fstat is failing and this gets turned into an exception that causes the program to exit. It works under msys, because msys provides *all* windows programs with stdin/out/err. I discovered this using 'mlton -debug true' and gdb. Set a breakpoint on Posix_FileSys_Stat_fstat and then trace the MLton-generated assembler. fstat fails in a "dos" terminal (info registers -> eax = return value). There are two fixes that come to mind: 1) handle/ignore the exception from fstat (isReg posix/io.sml:187) 2) setup place-holder stdin/out/err if none exist I tend towards option #2. stdin&out can come from openIn/Out "NUL". However, if stderr is missing one loses exception information. Perhaps it could create a popup window. A TextPrimIO.writer that creates a window and adds text on write* calls shouldn't be that hard to implement. Which do other people prefer? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080915/a94d2975/attachment.html From vesa.a.j.k at gmail.com Mon Sep 15 06:36:50 2008 From: vesa.a.j.k at gmail.com (Vesa Karvonen) Date: Mon Sep 15 06:37:24 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> Message-ID: <9e43b9a0809150636kc4a990aua203a42db00a5b77@mail.gmail.com> On Mon, Sep 15, 2008 at 2:30 PM, Wesley W. Terpstra wrote: [...] > I tend towards option #2. stdin&out can come from openIn/Out "NUL". However, > if stderr is missing one loses exception information. Perhaps it could > create a popup window. A TextPrimIO.writer that creates a window and adds > text on write* calls shouldn't be that hard to implement. BTW, this issue was also underlying the thread starting here: http://mlton.org/pipermail/mlton/2007-June/029811.html Basically, some code was failing and (IIRC) then the program went into an infinite memory hogging loop, because the default handler couldn't write to stderr. With the current MLton one can set the top-level handler in SML and do whatever one wants there. A default behavior where (at least) something gets displayed (in a message box), could be nice to have. I don't know how intrusive the change (to handle the "write* calls") would be. Perhaps it would be good enough to just show a message box (in the default top-level handler) to the effect that one needs to setup a custom top-level handler to see exception message. -Vesa Karvonen From fluet at tti-c.org Mon Sep 15 10:22:09 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 15 09:32:01 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, Wesley W. Terpstra wrote: > On Mon, Sep 15, 2008 at 11:39 AM, Wesley W. Terpstra wrote: >> On Sun, Sep 14, 2008 at 7:07 PM, Tom 7 wrote: >> >>> I'm trying to debug a problem with using mlton+mingw+SDL on windows. >>> Everything works fine when I run my app from the mingw command line, but >>> when I run it from the DOS prompt or by clicking it in explorer, it >>> terminates immediately and silently. >> >> >> I have reproduced this problem with r6841 on win2003/x64. > > The problem is that -mwindows removes the stdin/out/err file descriptors > from the program. What happens to an 'fprintf(stderr,...);' or an 'fwrite(s,size,n,stderr);' statement with -mwindows? An exception raised during the evaluation of the Basis Library will be printed using functions from /runtime/basis/Stdio.c. (See /basis-library/primitive/prim2.sml.) > When you reference print, that forces the basis to create > the stdOut variable. As you suspected, this does some initialization. > Specifically, it checks if it's a tty, fstats it, then setmode/text's it. Correct. > There are two fixes that come to mind: > 1) handle/ignore the exception from fstat (isReg posix/io.sml:187) > 2) setup place-holder stdin/out/err if none exist > > I tend towards option #2. How does one determine that stdin/out/err 'exist'? It seems as though they exist as values/handles, but don't support the full range of operations. > However, > if stderr is missing one loses exception information. Perhaps it could > create a popup window. A TextPrimIO.writer that creates a window and adds > text on write* calls shouldn't be that hard to implement. As noted above, this wouldn't help in this situation, because the exception printer (that is in scope for the evaluating the Basis Library) doesn't go through TextIO.print. From fluet at tti-c.org Mon Sep 15 10:28:58 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 15 09:38:33 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <9e43b9a0809150636kc4a990aua203a42db00a5b77@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> <9e43b9a0809150636kc4a990aua203a42db00a5b77@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, Vesa Karvonen wrote: > On Mon, Sep 15, 2008 at 2:30 PM, Wesley W. Terpstra wrote: > [...] >> I tend towards option #2. stdin&out can come from openIn/Out "NUL". However, >> if stderr is missing one loses exception information. Perhaps it could >> create a popup window. A TextPrimIO.writer that creates a window and adds >> text on write* calls shouldn't be that hard to implement. > > BTW, this issue was also underlying the thread starting here: > > http://mlton.org/pipermail/mlton/2007-June/029811.html > > Basically, some code was failing and (IIRC) then the program went into > an infinite memory hogging loop, because the default handler couldn't > write to stderr. > > With the current MLton one can set the top-level handler in SML and do > whatever one wants there. But, this doesn't help with exceptions raised during the evaluation of the Basis Library, since they occur before any user-code that installs a different top-level handler. > A default behavior where (at least) something gets displayed (in a > message box), could be nice to have. I don't know how intrusive the > change (to handle the "write* calls") would be. Actually, even the default top-level handler for a program doesn't go through TextIO. See /basis-library/mlton/exn.sml. This is purposeful, so that if a program doesn't otherwise use TextIO, the (necessary) top-level handler doesn't pull it in. From wesley at terpstra.ca Mon Sep 15 09:45:04 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Sep 15 09:45:08 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> Message-ID: <162de7480809150945i34af439i377ec02ea2f74462@mail.gmail.com> On Mon, Sep 15, 2008 at 7:22 PM, Matthew Fluet wrote: > On Mon, 15 Sep 2008, Wesley W. Terpstra wrote: > >> The problem is that -mwindows removes the stdin/out/err file descriptors >> from the program. >> > > What happens to an 'fprintf(stderr,...);' or an 'fwrite(s,size,n,stderr);' > statement with -mwindows? An exception raised during the evaluation of the > Basis Library will be printed using functions from > /runtime/basis/Stdio.c. (See /basis-library/primitive/prim2.sml.) They will all silently fail. The C code in my previous email will correct std*, however, so if it is called soon enough, stderr will work. There are two fixes that come to mind: >> 1) handle/ignore the exception from fstat (isReg posix/io.sml:187) >> 2) setup place-holder stdin/out/err if none exist >> >> I tend towards option #2. >> > > How does one determine that stdin/out/err 'exist'? It seems as though they > exist as values/handles, but don't support the full range of operations. The test fileno(stdout) == 1 in my previous email has worked on all the platforms / combinations I was able to test. However, >> if stderr is missing one loses exception information. Perhaps it could >> create a popup window. A TextPrimIO.writer that creates a window and adds >> text on write* calls shouldn't be that hard to implement. >> > > As noted above, this wouldn't help in this situation, because the exception > printer (that is in scope for the evaluating the Basis Library) doesn't go > through TextIO.print. > Yes. I no longer advocate this. My current suggestion is that we instead attach a hidden console, and display it if it is used. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080915/d60b7708/attachment.htm From fluet at tti-c.org Mon Sep 15 10:36:06 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 15 09:45:48 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: On Sun, 14 Sep 2008, Tom 7 wrote: > I'm trying to debug a problem with using mlton+mingw+SDL on windows. > Everything works fine when I run my app from the mingw command line, but when > I run it from the DOS prompt or by clicking it in explorer, it terminates > immediately and silently. I spent some time whittling it down and it happens > even when I'm not using SDL. > > The only difference is > the mention of the 'print' function in dead code. My guess is that this > causes some I/O part of the Basis to be included (But then not eliminated?), > which creates some more initialization steps (binding to stdout, perhaps) > that abort the program when run in the click environment rather than the > mingw command line environment. > > Does this sound plausible? If so, what code should I look at? Or is there > some simple fix? =) >From the comments of Wesley, it does seem as though demanding the initialization of TextIO is resulting in an uncaught exception, which would normally be acknowledged via a message to stderr, but that apparently doesn't exist. You might be able to make progress with your application as a whole using: Index: basis-library/posix/io.sml =================================================================== --- basis-library/posix/io.sml (revision 6853) +++ basis-library/posix/io.sml (working copy) @@ -182,7 +182,7 @@ *) local val pos0 = Position.fromInt 0 - fun isReg fd = FS.ST.isReg(FS.fstat fd) + fun isReg fd = FS.ST.isReg(FS.fstat fd) handle _ => false fun posFns (closed, fd) = if (isReg fd) then let From fluet at tti-c.org Mon Sep 15 12:35:37 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Mon Sep 15 11:45:12 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <162de7480809150945i34af439i377ec02ea2f74462@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> <162de7480809150945i34af439i377ec02ea2f74462@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, Wesley W. Terpstra wrote: > On Mon, Sep 15, 2008 at 7:22 PM, Matthew Fluet wrote: >> What happens to an 'fprintf(stderr,...);' or an 'fwrite(s,size,n,stderr);' >> statement with -mwindows? An exception raised during the evaluation of the >> Basis Library will be printed using functions from >> /runtime/basis/Stdio.c. (See /basis-library/primitive/prim2.sml.) > > They will all silently fail. The C code in my previous email will correct > std*, however, so if it is called soon enough, stderr will work. What C code? From wesley at terpstra.ca Mon Sep 15 12:18:12 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Sep 15 12:18:17 2008 Subject: Fwd: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: <162de7480809150704j4a5c4d85y6d95e2af368e4b6e@mail.gmail.com> References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> <162de7480809150239r695f1df0pde862a7019ff5c68@mail.gmail.com> <162de7480809150430g60c2f5bfy753946e3eebd89a2@mail.gmail.com> <9e43b9a0809150636kc4a990aua203a42db00a5b77@mail.gmail.com> <162de7480809150704j4a5c4d85y6d95e2af368e4b6e@mail.gmail.com> Message-ID: <162de7480809151218r2c834ef6me5a9ebaa8c3f0597@mail.gmail.com> Foiled again by the google default of reply-only-to-one-person! ---------- Forwarded message ---------- From: Wesley W. Terpstra Date: Mon, Sep 15, 2008 at 4:04 PM Subject: Re: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line To: Vesa Karvonen On Mon, Sep 15, 2008 at 3:36 PM, Vesa Karvonen wrote: > On Mon, Sep 15, 2008 at 2:30 PM, Wesley W. Terpstra > wrote: > [...] > > I tend towards option #2. stdin&out can come from openIn/Out "NUL". > However, > > if stderr is missing one loses exception information. Perhaps it could > > create a popup window. A TextPrimIO.writer that creates a window and adds > > text on write* calls shouldn't be that hard to implement. > > BTW, this issue was also underlying the thread starting here: > > http://mlton.org/pipermail/mlton/2007-June/029811.html > > Basically, some code was failing and (IIRC) then the program went into > an infinite memory hogging loop, because the default handler couldn't > write to stderr. > It seems a pretty easy failure mode affecting people compiling with '-mwindows'. I did a bit of hacking in C to see how it could work to create a console on demand and link stdin/out/err to it. I figure you could just ShowWindow when a write happens. #define _WIN32_WINNT 0x0500 > #include > #include > #include > #include > #include > > int main() { > HWND console; > BOOL existed; > int in, out, err; > > existed = fileno(stdout) == 1; > > if (!existed) { > AllocConsole(); > > console = GetConsoleWindow(); > // ShowWindow(console, SW_HIDE); > > in = _open_osfhandle((intptr_t)GetStdHandle(STD_INPUT_HANDLE), > _O_TEXT); > out = _open_osfhandle((intptr_t)GetStdHandle(STD_OUTPUT_HANDLE), > _O_TEXT); > err = _open_osfhandle((intptr_t)GetStdHandle(STD_ERROR_HANDLE), > _O_TEXT); > dup2(in, 0); if (in > 0) close(in); stdin ->_file = 0; > dup2(out, 1); if (out > 1) close(out); stdout->_file = 1; > dup2(err, 2); if (err > 2) close(err); stderr->_file = 2; > setvbuf(stdin, NULL, _IONBF, 0); > setvbuf(stdout, NULL, _IOLBF, 4096); > setvbuf(stderr, NULL, _IONBF, 0); > } > > printf("mooo!\n"); > fflush(stdout); > write(1, "baaa!\n", 6); > > MessageBoxA(0, "Click.", "title", 0); > > return 0; > } > This code will only create a new console if needed. That means it will use the existing console of msys even if -mwindows. However, if -mwindows and run from explorer or command-line, it creates a console. So if someone wants this to work in MLton, that code should probably be glued into some MLton_initStdio() method that gets called in the SML-side construction of stdOut/Err/In. That way it's only run if you actual might be using stdio. Somehow it also needs to be shown once a write occurs. I'm not sure how to do this since linked C code might also printf. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080915/bb14d42c/attachment.htm From twm at andrew.cmu.edu Wed Sep 17 18:21:44 2008 From: twm at andrew.cmu.edu (Tom 7) Date: Wed Sep 17 18:21:47 2008 Subject: [MLton-user] Linking (?) 'print' means I can only run from the mingw command line In-Reply-To: References: <405C473125D4EC4C9DDD1143225286720E8E9E1836@EA-EXMSG-C332.europe.corp.microsoft.com> Message-ID: This works, thanks guys! I also have to be careful not to print anything out while the program runs, but that can be arranged. I need -mwindows in order to run my program with SDL, yes. For my purposes, the ideal behavior would be for writes to stdout and stderr to be discarded when running without a console. Being able to pop up a window with output would be great for debugging time, but when being run by users I wouldn't want them to see that stuff. This is what happens on OS X without doing anything special. But if the behavior engendered by the patch below were the default, that would be fine too. Tom > On Sun, 14 Sep 2008, Tom 7 wrote: >> I'm trying to debug a problem with using mlton+mingw+SDL on windows. >> Everything works fine when I run my app from the mingw command line, but >> when I run it from the DOS prompt or by clicking it in explorer, it >> terminates immediately and silently. I spent some time whittling it down >> and it happens even when I'm not using SDL. >> >> The only difference is the mention of the 'print' function in dead code. My >> guess is that this causes some I/O part of the Basis to be included (But >> then not eliminated?), which creates some more initialization steps >> (binding to stdout, perhaps) that abort the program when run in the click >> environment rather than the mingw command line environment. >> >> Does this sound plausible? If so, what code should I look at? Or is there >> some simple fix? =) > > From the comments of Wesley, it does seem as though demanding the > initialization of TextIO is resulting in an uncaught exception, which would > normally be acknowledged via a message to stderr, but that apparently doesn't > exist. > > You might be able to make progress with your application as a whole using: > > Index: basis-library/posix/io.sml > =================================================================== > --- basis-library/posix/io.sml (revision 6853) > +++ basis-library/posix/io.sml (working copy) > @@ -182,7 +182,7 @@ > *) > local > val pos0 = Position.fromInt 0 > - fun isReg fd = FS.ST.isReg(FS.fstat fd) > + fun isReg fd = FS.ST.isReg(FS.fstat fd) handle _ => false > fun posFns (closed, fd) = > if (isReg fd) > then let > > [ NEW! : http://tom7.org/ ] [ OLD! : http://fonts.tom7.com/ ] From jhreppy at mac.com Wed Sep 24 07:46:16 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 07:47:06 2008 Subject: [MLton-user] trouble building from svn on Mac OS X Message-ID: I don't know if anyone else has seen this issue, but I'm not able to build mlton on Mac OS X from svn. The problem appears to be with using the MacPorts version of gmp. For example, when compiling gen-types.c, I get gcc -std=gnu99 -I. -Iplatform -fno-common -fvisibility=hidden -I/usr/ local/include -I/sw/include -I/opt/local/include -O2 -fomit-frame- pointer -falign-loops=2 -falign-jumps=2 -falign-functions=5 -pedantic -Wall -Wextra -Wformat=2 -Wswitch-default -Wswitch-enum - Wuninitialized -Winit-self -Wstrict-aliasing=2 -Wfloat-equal -Wundef - Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align - Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style- definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-field- initializers -Wmissing-noreturn -Wmissing-format-attribute -Wredundant- decls -Wnested-externs -Wlong-long -o gen/gen-types gen/gen-types.c util.o In file included from ./cenv.h:133, from gen/gen-types.c:8: /opt/local/include/gmp.h:1607: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1633: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1644: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1655: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1666: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1694: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1705: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1718: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1736: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1754: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1765: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1776: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:1786: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:2031: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:2044: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:2057: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:2070: warning: ?__gnu_inline__? attribute directive ignored /opt/local/include/gmp.h:2083: warning: ?__gnu_inline__? attribute directive ignored ld: duplicate symbol ___gmpz_abs in util.o and /var/folders/YK/ YK6vDQY7ELKqHvtySh6GIE+++TI/-Tmp-//cc3ACJb0.o collect2: ld returned 1 exit status make[2]: *** [gen/c-types.h] Error 1 I think that the duplicate symbols are caused by the the inline directive being ignored. I've filed a bugreport with MacPorts. - John From fluet at tti-c.org Wed Sep 24 08:11:17 2008 From: fluet at tti-c.org (Matthew Fluet) Date: Wed Sep 24 08:11:22 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: References: Message-ID: IIRC, gcc used to use the inline attribute in a way that deviated from the C99 standard. More recent versions of gcc follow the C99 standard. GMP used to have headers that relied on gcc's old inline behavior. But, the latest release of GMP has updated their headers to match the C99 behavior. So, it might depend on which release of gcc and GMP you are using. You could try adding -fgnu89-inline to the runtime C flags. On Wed, 24 Sep 2008, John Reppy wrote: > I don't know if anyone else has seen this issue, but I'm not able to build > mlton > on Mac OS X from svn. The problem appears to be with using the MacPorts > version > of gmp. For example, when compiling gen-types.c, I get > > gcc -std=gnu99 -I. -Iplatform -fno-common -fvisibility=hidden > -I/usr/local/include -I/sw/include -I/opt/local/include -O2 > -fomit-frame-pointer -falign-loops=2 -falign-jumps=2 -falign-functions=5 > -pedantic -Wall -Wextra -Wformat=2 -Wswitch-default -Wswitch-enum > -Wuninitialized -Winit-self -Wstrict-aliasing=2 -Wfloat-equal -Wundef > -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align > -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition > -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers > -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls > -Wnested-externs -Wlong-long -o gen/gen-types gen/gen-types.c util.o > In file included from ./cenv.h:133, > from gen/gen-types.c:8: > /opt/local/include/gmp.h:1607: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1633: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1644: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1655: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1666: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1694: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1705: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1718: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1736: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1754: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1765: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1776: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:1786: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:2031: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:2044: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:2057: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:2070: warning: ?__gnu_inline__? attribute directive > ignored > /opt/local/include/gmp.h:2083: warning: ?__gnu_inline__? attribute directive > ignored > ld: duplicate symbol ___gmpz_abs in util.o and > /var/folders/YK/YK6vDQY7ELKqHvtySh6GIE+++TI/-Tmp-//cc3ACJb0.o > collect2: ld returned 1 exit status > make[2]: *** [gen/c-types.h] Error 1 > > I think that the duplicate symbols are caused by the the inline directive > being ignored. > I've filed a bugreport with MacPorts. > > - John > > > _______________________________________________ > MLton-user mailing list > MLton-user@mlton.org > http://mlton.org/mailman/listinfo/mlton-user > From wesley at terpstra.ca Wed Sep 24 08:19:43 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Wed Sep 24 08:19:47 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: References: Message-ID: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> On Wed, Sep 24, 2008 at 4:46 PM, John Reppy wrote: > I don't know if anyone else has seen this issue, but I'm not able to build > mlton > on Mac OS X from svn. The problem appears to be with using the MacPorts > version > of gmp. I put a working universal binary build of gmp (ppc/intel 32/64) at this URL: http://www.dvs.tu-darmstadt.de/staff/terpstra/gmp-3.4.2-ub.tar.gz Just put the libraries in /usr/local/lib and the header in /usr/local/include. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080924/6712a57b/attachment.htm From jhreppy at mac.com Wed Sep 24 08:26:10 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 08:26:49 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: References: Message-ID: <6458CC34-2C8F-4632-93DF-F97AAD0E545C@mac.com> Unfortunately, Apple's version of gcc doesn't understand -fgnu89-inline. From the discussion at http://www.mail-archive.com/bug-gnulib@gnu.org/msg09743.html , it appears that Apple's compilers differ in subtle, but unfortunate, ways from the regular gcc on this issue. - John On Sep 24, 2008, at 4:11 PM, Matthew Fluet wrote: > > IIRC, gcc used to use the inline attribute in a way that deviated > from the C99 standard. More recent versions of gcc follow the C99 > standard. GMP used to have headers that relied on gcc's old inline > behavior. But, the latest release of GMP has updated their headers > to match the C99 behavior. > So, it might depend on which release of gcc and GMP you are using. > You could try adding -fgnu89-inline to the runtime C flags. From wesley at terpstra.ca Wed Sep 24 08:40:58 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Wed Sep 24 08:41:04 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> References: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> Message-ID: <162de7480809240840p517b67faqe26283f4bf13cc15@mail.gmail.com> On Wed, Sep 24, 2008 at 5:19 PM, Wesley W. Terpstra wrote: > I put a working universal binary build of gmp (ppc/intel 32/64) at this > URL: > http://www.dvs.tu-darmstadt.de/staff/terpstra/gmp-3.4.2-ub.tar.gz > By which I meant of course http://www.dvs.tu-darmstadt.de/staff/terpstra/gmp-4.2.2-ub.tar.gz *smacks forehead* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080924/0aa39f97/attachment.html From jhreppy at mac.com Wed Sep 24 12:34:44 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 12:35:30 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: <162de7480809240840p517b67faqe26283f4bf13cc15@mail.gmail.com> References: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> <162de7480809240840p517b67faqe26283f4bf13cc15@mail.gmail.com> Message-ID: <8B2D37F1-4E8E-453D-8BCF-311259C6D5CF@mac.com> Thanks. With that version of gmp (and a specifc reference to /usr/ local/include/gmp.h in cenv.h), the runtime builds. - John On Sep 24, 2008, at 4:40 PM, Wesley W. Terpstra wrote: > On Wed, Sep 24, 2008 at 5:19 PM, Wesley W. Terpstra > wrote: > I put a working universal binary build of gmp (ppc/intel 32/64) at > this URL: > http://www.dvs.tu-darmstadt.de/staff/terpstra/gmp-3.4.2-ub.tar.gz > By which I meant of course > http://www.dvs.tu-darmstadt.de/staff/terpstra/gmp-4.2.2-ub.tar.gz > *smacks forehead* From jhreppy at mac.com Wed Sep 24 13:38:13 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 13:38:59 2008 Subject: [MLton-user] bogus warning messages about scope annotations Message-ID: <061E7934-4A43-48AC-A4C4-CDE7DAD877DF@mac.com> Using a fresh version of mlton on Mac OS X, I'm getting messages of the form Warning: /Users/jhr/Work/ICFPContest08/sml3d/src/glut/glut.sml 413.28. Symbol 'glutCreateMenuCB' redeclared as external (previously public). This may cause linker errors. when the code at lines 412-413 is val exportCreateMenu = _export "glutCreateMenuCB" private cdecl : (int -> unit) -> unit; val glutCreateMenuCB = _address "glutCreateMenuCB" private : Ptr.t; I've tried various other annotations instead of private, but the message is consistent. In fact, it turns out that one can put any identifier as an annoation and still get the same message. E.g., val exportCreateMenu = _export "glutCreateMenuCB" bogus cdecl : (int -> unit) -> unit; val glutCreateMenuCB = _address "glutCreateMenuCB" bogus : Ptr.t; I did not get this warning on the r6841 version on my windows box at work. - John From wesley at terpstra.ca Wed Sep 24 18:16:02 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Wed Sep 24 18:16:04 2008 Subject: [MLton-user] bogus warning messages about scope annotations In-Reply-To: <061E7934-4A43-48AC-A4C4-CDE7DAD877DF@mac.com> References: <061E7934-4A43-48AC-A4C4-CDE7DAD877DF@mac.com> Message-ID: <162de7480809241816t5760ef9djbde9993e7b7a5921@mail.gmail.com> On Wed, Sep 24, 2008 at 10:38 PM, John Reppy wrote: > Using a fresh version of mlton on Mac OS X, I'm getting messages of the > form > > Warning: /Users/jhr/Work/ICFPContest08/sml3d/src/glut/glut.sml 413.28. > Symbol 'glutCreateMenuCB' redeclared as external (previously public). This > may cause linker errors. > > when the code at lines 412-413 is > > val exportCreateMenu = _export "glutCreateMenuCB" private cdecl : > (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" private : > Ptr.t; That's strange. I copy and pasted those lines to a file (replacing Ptr with MLton.Pointer) and saw no warnings. Can you please provide a complete source file which causes these warnings? > I've tried various other annotations instead of private, but the message is > consistent. In fact, it turns out that one can put any identifier as an > annoation and > still get the same message. E.g., > > val exportCreateMenu = _export "glutCreateMenuCB" bogus cdecl : > (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" bogus : Ptr.t; The default visibility is public for export and external for address. So that's not unexpected as bogus is invalid and didn't override the defaults. I assume you also got errors that 'bogus' was unrecognized in this case? I did not get this warning on the r6841 version on my windows box at work. > This check did not exist in r6841. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080925/e3a48515/attachment.htm From wesley at terpstra.ca Wed Sep 24 18:20:44 2008 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Wed Sep 24 18:20:46 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: <8B2D37F1-4E8E-453D-8BCF-311259C6D5CF@mac.com> References: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> <162de7480809240840p517b67faqe26283f4bf13cc15@mail.gmail.com> <8B2D37F1-4E8E-453D-8BCF-311259C6D5CF@mac.com> Message-ID: <162de7480809241820macf0d14m8193f3bd83e90e69@mail.gmail.com> On Wed, Sep 24, 2008 at 9:34 PM, John Reppy wrote: > Thanks. With that version of gmp (and a specifc reference to > /usr/local/include/gmp.h > in cenv.h), the runtime builds. I am surprised you needed to specify /usr/local/include; I don't. Do you have another gmp installed? It would be prudent to remove it. If a libgmp.dylib is loaded which doesn't match the header, you could experience odd behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton-user/attachments/20080925/ab6759fb/attachment.html From jhreppy at mac.com Wed Sep 24 23:02:16 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 23:03:15 2008 Subject: [MLton-user] trouble building from svn on Mac OS X In-Reply-To: <162de7480809241820macf0d14m8193f3bd83e90e69@mail.gmail.com> References: <162de7480809240819l196d2e9n46ac4d15e50d4a5f@mail.gmail.com> <162de7480809240840p517b67faqe26283f4bf13cc15@mail.gmail.com> <8B2D37F1-4E8E-453D-8BCF-311259C6D5CF@mac.com> <162de7480809241820macf0d14m8193f3bd83e90e69@mail.gmail.com> Message-ID: <2895252B-87A1-4E1E-88FA-9CD7D895B57C@mac.com> On Sep 25, 2008, at 2:20 AM, Wesley W. Terpstra wrote: > On Wed, Sep 24, 2008 at 9:34 PM, John Reppy wrote: > Thanks. With that version of gmp (and a specifc reference to /usr/ > local/include/gmp.h > in cenv.h), the runtime builds. > > I am surprised you needed to specify /usr/local/include; I don't. Do > you have another gmp installed? It would be prudent to remove it. If > a libgmp.dylib is loaded which doesn't match the header, you could > experience odd behaviour. I don't know if I needed the explicit path, but I wanted to make sure that it did not pick up the one from MacPorts that was causing the problem. - John From jhreppy at mac.com Wed Sep 24 23:06:34 2008 From: jhreppy at mac.com (John Reppy) Date: Wed Sep 24 23:07:09 2008 Subject: [MLton-user] bogus warning messages about scope annotations In-Reply-To: <162de7480809241816t5760ef9djbde9993e7b7a5921@mail.gmail.com> References: <061E7934-4A43-48AC-A4C4-CDE7DAD877DF@mac.com> <162de7480809241816t5760ef9djbde9993e7b7a5921@mail.gmail.com> Message-ID: <90212F13-EA6D-46A0-B41B-51AEFA8E8ED7@mac.com> On Sep 25, 2008, at 2:16 AM, Wesley W. Terpstra wrote: > On Wed, Sep 24, 2008 at 10:38 PM, John Reppy wrote: > Using a fresh version of mlton on Mac OS X, I'm getting messages of > the form > > Warning: /Users/jhr/Work/ICFPContest08/sml3d/src/glut/glut.sml 413.28. > Symbol 'glutCreateMenuCB' redeclared as external (previously > public). This may cause linker errors. > > when the code at lines 412-413 is > > val exportCreateMenu = _export "glutCreateMenuCB" private > cdecl : (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" > private : Ptr.t; > > That's strange. I copy and pasted those lines to a file (replacing > Ptr with MLton.Pointer) and saw no warnings. Can you please provide > a complete source file which causes these warnings? I'll see if I can reduce it to a small test case (the actual code is part of the SML3d library, which is a pretty big download). > > > I've tried various other annotations instead of private, but the > message is > consistent. In fact, it turns out that one can put any identifier > as an annoation and > still get the same message. E.g., > > val exportCreateMenu = _export "glutCreateMenuCB" bogus > cdecl : (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" bogus : > Ptr.t; > > The default visibility is public for export and external for > address. So that's not unexpected as bogus is invalid and didn't > override the defaults. I assume you also got errors that 'bogus' was > unrecognized in this case? Nope. No error message about "bogus", just the warning about linkage. > > > I did not get this warning on the r6841 version on my windows box at > work. > > This check did not exist in r6841. > From jhreppy at mac.com Thu Sep 25 01:09:32 2008 From: jhreppy at mac.com (John Reppy) Date: Thu Sep 25 01:10:08 2008 Subject: [MLton-user] bogus warning messages about scope annotations In-Reply-To: <162de7480809241816t5760ef9djbde9993e7b7a5921@mail.gmail.com> References: <061E7934-4A43-48AC-A4C4-CDE7DAD877DF@mac.com> <162de7480809241816t5760ef9djbde9993e7b7a5921@mail.gmail.com> Message-ID: Upon deeper digging, I realize that I was getting confused between two different copies of the source tree (I was editing one that had the annotations, while compiling the other). Sorry for the false alarm. - John On Sep 25, 2008, at 2:16 AM, Wesley W. Terpstra wrote: > On Wed, Sep 24, 2008 at 10:38 PM, John Reppy wrote: > Using a fresh version of mlton on Mac OS X, I'm getting messages of > the form > > Warning: /Users/jhr/Work/ICFPContest08/sml3d/src/glut/glut.sml 413.28. > Symbol 'glutCreateMenuCB' redeclared as external (previously > public). This may cause linker errors. > > when the code at lines 412-413 is > > val exportCreateMenu = _export "glutCreateMenuCB" private > cdecl : (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" > private : Ptr.t; > > That's strange. I copy and pasted those lines to a file (replacing > Ptr with MLton.Pointer) and saw no warnings. Can you please provide > a complete source file which causes these warnings? > > I've tried various other annotations instead of private, but the > message is > consistent. In fact, it turns out that one can put any identifier > as an annoation and > still get the same message. E.g., > > val exportCreateMenu = _export "glutCreateMenuCB" bogus > cdecl : (int -> unit) -> unit; > val glutCreateMenuCB = _address "glutCreateMenuCB" bogus : > Ptr.t; > > The default visibility is public for export and external for > address. So that's not unexpected as bogus is invalid and didn't > override the defaults. I assume you also got errors that 'bogus' was > unrecognized in this case? > > I did not get this warning on the r6841 version on my windows box at > work. > > This check did not exist in r6841. >