A long-term goal is to refactor the code into a portable layer, a layer which can be ported (i.e., a maze of ifdefs) and a machine-dependent layer. I'm not sure when I'll get to that - work, my current ffi hacking and some personal stuff are consuming all my time.
sounds familiar, and I've got to admit that the ffi part sounds more interesting;-)
and <dream>HOpenGL works with all Haskell implementations</dream>, perhaps HGL could be ported to HOpenGL - to eliminate all further portability issues (missing features under X, etc.)..
I think the basic HGL API would work on a lot of platforms. I don't know enough about HOpenGL to be sure but I think it's easier to implement HGL on than X11 or Win32 were.
I'm not sure how to parse this, but the idea was that OpenGL is already available (and hardware-supported) on many platforms (www.opengl.org), and that it is the most likely route for more advanced graphics hackers. So an HGL as a learner's 2d interface to the full thing might be interesting in itself, but it should also permit to merge the x11/win32/whatever branches into a single one.. (modulo some minor infelicities, of course)
That sounds like my experience of the hslibs tree - once it has been assimilated it is really hard to use it in isolation.
The file Win32Dialogue.gc does genuinely seem to be missing something - but it sounds like you had more problems than just that.
Yep indeed. One was easy to fix - my win98 laptop had an old version of ghc-5.02.. after upgrading to 5.02.3, the effects here are now similar to what happens on the win2k system (only that instead of a full-screen titlebar, I get more-than-full-screen windows), so I had another look. The size problem is traceable to window creation (GraphicsWND.hs: createWND), where there is a call to adjustWindowRect in calcSize - adding a print there gives sensible values from within hugs, and large-valued nonsense from within ghc-compiled executables. So there is something fishy going on with ghc's win32 binding (which is where adjustWindowRect seems to reside, even though simple "hello world"-style programs still work fine. Which seemed to remind me of an earlier thread, and sure enough, in March, Hal Daume complained about just the same problem with HGL, GHC, Windows, and the outcome was that there is a bug in greencard's ffi target, which you set out to fix, recommending the use of the ghc target in the meantime: http://haskell.org/pipermail/glasgow-haskell-bugs/2002-March/002269.html In light of this, ghc's win32 ought to be re-greencarded anyway (once greencard's ffi target is fixed for ghc, which seems to be in progress:), before the next release, no? By fiddling with your makefile a bit, I managed to re-greencard, but now the cvs-makefile (which I managed to convince that I don't want a separate GHC_INPLACE/GHC_PKG_INPLACE, and that I don't want to update my package config, even if my ghc-pkg had such an option..) tries to split objects into a non-existing directory, and sure enough, if I create that directory, that step works fine, but the next one looks for the split objects in another directory.. and with fptools makefiles, it is not at all straightforward for me to tell where the problem is, let alone what it is:-( the effect is that the assembler complains that it can't generate .o files in StdDIS/, say, whereas the files should really go into StdDIS_split/ instead, methinks.. Could someone with more fptools-experience than myself please have a look at hslibs/win32 and its Makefiles, and preferably re-generate the Haskell sources in there from the .{gc,pgc} files in win32/gc-src, using a debugged greencard (changing to the ghc target is probably not a good idea for a cvs depot used by non-ghc folks as well;-).
This will gain momentum once Hugs switches over to using the new hierarchial libraries.
And that will gain momentum once Hugs switches over to the new FFI.
As an old fan of hugs, I'm glad that it keeps up with developments!-) Claus