[Haskell-cafe] MonadPrompt + Gtk2Hs = ?
duncan.coutts at worc.ox.ac.uk
Sun Jan 13 14:48:54 EST 2008
On Sun, 2008-01-13 at 16:37 -0200, Felipe Lessa wrote:
> On Jan 13, 2008 4:01 PM, Duncan Coutts <duncan.coutts at worc.ox.ac.uk>
> > On Sun, 2008-01-13 at 14:53 -0200, Felipe Lessa wrote:
> > Are you linking using -threaded or not? If not then you need another
> > trick to use cooperative scheduling between Gtk and the RTS.
> > You must not be using -threaded then I'm guessing. That'd solve the
> > problem.
> Actually I tried with all combinations of -threaded/not -threaded and
Use forkIO not forkOS.
> I'm using an uniprocessor, but a simple turn-based game shouldn't
> depend on dual-cores anyway =). Yes, those freezes do seem rather
> strange, and when I introduced some (unsafePerformIO . putStrLn) with
> the wall time they magically disappeared.
> I didn't try to pursue those little insects further because I got the
> feeling that no mather what, they would come back.
Is this unix or windows btw?
> > > [...] using 'mainIteraction' [...]
> > That's pretty ugly. I'd avoid that if I were you.
> Yes. =)
> > Here's my suggestion: use two threads. One thread for the game logic
> > one thread for communicating with the user interface.
> It seems to be a nice idea. I worry about intermediate states that
> shouldn't be observable (in my game the inputs the user is allowed to
> give change over the time -- it's a board game, so which pieces can
> move vary according to the current board), but what concerns me more
> after that bad experience with only one forked thread are the delays
> between the user giving an input ( e.g. moving a piece) and the
> feedback being given (an animation of the result). The chain would be
> something like
> input given --> processed --> new board created --> shown
> (1) (2) (3) (4)
> So the interaction between the threads would be
> gtk: (1) ===\ /===> (4)
> channel: \===\ /===/
> runPromptM: \===> (2) ===> (3) ===/
That should be fine. Haskell thread are quite sufficiently fast. The
delays you're seeing are not because of general thread implementation
> I'll try to code that ASAP and see how everything works together. If I
> do observe the same delay problem, I'll try to at least reproduce it
> on another machine and maybe create a simple test case.
Good plan. If you're using -threaded make sure you really only ever call
gui methods from event callbacks or within postGUISync/Async or things
will go wrong in various random ways. In fact it might be a better idea
to use the cooperative scheduling trick and make sure it works with the
single threaded rts.
> Other than that, I'm surprised you didn't comment about the last
> solution, as that's where I'm currently heading. =)
Oh sorry, I didn't get that far :-)
It looks like it works a lot nicer so go with it :-).
Remember, in general it is possible to switch between the console IO
style where you're in control and the GUI event inversion of control
style system. It's the thread/event duality thing.
More information about the Haskell-Cafe