- Glasgow-haskell-users

Error building head on OS X
by Johan Tibell 21 Jul '10

21 Jul '10

Building from a clean checkout of HEAD (from today) I get: "inplace/bin/ghc-stage2" -H32m -O -package-name dph-seq-0.4.0 -hide-all-packages -i -ilibraries/dph/dph-seq/../dph-common -ilibraries/dph/dph-seq/dist-install/build -ilibraries/dph/dph-seq/dist-install/build/autogen -Ilibraries/dph/dph-seq/dist-install/build -Ilibraries/dph/dph-seq/dist-install/build/autogen -Ilibraries/dph/dph-seq/. -optP-include -optPlibraries/dph/dph-seq/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.0 -package base-4.3.0.0 -package dph-base-0.4.0 -package dph-prim-seq-0.4.0 -package ghc-6.13.20100720 -package ghc-prim-0.2.0.0 -package random-1.0.0.2 -package template-haskell-2.4.0.0 -Odph -funbox-strict-fields -fcpr-off -fdph-this -package-name dph-seq -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/dph/dph-seq/dist-install/build -hidir libraries/dph/dph-seq/dist-install/build -stubdir libraries/dph/dph-seq/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/dph/dph-seq/../dph-common/Data/Array/Parallel/Lifted/PArray.hs -o libraries/dph/dph-seq/dist-install/build/Data/Array/Parallel/Lifted/PArray.o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package filepath-1.2.0.0 ... linking ... done. Loading package old-locale-1.0.0.2 ... linking ... done. Loading package old-time-1.0.0.5 ... linking ... done. Loading package unix-2.4.0.1 ... linking ... done. Loading package directory-1.0.1.2 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package process-1.0.1.3 ... linking ... done. ghc-stage2: internal error: Invalid Mach-O file:Address out of bounds while relocating object file (GHC version 6.13.20100720 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/dph/dph-seq/dist-install/build/Data/Array/Parallel/Lifted/PArray.o] Abort trap make: *** [all] Error 2 P.S. I'm running OS X 10.5.8 on a Intel Core 2 Duo Mac Book Pro.

3 2

ghc 6.12.3: Data.Array.Diff and package diffarray
by Rene de Visser 20 Jul '10

20 Jul '10

Hello, According to the release notes there is a new package that now contains the module Data.Array.Diff. According to Ian's commit this package is called diffarray. This package does not seem to be available on Hackage. Could someone upload it? Rene.

2 1

hot-refreshing a package (same version number, new content)
by Albert Y. C. Lai 19 Jul '10

19 Jul '10

Suppose I start ghci, use a value from a package, causing it to be linked, then I modify the package and reinstall, same version number, without quitting my ghci session. Is there a way to tell the ghci session to refresh and use the modified package? Suppose I do something similar with the GHC API (6.12.3, linux, x86, 32 bit). The attachment g.hs is my program to get a value from the package (called watermelon-0.1), print it, wait for me to press return, (at this point I modify the source code of the package, rebuild, reinstall), then loop back to get a value from the package again... how should I refresh so I get the new value? Or I am supposed to forget this and just bump the version number of the package? I attach my program g.hs and the package tarball for watermelon-0.1.

2 1

new qualified operators
by Christian Maeder 16 Jul '10

16 Jul '10

Hi, seeing http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#n… Could you add: "Spaces are not allowed in new qualified operators!" For {-# LANGUAGE NewQualifiedOperators #-} f1 = (+) f2 = ( +) f3 = (+ ) f4 = Prelude.(+) f5 = Prelude.( +) f6 = Prelude.(+ ) f1 - f4 are ok, but f5 and f6 are rejected by ghc-6.12.3 with: Not in scope: data constructor `Prelude' So ghc seems to see a composition and: data T = T (Int -> Int) f = T.( +) goes through, whereas f = T.(+) reports: Not in scope: `T.+' Note the old qualifiation in the error message. Christian

2 1

behaviour of ghci on .c modules that are part of a library
by Axel Simon 16 Jul '10

16 Jul '10

