- Reactive - Haskell.org

First steps in FRP
by Álvaro García Pérez 08 Jun '09

08 Jun '09

Hello, I'm new to FRP and I'm trying to write a simple program adapting the events to IO. I've read the tutorial "Introducing Reactive: Events" but it's not very clear how to do it. Can someone send me an example? I would like to capture events from IO (let's say, keyboard strokes) and print text in the console. I'm using the last version of the reactive package. Thanks, Alvaro.

1 1

Re: [reactive] Bug fixes in progress
by Svein Ove Aas 03 Jun '09

03 Jun '09

I can agree to this phrasing, but I don't think it's perfect yet. Specifically, it doesn't explicitly explain how unsafePerformIO code is paused; it only mentions pausing in respect to pure code, while it is arguably reasonable to expect unsafePerformIO to behave differently. Fix that, and I'd sign off on the patch if I were in charge. :) On Wed, Jun 3, 2009 at 1:34 AM, Bertram Felgenhauer <int-e(a)gmx.de> wrote: > Conal Elliott wrote: >> I've pushed Svein's patch, plus some small tweaks of my own, to the darcs >> repo at http://code.haskell.org/unamb . Comments, please. I have a pretty >> tenuous grip on this block/unblock/retry stuff. > > I think the code is fine. > > | -- Exception handling in unsafePerformIO does not happen like you're > | -- used to in normal code. Specifically: > > This is not really true. Exception handling is the same whether > unsafePerformIO is involved or not. The real point, I think, is that > normal IO code will never be executed more than once with the same > RealWorld# token, and never be called from pure code, so that you do > not have to think about the difference between asynchronous and > synchronous exceptions at all. > > I've tried to rephrase the comment below. (I can submit a patch if > we agree that this is an improvement.) > >>>> > restartingUnsafePerformIO :: IO a -> a > restartingUnsafePerformIO = unsafePerformIO . retry > where > -- We rely heavily on implementation details of GHC's exception handling > -- in the code below. Specificially: > -- > -- * If a thread catches an asynchronous exception, the stack is unwound > -- until the first exception handler is found. All pending updates > -- are turned into thunks that recreate the stack and continue the > -- computation where it is aborted. This is done so that pure > -- computations can be interrupted and later resumed when the > -- corresponding value is demanded another time. In other words, > -- the currently running computation is paused. This also works > -- for unsafePerformIO, and that's what we exploit below. > -- * If a thread throws a normal (synchronous) exception, e.g. throw, > -- throwIO, error (including pattern match failures), etc., then > -- all pending updates will instead be turned into thunks that > -- re-throw the same exception again. This is done for performance > -- reasons, but it would make our unsafePerformIO unrestartable. > -- So we have to avoid using throw or throwIO below. > -- > -- To make a whole IO action restartable, we catch any exceptions > -- thrown by it (which typically indicate that the thread was killed > -- in the case of 'unamb'), and use an asynchronous exception to set > -- up a paused computation that runs the IO action again. > -- > -- Incidentally, all exception handlers run inside an implicit block, and > -- blocking operations contain an implicit unblock. This ensures that any > -- further pending exceptions won't mess this scheme up, as they can't be > -- delivered until after throwTo has been called. > -- > retry :: IO a -> IO a > retry act = > act `catch` \ (SomeException e) -> do > myThreadId >>= flip throwTo e > unblock $ retry act > <<< > > regards, > > Bertram > -- Svein Ove Aas

1 0

Bug fixes in progress
by Svein Ove Aas 31 May '09

31 May '09

Certain people (*cough*quicksilver*cough*) thought it'd be nice of me to inform you of what I've been up to the last few days re: reactive bug-fixing, so here's an update. - I've rewritten unamb, fixing all the issues I've managed to find (relating to nested unamb invocations, mostly) and having it throw a BothBottom exception if both values are a finite bottom. - Written an IsEvaluated library (now on hackage) that might speed up unamb a bit. The code to use it is in place, but disabled; I don't trust it to be bug-free yet. - Rewritten makeEvent (from reactive legacy-adapters) to take advantage of finalizers. It will now produce finite events instead of deadlocking. I'm now trying to fix the joinE/>>=/mappend problems, but that might take a while. Meanwhile, more eyes on the rewritten code is better, so I've attached it; there hasn't been an official release yet. -- Svein Ove Aas

5 11

Reactive and GTK- Events 'backing up'
by Mark Wassell 06 May '09

06 May '09

