[Haskell-cafe] MonadPrompt + Gtk2Hs = ?

[Duncan Coutts]

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>
> wrote:
> > 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.
> [snip]
> > 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
> forkIO/forkOS.

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.

Weirder.

> 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
> and 
> > 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
slowness.

> 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.

Duncan