- Glasgow-haskell-users

Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC
by David Menendez 03 Feb '09

03 Feb '09

I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. This is possibly related to <http://trac.macports.org/ticket/15142> and <http://hackage.haskell.org/trac/ghc/ticket/2380>. cd extensible-exceptions && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp /bin/sh: line 1: 19203 Segmentation fault /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp make[1]: *** [bootstrapping.conf] Error 139 make: *** [stage1] Error 2 -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

3 3

ST monad and monad tranformers
by Tyson Whitehead 03 Feb '09

03 Feb '09

I have a situation in which I believe I need a parameterizable version of the strict ST monad. My computation type is "StateT s' (STT s (ErrorT e m)) a" (i.e., fails or succeeds and has an internal state involving a state thread). The STT type above is a version of ST like the ReaderT, StateT, etc. types. newtype STT s m a = STT ( State# s -> m (STTBox s a) ) data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a (I'm guessing on the UNPACK paragmas here) with runSTT :: (Monad m) => (forall s. STT s m a) -> m a runSTT m = case m of STT m' -> do STTBox _ x <- m' realWorld# return x (writing this as "runSTT (STT m') = ..." doesn't typecheck with ghc 6.8.2) instance Monad m => Monad (STT s m) where return x = STT $ \s -> return $ STTBox s x (STT m) >>= k = STT $ \s -> do STTBox s' x <- m s case k x of STT k' -> k' s' plus all the assorted instances for Functor, MonadPlus, MonadFix, MonadTrans, MonadReader, MonadState, etc. For example, instance MonadWriter w m => MonadWriter w (STT s m) where tell = lift . tell listen (STT m) = STT $ \s -> do (STTBox s' x,w) <- listen $ m s return $ STTBox s' (x,w) pass (STT m) = STT $ \s -> pass $ do STTBox s' (x,f) <- m s return (STTBox s' x,f) I was looking for any comments, wondering if there is a reason for this not existing in the library already, and what I should do in terms of paragmas and such for speed? I see the GHC-ST file has a mix of INLINE and NOINLINE. http://www.haskell.org/ghc/dist/current/docs/libraries/base/src/GHC-ST.html In particular, return, >>=, >>, and runST are marked INLINE, but there is a "regrettably delicate" comment that goes with the runST method. Also, what about the Functor, MonadPlus, MonadFix, MonadTrans, MonadReader, etc. methods? Thanks! -Tyson PS: I would be happy to provide the whole works to be added to the library if it is something that should be there.

3 5

Surprised to type in (1+n) as a type index!
by Ahn, Ki Yung 03 Feb '09

03 Feb '09

I was writing a document in lhs form and typed in something like this. > data Exp n where > Atom :: Exp () > List :: [Exp n] -> Exp (1+n) I wasn't expecting this to actually load up on GHCi, but when I load this up with the magical -fglasgow-exts option, it just worked !!! *Main> :t Atom Atom :: Exp () *Main> :t List [Atom, Atom] List [Atom, Atom] :: forall (+ :: * -> * -> *). Exp (+ GHC.Generics.Unit ()) It seems GHC is treating + as just a type variable for binary type constructor of kind * -> * -> *. *Main> :t List [Atom, Atom] List [Atom, Atom] :: forall (+ :: * -> * -> *). Exp (+ GHC.Generics.Unit ()) *Main> :t List [List [Atom, Atom], List []] List [List [Atom, Atom], List []] :: forall (+ :: * -> * -> *) (+1 :: * -> * -> *). Exp (+1 GHC.Generics.Unit (+ GHC.Generics.Unit ())) *Main> :t List [List [List [Atom, Atom], List []]] List [List [List [Atom, Atom], List []]] :: forall (+ :: * -> * -> *) (+1 :: * -> * -> *) (+2 :: * -> * -> *). Exp (+2 GHC.Generics.Unit (+1 GHC.Generics.Unit (+ GHC.Generics.Unit ()))) But, what is this GHC.Generics.Unit thing and where is this documented? Thanks, Ahn, Ki Yung

1 0

Core questions
by Matthijs Kooijman 02 Feb '09

02 Feb '09

(I've previously sent this mail to haskell-cafe, but I guess this list is more appropriate) Hi all, for my Master's thesis, I'm looking into functional hardware descriptions, and in particular to translate haskell code into VHDL that can be programmed into an FPGA. For this, I'm using the GHC API to load the haskell source and give me (simplified) core representation. I then walk over the core tree and translate it to VHDL. On the whole the GHC API has been very useful to me. It took me some time to get used to all the (deeply) nested (algebraic) types (I didn't have any previous haskell experience when I started a month or so ago), but things are working out by now. However, there are two issues bothering me still. The first is that the Core types (in particular CoreExpr) are not instances of Show. They are instances of Outputable, which allows them to be pretty printed. However, this pretty printing is good to view the structure of the expression that the CoreExpr represents, but doesn't show the structure of the CoreExpr itself. For example, tuple construction is printed simply as (a, b), while the actual core expression is a nested application of two types, and a and b to the GHC.Tuple.(,) function (or datacon?). Also, the exact constructors used are not quite clear, which made it harder to work with the Core language for me. Instead of looking at the structure of the CoreExpr and write the appropriate patterns, I had to resort to a lot of trial and error. I tried deriving show for CoreExpr myself, but that required me to derive Show for a dozen other types and resulted in type errors beyond my understanding. Is there any compelling reason that CoreExprs are not instances of Show? My second question concerns typle construction. Since tuple types are not primitive types, but dependent types defined in various places (GHC.Tuple and Base IIRC), code working with tuples is not fundamentally different from code working with other (user defined) dependent types and thus not trivial to recognize. I've found that there are some predicate functions that can tell me if a type is a tuple type, but I've had no such luck for the actual tuple construction. In particular, when an expression creates a tuple of two Ints (a, b), this is represented in Core as the application of the element types and the element values to the (,) function (or data constructor? Not sure about this, in Core it's just a Var and the isDataConName [IIRC] predicate crashes when run on the Var). For now, I've manually matched the Var's name to GHC.Tuple.(,) and removed all type arguments to get at the actual values in the tuple. This is of course completely non-portable, to tuples with more than two elements, or unboxed tuples, etc. Is there some predicate function that can do this for me in a more portable way? Gr. Matthijs

6 6

UVector overallocating for (Word/Int)(8/16/32)
by Tyson Whitehead 31 Jan '09

31 Jan '09

I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, and two times, respectively, as much memory as actually required. That is, newMBU n = ST $ \s1# -> case sizeBU n (undefined::e) of {I# len# -> case newByteArray# len# s1# of {(# s2#, marr# #) -> (# s2#, MBUArr n marr# #) }} sizeBU (I# n#) _ = I# (wORD_SCALE n#) wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD (sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64) which would seems to always allocate memory assuming an underlying alignment that is always eight bytes. It seems like the readWord(8/16/32)Array# functions may have once operated that way, but, when I dumped the assembler associated with them under ghc 6.8.2 (both native and C), I get readWord8Array leaq 16(%rsi),%rax movzbl (%rax,%rdi,1),%ebx jmp *(%rbp) readWord16Array leaq 16(%rsi),%rax movzwl (%rax,%rdi,2),%ebx jmp *(%rbp) readWord32Array leaq 16(%rsi),%rax movl (%rax,%rdi,4),%ebx jmp *(%rbp) readWord64Array leaq 16(%rsi),%rax movq (%rax,%rdi,8),%rbx jmp *(%rbp) which is using alignments of one, two, four, and eight bytes respectively. I'll attach a patch (which I haven't tested beyond compiling and looking at the generated assembler). Cheers! -Tyson

4 4

the impossible happened, large static list.
by Philip Weaver 30 Jan '09

30 Jan '09

Hello. I think I've seen other people encounter this problem before, but I wasn't able to find the solution, if there is one. I have a very large static list of type [[Int]]. It is 128 lists of 128 integers each. When I try to load the module that defines this list, I get an error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! - Philip

2 2

Haskell runtime in shared library?
by Patrick LeBoutillier 30 Jan '09

30 Jan '09

Hi, I'm trying to make a shared library containing the Haskell runtime, but no Haskell code per se. This shared library would then dynamically load other shared libraries containing conpiled Haskell code. Here is some pseudo code: In my_program: dlopen('my_haskell_runtime.so', RT_GLOBAL) ; hs_init(...) ; then later, in my_haskell_runtime.so: dlopen('my_haskell_module.so') ; __stginit_MyModule(); I've found some great information about FFI stuff here: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-… and here: http://blog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I can't seem to find examples where the runtime is in a different shared object from the Haskell code/module. Is this possible to do something like this using GHC? If so, where can I find more information of how exactly to link my_haskell_runtime.so and my_haskell_module.so? Note: I'm fairy new to FFI (and Haskell in general), so it is possible that my terminology is lacking. Thanks a lot, Patrick -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

2 1

a new impossible happened in ghci?
by Peter Hercek 30 Jan '09

30 Jan '09

Hi, My preliminary search indicated this is new, but still, should I add this to GHC Trac? Maybe I just cannot formulate my query well. See the ghci session log at the end. Peter. status:0 peter@dwarf [715] ~ % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :def err (\_->return$concat$replicate(read "\"1\"") "a") Prelude> :err ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): Prelude.read: no parse Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug status:0 peter@dwarf [715] ~ %

2 1

RE: [Haskell] type inference & instance extensions
by Simon Peyton-Jones 28 Jan '09

28 Jan '09

[Redirecting to GHC users] The <<loop>> is a bug. Thank you! I'll Trac it. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of Sittampalam, Ganesh | Sent: Monday, January 19, 2009 2:05 PM | To: haskell(a)haskell.org | Subject: RE: [Haskell] type inference & instance extensions | | Doug McIlroy wrote: | > A fragment of an attempt to make pairs serve as complex numbers, | using | > ghc/hugs extensions: | > | > instance Num a => Num (a,a) where | > (x,y) * (u,v) = (x*u-y*v, x*v+y*u) | > | > Unfortunately, type inference isn't strong enough to cope with | > | > (1,1)*(1,1) | > | > Why shouldn't it be strengthened to do so? | | The problem is that type classes are an "open" system. Although it's | obvious that your instance is the only one in this code that can be | used to type-check (1,1), that doesn't preclude new code adding an | instance that could make it behave differently. | | I had hoped that the code below (GHC 6.10+) would work, but it just | sends GHC into a loop when you actually try to typecheck (1,1). I don't | know if that's a bug in GHC or a misunderstanding on my part of how the | typechecking should work. | | {-# LANGUAGE FlexibleInstances, TypeFamilies #-} | | instance (a~b, Num a) => Num (a, b) where | fromInteger k = (fromInteger k, fromInteger 0) | (x,y) * (u,v) = (x*u-y*v, x*v+y*u) | | PS: Sorry, I didn't mean to say "typecheck (1,1)". I meant to say | "evaluate (1,1)*(1,1)" - I had a suspicion that some kind of infinite | polymorphic recursion through the Num instance is happening and | accidentally turned that thought into a completely different statement. | | | Ganesh | | ======================================================================= | ======= | Please access the attached hyperlink for an important electronic | communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ======================================================================= | ======= | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

new build system build fails on Solaris/x86
by Karel Gardas 28 Jan '09

28 Jan '09

Hello, I attempt to test new build system on solaris/x86 platform and after applying patch from here: http://hackage.haskell.org/trac/ghc/ticket/2951 I've been able to boot and configure the tree. On the other hand build alone fails with: checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... no checking readline/readline.h presence... no checking for readline/readline.h... no checking for sign of read_history result on error... negative checking for rl_completion_matches... no checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. gmake[1]: *** [libraries/editline/dist-install/package-data.mk] Error 1 gmake: *** [all] Error 2 karel@silence:/tmp/ghc-new-build-system$ Do you have any idea how to proceed or what exactly to install? Thanks, Karel

3 7