- Reactive - Haskell.org

First draft of reactive-tetris
by Creighton Hogg 20 Nov '08

20 Nov '08

Hey Reactive, Since I have no hosting space I'm actually going to include the implementation as an attachment all in one file. It's not very long anyway, so it should be alright. A few caveats: This code is still _really_ ugly, but it does work as far as I've tested There is no game over, you need to quit manually There is no score or level adjustment yet. I need to add that when I have more time, i.e. after this week That being said, my first real reactive program was surprisingly simple once I got comfortable with the semantics. The actual reactive code isn't that complicated, but it did take a pretty big shift in thinking from writing explicit game loops. I've included a good bit of comments so it hopefully it isn't too hard to follow, but if there are any questions about why I did something a particular way (the answer may be 'I'm dumb') please e-mail me or find me on #haskell.

7 20

Representation Details of Events
by David Sankel 20 Nov '08

20 Nov '08

Consider these two events: a = [] b = [(+infty, _|_)] Semantically, a and b are different values. Consider their representations in reactive: a = Event (Future ((Max MaxBound), (_|_))) b = Event (Future ((Max MaxBound), (_|_ `Stepper` a)))) At the end of an event, the second element of the future tuple is bottom. Conversely, the second element of the future tuple is never bottom when not at the end of an event. There's no particular point to this post, just musing on my discovery of the above facts. -- David Sankel Sankel Software

1 1

Small network-y example
by Creighton Hogg 19 Nov '08

19 Nov '08

