Hi,
I do not use -O to compile, as far as I know. I use eclipsefp and I use the
defaults from it.
I will upload my modules as a zip file, so you can reproduce the error. It
also contains a README.txt file that explains how to reproduce it.
Hope that helps.
http://www.nabble.com/file/p21439653/s
By popular demand, GHC 6.10.2 will support finalizers that are actually
guaranteed to run, and run promptly. There aren't any API changes: this
happens for finalizers created using newForeignPtr as normal.
However, there's a catch. Previously it was possible to call back into
Haskell from a
Heiko Studt wrote:
PPS: Why does your mailinglist not set the Reply-To header?
@Roman Cheplyaka: Sorry for double mailing.
Am 13.01.2009 schrieb Roman Cheplyaka:
| f x y z = a + b*c + b + fun c
| where a = x * y + z
| b = c * fun x
| c = a * b
| fun x = x * x + 1
Th
On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote:
> By popular demand, GHC 6.10.2 will support finalizers that are actually
> guaranteed to run, and run promptly. There aren't any API changes: this
> happens for finalizers created using newForeignPtr as normal.
Does this effect GC performance
Johan Tibell wrote:
On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote:
By popular demand, GHC 6.10.2 will support finalizers that are actually
guaranteed to run, and run promptly. There aren't any API changes: this
happens for finalizers created using newForeignPtr as normal.
Does this eff
Sigbjorn Finne wrote:
Thanks Simon,
great stuff; I like the introduction of these 'native code finalizers',
they've
been sorely missed at times.
You don't say, but will there be a dynamic check to catch such re-entries?
There is (now) a dynamic check, yes.
Cheers,
Simon
__
