[Haskell-cafe] ANN: Elerea, another FRP library

Hi everyone, I'm pleased to announce Elerea, aka "Eventless reactivity", a minimalistic FRP implementation that - comes with a convenient applicative interface (similar to Reactive) - supports recursive definition of signals - supports signals fed from outside by IO actions - supports dynamism in

Re: [Haskell-cafe] ANN: Elerea, another FRP library

I've seen alot of FRP libraries come up, and I'm always left with the question, "Where the heck are the FRP tutorials?" I'm talking about the bare-bones, "I've-never-even-touched-this-stuff-before" kind of tutorial. Something that explains the general theory and provides a few simple applicati

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> I've seen alot of FRP libraries come up, and I'm always left with the > question, "Where the heck are the FRP tutorials?" Writing a good tutorial takes a lot of time, but I made some example code precisely to show how the library can be used. The best way to learn is to start playing with them.

Re: [Haskell-cafe] ANN: Elerea, another FRP library

If you're interested in the history of FRP (which I think isn't too bad) you could read - the book "Haskell School of Expression ", which contains a good introduction to classical FRP. - "The Yampa Arcade

Re: [Haskell-cafe] ANN: Elerea, another FRP library

An other interesting approach to FRP is frtime (in Scheme): http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/ There should be a second paper than this one, I have just forget its reference. Thu 2009/4/10 Peter Verswyvelen : > If you're interested in the history of FRP (which I

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> An other interesting approach to FRP is frtime (in Scheme): > http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/ > There should be a second paper than this one, I have just forget its > reference. Elerea is a bit similar, since it also maintains the connections between signals e

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Any idea how Elerea compares to Grapefruit? It's great to see a lot of competition in the FRP arena, but I hope in the end this results in a really usable and scalable FRP system for Haskell :-) 2009/4/11 Patai Gergely > > An other interesting approach to FRP is frtime (in Scheme): > > http://ww

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> Any idea how Elerea compares to Grapefruit? It's great to see a lot of > competition in the FRP arena, but I hope in the end this results in a > really usable and scalable FRP system for Haskell :-) I think Wolfgang can judge this better, because I don't really know the innards of Grapefruit, whi

Re: [Haskell-cafe] ANN: Elerea, another FRP library

I uploaded a new version of the library. The biggest change is that transfer functions and latchers have no delay by default any more. Additionally, this version has a unique and rather shady feature: it inserts delays whenever it encounters a cyclic dependency involving stateful signals. If you do

Re: [Haskell-cafe] ANN: Elerea, another FRP library

That's rather amazing. Is this the first FRP lib that does this? 2009/4/12 Patai Gergely > I uploaded a new version of the library. The biggest change is that > transfer functions and latchers have no delay by default any more. > Additionally, this version has a unique and rather shady feature:

Re: [Haskell-cafe] ANN: Elerea, another FRP library

seems something is wrong with either your time sampling or performance, because I get rather jerky movement when playing the breakout or the chase demo. did you notice that too? at what rate are you sampling? if you are sampling at a lower rate as the video vsync, you might want to perform interpol

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> That's rather amazing. Is this the first FRP lib that does this? I can't be 100% certain, but it is very likely. It's nearly trivial to do with my approach, since every node of the network is a mutable variable, and I can simply mark the nodes I have already visited in the current superstep. It's

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> seems something is wrong with either your time sampling or performance, > because I get rather jerky movement when playing the breakout or the > chase demo. did you notice that too? No, it was always smooth for me. But I only tried it on 64-bit machines and only with ghc-6.10.2. > at what rate a

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Interesting. I'm testing it on Window though. You're using Linux? Maybe the scheduling is different. 2009/4/13 Patai Gergely > > seems something is wrong with either your time sampling or performance, > > because I get rather jerky movement when playing the breakout or the > > chase demo. did yo

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> Interesting. I'm testing it on Window though. You're using Linux? Maybe > the scheduling is different. I'm on Linux, yes. But I've no idea what could cause such a difference, since both the library and the examples are single threaded. GLFW might also be the culprit, since that's where the frame

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> > To keep with the example, > something like drawUnitRectangle <$> mousePosition would result in a > signal whose points are IO actions that draw the rectangle where the > mouse is at the moment you sample them. And just as IO is unnecessary for behavior (functions of time), it's also unnecessa

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> And just as IO is unnecessary for behavior (functions of time), it's also > unnecessary for imagery (functions of space). Continuing with the > functional (non-IO) theme, you can give a semantically precise, > composable and simple type of images. Yes, that's a further separation of concerns. In

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> Interesting. I'm testing it on Window though. You're using Linux? Maybe > the scheduling is different. Now I tried it on Windows in VirtualBox, and it still looks quite smooth to me (except that hardware acceleration doesn't seem to work properly through virtualisation, but it's okay as long as I

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Freitag, 10. April 2009 18:41 schrieb Patai Gergely: > is based on some unsafePerformIO dark magic (that might easily break > depending on many factors) I wonder if this breaks referential transparency. Say, you define a signal s and use s twice in some expression. s may be evaluated once and

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Dienstag, 14. April 2009 11:33 schrieb Patai Gergely: > and then the integration of a Grapefruit-like and a Reactive-like system > could be the ultimate solution in the long run. What do you think, Grapefruit is lacking, compared to Reactive? Best wishes, Wolfgang _

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Samstag, 11. April 2009 16:57 schrieb Patai Gergely: > > Any idea how Elerea compares to Grapefruit? It's great to see a lot of > > competition in the FRP arena, but I hope in the end this results in a > > really usable and scalable FRP system for Haskell :-) > > I think Wolfgang can judge this

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> I wonder if this breaks referential transparency. Say, you define a signal > s and use s twice in some expression. s may be evaluated once and it > maybe evaluated twice. Does this make a difference? I'm not sure about the answer at the moment, but I believe we'd simply get two identically behavi

Re: [Haskell-cafe] ANN: Elerea, another FRP library

I will test it on a couple of machines, desktops and laptops. I think the problem was my laptop going into power safe mode or something, since sometimes it runs smooth, sometimes it doesn't. This could indeed be a problem with GLFW's time attribute on windows (which uses the CPU tick frequency whic

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Ouch, I did not see Wolfgang's email nor your reply, sorry for the noise (which I'm doing again with this email ;-) On Tue, Apr 14, 2009 at 11:01 PM, Peter Verswyvelen wrote: > I will test it on a couple of machines, desktops and laptops. I think the > problem was my laptop going into power safe m

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> I don't think using dirty tricks to implement FRP deserves > flak, at all, from my POV, it sounds like complaining that the > IO monad is implemented using C... meaning that if you're that > close to bare thunks, you have every right to use any means > necessary to make them behave properly. Dirt

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> I will test it on a couple of machines, desktops and laptops. Try using a sensible nonzero value with threadDelay. Apparently it brings CPU usage down under Windows while retaining smoothness. However, increasing it from zero results in jerkiness under Linux... > If you take a look what Yampa do

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Well, a breakout game does *not* work (yet) in most other FRP implementations except Yampa, which do have firm theoretical foundations :-) 2009/4/15 Patai Gergely > > I don't think using dirty tricks to implement FRP deserves > > flak, at all, from my POV, it sounds like complaining that the > >

