I've released control-event (on hackage.haskell.org), which provides a system to schedule and cancel IO events for given System.Time.ClockTimes. While designed prior to the release of Control.Timeout, it is very similar, the main differences are:
- Control.Event requires initilization while Control.Timeout hides this via unsafePerformIO.
- Control.Event can add events in the STM monad using addEventSTM. While Control.Timeout has an addEventAtomic, they aren't drop in replacements for each other (addEventAtomic is an IO action that returns an STM operation).
- Control.Timeout externally interfaces by time deltas (Float) while Control.Event is based on absolute ClockTimes.
- Control.Timeout uses only one Haskell thread while Control.Event needs two.
- Control.Event will not duplicate EventIds once the counter overflows. The possibility of this happening in Control.Timeout is entirely theoretical - I'm not claiming there is a practical difference.
- I'll either expand or eliminate the extra features of Event Preprocessing.
- If no one uses it, I'll probably be getting rid of the ability to run expired actions in the event system thread.
- I'm guessing Data.Time works on Windows. So long as I don't learn otherwise, I'll move from the old-time package to the 'time' package.
- I'll add a shim to allow adding events using time deltas.
EDIT: I should add that Control.Timeout performs MUCH better.
Let me know if you find this useful!
Getting caught up on announcements here...
Issue Two of The Mondad.Reader is out. For issue two, the subjects are Template Haskell, better module compatibility, exploring dark corners of GHC, domain specific languages, and the Foreign Function Interface.
The fptools CVS repository is now available in via a darcs mirror. There has been discussion about how a permanent conversion could be done.
Two new releases today:
A new version of MissingPy is also out, with only minor updates to work with the latest Cabal code.
The fun thing for me, is that they all come with The Haskell Cabal. This is an enabling technology for packagers and an eventual CPAN-like package database for Haskell tools. Each of today's release announcements highlighted Cabal.
This effectively adds up to the first major release of the Haskell Cabal, 0.6! Woohoo!
The point of the cabal is to make a standard way to build and install Haskell tools. Cabal packages come with a little Haskell script, Setup.lhs, which has a standard interface. The Cabal provides a library that implements this interface.
The first issue of the online Haskell e-zine, The Monad.Reader, has been posted.
Looks like good work to me. I think this will be a wonderful thing for the Haskell community.
Don Stewart's hs-plugins is a cool tool for dynamically loading haskell modules at runtime. hs-plugins history begins with GHCi, which was the first interpreter-like software for GHC. Some time later, Andre Pang wrote the RuntimeLoader, which turned GHCi into a library allowing any Haskell application to do dynamic loading. RuntimeLoader was very close to GHCi, the user needed to handle library dependencies themselves, for example. hs-plugins is a complete solution to dynamic loading in Haskell, it has lots of features and can do all sorts of nifty things.
hs-plugins includes spiffy features like eval, make, and load. The eval function does compiling, loading, and executing a single string's worth of code. the make function checks a source module and its dependencies for any changes since the last compilation, and recompiles and reloads all changed modules.
hs-plugins is already used in several applications. One especially nice example is the Yi editor from the same author, where hs-plugins is used to allow the entire application to be dynamically reloaded from a single Boot.hs startup file.