I just checked it seems not to be possible to load any module in
GHCi that uses FFI to wrap the standard C function 'atexit'. (...)
A simple workaround is to just compile the module. (...)
If I build a package (using cabal etc.) and try to load such
package with 'ghci -package name' the
On Fri, Aug 21, 2009 at 04:34:24PM -0400, Ravi Nanavati wrote:
Hypothetically speaking (since I haven't made the call yet), if I
wanted to be an early adopter of 6.12.1 when it is released, would
now would be the time to start grabbing HEAD and playing with it
There are currently some known
Simon and I have been chatting about how we accommodate libraries in the
GHC repository. After previous discussion on this list, GHC has been
gradually migrating towards having snapshots of libraries kept as
tarballs in the repo (currently only time falls into this category),
but I don't
On Wed, Aug 26, 2009 at 9:15 AM, Simon Marlowmarlo...@gmail.com wrote:
Simon and I have been chatting about how we accommodate libraries in the GHC
repository. After previous discussion on this list, GHC has been gradually
migrating towards having snapshots of libraries kept as tarballs in the
On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote:
* Sometimes we want to make local modifications to INDEPENDENT
libraries:
- when GHC adds a new warning, we need to fix instances of the
warning in the library to keep the GHC build warning-free.
I have to say I think
marlowsd:
Simon and I have been chatting about how we accommodate libraries in the
GHC repository. After previous discussion on this list, GHC has been
gradually migrating towards having snapshots of libraries kept as
tarballs in the repo (currently only time falls into this category),
