Re: [Haskell-cafe] MonadPrompt + Gtk2Hs = ?

On Sun, 2008-01-13 at 16:37 -0200, Felipe Lessa wrote:

On Jan 13, 2008 4:01 PM, Duncan Coutts 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