Re: [Haskell-cafe] ANN: Elerea, another FRP library

but the fact that the breakout example works is an indication that at least it's not hopelessly broken. Well, a breakout game does *not* work (yet) in most other FRP implementations except Yampa, which do have firm theoretical foundations :-) While certainly more entertaining, the problem looks

Re: [Haskell-cafe] ANN: Elerea, another FRP library

I think it would be nice if we could make a "reactive benchmark" or something: some tiny examples that capture the essence of reactive systems, and a way to compare each solution's pros and cons. For example the "plugging a space leak with an arrow" papers reduces the recursive signal problem to e

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> On the other hand, I hadn't got round to cleaning up the interface, > let alone firming the theoretical foundations, so perhaps this isn't an > exception to your rule?-) But I thought I'd mention it on the topic of > "other FRP libraries", with variations of approach/concepts. Thanks for the po

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> On the other hand, breaking referential transparency in the > external interface is a very bad idea, in my opinion. Actually, > this means that the library user would have to turn certain > compiler optimizations off to get the intended behavior. However, in practice you can compile Elerea with -

Re: [Haskell-cafe] ANN: Elerea, another FRP library

There's no guarantee about unsafePerformIO not being inlined, that's just how ghc treats it. 2009/4/16 Patai Gergely : >> On the other hand, breaking referential transparency in the >> external interface is a very bad idea, in my opinion. Actually, >> this means that the library user would have to

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Well, the documentation says: Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once. So you claim this does not prevent GHC to inline it anyway? That feels like a bug then, both in the documentation and

Re: [Haskell-cafe] ANN: Elerea, another FRP library

With NOINLINE you should be safe, but you never mentioned that originally. :) On Thu, Apr 16, 2009 at 10:29 AM, Peter Verswyvelen wrote: > Well, the documentation says: > Use {-# NOINLINE foo #-} as a pragma on any function foo that > calls unsafePerformIO. If the call is inlined, the I/O may be

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Oh I see. Gergely did mention it in a previous email: Am I right thinking that the NOINLINE pragma on unsafeDupablePerformIO prevents the problem of multiple evaluation discussed yesterday? Or should I add NOINLINE to primitives in Elerea.Internal too? If that guaranteed sharing, it would So I got

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Donnerstag, 16. April 2009 10:06 schrieb Patai Gergely: > unsafePerformIO is apparently never inlined, i.e. each instance is > executed once, so sharing works as desired But expressions that use unsafePerformIO might get inlined. > CSE is no problem either, it even helps if it's performed (and

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> But expressions that use unsafePerformIO might get inlined. That's true, but given the way this interface is used, this doesn't seem to be an issue, since there are typically no unsafePerformIO's hidden deep inside an expression without a chain of Elerea primitives leading to it. > What about ev

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Dienstag, 21. April 2009 17:18 schrieb Patai Gergely: > > What about evaluation time? If I remember correctly, the values > > of signals depend on the time when the signal expressions are > > evaluated. So evaluating them multiple times might lead to > > different behavior. Is this correct? > >

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> > network. Therefore, duplication and merging of identical > > expressions only affects the performance unless they are > > hidden in the input signal of a latcher. > > But isn't the latter a fundamental problem? Of course it is, but I said afterwards that this can be resolved by sampling 'more

Re: [Haskell-cafe] ANN: Elerea, another FRP library

Am Mittwoch, 22. April 2009 16:00 schrieb Patai Gergely: > This also means that if you want to restart a signal without external > dependencies using a latcher, you have to inject some bogus dependency > to prevent memoisation. If the new signal depends on some others, > latching should behave intu

Re: [Haskell-cafe] ANN: Elerea, another FRP library

> So does this mean that whether a signal is started at the > beginning or at switching time depends on what dependencies the > signal has? No, the situation is even more complicated, since some of its dependencies might be aged through other dependency chains, while others can only be animated thr

Re[2]: [Haskell-cafe] ANN: Elerea, another FRP library

Hello Peter, Thursday, April 16, 2009, 12:29:41 PM, you wrote: Lennart (and Patai) said about unsafePerformIO, you - about NOINLINE > Well, the documentation says: > Use {-# NOINLINE foo #-} as a pragma on any function foo that calls > unsafePerformIO. If the call is inlined, the I/O may be perf