August 2010 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Confusing warnings from GHC HEAD
by Bryan O'Sullivan 04 Sep '10

04 Sep '10

I get a few dozen of these when building the text package, and they weren't present in 6.12 or earlier: SpecConstr Function `$wa1{v X5A2} [lid]' has three call patterns, but the limit is 2 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations There are a few aspects to this that I find surprising. - I can't do anything with the Core name. - My cabal file contains -fspec-constr-count=5 just to be safe, but it doesn't help. I can't tell whether this is the compiler going a little off into the weeds, or whether I'm doing something wrong, but I appear to be unable to make the message go away. Thanks, Bryan.

4 6

FFI, signals and exceptions
by Edward Z. Yang 02 Sep '10

02 Sep '10

Hello all, I am currently investigating techniques to nicely handle SIGINTs when FFI code is running. Yes, I know it sounds kind of crazy. Ignoring the problems of cleaning up the unceremoniously terminated C computation, I'm having difficulty getting the FFI to /stop/ running when I get the signal. I currently have some code like this: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28422#a28422 which doesn't work, and which you guys can probably tell me doesn't work. :-) Throwing exceptions from the signal handler also doesn't work. Any suggestions for GHC source code to look at / techniques to try? Cheers, Edward

3 16

HEAD unbuildable
by Johan Tibell 31 Aug '10

31 Aug '10

