- Glasgow-haskell-users

$thisdir for package.conf?
by Greg Fitzgerald 12 Aug '10

12 Aug '10

Is there a way for a package.conf file to contain paths that are relative to the directory containing the .conf file? GHC 6.12.1 chokes on relative paths. I see the problem is solved for GHC's core libraries with the $topdir variable. Is there something like a $thisdir we could use in inplace .conf files? Thanks, Greg

2 1

Re: [Haskell-cafe] Weird behavior with arrow commands
by Jürgen Doser 02 Aug '10

02 Aug '10

El vie, 23-07-2010 a las 23:27 -0400, Ronald Guida escribió: > I am trying to figure out how to use GHC's arrow commands, and I found > some extremely weird behavior. CC'ed to ghc-users, because this may be a ghc bug. > In GHC's manual, there is a description of arrow commands, which I > don't really understand. > http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html… > (Primitive Constructs) > > I have two questions: > 1. What are arrow commands supposed to do? > 2. What is this code supposed to do? > > -- start of code -- > > {-# LANGUAGE Arrows #-} > module Main where > > import Control.Arrow > > foo :: (b -> String) -> ((((b, Int), Float), Double) -> String) -> (b -> String) > foo f g b = f b ++ " " ++ g (((b, 8), 1.0), 6.0) > > bar :: (t -> String) -> ((Double, Int) -> String) -> t -> String > bar f g = proc x -> do > (f -< x) `foo` \n m -> g -< (n) > > main = do > putStrLn $ foo show show 17 > putStrLn $ bar show show 17 > putStrLn $ foo show show 42 > putStrLn $ bar show show 42 > > -- end of code -- > > Output from GHCi: > > 17 (((17,8),1.0),6.0) > 17 (6.730326920298707e-306,0) > 42 (((42,8),1.0),6.0) > 42 (6.730326920298707e-306,0) > > Output after compiling with GHC: > > 17 (((17,8),1.0),6.0) > 17 (5.858736684536801e-270,0) > 42 (((42,8),1.0),6.0) > 42 (5.858736684536801e-270,0) > > GHC Version: > The Glorious Glasgow Haskell Compilation System, version 6.12.3 This seems to be a bug in ghc. First, let's fix bar to give the full three arguments (Int, Float, Double) to g: bar f g = proc x -> do (f -< x) `foo` (\n m k -> g -< (n,m,k)) ghc infers the type: bar :: (t -> String) -> ((Double, Float, Int) -> String) -> t -> String and we see that the argument order in the second argument to bar is reversed. But the arguments are still given to bar in the order (Int, Float, Double). For example, the 6.0 in foo is interpreted as an Int and outputs a 0 (the first 32 bits in such a small double are zeros). When one varies the numbers in foo, one can see the effects in bar. Can someone from GHC HQ confirm my understanding, or is this just not supposed to work with multiple arguments? Jürgen

3 2

Deadlock with Repa
by Jean-Marie Gaillourdet 29 Jul '10

29 Jul '10

Hi, I've been trying to use repa and stumbled into rather strange behavior of my program. Sometimes, there seems to be a deadlock at other times it seems there is a livelock. Now, I've managed to prepare a version which consistently generates the following output: $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ But I don't use any MVar directly. And the only used library which is not part of ghc are repa and repa-algorithms. To state it clearly I don't use any MVars, par, pseq, forkIO nor any other parallelism or cuncurrency functionality. The only thing my program uses is repa which is supposed to use some kind of parallelism as far as the documentation says. So I am wondering whether this is a problem with my code or with repa or with ghc. The same behaviour occurs with ghc-6.12.1 and ghc-6.13.20100726. This is on MacOSX 10.6.4. In order to reproduce take the attached file and compile it with: $ ghc --make -package dph-prim-par MDim.hs -main-is MDim -fforce-recomp [1 of 1] Compiling MDim ( MDim.hs, MDim.o ) Linking MDim ... $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ I haven't been able to make the program smaller without removing the blockage. But, essentially it's just pure number crunching you can ignore. I'd be really happy if anyone could give me a hint how to debug this, or whether I am able to do anything about it, at all. Best regards, Jean-Marie -- Dipl.-Inf. Jean-Marie Gaillourdet Software Technology Group University of Kaiserslautern, Department of Computer Science Gebäude 32, Raum 406 Gottlieb-Daimler-Str. D-67653 Kaiserslautern Tel: 06 31 - 205 - 32 72 Fax: 06 31 - 205 - 34 20

2 1

SPECIALIZE function for type defined elsewhere
by Sebastian Fischer 28 Jul '10

28 Jul '10

Dear GHC experts, say I have module A where class C a where ... f :: C a => String -> a module B where import A data T = ... instance C T where ... g :: String -> SomeOtherType g s = doSomethingWith (f s) Is it possible to SPECIALIZE `f` for the type `T`? If I put the pragma {-# SPECIALIZE f :: String -> T #-} in module A, GHC complains that `T` is not in scope. If I put it in module B GHC complains that there is no accompanying binding for `f`. In my case, I don't want to put everything in a single module because I cannot know what other B-like modules people will implement. Are they bound to use `f` unspecialized for their types? Why? Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

3 3

Allowing Instances to Unify Types
by Matt Brown 27 Jul '10

27 Jul '10

Hi all, I've been hacking on GHC for a couple months now, experimenting with some different ideas I find interesting. One thing I'm trying to do is allow instance unifs (when there's an unambiguous choice, a question which is simplified in this case by there being only one), and force the required unification. Here's a simple example: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} class Apply a b c | a b -> c where applyInst :: a -> b -> c instance (Monad m) => Apply (a -> m b) (m a) (m b) where applyInst = (=<<) apply :: (Monad m) => (a -> m b) -> (m a) -> (m b) apply = (=<<) ioStr :: IO String ioStr = return "foo" printStr :: String -> IO () printStr = print main = do print `apply` (return "foo") printStr `applyInst` ioStr print `applyInst` (return "bar") -- this fails With my code to use the unif instance enabled, I get Ambiguous type variable errors for "Show a" (from print) and "Monad m" (from return). My question is: in the case of apply (which isn't implemented by a class), how does the typechecker propagate "a ~ String" and "m ~ IO" to the predicates for print and return? If someone (such as myself) had sufficient time and energy to spend trying to achieve similar behavior for applyInst, where might he/I start? Thanks and Regards, -matt

3 4

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