Hi, I am having a little problem with the reactive/gtk example I am writing. See http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3718 In summary, combining two events ee1 and ee2 only gives me output when the trigger for ee2 is initiated. However when ee2 is initiated all of the previously backed up output for ee1 is output at that point. ee1 - Combining the event when start button pressed with the event for text entered into text box 1 with the event for text entered into text box 2 and then doing fmap putStrLn over each event. ee2 - Event that prints out contents of text boxes when the start button is pressed. This uses the events for the text boxes that have been turned into behaviours. Is reusing events to turn them into behaviours and then combining them with the original event permitted and/or going to work? Cheers Mark

1 0

Re: [reactive] Feedback on my first Reactive program: Monad Laws
by Freddie Manners 30 Mar '09

30 Mar '09

Digging around with the commented query -- that a "pure (string)" is getting delayed -- I've hit a rather fundamental problem: it seems Event doesn't obey the Monad laws. I don't know whether this is a known issue or whether I'm being plain stupid, but this:-- module Main where import FRP.Reactive import FRP.Reactive.LegacyAdapters import Control.Concurrent import Control.Applicative import Control.Monad import Data.Monoid import Data.Maybe main = do clock <- makeClock (sink, evnt) <- makeEvent clock forkIO . sequence_ $ repeat (getLine >>= sink) adaptE . fmap putStrLn $ (pure "A Line!" `mappend` evnt) -- adaptE . fmap putStrLn $ (pure "A Line!" `mappend` (evnt >>= return)) and the same with the penultimate line commented instead of the last, appear to have different behaviours: in the version shown, "A Line!" is printed when the program starts; and in the other, this is delayed until after the first line is read (but before it is printed). Should this happen? Freddie Manners 2009/3/29 Mads Lindstrøm <mads_lindstroem(a)yahoo.dk> > Hi > > As part of studying the Reactive library, I have created a simple game. > The object of the game is to guess a number. > > As I am a newbie with respect to FRP, I assume that my game could have > been implemented more elegantly. Comments are most welcome. > > The game can be found here > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3037#a3037 and it is > attached. > > > Greetings, > > Mads Lindstrøm > > > _______________________________________________ > Reactive mailing list > Reactive(a)haskell.org > http://www.haskell.org/mailman/listinfo/reactive > >

3 4

Missing key-events and scanlB
by Mads Lindstrøm 29 Mar '09

29 Mar '09

Hi I am trying to make a Behavior, which contains the last pressed key and the distance the mouse traveled since the key was pressed. I programmed this function: charAndRelativeMousePos :: Anim (Maybe (Char, (Double, Double))) charAndRelativeMousePos u = scanlB (\r _ -> r) (pure Nothing) (snapshotWith char (mousePosition u) (keyAction u)) where char (_, Char ch) m = (\newMouse -> Just (ch, newMouse - m)) <$> mousePosition u char _ _ = pure Nothing Unfortunately it is not working. If I move the mouse before pressing a key, then it takes a long time before recognizing the first key-press. And it only recognizes the first key-press, never the second, nor third, ... What am I doing wrong ? I think maybe it has something to do me using "mousePosition u" twice. Am I hanging on to tons of mouse-position, due to the second use of mousePosistion ? A complete program using the charAndRelativeMousePos function can be seen here http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3062#a3062 . Greetings, Mads Lindstrøm

1 0

Feedback on my first Reactive program
by Mads Lindstrøm 29 Mar '09

29 Mar '09

Hi As part of studying the Reactive library, I have created a simple game. The object of the game is to guess a number. As I am a newbie with respect to FRP, I assume that my game could have been implemented more elegantly. Comments are most welcome. The game can be found here http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3037#a3037 and it is attached. Greetings, Mads Lindstrøm

1 0

crayon - a 2D opengl curve renderer, with Reactive animations
by Jules Bean 27 Mar '09

27 Mar '09

