- Glasgow-haskell-users

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

ANN: Data.Array.Accelerate 0.8.0.0 — an EDSL for accelerated array computations
by Manuel M T Chakravarty 22 Aug '10

22 Aug '10

Data.Array.Accelerate defines an embedded language of array computations for high-performance computing. Computations on multi-dimensional, regular arrays are expressed in the form of parameterised collective operations (such as maps, reductions, and permutations). Version 0.8.0.0 of Accelerate includes a mostly feature-complete backend generating code for NVIDIA's CUDA language for general-purpose GPU computing. More on this release is at http://justtesting.org/second-beta-release-for-the-cuda-backend-of-a On Hackage: http://hackage.haskell.org/package/accelerate If you are keen on Haskell on GPUs, give this a spin! Manuel

1 0

Possible bug with GADTs?
by Dan Knapp 18 Aug '10

18 Aug '10

Below, please find a snippet from a program I'm working on, and the error it produces. I was told in #haskell that this was "pretty suspect" and could conceivably be a ghc bug. So I'm reporting it here. I'd also be grateful for workarounds. This is on ghc 6.12.1.20100203, but if people can't reproduce it I'll install a newer one; I'm just not eager to do that because of course it means rebuilding quite a lot of things. {-# LANGUAGE GADTs #-} module Foo where data TemplateValue t where TemplateList :: [a] -> TemplateValue [a] instance (Eq a) => Eq (TemplateValue a) where (==) (TemplateList a) (TemplateList b) = (==) a b Foo.hs:7:45: Could not deduce (Eq a1) from the context (a ~ [a2]) arising from a use of `==' at Foo.hs:7:45-52 Possible fix: add (Eq a1) to the context of the constructor `TemplateList' In the expression: (==) a b In the definition of `==': == (TemplateList a) (TemplateList b) = (==) a b In the instance declaration for `Eq (TemplateValue a)' -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

5 6

Re: Surprising strictness properties of pre-order fold over a Data.Map
by Johan Tibell 18 Aug '10

18 Aug '10

On Wed, Aug 18, 2010 at 4:38 PM, Lennart Augustsson < lennart.augustsson(a)gmail.com> wrote: > You don't know that f is strict in its first argument so you cannot > deduce that go is strict in z in the first case. > I'm not sure I understand. f :: Int -> Int -> Int -> Int f = \x y z -> x + y + z in this particular case so it's strict in all its parameters since + is strict (for Ints). f is inlined into go so it should be possible to deduce that go is indeed strict. As I mentioned to Ian you get the same result if you inline f manually. Cheers, Johan

1 0

Surprising strictness properties of pre-order fold over a Data.Map
by Johan Tibell 18 Aug '10

18 Aug '10

Hi, I was adding a strict pre-order fold to the Data.Map module and I ran into this slightly surprising behavior. Modeled on foldl' for lists I defined foldlWithKey' :: (b -> k -> a -> b) -> b -> Map k a -> b foldlWithKey' f z0 m = go z0 m where go z Tip = z go z (Bin _ kx x l r) = let x' = f (go z l) kx x in x' `seq` go x' r {-# INLINE foldlWithKey' #-} and, in a separate module, I defined this test module Test (test) where import qualified Data.Map as M test :: M.Map Int Int -> Int test m = M.foldlWithKey' (\n k v -> n + k + v) 0 m which generates this core: test1 :: Int test1 = I# 0 test_go2 :: Int -> Data.Map.Map Int Int -> Int test_go2 = \ (z_ani :: Int) (ds_anj :: Data.Map.Map Int Int) -> case ds_anj of _ { Data.Map.Tip -> z_ani; Data.Map.Bin _ kx_anp x_anq l_anr r_ans -> case test_go2 z_ani l_anr of _ { I# x1_ao5 -> case kx_anp of _ { I# y_ao9 -> case x_anq of _ { I# y1_Xot -> test_go2 (I# (+# (+# x1_ao5 y_ao9) y1_Xot)) r_ans } } } } test :: Data.Map.Map Int Int -> Int test = \ (m_ajo :: Data.Map.Map Int Int) -> test_go2 test1 m_ajo Note how the accumulator 'z' is not unboxed in the loop. I don't quite understand why that is. I do know I can get the core that I want by defining foldlWithKey2' :: (b -> k -> a -> b) -> b -> Map k a -> b foldlWithKey2' f z0 m = go z0 m where go z _ | z `seq` False = undefined go z Tip = z go z (Bin _ kx x l r) = go (f (go z l) kx x) r {-# INLINE foldlWithKey2' #-} and module Test (test2) where import qualified Data.Map as M test2 :: M.Map Int Int -> Int test2 m = M.foldlWithKey2' (\n k v -> n + k + v) 0 m you get this core: test2_$s$wgo2 :: Data.Map.Map Int Int -> Int# -> Int# test2_$s$wgo2 = \ (sc_soS :: Data.Map.Map Int Int) (sc1_soT :: Int#) -> case sc_soS of _ { Data.Map.Tip -> sc1_soT; Data.Map.Bin _ kx_anK x_anL l_anM r_anN -> case test2_$s$wgo2 l_anM sc1_soT of ww_sou { __DEFAULT -> case kx_anK of _ { I# y_ao9 -> case x_anL of _ { I# y1_Xow -> test2_$s$wgo2 r_anN (+# (+# ww_sou y_ao9) y1_Xow) } } } } $wtest2 :: Data.Map.Map Int Int -> Int# $wtest2 = \ (w_sox :: Data.Map.Map Int Int) -> test2_$s$wgo2 w_sox 0 test2 :: Data.Map.Map Int Int -> Int test2 = __inline_me (\ (w_sox :: Data.Map.Map Int Int) -> case $wtest2 w_sox of ww_soA { __DEFAULT -> I# ww_soA }) Note that the accumulator is now unboxed. Could someone please explain the difference. I would like to be able to to understand when I would get the former or the latter by looking at the Haskell source. Cheers, Johan

2 2

Template Haskell reification of instances
by Simon Peyton-Jones 13 Aug '10

13 Aug '10

Dear TH users In Template Haskell, it's not currently possible to say "give me all the instances of this class"; it's a long-standing feature request. Sam Anklesaria has come up with a design and implemented it. Before committing to it, I want to check that other Template Haskell users are happy with the design. You can find the details here: http://hackage.haskell.org/trac/ghc/ticket/1835 But a summary of the design appears below. If you have a stake in Template Haskell, pls RSVP by adding a comment to the ticket. Thanks Simon ================ Proposed design * Extending the Quasi monad to have class (Monad m, Functor m) => Quasi m where ... qReify :: Name -> m Info qIsClassInstance :: Name -> [Type] -> m Bool isClassInstance :: Name -> [Type] -> Q Bool isClassInstance n ts = Q (qIsClassInstance n ts) * Extending the info you get back when reifying a Class, by adding its instances: data Dec = ... | ClassI Dec [([TyVarBndr],Cxt,[Type])] Some random thoughts * In principle, I suppose that isClassInstance isn't really necessary: you could reify the class and search the list yourself. But I can see that it's convenient. * Currently isClassInstance returns True if any instances match, even if they overlap etc. Might you want to know more?

1 0

Using associated data types to create unpacked data structures
by Johan Tibell 13 Aug '10

13 Aug '10

Hi all, Inspired by the generic maps example at http://www.haskell.org/haskellwiki/GHC/Indexed_types I tried to use associated data types to create a generic finite map that unpacks both the key and value into the leaf data constructor. This makes functions such as lookup faster as the key can be accessed directly instead than via an indirection. It also makes the data structure more space efficient (4 words less per key/value pair for weight balanced trees), which makes it possible to fit more data in main memory (and cache). Memory overhead is important when working with "Big Data" processing, where fitting as much data in memory as possible is important. Working with big data sets is something done daily at companies like Google, Microsoft, Yahoo, Twitter, Facebook, etc. We can achieve the above goals using an associated data type like so: {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Ex where class Unbox k v where data Map k v :: * empty :: Map k v lookup :: k -> Map k v -> Maybe v insert :: k -> v -> Map k v -> Map k v and an instance instance Unbox Int Double where data Map Int Double = TipIntDouble | BinIntDouble {-# UNPACK #-} !Size {-# UNPACK #-} !Int {-# UNPACK #-} !Double !(Map Int Double) !(Map Int Double) -- implementation elided empty = undefined lookup k m = undefined insert k v m = undefined type Size = Int However, if we try to apply this method to large programs we run into problems: we need to defined instances for a large number of combinations of keys/values. We could generate a large number of instances, hoping that these will be enough for most users' needs, using Template Haskell or CPP. However, the potential number of instances is very large, about a hundred if you consider only Prelude types and tens of thousands if you include tuples. We cannot add instances for types not defined in base without adding a dependency on all libraries which data types we want to add instances for. Since we cannot define all instances up-front we'll have to rely on the user to create instances for the combinations she needs. This is tedious work for the user; most of the time the instance is an exact copy of the above instance for Int/Double, modulo renaming of the type arguments and the constructor names. Unfortunately our problems don't end here. If we assume for a second that the user writes the necessary boilerplate (perhaps using a Template Haskell function that generates it) there are still more problems ahead. It's quite likely that two different libraries wants an instance for the same types, and each declare one locally. However, now the poor user can't use both libraries as there are conflicting instances (or can she using some extension?) and imports always bring in instances. This problem exists for type classes in general but we only use ten or so type classes in most Haskell programs (e.g Functor, Monad, Eq, Ord, and Show) so it doesn't seem to be a big problem so far. What to do? It seems that associated data types might not be right tool for this problem. Could it be extended to work well for this use case? Can it be made to *scale* to large programs. Here's an idea: allow default implementations of associated data types, just like for methods class Unbox k v where data Map k v :: * empty :: Map k v lookup :: k -> Map k v -> Maybe v insert :: k -> v -> Map k v -> Map k v data Map Int Double = Tip | Bin {-# UNPACK #-} !Size {-# UNPACK #-} !k {-# UNPACK #-} !v !(Map k v) !(Map k v) -- implementation elided empty = undefined lookup k m = undefined insert k v m = undefined and export the definition in the interface file. This would allow instantiation of the type class without boilerplate instance Unbox Int Double -- no "body" The compiler would perhaps have to generate unique names for the constructors for this to work. This is not enough. We still have two problems left: * boilerplate instance declarations (but less so that before), and * instance collisions. Could we automatic create instances whenever the user mentions a type class? For example, if a program mentions f :: Map Int Double -> ... we know we need an instance for Int/Double and if we can't find one we derive one using the default definition. It is all the user needs to do when using the classic containers package. This would completely remove the boilerplate instance declarations. We could still use OverlappingInstances to allow the user to provide more specific instances (with a different implementation), if needed. This is akin to C++ template specialization. The compiler will need to help us with the instance collision problem in that it only generates on instance even if the same type parameters are used with the Map type in several different modules. Summary: While associated data types in theory allows us to create more efficient data structures, the feature doesn't seem to scale to large programs, for this use case. Cheers, Johan

8 19

how to link a minimal executable?
by Greg Fitzgerald 12 Aug '10

12 Aug '10

Is there any documentation or examples available that shows what needs to be linked to get a haskell executable to print "hello world"? Instead of using GHC to link, I'm interested in using gcc, ar, or link directly. For starters, what implements the entry point? $ cat Main.hs main = print "hello world" $ ghc -c Main.hs $ Vs8/VC/bin/link.exe -NOLOGO Main.o LINK : fatal error LNK1561: entry point must be defined I see using ghc -v, it links all sorts of stuff: $ ghc -v Main.hs ... *** Linker: ... -lHSrtsmain -lHShaskell98-1.0.1.1 -lHSrandom-1.0.0.2 -lHStime-1.1.4 -lHSprocess-1.0.1.2 -lHSdirectory-1.0.1.0 -lHSold-time-1.0.0.3 -lHSold-locale-1.0.0.2 -lHSfilepath-1.1.0.3 -lHSWin32-2.2.0.1 -luser32 -lgdi32 -lwinmm -ladvapi32 -lshell32 -lshfolder -lHSbytestring-0.9.1.5 -lHSarray-0.3.0.0 -lHSbase-4.2.0.0 -lwsock32 -luser32 -lshell32 -lHSinteger-simple-0.1.0.0 -lHSghc-prim-0.2.0.0 -lHSrts -lm -lwsock32 -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u _base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -lHSffiReading Any insight would be greatly appreciated. Thanks, Greg

3 2