http://code.haskell.org/~wchogg/Tetris.hs Conal told me how to host the files on code.haskell.org, so now the following link will work as well.
BTW, you can also host darcs repos under your home dir, e.g., under a 'code'
directory, as dons does. Nice if you have multiple source files and a
.cabal file but don't want to wait for an official code.haskell.org project
to be set up. You can later request a full project later if you want better
support, like multiple committers, trac, wiki, mailing list.
2008/11/17 Creighton Hogg
http://code.haskell.org/~wchogg/Tetris.hshttp://code.haskell.org/%7Ewchogg/Tetris.hs
Conal told me how to host the files on code.haskell.org, so now the following link will work as well.
_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
Having just managed to install reactive et al with 6.11.20081215 (windows, glut), I wanted to try the example posted here earlier:
I had to flip a call to snapshot_, then it built, with a warning: $ ghc --make Tetris.hs [1 of 1] Compiling Main ( Tetris.hs, Tetris.o ) Tetris.hs:59:12: Warning: Defaulting the following constraint(s) to type `Integer' `Integral t' arising from a use of `levelToTicks' at Tetris.hs:59:12-25 In the expression: levelToTicks 1 In the definition of `testTicks': testTicks = levelToTicks 1 Linking Tetris.exe ... But when I try to run it, it exits immediately, without any message or window, let alone any animations.. Any suggestions? I just tried building and running one of my old FunWorlds examples with the same ghc, and that works fine, so my OpenGL/GLUT setup seems to be ok. Claus
http://code.haskell.org/~wchogg/Tetris.hs But when I try to run it, it exits immediately, without any message or window, let alone any animations..
That seems to be an issue when starting from within cygwin's bash. Starting from cmd, or by double-clicking, works. Since I don't have this issue with other OpenGL code, it must be built into reactive somewhere? The result appears very sluggish: when I do nothing, the ticks don't seem to come evenly, and when I try to move pieces, keyboard input and movement are out of sync by the second piece, with reactions happening very late (perhaps for the next piece instead of the current one), or seemingly not at all. I assume that is not an expected feature?-) This is on a 2Ghz single-core laptop running windows/xp, with ghc 6.11.20081215. Claus
http://code.haskell.org/~wchogg/Tetris.hs But when I try to run it, it exits immediately, without any message or window, let alone any animations..
That seems to be an issue when starting from within cygwin's bash. Starting from cmd, or by double-clicking, works. Since I don't have this issue with other OpenGL code, it must be built into reactive somewhere?
The result appears very sluggish: when I do nothing, the ticks don't seem to come evenly, and when I try to move pieces, keyboard input and movement are out of sync by the second piece, with reactions happening very late (perhaps for the next piece instead of the current one), or seemingly not at all. I assume that is not an expected feature?-)
Seems to be partially timer- and partially event-merge-related: if I compile with -threaded, the pieces do not move at all on their own, but as long as I keep pressing "down", the game appears playable as intended; if I compile without -threaded, the pieces move occasionally, but the effects of keyboard input are entirely unpredictable. Any advice? Claus
On 16 Dec 2008, at 11:36, Claus Reinke wrote:
http://code.haskell.org/~wchogg/Tetris.hs But when I try to run it, it exits immediately, without any message or window, let alone any animations..
That seems to be an issue when starting from within cygwin's bash. Starting from cmd, or by double-clicking, works. Since I don't have this issue with other OpenGL code, it must be built into reactive somewhere?
The result appears very sluggish: when I do nothing, the ticks don't seem to come evenly, and when I try to move pieces, keyboard input and movement are out of sync by the second piece, with reactions happening very late (perhaps for the next piece instead of the current one), or seemingly not at all. I assume that is not an expected feature?-)
Seems to be partially timer- and partially event-merge-related: if I compile with -threaded, the pieces do not move at all on their own, but as long as I keep pressing "down", the game appears playable as intended; if I compile without -threaded, the pieces move occasionally, but the effects of keyboard input are entirely unpredictable.
I've noticed this behavior in since the last couple of days, So at a guess a bug got introduced somewhere along the line. The merge issue is known -- at the moment, an occurrence doesn't appear in the output until it's known whether or not the other event ever occurs, which isn't ideal. Unfortunately, the obvious fix for the issue creates a large memory leak, I've been playing with a few ways to fix this. Tom Davie
Seems to be partially timer- and partially event-merge-related: if I compile with -threaded, the pieces do not move at all on their own, but as long as I keep pressing "down", the game appears playable as intended; if I compile without -threaded, the pieces move occasionally, but the effects of keyboard input are entirely unpredictable.
I've noticed this behavior in since the last couple of days, So at a guess a bug got introduced somewhere along the line. The merge issue is known -- at the moment, an occurrence doesn't appear in the output until it's known whether or not the other event ever occurs, which isn't ideal. Unfortunately, the obvious fix for the issue creates a large memory leak, I've been playing with a few ways to fix this.
Thanks for the info, Tom, where can I find more details about this merge issue? Given that FRPLs are traditionally synchronously concurrent languages, this is rather surprising: when sampling anything, one knows about everything's values _now_, which should be sufficient for merge, no matter whether the other event might or might not happen later. Claus
On 16 Dec 2008, at 11:50, Claus Reinke wrote:
Seems to be partially timer- and partially event-merge-related: if I compile with -threaded, the pieces do not move at all on their own, but as long as I keep pressing "down", the game appears playable as intended; if I compile without -threaded, the pieces move occasionally, but the effects of keyboard input are entirely unpredictable.
I've noticed this behavior in since the last couple of days, So at a guess a bug got introduced somewhere along the line. The merge issue is known -- at the moment, an occurrence doesn't appear in the output until it's known whether or not the other event ever occurs, which isn't ideal. Unfortunately, the obvious fix for the issue creates a large memory leak, I've been playing with a few ways to fix this.
Thanks for the info, Tom,
where can I find more details about this merge issue? Given that FRPLs are traditionally synchronously concurrent languages, this is rather surprising: when sampling anything, one knows about everything's values _now_, which should be sufficient for merge, no matter whether the other event might or might not happen later.
Yes indeed. The issue is that if you know one of the events will never happen again, what you want to do is stop merging, and throw the never-occurring event in the bin. Unfortunately, to pattern match against the never occurring event then blocks checking whether the match works or not :(. The particular interesting bit of code is in PrimReactive.hs (Conal's comments here): -- | Merge two 'Future' streams into one. merge :: Ord t => Binop (FutureG t (ReactiveG t a)) -- The following two lines seem to be too strict and are causing -- reactive to lock up. I.e. the time argument of one of these -- must have been _|_, so when we pattern match against it, we -- block. -- -- On the other hand, they patch a massive space leak in filterE. Perhaps -- there's an unamb solution. Future (Max MaxBound,_) `merge` v = v u `merge` Future (Max MaxBound,_) = u u `merge` v = (inFutR (`merge` v) <$> u) `mappend` (inFutR (u `merge`) <$> v) -- What's going on in this 'merge' definition? Try two different -- future paths. If u arrives before v (or simultaneously), then -- begin as u begins and then merge v with the rest of u. Otherwise, -- begin as v begins and then merge u with the rest of v. Because of -- the left-bias, make sure u fragments are always the first argument -- to merge and v fragments are always the second. Bob
participants (4)
-
Claus Reinke -
Conal Elliott -
Creighton Hogg -
Thomas Davie