- Reactive - Haskell.org

Version conflicts despite hiding
by Patai Gergely 17 Dec '08

17 Dec '08

Hello all, I have a little problem I haven't run into yet. I'm not sure if it's Reactive related, but that's what caused it for me, so I'm writing here. I managed to run Tetris.hs with reactive-0.10.3 and reactive-glut-0.1.4 with success (also observing the problems mentioned by Claus Reinke). Now I ran an update, and ghc -v says the following as expected: hiding package reactive-0.10.3 to avoid conflict with later version reactive-0.10.5 hiding package reactive-glut-0.1.4 to avoid conflict with later version reactive-glut-0.1.6 However, when I try to compile Tetris or load it into ghci, it says that it can't match 'UI' (expected) with 'reactive-glut-0.1.4:FRP.Reactive.GLUT.UI.UI' (inferred) in dropPiece, and I've no idea where it is getting the latter from. There are no leftover .hi files or anything else in reach. Is reactive-fieldtrip a possible culprit? Gergely -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

4 5

Fw: [Haskell-cafe] Re: Threads not running under GHC 6.10?
by Robin Green 17 Dec '08

17 Dec '08

This would appear to present a problem for unamb... Begin forwarded message: Date: Wed, 17 Dec 2008 13:05:48 +0000 From: Simon Marlow <marlowsd(a)gmail.com> To: Gwern Branwen <gwern0(a)gmail.com> Cc: Haskell Cafe <haskell-cafe(a)haskell.org> Subject: [Haskell-cafe] Re: Threads not running under GHC 6.10? Gwern Branwen wrote: > On Mon, Dec 15, 2008 at 9:00 AM, Simon Marlow wrote: >> This particular example illustrates a bug in 6.10.1 that we've since >> fixed: >> >> http://hackage.haskell.org/trac/ghc/ticket/2783 > > OK, that's good... > >> However in general you can still write expressions that don't >> allocate anything (e.g. nfib 1000), and your watchdog thread won't >> get a chance to run unless there's a spare CPU available (+RTS -N2). >> >> Cheers, >> Simon > > But that's bad. What are my options here? Will this > threads-not-running issue be fixed in the next release? Since it > worked fine in 6.8 as far as I could tell, that makes me think that it > must not be anything completely fundamental and unfixable. I'm afraid the underlying problem is one that GHC has always had - that we can't preempt threads that aren't allocating. It's not easily fixable, we would have to inject dummy heap checks into every non-allocating loop, which would seriously hurt performance for those tight loops. In general you can't rely on being able to kill a thread; however, this only applies to compiled code, interpreted code should always be preemptable, even if it isn't allocating. Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

event merge problem?
by Conal Elliott 17 Dec '08

17 Dec '08

