I should probably do a refresh of Control-Event - it was right when I was starting to learn proper Haskell style; I soon discovered STM and used it for everything... even when I shouldn't. To cut down on any investigation you might do here is a rundown: Control-Event uses absolute times (control-timeout uses relative) - this can be slower, but might be what you want and allows you to add events via STM actions (no IO after the fact). Control-Event also has a control-timeout compatability shim (Control.Event.TImeout). On the other hand, it still uses old-time and really should be ported to the 'time' package along with getting proper version bounds in the .cabal file. CE Benchmarks/Blog: http://sequence.complete.org/node/376 Thomas On Mon, Jun 8, 2009 at 4:32 PM, Erik de Castro Lopo wrote:

Adam Langley wrote:

...

Yes, it's just missing a maintainer, you're welcome to take it over if you like. However, you should probably take a look at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-event

I'm actually interested in the network-dns package. I might try port that to control-event and only revive control-timeout if that fails.

Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Erik said:

Well, if you roll a new version of control-event, I'll try porting network-dns to control-event.

Give me a week or two and I should get one out. Thomas

Erik,

There is a different in the function signature between the two versions. Control.Timeout has:

   addTimeoutAtomic :: Float -> IO (IO () -> STM TimeoutTag)

while your Control.Event.Timeout has:

   addTimeoutAtomic :: Float -> IO () -> IO (STM TimeoutTag)

Was that intentional? As a relative newbie, I can't immediately see how to port code from the first to the second.

No, I intended to match function types to allow a seemless transition. This is a bug. Still, I'm questioning the value in supporting a compatability API for a depricated package - especially seeing as it depends on the unsafePeformGlobalBadness hack. I could add a module Control.Event.Relative to allow relative times using just forkIO and threadId (a lighter weight solution than the current bloatware), but that would just use IO and no STM. What would be useful for your network-dns work?

There is also a little matter of documentation :-).

Documentation for Control.Event.TImeout? I assumed that people using the module would be familure with Control.Timeout - perhaps its time for that assumption to change. Thomas

Erik, control-event 1.0.0.0 is uploaded [1]. Haddock documents will be available in due time. If you don't have any fancy needs then just use Control.Event.Relative.addEvent and give it a time (in ms) and an action :: IO (). Control.Event and Control.Event.Timeout are still there. Let me know if you have issues. Thomas [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-event On Tue, Jun 9, 2009 at 4:03 PM, Erik de Castro Lopo wrote:

Thomas DuBuisson wrote:

...

No, I intended to match function types to allow a seemless transition.  This is a bug.

:-)

...

Still, I'm questioning the value in supporting a compatability API for a depricated package

Well, the value you provide is that your module replaces the deprecated one.

...

- especially seeing as it depends on the unsafePeformGlobalBadness hack.

If that hack is the only way to provide the functionality then yes its probably best to drop it.

...

  I could add a module Control.Event.Relative to allow relative times using just forkIO and threadId (a lighter weight solution than the current bloatware), but that would just use IO and no STM.  What would be useful for your network-dns work?

Yes, I think it probably would be.

...

Documentation for Control.Event.TImeout?  I assumed that people using the module would be familure with Control.Timeout - perhaps its time for that assumption to change.

Well the documentation for Control.Event.Timeout could have pointed to Control.Timeout.

The only really went looking was when I found that the APIs were different :-).

Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries