GHCI hangs on Gtk2HS SOE on Windows, but GHC works fine?
I'm learning Haskell using Paul Hudak's book SOE. I'm using GHC 6.6 under Windows XP. GHC on Windows does not seem to come with HGL (is this correct?), so I used Gtk2HS, which contains a SOE implementation. I noticed that most programs hang when using GHCI, but they work fine with GHC. For example, the following mini program: import Graphics.SOE.Gtk main = runGraphics (openWindow "Stuck" (300,300) >>= closeWindow) completely hangs GHCI when running 'main', but using the GHC-created executable, a window correctly pops up and closes immediately, nicely returning to the command prompt. As GHCI is easier for experimenting, it would be nice if this worked. Thanks, Peter
On Fri, 2007-06-15 at 23:15 +0200, bf3@telenet.be wrote:
I'm learning Haskell using Paul Hudak's book SOE.
I'm using GHC 6.6 under Windows XP.
GHC on Windows does not seem to come with HGL (is this correct?), so I used Gtk2HS, which contains a SOE implementation.
I noticed that most programs hang when using GHCI, but they work fine with GHC.
It's not GHCi's fault as such. The reason it does not work well in GHCi at the moment is a bit technical. The Gtk2Hs SOE implementation currently uses Haskell threads. Like most GUI toolkits, Gtk+ is single threaded and requires special attention to use it from multiple OS threads. Currently, by default, GHC produces executables that use the single-threaded runtime system, and this works fine with multiple Haskell threads because they get multiplexed on the same OS thread. GHC can however produce executables that use the multi-threaded runtime system and ghci.exe itself is such a program. So when you use SOE with GHCi it's actually using multiple threads to access Gtk+ an not in a safe way, so it goes wrong in a myriad of ways. I'll take another look at trying to make the SOE stuff work with the threaded runtime system by using the primitives Gtk2Hs provides to use Gtk+ safely from multiple threads. Duncan
participants (2)
-
bf3＠telenet.be -
Duncan Coutts