> > 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 :(. I'm trying to understand what the problem is here. I think the not-yet-known values are all wrapped with a NoBound and so should pass right by the MaxBound pattern matches without blocking. - Conal On Tue, Dec 16, 2008 at 2:56 AM, Thomas Davie <tom.davie(a)gmail.com> wrote: > > 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

3 5

reactive-0.10.4 and reactive-glut-0.1.5
by Conal Elliott 17 Dec '08

17 Dec '08

I just released reactive-0.10.4 and reactive-glut-0.1.5. Highlights: * Improving values: QuickCheck tests, before and after functions, non-default max method. * makeEvent now yields (sink,event) instead of (event,sink). This new order is Functor-friendlier. And perhaps Arrow-friendly as well. If you've written an adapter, you'll probably have to tweak it, as I did for reactive-glut-0.1.5. * Added Reactive.Internal.Chan, which is a copy of Control.Concurrent.Chan, but with a new function weakChanWriter. The point for data consumers to keep data producers alive. I'll pitch weakChanWriter for inclusion in Control.Concurrent.Chan. * Internal.TVal: plug space leak for external inputs (I think), using weakChanWriter. Added getChanStream, which is like getChanContents, but makes a stream. * Added dependency on the Stream package. * PrimReactive: futureStreamE, using a refutable pattern, which may help laziness. Added some snapshot variants, commented out. - Conal

2 2

Stars - a simple reactive simulation with an alternative Reactive implementation
by Jules Bean 16 Dec '08

16 Dec '08

Hi, I've just uploaded the results of my tinkering with Reactive-style FRP to http://roobarb.jellybean.co.uk/~jules/stars.4.tgz It should compile with ghc 6.8 or 6.6 and presumably also 6.10. I recommend the command-line: ghc -threaded -O2 --make stars.hs It doesn't have any library dependencies outside of extralibs (opengl et al). It's not very interactive but you can do the following: * mouseover the planets to see a price list * mouseover a ship to see what it's carrying * PgUp/PgDn to zoom in/out * click on a ship (not the easiest thing in the world with the speed they move at) to switch to a view which centers on the ship. My goals on writing this code were to exhibit various different kinds of discrete and continuous behaviour as a serious test on how the framework holds together. All kinds of stuff is displayed around the edges of the screen so you can see stuff changing or not changing. The "simulated universe" evolves at fixed rate based on a ticking timer. Two and a half ticks per second. The frame rate is completely independent of that, and is capped at around 60fps by virtue of a 16ms timer, although I make no attempt to keep it smooth. I suspect it's fairly vicious on your CPU; it runs OK for me on a 2Ghz C2D. The actual displayed location of the ships is "tweened" between the last and next 'tick' for smooth movement, the percentage of 'tween' is shown in the top-left. MouseMotion events from GLUT update the world-coordinate mouse position which enables the mouseover code for ships and planets. There is a known bug that when the camera is constantly moving (i.e. you click on a ship) the world-coords need constantly updating but they aren't until next time you move the mouse. The behaviour which says "camera follows the selected ship if there is one and stands still if not" requires 'feedback' from one phase to the next. This would be a classic use of a recursive snapshot, but since I can't get that working I implemented a non-recursive "switcherFold". The implementation of Reactive is not conal's, but my own. It takes a very different approach at the low level: eschewing the notion of a 'blocking pure value' which makes me slightly uncomfortable, I explicitly mark possibly blocking stuff with IO, giving an explicitly IO implementation of Future. However, this isn't exposed at the user level: the user-level combinators follow conal's very closely, with just a few differences here and there where I didn't see something and came up with my own alternative. My main motivation for writing my own implementation was learning, but now I've done so it's quite interesting to examine the different design choices. I had quite a few space leaks to track down, which I did with GHC's heap profiling. Mostly I found -hT (which doesn't even need profiling compilation) and -hc useful, but try all of them. One space leak I couldn't fix properly and had to hack was in shipclicks; in the end I have added in an artificial ticker to properly progress, more of which in another email perhaps. Another spaceleak, in shipclicks'' required "cojoinB", which provides pre-aged behaviours to use (via snapshot or <*>) in closures; naive use of a Behaviour in a closure holds onto the head of the Behaviour forever. There are still some minor space leaks, but they are very minor in comparison to the big ones I fixed. I will track them down in due course. It might be only the "history" leak which is commented. Oh, I should say the code is really ugly. Sorry about that. One of the bits of code I have finally uploaded as a result of this is 'FunctionalTexture' which is a setup for two dimensional procedurally rendered textures in the style of POVray - turbulence, marbles, layering, that kind of thing. I just use it to make the planets look slightly more interesting but it's capable of much more. Jules

2 1

Re: [reactive] Re: Re: Link to Tetris
by Thomas Davie 16 Dec '08

16 Dec '08

On 16 Dec 2008, at 12:35, Claus Reinke wrote: >> 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. > > hmm, I can find various bits of code that *test* for MaxBound, but > are there actually any bits that *deliver* MaxBound? Yes, listEG [] for example. > Anyway, if I > understand this part correctly, then testing for MaxBound shouldn't > be privileged this way: just as the actual merge looks for the first > of 'u' or 'v' to arrive, so checking, say, 'u' for MaxBound should > be a check on the first of 'u' and some artificial 'now' (left- > biased, so that 'u's MaxBound has a chance to come through, but with > an immediately available alternative 'now', so that the whole test > doesn't block if 'u' isn't available yet). Yep, absolutely, the problem is that such a test that also checks for the MaxBound is very hard to implement in Haskell. My thoughts at the moment include 1) using unamb to check for MaxBound, but this doesn't guarentee to squash the leak, only makes it likely. 2) Use some new ghc primitive along the lines of unsafeIsInWHNF :: a -> IO Bool to check whether I can find out if u or v is MaxBound yet. Tom Davie

1 0

Link to Tetris
by Creighton Hogg 16 Dec '08

16 Dec '08

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.

4 7

Some simple but full examples
by Paul Sujkov 14 Dec '08

14 Dec '08

Hi everybody, I'm pretty new to the Reactive library, but I see it very useful; currently trying to get to work simple clock examples from http://netsuperbrain.com/blog, but can't find any simple examples of the full reactive control flow :( serfing this mail list gives little help too (or maybe I just can't search well). I mean, can somebody give a code snippet with the event (atTime 5 would be enough), the sink (simple IO, or the sound bell call, or anything observable at all) - I hope I understand the sink as an event handler correctly - and a main function call that fires the event. Just need a full example with an observable effect to start with Sorry for a bit silly question, but anyway I think that a full example of that kind would be a good start point for beginners. Thank you Regards, Paul Sujkov

3 2

Changed argument orders for snapshot etc
by Conal Elliott 09 Dec '08

09 Dec '08

I swapped the argument order for snapshot and a few other functions. For instance, -- old type snapshot :: Event a -> Behavior b -> Event (a,b) -- new type snapshot :: Behavior b -> Event a -> Event (a,b) So that 'snapshot b' is an event transformer. This change makes other operations work out nicely when partially applied. Take careful note of the argument and result orders. I'm not sure what's most memorable. I've kept to the convention that the additional info is in the second half of the result. Also a bit odd: snapshotWith :: (a -> b -> c) -> Behavior b -> Event a -> Event c The complete list of argument-swappedfns: snap, snapshot, snapshot_, snapRemainderE, splitE (watch out). Libraries affected: reactive, reactive-glut, reactive-fieldtrip. - Conal

2 2

Status of Reactive "feedback" (recursive integral, etc)
by Peter Verswyvelen 06 Dec '08

06 Dec '08

This has been brought up before, but I'm not sure about the current status our consensus regarding "recursive feedback" in Reactive. In Yampa this is solved by the ArrowLoop instance, and by having two different integral functions: one with a delay and without a delay. If I understood it correctly, it Conal's aim to provide just a single integral function that can handle both the recursive and regular cases? But, is this even possible? A nice example of this is David's "boingee" example: a ball on the screen gets dragged towards the current mouse position. Mathematically, this is vb(t) = s * ( pm(t) - pb(t) ) pb(t) = pb0 + integral [0..t] vb(t) where pb(t) is the position of the ball at time t pb0 is the initial position of the ball at time t=0, pm(t) is the position of the mouse at time t s is some arbitrary scale factor Of course this is not really realistic but it is a simple example of recursive feedback: pb(t) depends on vb(t) and vice versa. Can we make such behaviors with Reactive?

3 8