--------------------------- Two suggestions for CVS maintainers: 1. we could make better use of the cvs.haskell.org home page: - add a link to the cvs-web interface proper - add an overview of what is where in the cvs tree (probably best generated automatically from brief description text files in each of the major cvs directories) - add a link to ghc build guide (which has more complete how to use this cvs info, and more info about the structure) - add a link to ghc commentary and - add a link to cvs.haskell.org from the top of www.haskell.org/libraries/ 2. introduce parts of hslibs as cvs modules (see cvs(5), so that one can say "cd fptools; cvs co win32" and get all the relevant subdirectories and tools. The current suggestion, to do "cd fptools; cvs co hslibs/win32" will only give the win32 subdirectory of hslibs, but not necessarily all files that are needed to do a make there.. ---------------------------
Anyway, is there a useable win32 green card input package hanging around somewhere (the link to glasgow is dead it seems; CVS has moved the gc-sources aside and has never been very modular - is there a way for me to take the win32/gc-src/ directory from CVS and make it, without having to prepare the various other parts of fptools that fptools-Makefiles tend to depend on so merrily?-(.
I have no idea how to do it. GreenCard I can do (details attached) but building Win32 for GHC is beyond me.
GreenCard is no problem - there's that nice installer, and since there is no HOpenGL without GreenCard so far, I had to install GreenCard anyway;-) Unless there have been relevant changes that would force me to use the cvs version?
Shouldn't all those IORefs (e.g., for the list of windows) be MVars in the GHC version?
We did that for the X11 version -
Ok, I tried that change - no difference.
I guess the Win32 version has fallen behind.
Yet in other aspects, the SOE version is ahead.. Would it be possible to resynch the various versions? Or, even better: once the various ffi implementations have settled down to the latest spec, 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.).. Personally, I think I'll try to stick with HOpenGL for both 3d and 2d, but for teaching purposes, there would need to be a simple interface, a la HGL, and it would have to work with Hugs as well. But having to switch interfaces when moving from hugs to ghc would keep students from doing that. So perhaps we need to keep HGL!-)
What really needs done though is to introduce a single semaphore to control all access to all parts of the HGL data structures - atomically accessing each part of the data structures doesn't necessarily protect all the system invariants.
I'll leave that to others:)
For a start, what about NoInline pragmas for global IORefs?
Yes, that should be done.
Tried that as well - no difference (at least not at this stage, that is, but both the MVars and the pragmas look like the right thing to do overall). Btw, you use yield before a potentially blocking call - would the latter run into the problems (default-configured) ghc has with blocking foreign calls (see multithreading support in the ghc commentary)? Probably not, because it works with Hugs, which has only non-preemptive concurrency, but I thought I'd better ask.. Or is this what you referred to with GreenCard's safecode?
(Hmmm, maybe we should push harder on a portable language extension for defining global, mutable, monomorphic IORefs.)
The current hack kind of seems to work, yet discourages wide useage - the problem with a language extension is that noone has suggested a good solution yet, and noone wants to freeze a hack into the language (parameterised modules would be my personal favourite, even though that's not quite as "convenient" as the current hack).
--safe-code a try. But why doesn't the green card input use %safecode to eliminate that potential error source?-)
Because I wrote the Win32 bindings for Hugs where %safecode and %code mean the same thing. Really, GreenCard should be changed so that %code is safe by default and you have to write %unsafecode to get the faster version. (That's the way it is in the ffi.)
Either change looks like a straightforward substitution?
And how would cross-ffi garbage-collection issues affect window parameters at startup?
Not sure what you mean - I can't think of any new issues in GC which aren't present in Hugs.
I was just trying to understand what safecode does, and the GreenCard docs say it's about foreign code that might trigger GCs. Which is allright, but at startup (when the window size parameters are ignored) there shouldn't be any GCs, so the question was how the lack of safecode is supposed to cause the effects I see.
Anyway, is there a useable win32 green card input package hanging around somewhere (the link to glasgow is dead it seems; CVS has moved the gc-sources aside and has never been very modular - is there a way for me to take the win32/gc-src/ directory from CVS and make it, without having to prepare the various other parts of fptools that fptools-Makefiles tend to depend on so merrily?-(.
I'm attaching a crudely hacked up version of hugs.mk which generates the necessary .hs files.
Thanks, that should help - I'll try it next week. I had all kinds of problems with the CVS makefile, not only that it doesn't like to be used in isolation, but complaints about missing files in the win32 package itself, which seems rather unlikely (perhaps a side-effect of the cross-CVS dependencies?). Also, I'm quite confused about the current CVS structure - I'm looking in fptools/hslibs, but shouldn't all that have moved into the new libraries somewhere? My win98 system here at home has even more problems (apart from a full disk, or taking ages to configure stuff I haven't even checked out of cvs..) than the win2k box: when trying to compile the snowflake example with ghc5.02 and SOE graphics, I get a linker error - about a missing Win32Window_dfQU .. So I won't be back on the problem before Tuesday, I guess. Claus