I'm having trouble building HEAD, to the point where even running "make clean" fails. $ make clean && make maintainer-clean make -r --no-print-directory -f ghc.mk clean CLEANING=YES "rm" -rf inplace "rm" -rf "rm" -rf docs/users_guide/users_guide docs/users_guide/users_guide.pdf docs/users_guide/users_guide.ps "rm" -rf docs/users_guide/users_guide.xml docs/users_guide/what_glasgow_exts_does.gen.xml "rm" -rf docs/man/ghc.1 docs/man/flags.xsl docs/man/flags.xml "rm" -rf libraries/Cabal/doc/Cabal libraries/Cabal/doc/Cabal.pdf libraries/Cabal/doc/Cabal.ps "rm" -rf utils/unlit/dist "rm" -rf inplace/lib/ "rm" -rf utils/hp2ps/dist "rm" -rf inplace/bin/hp2ps "rm" -rf driver/mangler/dist inplace/lib/ "rm" -rf driver/split/dist inplace/lib/ "rm" -rf utils/genprimopcode/dist "rm" -rf inplace/bin/ "rm" -rf libffi/build libffi/stamp.ffi.* libffi/dist-install "rm" -rf includes/dist-derivedconstants "rm" -rf inplace/bin/mkDerivedConstants "rm" -rf includes/dist-ghcconstants "rm" -rf inplace/bin/mkGHCConstants "rm" -rf includes/ghcautoconf.h includes/ghcplatform.h includes/GHCConstants.h includes/DerivedConstants.h "rm" -rf rts/dist "rm" -rf bindisttest/"install dir" bindisttest/HelloWorld bindisttest/HelloWorld.o bindisttest/HelloWorld.hi bindisttest/output "rm" -rf utils/ghc-cabal/dist bootstrapping "rm" -rf utils/ghc-cabal/dist-dummy-ghc "rm" -rf inplace/bin/dummy-ghc "rm" -rf utils/genapply/dist "rm" -rf inplace/bin/ "rm" -rf utils/haddock/dist "rm" -rf utils/haddock/doc/haddock utils/haddock/doc/haddock.pdf utils/haddock/doc/haddock.ps make[1]: *** No rule to make target `clean_libraries/dph/dph-base', needed by `clean_libraries/dph'. Stop. make: *** [clean] Error 2 A normal make fails on some profiling thingy. -- Johan

3 3

RE: late optimization of typeclass callers
by christian Hoener zu Siederdissen 27 Aug '10

27 Aug '10

Thanks that is *exactly* the problem I am having. The missing line breaks are kind of weird. I will try the newest head (which will mean getting about 20 libs to compile...) and report back. I left the core out intentionally because the vector library tends to produce ugly core when it can not optimize. Should the problem *not* go away with HEAD (right now I am using 6.12.3) then I will create a self-contained set of files that reproduce the problem. Thanks again, Christian ----- Original message ----- > It's hard to read your code because the line breaks have been removed. > Moreover I think your code depends on some unspecified Hackage package. > And I couldn't find the enclosed Core dumps. Nor do you specify which > version of GHC you are using. > > Still I believe that the nub is this. You have a class with a default > method declaration > > class FoldFunctions a where > opt = <blah> > > and you get different behaviour if you say > > instance FoldFunctions Int > from > instance FoldFunctions Int where > opt = <blah> > > That's surprising because the second case simply fills in the method > with the identical code to the code in the class declaration. > > Is that right? > > If so, I think you might want to try the HEAD. Can you do that (use a > binary snapshot). I think I fixed this default-method-inlining stuff so > that there is no difference between the above two. > > But I could have failed, or there could be something else going on in > your example. > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of > Christian Höner zu Siederdissen | Sent: 26 August 2010 10:36 > | To: Glasgow-Haskell-Users > | Subject: late optimization of typeclass callers > | > | Hi, > | > | I do have the problem that my code is not completely optimized. We > begin with | > | -- Ring.hs > | class Ring a where > | rmult :: a -> a -> a > | zero :: a > | > | -- PrimitiveArray.hs > | class PrimArrayOps a b where > | data PrimArray a b :: * > | unsafeIndex :: PrimArray a b -> a -> b > | > | -- PAInstances.hs > | -- for any 'a' of Data.Primitive.Types by Roman, have unboxed arrays > instance | (Prim a) => PrimArrayOps where > | data PrimArray (Int,Int) a = PaIIxI {-# UNPACK #-} !(Int,Int) {-# > UNPACK #- | } !ByteArray > | unsafeIndex (PaIIxI (mI,mJ) arr) (i,j) = {-# CORE "IIxIunsafeIndex" > #-} | case (i*(mJ+1)+j) of idx -> indexByteArray arr idx > | > | -- RNAfoldFunctions.hs > | -- VU.Unbox a, because of the vector package import > Data.Vector.Unboxed as VU | class (Ring a, VU.Unbox a, Prim a) => > FoldFunctions a where | opt = VU.foldl' rmult zero $ base turnertables > inp table table i j | > | base trnr inp m m1 i j = VU.zipWith rmult ms m1s where > | cnt = j-i-2 -- TODO when to stop? > | ms = VU.map (\ik -> m `unsafeIndex` ik) $ VU.generate cnt (\k -> > | (i,i+k)) > | m1s = VU.map (\kj -> m1 `unsafeIndex` kj) $ VU.generate cnt (\k -> > | (k+1+i,j)) {-# INLINE multibranchCloseBase #-} > | > | > | > | If I now use this stuff... > | -- [1] > | instance Ring Int where > | rmult = min > | zero = 10000 > | instance FoldFunctions Int > | module MyProgram where > | main = do > | let val = opt trnr inp myM myM1 15 78 > | > | I get this core [1]. If I do this > | -- [2] > | instance Ring Int where > | rmult = min > | zero = 10000 > | instance FoldFunctions Int > | opt = VU.foldl' rmult zero $ base turnertables inp table table i j > module | MyProgram where main = do > | let myM = PrimArray of (Int,Int) with Int values > | ... > | let val = opt trnr inp myM myM1 15 78 > | > | Is there a way to get the program without an explicit FoldFunctions > instance | to specialize to the same Core as the second? The runtime > (Criterion was | used) is 7.1us (or worse) for [1] and 2.7us for [2]. I > could put nice INLINEs | everywhere but they do not help optimizing. > These functions run O(n^2) times, | with n between 100 and 10000. The > core shows that temporary arrays are even | created, filled, and then > the fold run over them. | > | So basically, can I get code running through several class instances > to be | optimized at the caller, where all instances are known? > Otherwise I could | live with [2], but as the code will almost always be > the same for | FoldFunctions instances, it would be really nice to be > able to use the | defaults that were defined on (Ring a, VU.Unbox a, > Prim a). | > | Thanks, > | Christian

1 0

late optimization of typeclass callers
by Christian Höner zu Siederdissen 27 Aug '10

27 Aug '10

Hi, I do have the problem that my code is not completely optimized. We begin with -- Ring.hs class Ring a where rmult :: a -> a -> a zero :: a -- PrimitiveArray.hs class PrimArrayOps a b where data PrimArray a b :: * unsafeIndex :: PrimArray a b -> a -> b -- PAInstances.hs -- for any 'a' of Data.Primitive.Types by Roman, have unboxed arrays instance (Prim a) => PrimArrayOps where data PrimArray (Int,Int) a = PaIIxI {-# UNPACK #-} !(Int,Int) {-# UNPACK #-} !ByteArray unsafeIndex (PaIIxI (mI,mJ) arr) (i,j) = {-# CORE "IIxIunsafeIndex" #-} case (i*(mJ+1)+j) of idx -> indexByteArray arr idx -- RNAfoldFunctions.hs -- VU.Unbox a, because of the vector package import Data.Vector.Unboxed as VU class (Ring a, VU.Unbox a, Prim a) => FoldFunctions a where opt = VU.foldl' rmult zero $ base turnertables inp table table i j base trnr inp m m1 i j = VU.zipWith rmult ms m1s where cnt = j-i-2 -- TODO when to stop? ms = VU.map (\ik -> m `unsafeIndex` ik) $ VU.generate cnt (\k -> (i,i+k)) m1s = VU.map (\kj -> m1 `unsafeIndex` kj) $ VU.generate cnt (\k -> (k+1+i,j)) {-# INLINE multibranchCloseBase #-} If I now use this stuff... -- [1] instance Ring Int where rmult = min zero = 10000 instance FoldFunctions Int module MyProgram where main = do let val = opt trnr inp myM myM1 15 78 I get this core [1]. If I do this -- [2] instance Ring Int where rmult = min zero = 10000 instance FoldFunctions Int opt = VU.foldl' rmult zero $ base turnertables inp table table i j module MyProgram where main = do let myM = PrimArray of (Int,Int) with Int values ... let val = opt trnr inp myM myM1 15 78 Is there a way to get the program without an explicit FoldFunctions instance to specialize to the same Core as the second? The runtime (Criterion was used) is 7.1us (or worse) for [1] and 2.7us for [2]. I could put nice INLINEs everywhere but they do not help optimizing. These functions run O(n^2) times, with n between 100 and 10000. The core shows that temporary arrays are even created, filled, and then the fold run over them. So basically, can I get code running through several class instances to be optimized at the caller, where all instances are known? Otherwise I could live with [2], but as the code will almost always be the same for FoldFunctions instances, it would be really nice to be able to use the defaults that were defined on (Ring a, VU.Unbox a, Prim a). Thanks, Christian

2 1

__emutls_get_address link problem
by Christian Maeder 26 Aug '10

26 Aug '10

Hi, I've created a sparc solaris installation of ghc-6.12.3 using gcc-4.3.3 However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts! With ghc-6.12.1 and gcc-4.x.y (x < 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. Does anybody have an explanation or proposal to fix this? Thanks Christian Linking Hello ... /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o): In function `scavenge_until_all_done': GC.c:(.text+0x178): undefined reference to `__emutls_get_address' GC.c:(.text+0x204): undefined reference to `__emutls_get_address' GC.c:(.text+0x250): undefined reference to `__emutls_get_address' GC.c:(.text+0x27c): undefined reference to `__emutls_get_address' GC.c:(.text+0x338): undefined reference to `__emutls_get_address' /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o):GC.c:(.text+0x408): more undefined references to `__emutls_get_address' follow collect2: ld returned 1 exit status -bash-3.00$ gcc -v Reading specs from /export/local/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77: (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.4 gcc used for Building ghc-6.12.3 Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC)

