Thanks for looking at this Claus.
no problem - I'm kind of nearby, and I'm not promising anything (unless just looking at it is going to help;-).
- the full-screen titlebar effect with the SOE variant suggests some window-handling incompatibility, if it wasn't for Hugs and GHC using the same graphics source code.. (is there a difference in the win32 bindings for Hugs vs GHC?)
[This mail got rather long. My best guess is that yield on GHC doesn't yield as thoroughly as on Hugs and that the Win32 library isn't being greencarded with the --safe-code flag. (Either by itself would probably be fine, it's having both at once that is probably killing you.)]
According to the docs, yield does as yield should, and the unix version (ghc/hgl/X) seems to work.. Btw, while looking at code with scheduling-related issues in mind, other questions appeared to me: Shouldn't all those IORefs (e.g., for the list of windows) be MVars in the GHC version? For a start, what about NoInline pragmas for global IORefs? But, at least on unix, these don't seem to be the problem.. Unless there are any other suggestions, I could give the green card --safe-code a try. But why doesn't the green card input use %safecode to eliminate that potential error source?-) And how would cross-ffi garbage-collection issues affect window parameters at startup? 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?-(. Alternatively, is anyone out there using ghc's win32 binding? Presumably, that kind of problem would show up in other uses. Claus PS. Is there a way to get system call traces on windows/cygwin?
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 - I guess the Win32 version has fallen behind. 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.
For a start, what about NoInline pragmas for global IORefs?
Yes, that should be done. (Hmmm, maybe we should push harder on a portable language extension for defining global, mutable, monomorphic IORefs.)
Unless there are any other suggestions, I could give the green card --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.)
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.
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. To invoke it: cd hslibs/win32 rm *.hs *stub* make -f hugs.mk GC="green-card --target=ghc" GCDIR=../../green-card GC_INCLUDES="--include-dir ../../green-card/lib/ghc" gen_hss -k It will fail when building Win32Dialogue.hs hence the use of -k. I looked at this just long enough to persuade myself that there was no easy fix (apart from deleting gc-src/Win32Dialogue.gc) but that the error was harmless (Win32.hs doesn't import Win32Dialogue). I could have changed the file further to set the target and greencard directories more quietly - but maybe you want to change the target (ffi?) or use a different greencard so it seemed easier to specify them on the command line. I have not tried compiling the generated files - my windows machine isn't used to being used for development and needs a bit of sweet-talking before it's willing to contemplate the idea. You'll need a different Makefile to compile the generated files - the compilation stuff that's there at the moment is for use with Hugs/GreenCard not GHC/FFI or GHC/GreenCard. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk http://www.reid-consulting-uk.ltd.uk/alastair/ ################################################################ # Makefile for Win32 library # # This Makefile only works with GNUMake. If you feel like supplying # us with a more portable Makefile, we'll be happy to distribute it # as well. ################################################################ # This goes first to make it the default default : all # All generated C files #include errors.h to get consistent error messages $(DLLS) : errors.h GUILIBS = kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib comctl32.lib winmm.lib advapi32.lib # Describe how your system is configured here ROOT = $(HOME) HUGSDIR = $(ROOT)/hugs GCDIR = $(ROOT)/fptools/green-card RUNHUGS = $(ROOT)/hugs/runhugs CPP = gcc -P -E -x c -traditional # GC = $(ROOT)/green-card.exe --target Hugs GC = $(RUNHUGS) -F"$(CPP)" -h1m $(GCDIR)/src/GreenCard.lhs --target Hugs GC_INCLUDES = --include-dir $(GCDIR)/lib/hugs GCPP_FLAGS = -DTARGET_HUGS # Where to find GreenCard.h - in the Hugs source code INCLUDES = -i $(HUGSDIR)/src ################################################################ # Explicit dependencies ################################################################ Win32Window.dll: WndProc.c ################################################################ # Standard rules from here on ################################################################ RAW_GCS = $(wildcard gc-src/*.gc) GCS = $(notdir $(RAW_GCS)) DLLS = $(addsuffix .dll, $(basename $(GCS))) GEN_HSS = $(addsuffix .hs, $(basename $(GCS))) GEN_CFILES = $(addsuffix .c, $(basename $(GCS))) gen_hss: $(GCS) $(GEN_HSS) all: gen_hss $(DLLS) .SUFFIXES : .SUFFIXES : .pgc .gc .hs .dll .c %.gc : gc-src/%.gc $(CPP) $(GCPP_FLAGS) $< | perl -pe 's#\\n#\n#g' >$*.gc %.hs %.c : %.gc $(CPP) $(GCPP_FLAGS) $< | perl -pe 's#\\n#\n#g' >$*.gc $(GC) $(GC_INCLUDES) -i . $*.gc %.dll : %.c cl /nologo /LD /MD $(INCLUDES) $(GUILIBS) $(GCPP_FLAGS) -DSTRICT -o $@ $*.c %.obj : %.c cl /nologo $(INCLUDES) $(GCPP_FLAGS) -DSTRICT -o $@ $*.c # Cleanliness is next to dependencies clean : rm -f *.obj *.exp *.lib rm -f *.hi rm -f $(GEN_CFILES) $(GEN_HSS) $(DLLS) # Dependencies $(GCS) : $(PGCS) depends.mk :: perl mkGCDep *.gc >depends.mk include depends.mk ################################################################ # End of Makefile ################################################################
--------------------------- 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
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?
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.
Or, even better: once the various ffi implementations have settled down to the latest spec,
The CVS copy of Hugs implements the current spec. (But works only on Linux and (perhaps) Windows) at the moment and has a habit of changing critical details of how you use it every other day at the moment...)
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.
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:)
I see it as part of a complete rewrite of the system - adding preemptive concurrency to a cooperatively-threaded program is very hard to get right.
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)?
The way HGL works is that an event comes in, triggers a lot of work which eventually terminates, and then we block for another event. The idea of the yield is to make sure that all other work has terminated before we make that blocking call to get the next event.
Or is this what you referred to with GreenCard's safecode?
Looking a bit harder at it, it seems I was a bit confused... The ffi distinguishes 3 levels of safety: unsafe = not reentrant, only calls RTS system calls from a very restricted list (e.g., freeHaskellFunPtr should be on that list) safe = can call arbitrary foreign exported functions which, in turn might cause a garbage collection to happen (which is what you refer to later) threadsafe = safe but may invoke a blocking function so has to run on a separate thread. I think GreenCard's %safecode generates safe ffi calls. I'm not sure if GreenCard can generate trheadsafe calls. And I have no idea what threadsafe should mean for Hugs - I could throw a call to yield into the translation and hope that is enough (but, in general, it is not).
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.
Sorry. That was me confusing safe with threadsafe.
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?).
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.
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?
The new library structure is a work in progress - it'll move over eventually. 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. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
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
sounds familiar, and I've got to admit that the ffi part sounds more interesting;-)
I think I did the interesting part about a year and a half ago when I first wrote an ffi-like system. I'm now contemplating how to make the configure system automagically detect how to build shared object files and the interest level has fallen off considerably :-)
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)
What I meant by platform was: - some sort of library for drawing graphics (win32, X11, postscript, HOpenGL, etc.) - some sort of library for creating drawing regions (windows, boxes inside TCL/Tk widgets, texture maps, GIF files, fresh sheets of paper in printer, etc.) - (optional?) some sort of library for getting input (I vaguely remember being told that OpenGL doesn't directly support that - but could be mistaken). HGL's role is to present this platform in a uniform way and to take care of any buffering of output, redrawing of freshly exposed windows, allocation of colours, etc. It'd be cool if supporting HOpenGL let us get rid of the Win32 and X11-specific versions at the moment.
The size problem is traceable to [Greencard's ffi code generation]
The problem seems to be present in the current repository. Hmmm, I distinctly remember tracking this down and fixing it but it doesn't look like I committed the change - I'll check in the morning.
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?
Well I'll fix it for Hugs and trust GHC to conform to the ffi spec.
As an old fan of hugs, I'm glad that it keeps up with developments!-)
I guess I'm sentimentally attached to Hugs but I like the fact that it's so portable and trivial to install. I also think it's good to have multiple Haskell implementations around. Plus, it's easy to hack on Hugs. Quite a few GHC features first appeared in Hugs (TREX, imprecise exception handling, implicit parameters, mudo, GreenCard version 1, constructor classes, zip comprehensions (does GHC have those yet?), ...) Incompatibilities have tended to set in because the design gets improved in being ported to GHC and the Hugs hackers are slow to see the light. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk http://www.reid-consulting-uk.ltd.uk/alastair/
Claus:
The size problem is traceable to [Greencard's ffi code generation]
Alastair:
The problem seems to be present in the current repository.
Hmmm, I distinctly remember tracking this down and fixing it but it doesn't look like I committed the change - I'll check in the morning.
I took a look at this and found that Sigbjorn had fixed it some months ago - but I was using it wrong. Building GDITypes with this command: green-card --target=ffi -i. --include-dir ../../green-card/lib/ghc -i . GDITypes.gc (Very important to use the ghc directory here ^^^) generates correct code for prim_RGB (the problem Hal Daume ran into). and for Win32Window.adjustWindowRect If you use ../../green-card/lib/hugs on the command line, you'll get incorrect code. This hasn't been affecting Hugs up till now because the ffi target didn't work with Hugs anyway. I'm hoping we'll be able to merge the GHC and Hugs versions of StdDIS.gc into a single FFI version. -- Alastair
participants (3)
-
Alastair Reid -
C.Reinke -
Claus Reinke