Hi, I have just uploaded another little proof-of-concept reactive toy. http://roobarb.jellybean.co.uk/~jules/crayon.8.tgz The important part is the beginnings of an OpenGL accelerated 2D rendering engine, for rendering parametric curves and in particular bezier curves. The way it works at the moment is: * A sampling step tries to adaptively generate points on the curve to approximate it as a polygon. This is done on the CPU, isn't as clever as it could be, but turns out to be not the bottleneck right now * For stroked regions, this is 'thickened' out to a stroke using difference-based approximations to a tangent. This works well for smooth curves but poorly at end points and sharp corners. For filled regions the GLU tessellator is used to convert it to GL primitives, normally triangles. * Then this is rendered by openGL in either immediate mode or using VAs. Currently the sampling and GLU tessellation can be cached and not redone every frame, if the appropriate part of the structure doesn't change each frame. You need to use standard GHC sharing to make this work - define constant picture fragments at a high enough scope that they get shared. The stroke generation is not cached and this turns out to be pretty expensive. You may need to compile with -fno-state-hack to get proper sharing (GHC "issue"/bug). I discovered a bug in the HOpenGL GLU binding. I don't think this demo tickles the bug so it should run on a standard build, details of that bug on the hopengl list. The immediate mode renderer turns out to be faster than the VA based renderer, at least for these small demos. I think that's because the extra pass over the data structure (to generate the VAs) is a relatively high cost, the number of vertices is small, and I'm not smart about sharing vertices. I then plugged all this into Reactive and set up three simple animations - some spinning flowers, some business-like charts, and a classic pong game. You can switch between them using your left + right arrows keys, and they spin in + out using a simple animation, whilst their own animations continue independently. Exactly the kind of thing Reactive is supposed to make easy! The framerate is artificially limited to save battery life when developing. As before, this code uses my incomplete Reactive implementation not Conal's; it should be easy to port although I think some of my primitives have slightly different names. I'm not going to work on this code for a bit, but I have in mind various possible extensions, including using the GPU to do some of the heavy lifting, using a fragment shader to support gradients and other kinds of procedural texturing, supporting implicit curves as well as parametric ones. I'm interested in any thoughts on how to design a useful attractive combinator library for 2D graphics. The real target is to have something fast enough to make an expressive library for complex smooth animations, e.g. 2D games. Jules

7 12

Can we do without delayed switching?
by Patai Gergely 26 Mar '09

26 Mar '09

Hi everyone, I feel this should be very simple to do, but I can't find a way to describe the movement of the ball in a breakout game. What do you think, how should it be modelled? My idea was to define a vector-valued behaviour for the position of the ball, and an event that fires on collisions and carries information about them. I believe such an event is necessary if I am to add sound to the program, for instance, and it feels natural to me anyway. The ball position behaviour is then defined as a stepper in terms of this event. Now the problem is that the event is defined in terms of the ball position among other things. At the moment this leads to a <<loop>>, no matter how I try to approach the problem. This is not too surprising, since I can't really think of a way to define the event other than filtering some kind of clock tick (e.g. framePass) using whenE. Please tell me if there are other, fundamentally different alternatives. After thinking about this for a while, I feel that Reactive really needs delayed semantics for switching, at least optionally. Otherwise I don't see how we could possibly avoid looping, since the event must be generated assuming that the behaviour continues without switching. Such an alternative reality doesn't fit in the semantic domain of time functions, but an infinitesimal delay looks like a possible solution that resolves the dependency loop. Using delayed constructs always felt clumsy in Yampa too, but loops need special attention... Another thought I had for a moment was defining some kind of intermediate semantic domain, where behaviours are represented as a _list_ of time functions (with or without intervals provided), which would somehow give access to pre- and post-switching behaviours (like 'head' and 'tail') through some mid-level combinators. But I don't see how that could be made elegant on the application level, and it doesn't seem to achieve anything the delayed switch can't do for us. What do you think? Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are

6 7

Monads in Event streams
by Freddie Manners 24 Mar '09

24 Mar '09

I've been worrying about what happens when monads end up caught inside an Event stream, as they inevitably do. Usually this is the IO monad, & usually it's not a problem because adaptE deals with Event (IO a) types eventually. But look at the following (contrived) example: I read lots of people's mail. I have a load of buttons which add a person's mail to the set I receive, summarised by: addPerson :: Event Person I want an event of all the mail I get. Given: getMail :: Person -> Event Mail I can do: allMail :: Event Mail allMail = addPerson >>= getMail But realistically, I might have to create a new event for each person, or look the event up in a database or something. Then I have only: getMailM :: Person -> IO (Event Mail) So, fmap getMailM addPerson :: Event (IO (Event Mail)) and there is no longer a function (like "join" above) for getting an Event Mail, an Event (IO Mail), an IO (Event Mail) or even an IO (Event (IO Mail)) out of that as things stand. Given a clock, I could do something like:-- undoIO :: Clock t -> Event (IO a) -> IO (Event a) undoIO c e = do (sink, e') <- makeEvent c forkIO $ adaptE (>>= sink) e return e' But having a clock lying around seems wrong; and I'd ideally like the new Event to be simultaneous with the old one (provided getMailM finishes quickly). I could also do this an old-fashioned way by passing around event sinks; but again that's not really in the spirit. Also, these fixes will only stand a chance with IO (or ST, maybe); what if getMailM :: Person -> State Foo (Event Mail) ? So, can a function be constructed with the desired type (say Event (m (Event a)) -> m (Event a)), or is that unreasonable to expect? Is there a (generalizable) alternative way of doing this example which doesn't require one? This seems a natural thing to want to do. Freddie Manners

3 3