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 <[email protected]>wrote:
> 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 which gets trottled to safe energy), although I believe the > Windows API should take care of this. I haven't seen this yet with my own > frp experiments, which seem to run smooth all the time, but again I will do > more testing. > I have been thinking about your approach, using mutable variables to hold a > signal's sample. This is exactly what I did with on old C# prototype, and it > worked out nicely. If you take a look what Yampa does: it hides signals and > only exposes signal functions. But that means that the FRP engine itself > could indeed use mutable variables for its signals, as long as during the > evaluation of the circuit at time T no side effects should occur; the side > effects should take place when the simulation is advanced to T+dT, which is > done after the circuit is fully evaluated at time T. If you want higher > order integration, you would need to keep a buffer of more samples, but it > would still work. So I think you approach is a very good pragmatic one! I'm > only a bit worried about your automatic insertion of delays; this might > break referential transparency at time T, since it depends on the order in > which the nodes in the circuit are evaluated no? The latter could be > problematic when doing evaluation in parallel on multiple cores I guess. > > 2009/4/14 Patai Gergely <[email protected]> > > > 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 keep the window small >> enough). However, unlike the Linux version, it does max out the CPU, so >> the trick with threadDelay 0 doesn't work. Apparently, I'll have to find >> a real Windows box somewhere, because I couldn't reproduce the jerkiness >> you're talking about. >> >> Gergely >> >> -- >> http://www.fastmail.fm - The way an email service should be >> >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