4 8

SIGPIPE in the GHC runtime
by Brian Bloniarz 26 Aug '10

26 Aug '10

The GHC runtime ignores SIGPIPE by setting the signal to SIG_IGN. This means that any subprocesses (created via System.Process or otherwise) will also have their SIGPIPE handler set to SIG_IGN; I think this might be a bug. The Python runtime does the same thing, there's a good explanation of the drawbacks in: http://bugs.python.org/issue1652 IMHO the simplest fix is the patch below: simply avoid SIG_IGN, instead install a handler which does nothing. This way, an exec() restores the handler to SIG_DFL. I've included a testcase too. Do people think this is the way to go? I think the alternative is the approach Python took: patch the various bits of code that fork&exec and have them restore the signal handler manually. --- diff -rN old-ghc/rts/posix/Signals.c new-ghc/rts/posix/Signals.c 472a473,477 > static void > ignoreSigPipe(int sig) > { > } > 528,529c533,535 < // ignore SIGPIPE; see #1619 < action.sa_handler = SIG_IGN; --- > // ignore SIGPIPE; see #1619. Don't use SIG_IGN since that'd > // be inherited by any children that get fork&exec'd. > action.sa_handler = &ignoreSigPipe; 531c537 < action.sa_flags = 0; --- > action.sa_flags = SA_RESTART; --- Testcase: diff -rN old-testsuite/tests/ghc-regress/rts/all.T new-testsuite/tests/ghc-regress/rts/all.T 86a87,88 > > test('exec_signals', [cmd_prefix('$MAKE exec_signals-prep && ./exec_signals_prepare')], compile_and_run, ['']) diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_child.c new-testsuite/tests/ghc-regress/rts/exec_signals_child.c 0a1,47 > #include <signal.h> > #include <stdio.h> > #include <errno.h> > > // Prints the state of the signal handlers to stdout > int main() > { > int open = 0, i; > sigset_t blockedsigs; > > printf("ChildInfo { masked = ["); > > sigprocmask(SIG_BLOCK, NULL, &blockedsigs); > for(i = 0; i < NSIG; ++i) > { > int ret = sigismember(&blockedsigs, i); > if(ret >= 0) > { > if(!open) > open=1; > else > printf(","); > printf("(%d,%s)", i, ret == 1 ? "True" : "False"); > } > } > printf("], handlers = ["); > > open = 0; > for(i = 0; i < NSIG; ++i) > { > struct sigaction old; > if(sigaction(i, NULL, &old) >= 0) > { > if(!open) > open=1; > else > printf(","); > > printf("(%d,%s)", i, > old.sa_handler == SIG_IGN ? "Ignored" : > (old.sa_handler == SIG_DFL ? "Default" : "Handled")); > } > } > printf("]}"); > > return 0; > } diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals.hs new-testsuite/tests/ghc-regress/rts/exec_signals.hs 0a1,20 > import System.Process > import System.Posix.Signals > import Control.Monad(when) > > data SigState = Ignored | Default | Handled > deriving (Eq, Read, Show) > > data ChildInfo = ChildInfo { > masked :: [(Int,Bool)], > handlers :: [(Int, SigState)] } > deriving (Read, Show) > > main = do out <- readProcess "./exec_signals_child" [] "" > let ci = read out :: ChildInfo > blockedSigs = [x | (x, True) <- masked ci] > ignoredSigs = [x | (x, Ignored) <- handlers ci] > when (not $ null blockedSigs) $ > putStrLn ("signals " ++ show blockedSigs ++ " are blocked") > when (not $ null ignoredSigs) $ > putStrLn ("signals " ++ show ignoredSigs ++ " are ignored") diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c new-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c 0a1,29 > #include <signal.h> > #include <stdio.h> > #include <errno.h> > #include <string.h> > > // Invokes a process, making sure that the state of the signal > // handlers has all been set back to the unix default. > int main(int argc, char **argv) > { > int i; > sigset_t blockedsigs; > struct sigaction action; > > // unblock all signals > sigemptyset(&blockedsigs); > sigprocmask(SIG_BLOCK, NULL, NULL); > > // reset all signals to SIG_DFL > memset(&action, 0, sizeof(action)); > action.sa_handler = SIG_DFL; > action.sa_flags = 0; > sigemptyset(&action.sa_mask); > for(i = 0; i < NSIG; ++i) > sigaction(i, &action, NULL); > > execv(argv[1], argv+1); > fprintf(stderr, "failed to execv %s\n", argv[1]); > return 0; > } diff -rN old-testsuite/tests/ghc-regress/rts/Makefile new-testsuite/tests/ghc-regress/rts/Makefile 29a30,32 > exec_signals-prep:: > $(CC) -o exec_signals_child exec_signals_child.c > $(CC) -o exec_signals_prepare exec_signals_prepare.c

