January 2009 - Reactive

Fun with existentials
by Achim Schneider 30 Jan '09

30 Jan '09

XHB uses existentials to enable X extensions to define their own events and still have them delivered to the user by the main library, so I had the chance to mess around with them and reactive. If you comment out the keyPressH, things are perfectly fine, but there's no dispatch on event types. With the forkIO, the program stumbles over an indefinite block on the next event. The adaptE without fromEventE is the only thing keeping the program alive: It seems that if there is only a single event that is possibly not handled, things go haywire... even if every event is guaranteed to be handled (in some other adaptE). Without any adaptE things work fine, too. I don't know if multiple adaptE's are supposed to work, but it'd be certainly nice if they would. I'm going to try to join the Nothings sorted out by joinMaybes back into the stream, hopefully that'll convince the RTS. {-# LANGUAGE ExistentialQuantification #-} module Main where -- current darcs XHB -- hack it to export Graphics.XHB.Connection.Types -- port of http://en.wikibooks.org/wiki/X_Window_Programming/XCB -- run your X server on :0 or change getScreen import Graphics.XHB as X import FRP.Reactive as R import FRP.Reactive.LegacyAdapters import Control.Concurrent import Control.Monad import System.Exit import Control.Applicative printErrors c = (forkIO . forever) $ waitForError c >>= print getScreen = head . roots_Setup . conf_setup . conn_conf castXid = fromXid . toXid main = do (Just c) <- connect printErrors c print $ displayInfo c let s = getScreen c black = black_pixel_SCREEN s white = white_pixel_SCREEN s root = root_SCREEN s depth = root_depth_SCREEN s visual = root_visual_SCREEN s g <- newResource c createGC c (MkCreateGC g (castXid root) (toValueParam [(GCForeground,white) ,(GCGraphicsExposures,0) ] )) w <- newResource c createWindow c (MkCreateWindow depth w root 0 0 640 480 0 0 visual (toValueParam [(CWBackPixel,black) ,(CWEventMask,toMask [ EventMaskExposure , EventMaskKeyPress ] ) ] )) lock <- newEmptyMVar sync <- makeSync evs <- eventsE sync c mapWindow c w forkIO $ adaptE $ keyPressH lock c $ fromEventE evs -- forkIO $ adaptE $ exposeH c $ fromEventE evs adaptE $ (fmap.const) (putStrLn "some event" ) evs --readMVar lock keyPressH :: MVar () -> Connection -> R.Event KeyPress -> R.Event Action keyPressH lock _ = (fmap.const) $ putStrLn "key" >> putMVar lock () exposeH :: Connection -> R.Event KeyPress -> R.Event Action exposeH _ = fmap print fromEventE :: X.Event a => R.Event SomeEvent -> R.Event a fromEventE = joinMaybes <$> fmap fromEvent type Sync = Clock TimeT makeSync = makeClock eventsE :: Sync -> Connection -> IO (R.Event SomeEvent) eventsE cl c = do (sink, res) <- makeEvent cl (forkIO . forever) $ putStrLn "tick " >> waitForEvent c >>= sink return res -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

1 1

Is Reactive.integral broken?
by Eyal Lotem 14 Jan '09

14 Jan '09

The problematic expression is: let ticks = R.atTimes [0,0.1..] :: R.Event () integration = ticks `R.integral` R.time in integration The value inside integration is always 0. But here is a full sample program to demonstrate the problem: {-# OPTIONS -fglasgow-exts -O2 -Wall #-} import Control.Applicative import qualified FRP.Reactive as R import qualified Graphics.FieldTrip as FT import Graphics.FieldTrip((*%)) import qualified FRP.Reactive.FieldTrip.Adapter as FieldTripA resize :: (FT.Transform (FT.Transform3 s) a) => s -> a -> a resize size = (FT.uscale3 size *%) utext :: String -> FT.Geometry3 utext = FT.flatG . FT.utext main :: IO () main = do let ticks = R.atTimes [0,0.1..] :: R.Event () integration = ticks `R.integral` R.time FieldTripA.anim3 . pure $ resize (0.3::Double) . utext . show <$> integration

2 1

snapshot_ vs. withTimeE_
by Achim Schneider 09 Jan '09

09 Jan '09

Shouldn't timeAtFramePass :: UI -> Event TimeT timeAtFramePass i = snapshot_ time (framePass i) and timeAtFramePass = withTimeE_ . framePass be equivalent? The final output of the first one seems to skip occurrences (I don't think frames are truly skipped). See http://hpaste.org/13746 -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

2 3

Re: black hole detection and concurrency
by Sterling Clover 08 Jan '09

08 Jan '09

On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote: > > The key part here is 'myThreadId >>= killThread' which throws an > asynchronous exception to the thread itself, causing the update > frames to be saved on the heap. > > Note that 'myThreadId >>= killThread' is not equivalent to > 'throw ThreadKilled'; it is a synchronous exception and replaces > thunks > pointed to by the update frames by another call to the raise > primitive - > the result being that the exception gets rethrown whenever such a > thunk > is evaluated. This happens with 'finally' and 'bracket': they use > 'throw' for re-throwing the exception. > > See rts/RaiseAsync.c (raiseAsync() in particular) for the gory details > for the first case, and rts/Schedule.c, raiseExceptionHelper() for the > second case. > > In the above code, there is a small window between catching the > ThreadKilled exception and throwing it again though, where other > exceptions may creep in. The only way I see of fixing that is to use > 'block' and 'unblock' directly. > That certainly seems to do the trick for the simple example at least. One way to reason about it better would be, instead of folding everything into the race function, to simply modify ghc's bracket function to give us the behavior we'd prefer (speaking of which, I recall there's something in the works for 6.12 or so to improve rethrowing of asynchronous exceptions?) brackAsync before after thing = block (do a <- before r <- catch (unblock (thing a)) (\_ -> after a >> myThreadId >>= killThread >> brackAsync before after thing ) after a return r ) where threadKilled ThreadKilled = Just () threadKilled _ = Nothing This brackAsync just drops in to the previous code where bracket was and appears to perform correctly. Further, if we place a trace after the killThread, we se it gets executed once when the example is read (i.e. a resumption) but it does not get executed if the (`seq` v) is removed from the example So this gives me some hope that this is actually doing what we'd like. I don't doubt it may have further kinks however. Cheers, Sterl.

7 19

Is Arrow based FRP a subset of Classic FRP, at least conceptually/semantically?
by Peter Verswyvelen 05 Jan '09

05 Jan '09

Classic FRP ("CFRP", like Fran, FAL, Reactive, Grapefruit?...) exposes signals as first class values. Arrow based FRP ("AFRP", like Fruit, Yampa...) hides signals as first class values; instead the signal transformers are the first class values. Can I conclude that it would theoretically be possible to translate an AFRP function into a CFRP function? I.e. is AFRP a subset of CFRP? Thanks, Peter

2 1