S J Thompson
Can anyone help? I would like to run a program using the Haskell Graphics Library under GHC on Windows. HGL is listed as a package (when ghc is asked about its packages) but not actually distributed as a package with ghc-5.02.3. On trying to remedy this, - I am able to compile HGL by hand on windows, but on executing the HelloWorld.hs the program hangs: nothing happens. - HGL doesn't appear to compile on unix (solaris). I'd be grateful for any feedback.
As far as I can see, none of the replies so far answered Simon's Win32 question, so I had quick look: - Alastair suggested using a different green card target, but no user green-carding seems needed in the win32 case -- the win32 binding comes with ghc, and the win32 graphics sources don't seem to include green card input (no .gc, .gc.in, only .hs) - using ghc --make, compilation is no (big) problem but graphics-2.0.4.src.tar.gz and SOE.msi's graphics are out of synch - running examples compiled against minimally modified graphics-2.0.4 win32 sources just blocks - running examples compiled against SOE.msi's graphics win32 sources kind of works sometimes (although that may not be obvious), but more often it produces odd effects, not at all in line with the Hugs behaviour for the same sources - 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?) It seems that others started to look into this some 6 months ago, which is why the SOE version is slightly more successful, but no further progress is recorded in CVS. Has anyone succeeded in removing the remaining quirks? Claus PS. Some more details (win2k/cygwin, if that matters): The file graphics-2.0.4.src.tar.gz from the X11 section at http://haskell.org/graphics/downloading.html includes both x11 and win32 directories, but the win32-branch is out of synch (modifications to get it to compile with ghc on win32 are relatively straightforward, but then the resulting executable just hangs, so there must be some less obvious changes missing). The main Hugs98 download page at http://cvs.haskell.org/Hugs/pages/downloading.htm links to the graphics-bundle, but also provides an SOE bundle (SOE.msi), which includes a graphics bundle (also available separately). Again, the graphics bundle includes both x11 and win32 branches, but in this version, the win32 branch compiles without further changes. The resulting executables produce titlebars (full screen width) instead of windows as default, but double-clicking on the title bars unfolds a (full-screen) window, and some simple examples seem to run more or less okay (often less:-(. Here are two trivial examples: import GraphicsUtils main = runGraphics $ do w <- openWindow "testing" (200,200) drawInWindow w $ text (100,100) "1,2,3" getKey w closeWindow w The window size is ignored (full-screen titlebar effect), and after a keypress, the window closes, but the executable has to be stopped by ctrl-c. With a slight modification, main = runGraphics $ do w <- openWindow "testing" (200,200) drawInWindow w $ text (100,100) "1,2,3" drawInWindow w $ polygon [(50,50),(100,100),(50,100)] getKey w closeWindow w we get: $ a.out Uncaught Error: Polygon: Not enough storage is available to process this command. (error code: 8) Both examples run just fine with Hugs on win32, using the same win32 branch of the same graphics bundle. This may indicate differences in the win32 bindings themselves? The CVS pages (how do I find the latest location of stuff in there, btw? is there a libraries version of HGL?) at http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/graphics/lib/win32/... list some changes by Sigbjorn, suggesting that Simon was not the first to run into these problems: "Misc changes to have it *compile* with ghc-5.02.1 (but not exec correctly). Based on patches contrib'ed by Frank Dellaert." PPS. Things are starting to get hard to find. Compiling a list of all locations of various graphics variants on {www,cvs}.haskell.org is left as an exercise.. :-(
Thanks for looking at this Claus.
- 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.)] I believe they're the same. More likely is a difference in the concurrency models of Hugs and GHC. To make the X11 code work with Hugs we had to: 1) Add a call to yield in the event loop. lib/x11/GraphicsWindows.hs(line 360): loop = do -- We yield at this point because we're (potentially) -- about to block so we should give other threads a chance -- to run.
yield ws <- readMVar wnds if (null ws) then return () else do handleEvent loop
It looks as though this fix is part of the Win32 version. (lib/win32/GraphicsWND.hs(line 124)) There is the possibility that yield does something different on GHC than it does on Hugs. On Hugs, yield guarantees not to run this thread until all other threads do one of: block terminate yield This guarantee is required if you're going to write producer-consumer style threads if the producer can possibly block waiting for input (such as Window events). But this shouldn't be needed because of the way that GHC does ccalls - running them in fresh threads, etc. Unless.... unless... GHC is making 'unsafe' ccalls instead of 'safe' ones. Is GreenCard being invoked with the --safe-code flag? 2) Fix a race condition between the code that detects when there's no more windows to service and the code that creates windows: lib/x11/GraphicsWindows.hs(line 142): -- HN 2001-01-30 -- There is a race condition here since the event loop terminates if it -- encounters an empty window list (in the global, imperative, variable -- wnds). Thus, if m has not yet opened a window (assuming it will!) -- when the event_loop is entered, it will exit immediately. -- Solution: wait until either the window list is non-empty, or until -- m exits (in case it does not open a window for some reason). mDone <- newIORef False forkIO (catchErrors m `finally` writeIORef mDone True) let loop = do yield ws <- readMVar wnds d <- readIORef mDone if not (null ws) then main_eloop display else if not d then loop else return () It looks as though this fix is part of the Win32 version. (If I recall correctly, it was there from day 1) (lib/win32/GraphicsWindows.hs(line 83))
It seems that others started to look into this some 6 months ago, which is why the SOE version is slightly more successful, but no further progress is recorded in CVS. Has anyone succeeded in removing the remaining quirks?
I thought we had it working back in April 2001. I clearly remember it running on Unix and _thought_ that we'd run it on Win32 too. I guess I could be mistaken about the latter. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (2)
-
Alastair Reid -
C.Reinke