Hi all, I'm trying to debug a segfault relating to the memory management in Gtk2Hs. Rather than make you read the ticket http://hackage.haskell.org/trac/gtk2hs/ticket/1183 , I'll describe the problem: - compiler 6.12.1 or 6.12.3 - darcs head of Gtk2Hs with #define DEBUG instead of #undef DEBUG in gtk/Graphics/UI/Gtk/General/hsthread.c - platform Ubuntu Linux, x86-64 - to reproduce: cd gtk2hs/gtk/demo/hello and run ghci World.hs and type 'main' A window with the "Hello World" button appears. After a few seconds, the GC runs and the finaliser of the GtkButton is run since the Haskell program no longer holds a reference to that object (only the GtkWindow in C land has). Thus, the GC calls a C function gtk2hs_g_object_unref_from_mainloop which is supposed to enqueue the object into a global data structure from which objects are later taken and g_object_unref is called on them. This global data structure is protected by a mutex, which is acquired using g_static_mutex_lock: void gtk2hs_g_object_unref_from_mainloop(gpointer object) { int mutex_locked = 0; if (threads_initialised) { #ifdef DEBUG printf("acquiring lock to add a %s object at %lx\n", g_type_name(G_OBJECT_TYPE(object)), (unsigned long) object); printf("value of lock function is %lx\n", (unsigned long) g_thread_functions_for_glib_use.mutex_lock); #endif g_rand_new(); #if defined( WIN32 ) EnterCriticalSection(&gtk2hs_finalizer_mutex); #else g_static_mutex_lock(&gtk2hs_finalizer_mutex); #endif mutex_locked = 1; } [..] The program prints: acquiring lock to add a GtkButton object at 22d8020 value of lock function is 0 zsh: segmentation fault ghci World Now the debugging weirdness starts. Whatever I do, I cannot get gdb to find the symbol gtk2hs_g_object_unref_from_mainloop. Since the function above is contained in a C file that comes with our Haskell library, I tried to add "cc-options: -g" and "cc-options: - ggdb -O0", but maybe somewhere symbols are stripped. So I added the bogus function call to "g_rand_new()" which is not called anywhere else and gdb stops as follows: acquiring lock to add a GtkButton object at 2105020 value of lock function is 0 [Switching to Thread 0x7ffff41ff710 (LWP 15735)] Breakpoint 12, 0x00007ffff115bfa0 in g_rand_new () from /usr/lib/ libglib-2.0.so This all seems reasonable, but: (gdb) bt #0 0x00007ffff115bfa0 in g_rand_new () from /usr/lib/libglib-2.0.so #1 0x00000000419b3792 in ?? () #2 0x00007ffff678f078 in ?? () i.e. the calling context is broken. I'm very, very sure that the caller is indeed the above mentioned function and since g_rand_new isn't called anywhere in my Haskell program (and otherwise the calling context would be sane). I'm also passing the address of gtk2hs_g_object_unref_from_mainloop as FinalizerPtr to all my ForeignPtrs, so there is no inlining going on. Back to the culprit, the call to g_static_mutex_lock. This is a macro that expands to *g_thread_functions_for_glib_use.mutex_lock where g_thread_functions_for_glib is a global variable that contains a lot of function pointers. At the break point, it contains this: (gdb) print g_thread_functions_for_glib_use $33 = {mutex_new = 0x7ffff0cd9820 <g_mutex_new_posix_impl>, mutex_lock = 0x7ffff6c8b3c0 <__pthread_mutex_lock>, mutex_trylock = 0x7ffff0cd97b0 <g_mutex_trylock_posix_impl>, mutex_unlock = 0x7ffff6c8ca00 <__pthread_mutex_unlock>, mutex_free = 0x7ffff0cd9740 <g_mutex_free_posix_impl>, [..] So the call to g_mutex_lock should call the function __pthread_mutex_lock but it calls NULL. I hoped that writing this email would give me a bit more insight into the problem, but for now I suspect that something overwrites either the stack or the code of the function. On the same platform, the compiled version prints: acquiring lock to add a GtkButton object at 1b05820 value of lock function is 7f7adcabd3c0 within mutex: adding finalizer to a GtkButton object! On Mac OS or i386, using ghci or ghc, version 6.10.4, it works as well. Now for the fun bit: on i386 using ghci version 6.12.1 it works too. So it's an x86-64 and ghc 6.12.1 bug. According to Christian Maeder who submitted the ticket, the problem persists in 6.12.3. Any hints and help appreciated, Cheers, Axel

2 4

Casting + eta reduction
by Louis Wasserman 16 Jul '10

16 Jul '10

Consider newtype Foo = Foo Int lift :: (Int -> a) -> Foo -> a lift f (Foo x) = f x Now, I'd expect this to compile with -O2 down to something like lift f = f `cast` (Foo -> a) but it doesn't. It seems that GeneralizedNewtypeDeriving assumes that these two things *are* equivalent, and it just directly casts the class dictionary. The implication would be that that GeneralizedNewtypeDeriving gives more efficient instances than you could *possibly* get if you wrote them by hand, which is very sad. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