This is very much a work in progress, but I thought I'd share it with the class and see if there are any suggestions. My ultimate goal is to figure out how to make a small MUD with Reactive. So this is my second attempt at figuring out how we can make an adapter for network communication. At the moment the idea is that you can provide a function of signature String -> [Handle] -> IO () to the function adapt and you'll get back an IO () suitable for your main loop. > {-# OPTIONS_GHC -Wall #-} > > module Main where > > import Control.Concurrent > import Control.Monad > import FRP.Reactive > import FRP.Reactive.Internal.Reactive (runE) > import FRP.Reactive.Internal.Timing > import FRP.Reactive.Improving > import FRP.Reactive.LegacyAdapters > import Network > import System.IO > > pushMessage' :: [Handle] -> String -> IO () > pushMessage' hs s = mapM_ (flip hPutStrLn s) hs > > pushMessage :: Behavior [Handle] -> Event String -> Event Action > pushMessage b e = fmap (\(s,hs) -> mapM_ (flip hPutStrLn s) hs) $ snapshot e b > > messageHandler :: Handle -> Sink String -> IO () > messageHandler h = (hGetLine h >>=) > > adapt :: (Behavior [Handle] -> Event String -> Event Action) -> IO () > adapt f = do > c <- makeClock > (messageE,msgSink) <- makeEvent c > connectE <- socketServer c msgSink > let handles = accumB [] (fmap (:) connectE) > runE (sleepPast (cGetTime c) . exact) $ f handles messageE > > main :: IO () > main = adapt pushMessage > > socketServer :: Clock TimeT -> Sink String -> IO (Event Handle) > socketServer c msgSink = withSocketsDo $ do > (event,sink) <- makeEvent c > socket <- listenOn (PortNumber 5000) > forkIO $ forever $ acceptConnection socket sink msgSink > return event > > acceptConnection :: Socket -> Sink Handle -> Sink String -> IO ThreadId > acceptConnection s handleSink msgSink = do > (h,_,_) <- accept s > hSetBuffering h NoBuffering > handleSink h > forkIO $ forever $ messageHandler h msgSink There are a few caveats here, though, in that I haven't yet figured out how to handle errors or the closing of handles. In a perfect world, in which I am much smarter than I actually am, we'd have a properly captured notion of disconnect events of type Event Handle that I can combine via something like accumB [] $ (fmap (:) connectE) `mappend` (fmap delete disconnectE) The problem I have is that I'm not sure yet how to generate the disconnect events. Cheers, Creighton

2 1

Google group for the mailing list
by eyal.lotem＠gmail.com 19 Nov '08

19 Nov '08

You might prefer to use the http://groups.google.com/group/reactive-haskell/ URL to read the reactive mailing list, or to post messages. It does the archiving for you, and lets you post via a web form.

1 0

More recursive fun
by Creighton Hogg 18 Nov '08

18 Nov '08

So in the interest of simplifying the recursive integral problem as much as possible, to make it a bit more tractable, I've come up with another recursive Behavior definition that I think should work if the current implementation of integral is expected to work. I'd just like to get an opinion on that to see if it's a test case I should try digging harder into. As I said, I _think_ that this should work iff the current definition of integral should work but if that's not true, please let me know. My reasoning is that this should be the equivalent of using integral with an event stream that has a constant difference of 1. Thanks, Creighton myIntegral :: Event a -> Behavior Double -> Behavior Double myIntegral e b = let e' = snapshot_ e b in sumB e' x :: Event () -> Behavior Double x e = let b =myIntegral' e b in b events :: Event () events = atTimes [0.1,0.2] schedule a = threadDelay 100000 >> a main = do c <- makeClock u <- mkUpdater (cGetTime c) (fmap print $ x events) forever $ schedule u

2 1

Composable adapters and multiple event sources
by pierre 14 Nov '08

14 Nov '08

Hello, I'm trying to write simple GTK2hs adapter using new reactive library. However, I've ran into some issues there: 1. All of the adapters i've seen come with static "primitive signals", like FRP.Reactive.GLUT.Adapter.UI. But this doesn't seem to be applicable to UIs like "UI loaded from glade file" because it's impossible to create all signals in advance -- you should be able to create them with functions like: mkButton :: Glade -> String -> IO (Event ()) but that doesn't seem to fit well into FRP.Reactive.LegacyAdapters interface. 2. Is stacking of multiple adapters possible? In my view it's essential feature for many applications, GUI network clients, for example. Best wishes and thanks in advance, -- pierre

3 4

Curious crash
by Creighton Hogg 13 Nov '08

13 Nov '08

So below is something I discovered that seems very strange. If you run the following code as is, it will run & you'll get stuck in the already documented integral loop. If you replace the use of events in main with events', the program consumes all available memory & locks up hard. I know I'm horribly abusing Reactive here, but I don't see why it should fail _so_ ungracefully. Cheers, Creighton import FRP.Reactive import FRP.Reactive.LegacyAdapters import Control.Concurrent import Control.Monad x :: Event () -> Behavior Double x e = b where b = integral e b events :: Event () events = atTimes [0.1,0.2] events' :: Event () events' = once events schedule a = threadDelay 100000 >> a main = do c <- makeClock u <- mkUpdater (cGetTime c) (fmap print $ x events) forever $ schedule u

2 1

Subtle weirdness with lplace demo
by David Sankel 12 Nov '08

12 Nov '08

When I run the lplace demo in reactive-fieldtrip, I get two different responses to a certain input. Input: press the mouse down, hold current position for a couple seconds, then move the mouse while down. Response 1: Two new tori display when the mouse is pressed. Response 2: Two new tori display when the mouse is moved after the press. I get response 2 about 2/3 of the time. I wonder if this is connected to ticket 2 (http://trac.haskell.org/reactive/ticket/2) since it has this delayed response. conal, can you reproduce this on your linux machine? David -- David Sankel Sankel Software

2 1

reactive-fieldtrip
by Eyal Lotem 11 Nov '08

11 Nov '08

Hi I would also like to congratulate Conal and everyone else involved in the Reactive framework and libraries for the new release. Amazing work! I have finally managed to do more than read about it, and actually toy with some Reactive programming :-) It seems great fun, and the learning curve is not as steep as it might seem at first. I mostly played with Test.hs inside the reactive-fieldtrip adapter, and I have encountered a few issues: A. It seems that when changing spinningG to scale according to time, it becomes extremely slow very quickly. B. The lplace demo itself is also extremely slow, whereas other demos seem to be fine/quick. It might be buggy, and not extremely slow, its taking so long to react that I am not sure what is happening. C. Stylistic question/comment: The (Anim a) type (UI -> Behavior a) is a Reader Functor/Applicative/Monad. I see it used as a Functor in various examples, but it seems that there's no use of the Applicative/Monad of the reader, is this intentional? I find it a bit awkward that it passes the "env" arg to all of the stuff its combining... The example even used an undefined error value in place of the env in some cases, suggesting that it is a burden to pass it around. Why not encourage the implicit passing of the env everywhere via the reader Applicative? Eyal

1 0

Laziness and IO adapters
by Sasha Rush 11 Nov '08

11 Nov '08

Tried putting this on "Introducing Reactive: Events." But was having commenting issues. I wanted to make the BellMachines actually work with on the command line so I tried the following code. > runMachine :: BellMachine -> IO () > runMachine machine = do > -- get button press > clock <- makeClock > (buttonPressed, buttonPressedSink) <- makeEvent clock > forkIO $ buttonPresses buttonPressedSink > adaptE (fmap bell $ machine buttonPressed) > -- run the machine > where bell = const $ print "beep!" > buttonPresses sink = sequence_ $ repeat $ (getChar >> sink ()) > main = runMachine metronome This guy works fine for the basic machines but it breaks for metronome. The first reason seems to be that when it gets to a point when there are no future events, switchE fails. "Exception: Future mempty: it'll never happen, buddy" I could hack around this, but then I got to another issue. It seems like switchE is too lazy, which causes my events always fire one click behind when I press the button. My guess is that since switchE is implemented with withRestE, it needs to peak ahead one event. Not sure how to deal with these issues in practice. Curious if I'm just doing something wrong. Thanks, Sasha

2 1