3 8

DataCon workers and wrapers through GHC API
by Victor Nazarov 25 Aug '10

25 Aug '10

Is it possible to generate bindings for worker and wrapper of data constructor through GHC API? How can I do it? I want CoreBindings or StgBindings for workers and wrappers for all data constructors of the module... -- Victor Nazarov

2 1

GHC-HEAD 19.Aug.2010, llvm, threaded [Memory Exhaustion]
by Christian Höner zu Siederdissen 23 Aug '10

23 Aug '10

Hi, using: http://www.haskell.org/ghc/dist/current/dist/ghc-6.13.20100819-x86_64-unkno… parallel-3.1.0.0 and the most-common test program ... ever: module Main where import Control.Parallel.Strategies fib :: Int -> Int fib n | n < 1 = error "n < 1" | n == 1 = 1 | n == 2 = 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rdeepseq fib $ [1..100] main = do mapM_ (putStrLn . show) $ zip [1..] fibs ghc -fllvm -threaded -rtsopts -O2 Prog.hs ./Prog -- runs slowly through 1..100 [OK] ./Prog +RTS -N2 -RTS -- requests all available memory [NOT OK] ghc -fllvm -threaded -rtsopts Prog.hs ./Prog +RTS -N2 -RTS -- slowly but [OK] Can anybody confirm this? Gruss, Christian

2 1