Hi, On 10.01.2012, at 19:05, Dave Tapley wrote:
I'm working on a dev branch of wxHaskell [1] and one of the new features is that you can use wxHaskell in GHCi (again), but I seem to have broken something in the process: Firstly: wxHaskell works in GHCi insomuch as: You can load the hello world sample [2] in GHCi, do "> main", see the window spawn, close it and be returned to the GHCi prompt.
What I'm interested in is the case where you call wxHaskell's start function [3] from GHCi. The result is becoming stuck with no way back to the GHCi prompt without resorting to sending kill signals.
I made a screen cast to illustrate my findings [4]: 1. Once you've done "> start $ return ()" you can press ^C all you want, there's no way back to the GHCi prompt. 2. If you send three (less has no effect) kills to the GHCi process it will exit, but it will exit GHCi as well (instead of putting you back at the GHCi prompt). 3. If you do "> start $ return ()" but *do not* try and ^C, you can send a single kill to GHCi and be returned to the GHCi prompt.
My questions: 1. Why doesn't GHCi respond to the ^C? 2a. Why does entering ^C from within GHCi then prevent you from getting back to the GHCi prompt? 2b. Why doesn't any other input (i.e. entering anything but ^C) cause this behaviour? 3. If you have sent ^C from GHCi, why do you then have to kill three times to get out of GHCi?
Feel free to pull the repo [1] and try it out, you'll need the latest dev release of wxWidgets [5] installed.
I didn't try to reproduce your problem, but are you aware of the -fno-ghci-sandbox flag? E.g. it helps with GLUT based programs on OS X. Cheers, Jean