3 5

GADT related bug in GHC type checker
by George Giorgidze 13 Jul '10

13 Jul '10

Hi, I have encountered a bug in GHC type checker. I have stripped down my code to small manageable example that illustrates the bug: {-# LANGUAGE GADTs #-} {-# OPTIONS -Wall #-} module StrangeGADT where data Q a where ToQ :: (QA a) => a -> Q a Sum :: (QA a, Num a) => Q [a] -> Q a class QA a where toQ :: a -> Q a fromQ :: Q a -> a instance QA Int where toQ = ToQ fromQ q = case q of ToQ a -> a Sum as -> sum (fromQ as) instance QA a => QA [a] where toQ = ToQ fromQ q = case q of ToQ a -> a -- Sum _ -> ([] + 13) The above program typechecks but GHC wrongly warns that last pattern match is not exhaustive. Furthermore, if I uncomment the last line of the code it typechecks (without warnings) and does not reject ([] + 13) as type incorrect expression. It would be very much appreciated if someone could suggest how to circumvent the problem. Is there a version of GHC that behaves correctly in this case? Is this yet another instance of GADT related bugs already reported in GHC trac? or it is unrelated and I better report it as a separate ticket. Cheers, George

2 1

mallocForeignPtr vs. C
by Evan Laforge 13 Jul '10

13 Jul '10

So I was planning to pass a StorableVector to C. StorableVector uses ForeignPtrs to manage its memory, so it should just be a pointer pass. I happily wrote up a reference counting scheme so I could attach decref to the finalizer and have haskell and C cooperate about when to delete the pointer. However, then I found out that StorableVector uses mallocForeignPtr, which says it already has the equivalent of a free() finalizer attached, without actually using a finalizer. So it looks like I can't safely pass it to C unless I also guarantee that haskell still has a reference to it. So the only thing I thought of to deal with that is to pass C a FunPtr to a "wrapper" style haskell function. That function is never called, but it returns the vector so the haskell GC can't free the vector while the function is still alive. Then when C is done with the vector, it can call freeHaskellFunPtr via the usual freeHaskellFunPtr wrapper trick. But I'm not convinced that's actually enough because the C code is still running outside of a withForeignPtr. I would have to do something really hairy like call back to C from the haskell callback, wrapping it in withForeignPtr. Is there a better way to convince the GC that the pointer should remain alive until I explicitly release it from C? The ideal I think would be a ref count that would keep the pointer alive while >0, that could be decremented from C. Since one of the advantages of ForeignPtr using types is to pass them to C, this must be a problem someone has dealt with. A synchronous call that uses the foreign pointer temporarily is easy enough via withForeignPtr, but what about when I want to share ownership with C?

7 14

Massive slowdown in mwc-random after switching to use of primitive package
by Bryan O'Sullivan 13 Jul '10

13 Jul '10

Hi, Roman — Recently, I switched the mwc-random package ( http://hackage.haskell.org/package/mwc-random) over from running in the ST monad to using your primitive package. I didn't notice initially, but this caused a huge performance regression. mwc-random 0.4.1.1 uses ST internally, and runs the benchmarks/Quickie benchmark in 0.017 seconds. mwc-random 0.5.1.3 uses PrimMonad internally, and takes 1.328 seconds to run the same benchmark. That's about a factor of 80 slowdown. This causes a massive knock-on performance loss in packages such as criterion that need fast PRNGs. The problem is very easy to reproduce: cabal install mwc-random-0.4.1.1 cabal install mwc-random-0.5.1.3 darcs get http://darcs.serpentine.com/mwc-random/ cd mwc-random/benchmarks ghc -fforce-recomp -O -package mwc-random-0.4.1.1 --make Quickie -o quickie-411 ghc -fforce-recomp -O -package mwc-random-0.5.1.3 --make Quickie -o quickie-513 time ./quickie-411 time ./quickie-513 If you could shed any light, I'd be most grateful, as this has me a bit confounded.

4 11

Re: unsafeCoerce# between integral and floating point types
by John Meacham 09 Jul '10

09 Jul '10

On Fri, Jul 09, 2010 at 07:14:58AM -1000, Lennart Augustsson wrote: > That might not work if the alignment constraints differ between the two types. Easy enough to fix, just compare the alignments and alloca with the greater of the two. the optimizer should be able to optimize out the test. of course, this bug[1] makes it sort of moot in ghc at least. [1] http://hackage.haskell.org/trac/ghc/ticket/r2917 John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0