Ah OK. Thank you again for the fast fixes!
On Tue 14 May 2013 11:44:43 SGT, Chris Wong wrote: > I removed the functionality because I didn't really see a use for it > anymore. The `hold` and `tap` functions are already exception safe > (thanks to `bracket`), and anyone who uses the unguarded `press` > function probably wants to keep it held down anyway. > > Chris > > > On Tue, May 14, 2013 at 12:46 PM, Niklas Hambüchen <[email protected]> wrote: >> Awesome, that works very well, and it even made my program run faster / >> with less CPU. >> >> The reset functionality is useful, but I think optional is better. Did >> you remove it entirely or is it still available? >> >> On Tue 14 May 2013 08:25:04 SGT, Chris Wong wrote: >>> Oh, I see now. I originally made the runRobot functions reset the >>> input state when the Robot finished running. That worked well for my >>> use case (testing GUIs), but as you have noticed, it causes >>> unintuitive behavior when runRobot is called at a high frequency. >>> >>> In hindsight, that was a design flaw on my part: that resetting >>> behavior should be specified explicitly, not attached unconditionally >>> to every call to runRobot. >>> >>> I've removed the offending code, and released it as version 1.1. >>> Hopefully I've ironed out the issues now :) >>> >>> >>> On Mon, May 13, 2013 at 12:49 PM, Niklas Hambüchen <[email protected]> wrote: >>>>> Can you show me the code that triggers that behavior? >>>> >>>> It is basically >>>> >>>> Just connection <- connect >>>> forever $ do >>>> (x,y) <- getGyroMovement >>>> runRobotWithConnection (moveBy x y) connection >>> >>> >>> >>> -- >>> Chris Wong, fixpoint conjurer >>> e: [email protected] >>> w: http://lfairy.github.io/ > > > > -- > Chris Wong, fixpoint conjurer > e: [email protected] > w: http://lfairy.github.io/ _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
