May 2011 - Glasgow-haskell-users

(no subject)
by hsing-chou chen 02 May '11

02 May '11

http://www.buonviaggioitaly.com/modules/mod_osdonate/myhome.html

1 0

Incrementally consuming the eventlog
by Johan Tibell 01 May '11

01 May '11

Hi, We were discussing how to consume the eventlog incrementally on #ghc today. Would it be feasible to offer an API (e.g. GHC.EventLog) that allows programs to register for events that occur in the program? Programs would register listeners like so: registerEventListener (\ event -> doSomethingWith event) The current write-to-file system could be implemented in terms of this API. We could even allow event logging to be turned on/off from within the application, allowing developers to attach to a running application, enable event logging, diagnose the app, and then turn of event logging again. The RTS would invoke listeners every time a new event is written. This design has many benefits: - We don't need to introduce the serialization, deserialization, and I/O overhead of first writing the eventlog to file and then parsing it again. - Programs could monitor themselves and provide debug output (e.g. via some UI component). - Users could write code that redirects the output elsewhere e.g. to a socket for remote monitoring. Would invoking a callback on each event add too big of an overhead? How about invoking the callback once every time the event buffer is full? Johan

5 9

Package management
by Brandon Moore 01 May '11

01 May '11

Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them. Deleting perfectly good versions seems to be the root of all package management problems. There are already hashes to keep incompatible builds of a package separate. Would anything break if existing packages were left alone when a new version was installed? (perhaps preferring the most recent if a package flag specifies version but not hash). For example, It seems the butterfly effect http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ could be avoided if the package database was allowed to simultaneously contain a "twittertags-1.0.0-hashA" and "twittertags-1.0.0-hashB" built against different dependencies. The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea? Brandon

3 3