November 2008 - Reactive

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

18 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 18 Nov '08

18 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 13 Nov '08

13 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 12 Nov '08

12 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 10 Nov '08

10 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

automatic recompilation/re-execution?
by Shahbaz 10 Nov '08

10 Nov '08

In the mailing list announcement, one of the potential uses of this library is "automatic recompilation/re-execution." This sounds very interesting, is there more information? Is this at all similar to "Living it up with a Live Programming Language" [http://lambda-the-ultimate.org/node/2149] ? Also, are there any tutorials that show how this library can be used (rather than just explaining semantics)? Thanks

4 3

Re: Stuff to add to Reactive
by David Sankel 06 Nov '08

06 Nov '08

On Wed, Nov 5, 2008 at 6:57 PM, Conal Elliott <conal.elliott(a)gmail.com>wrote: > The 'changes' function would break through the step-function-of-time > semantics of Reactive. In other words, I don't think you can specify the > meaning of 'changes' in terms of the meaning of Reactive. I see what you mean: my implementation of changes only removes one kind of redundancy (reactive's simultaneous occurrences). It doesn't remove the redundancy where some occurrences may not change the value. My next thought is, why not add an Eq parameter to the changes function and use that to remove the other redundancy? I'm thinking that could work in many cases, but in this case: data WiperMode = Normal { singleWipe :: Event () , customWipe :: Event () } | SlowWipe | ContinuousWipe | FastWipe type WiperStick = Reactive WiperMode That would require me to have an Eq on WiperMode with the embedded events. I can't see a way to make that work. I think I'll just change my example to be WiperStick = Event WiperMode with a condition that there exists an occurance at -infinity. Hrm, I'm thinking this conversation should probably be on the reactive list. I'll cc it. David > - Conal > > > On Wed, Nov 5, 2008 at 1:47 PM, David Sankel <camior(a)gmail.com> wrote: > >> In this example (marked with the module it should go into). >> >> http://hpaste.org/11766 >> >> Also, I've attached a patch to generalize the type of something. >> >> David >> > -- David Sankel Sankel Software www.sankelsoftware.com

1 0