- Glasgow-haskell-users

porting using unregisterised build: x86->amd64 solaris
by Karel Gardas 11 Oct '10

11 Oct '10

Hello, I'm attempting to make unregisterised build of recent GHC head on Solaris/x86 for Solaris/amd64 platform. I'm closely following: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#Cross-compilingto… with the only one issue: mentioned: echo compiler/main/Config.hs >> list seems to be incorrect due to missing compiler/main/Config.hs file which means gtar will fail on it later. However I've got to the: <T>$ make all_ghc_stage2 2>&1 | tee c.log step which fails with: gmake -r --no-print-directory -f ghc.mk phase=0 just-makefiles "" configure --with-ghc="/export/home/karel/vcs/ghc-target/" --with-ghc-pkg="/export/home/karel/vcs/ghc-target/" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --ghc-option=-DOMIT_NATIVE_CODEGEN --ghc-option=-DNO_REGS --flags=stage2 --ghc-option=-DSTAGE=2 --disable-library-for-ghci --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-g -O0 -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=613 -Iincludes " --configure-option=LDFLAGS=" " -- stage2 compiler /bin/sh: line 1: : cannot execute [Is a directory] gmake[1]: *** [compiler/stage2/package-data.mk] Error 126 gmake: *** [all_ghc_stage2] Error 2 To me it looks like it's perhaps expecting to have `ghc' binary in /export/home/karel/vcs/ghc-target/ but there is only `ghc' subdirectory there hence failing. Also I'm not sure I've detected correctly mentioned "unimportant build failures in the RTS" as I've got one which looks like: gmake -r --no-print-directory -f ghc.mk all "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Irts -optc-DCOMPILING_RTS -optc-DNOSMP -optc-fno-strict-aliasing -optc-fno-common -optc-Ilibffi/build/include -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -H32m -O -H32m -Iincludes -Irts -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -Ilibffi/build/include -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -keep-hc-files -c rts/Linker.c -o rts/dist/build/Linker.o rts/Linker.c: In function `do_Elf_Rel_relocations': rts/Linker.c:3784:0: warning: cast from pointer to integer of different size rts/Linker.c:3785:0: warning: cast to pointer from integer of different size rts/Linker.c:3807:0: warning: cast from pointer to integer of different size rts/Linker.c:3815:0: warning: cast from pointer to integer of different size rts/Linker.c:3819:0: warning: cast from pointer to integer of different size rts/Linker.c: In function `do_Elf_Rela_relocations': rts/Linker.c:3866:0: warning: cast from pointer to integer of different size rts/Linker.c:3903:0: warning: cast from pointer to integer of different size rts/Linker.c:3915:0: warning: cast from pointer to integer of different size rts/Linker.c:4028:0: error: `R_X86_64_64' undeclared (first use in this function) rts/Linker.c:4028:0: error: (Each undeclared identifier is reported only once rts/Linker.c:4028:0: error: for each function it appears in.) rts/Linker.c:4029:0: warning: cast to pointer from integer of different size rts/Linker.c:4032:0: error: `R_X86_64_PC32' undeclared (first use in this function) rts/Linker.c:4038:0: warning: comparison between signed and unsigned rts/Linker.c:4048:0: warning: cast to pointer from integer of different size rts/Linker.c:4056:0: warning: cast to pointer from integer of different size rts/Linker.c:4060:0: error: `R_X86_64_32' undeclared (first use in this function) rts/Linker.c:4074:0: warning: cast to pointer from integer of different size rts/Linker.c:4078:0: error: `R_X86_64_32S' undeclared (first use in this function) rts/Linker.c:4082:0: warning: comparison between signed and unsigned rts/Linker.c:4092:0: warning: cast to pointer from integer of different size rts/Linker.c:4096:0: error: `R_X86_64_GOTPCREL' undeclared (first use in this function) rts/Linker.c:4100:0: warning: cast to pointer from integer of different size rts/Linker.c:4104:0: error: `R_X86_64_PLT32' undeclared (first use in this function) rts/Linker.c:4110:0: warning: comparison between signed and unsigned rts/Linker.c:4115:0: warning: cast to pointer from integer of different size gmake[1]: *** [rts/dist/build/Linker.o] Error 1 gmake: *** [all] Error 2 karel@silence:~/vcs/ghc-host$ I do have two questions: 1) is the url above describing cross-compiling GHC for porting up-to-date? 2) is there any trick how to get my last step (i.e. <T>$ make all_ghc_stage2 2>&1 | tee c.log) working? Thanks! Karel

3 7

Bringing back Monad Comprehensions (in style)
by George Giorgidze 07 Oct '10

07 Oct '10

Bringing back Monad Comprehensions (in style). Dear GHC users, My colleagues and I are working on Haskell embedded DSL for data-intensive and data-parallel applications [1]. The idea is to provide the Haskell list prelude combinators to manipulate database-resident data. The combinators are not executed in Haskell runtime, instead they are compiled down to SQL, executed on relational database systems and the results are marshalled back to Haskell for further in-heap processing or generation of new database-able embedded programs. Although programming with the standard list processing combinators is feasible, the embedded programs are much more concisely formulated using the list comprehension notation, especially, when extended with 'order by' and 'group by' constructs [2]. Unfortunately, in Haskell, the list comprehension notation is only available for processing lists. In order to support the list comprehension notation, we have built a quasiquter that desugars the list comprehension notation, but, instead of generating code using the Haskell list prelude combinators the quasiquter generates code that uses list processing combinators from our embedded language. Although the quasiquoting approach worked for us, it has a number of drawbacks: * Introduces extra syntactic noise * Error messages are hard to understand as they refer to generated code * Needs to be re-implemented for every list-based embedded language One way to address the aforementioned drawbacks is to define our queries as a monad (similar to list monad) and use the monad comprehension notation. The do notation can be used but it is less suited for query languages. Unfortunately monad comprehensions were removed from Haskell, prior to Haskell 98. However, I think that the notation is extremely useful not only for lists, but for other list like data structures, list-based query languages (see above), maybe even for wider range of EDSLs and monads. I think the feature deserves to be supported at least as a GHC language extension. Thus, I would like to propose to design and implement the monad comprehension notation as a GHC language extension. I am willing to invest some time and contribute to this effort. One can also look at how recently introduced 'order by' and 'group by' constructs generalise to monad comprehensions. If that works, one could implement even more "stylish" monad comprehension notation. Feedback from GHC users and developers would be very much appreciated. * Do you think that this is a good idea? * Would you use monad comprehensions (if available) for your library/EDSL/application? * Do you think that it would be hard to integrate this extension into current GHC codebase? * Have you already thought about how to generalise 'order by' and 'group by' to monad comprehensions? * Have you already thought about how to address the original objections to the monad comprehension notation? Cheers, George [1] http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf [2] http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/

6 8

Profiling: 0 entries but high costs
by Stefan Wehr 06 Oct '10

06 Oct '10

Hi all, here is some profiling output which shows strange behavior: COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 ... CAF:runHttpNewsWatch_watchNews MobileGateway.DataClient.HttpNewsWatch 8685 1 0.0 0.0 90.2 95.7 watchNews MobileGateway.LubSync.NewsWatch 12239 14 0.0 0.0 90.2 95.7 watchNewsIteration MobileGateway.LubSync.NewsWatch 12283 4 0.0 0.0 90.2 95.7 ... getAndProcessNews MobileGateway.LubSync.NewsWatch 12284 156 0.0 0.0 90.2 95.7 ... handleNewsItem MobileGateway.LubSync.NewsWatch 12526 577 0.0 0.0 88.9 95.1 ... dsLoadObject_a7eq MobileGateway.DataClient.HttpDs 12648 144 0.0 0.0 84.0 91.5 loadObject MobileGateway.DataClient.HttpDs 12650 720 0.7 0.6 84.0 91.5 ... runNewsWatchTInIO MobileGateway.DataClient.HttpNewsWatch 12654 0 0.0 0.0 69.5 80.3 runHttpDsM MobileGateway.DataClient.HttpDs 12655 0 69.5 80.3 69.5 80.3 The cost centre runHttpDsM has yero entries but rather high costs. How can this be? According to the manual, the entries column specifies "the number of times this particular point in the call graph was entered". From this definition I would conclude that a cost centre with zero entries cannot have any costs. What am I doing wrong? Thanks for helping. -- Stefan

2 1

Attempt at building on OpenBSD/sparc64 - failure at "make all_ghc_stage2"
by Benjamin Jansen 05 Oct '10

05 Oct '10

Hello, I am attempting to build GHC 6.12.3 on OpenBSD4.4/sparc64 [1]. I've been following the instructions on the Porting page [2], using a Linux x86 system as the host machine. I've gotten to executing the following command on the target system: aogail@netra> gmake all_ghc_stage2 ===--- updating makefiles phase 0 gmake -r --no-print-directory -f ghc.mk phase=0 just-makefiles "" configure --with-ghc="/home/aogail/software/ghc-6.12.3/" --with-ghc-pkg="/home/aogail/software/ghc-6.12.3/" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --ghc-option=-DOMIT_NATIVE_CODEGEN --ld-options=-E --flags=stage2 --ghc-option=-DSTAGE=2 --ghc-options='-O2' --configure-option=CFLAGS="-g -O0 -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=612 -Iincludes " --configure-option=LDFLAGS=" " -- stage2 compiler /bin/sh: : cannot execute - Is a directory gmake[1]: *** [compiler/stage2/package-data.mk] Error 126 gmake: *** [all_ghc_stage2] Error 2 My experience with complicated make systems is limited so I'm not sure where to look at this point. Can I get some pointers? Thanks, Ben Jansen 1: http://hackage.haskell.org/trac/ghc/ticket/3511 2: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting

2 2

Cabal constraint solver
by Christian Höner zu Siederdissen 05 Oct '10

05 Oct '10

Hi, does the Cabal constraint solver always try to solve the complete graph? example: (ghc-7.0.0-rc1) $ cabal install parsec-3.1.0 cabal: cannot configure syb-0.2.1. It requires base >=4.0 && <4.3 cd syb-0.2.1 * remove base<4.3 constraint from syb.cabal cabal install * syb-0.2.1 is now installed and works! $ cabal install parsec-3.1.0 cabal: cannot configure syb-0.2.1. It requires base >=4.0 && <4.3 This is rather annoying: the constraint is solved (eg. syb is installed) but we /still/ assume that we can not continue. So obviously, I would like to be able to have cabal assume constraints fullfilled if the package is installed. Am I missing something? (Otherwise, testing packages with 7-rc1 is becoming annoying as almost everything depends on syb) === And a second thing: cabal fetch How does one disable the solver for fetching packages? It is a bit annoying (here too) that 'cabal fetch parsec-3.1.0' fails. (It should maybe warn that constraints can not be fulfilled but the idea here is to get the packages to change them manually) === So did I miss anything or can I write a bug report? ;-) Gruss, Christian

5 5

haddock and associated data families
by Christian Höner zu Siederdissen 03 Oct '10

03 Oct '10

Hi, haddock seems to produce an error on associated data family decls.: http://hackage.haskell.org/packages/archive/PrimitiveArray/0.0.2.1/logs/fai… line 22, where the errors occurs is exactly this one: class PrimArrayOps a b where data PrimArray a b :: * -- ^ PrimArray data type I'll fix it by trying other methods to put comments there. Could someone enter this as a bug, if it is not done yet? (Assuming it is a bug ;-) Thanks, Christian

3 2

Re: Cabal constraint solver
by Christian Höner zu Siederdissen 03 Oct '10

03 Oct '10

Hi, thanks to you all for the answers. I will then go with increasing the version number for testing, this seems to be the easiest way to go. And indeed, 'cabal unpack' fetches ( ;-) ) the package without checking that constraints are met. Gruss, Christian * Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> [03.10.2010 00:07]: > Hi, > > does the Cabal constraint solver always try to solve the complete graph? > > example: (ghc-7.0.0-rc1) > > $ cabal install parsec-3.1.0 > cabal: cannot configure syb-0.2.1. It requires base >=4.0 && <4.3 > > cd syb-0.2.1 > * remove base<4.3 constraint from syb.cabal > cabal install > * syb-0.2.1 is now installed and works! > > $ cabal install parsec-3.1.0 > cabal: cannot configure syb-0.2.1. It requires base >=4.0 && <4.3 > > > > This is rather annoying: the constraint is solved (eg. syb is installed) > but we /still/ assume that we can not continue. So obviously, I would > like to be able to have cabal assume constraints fullfilled if the > package is installed. > > Am I missing something? (Otherwise, testing packages with 7-rc1 is > becoming annoying as almost everything depends on syb) > > === > > And a second thing: cabal fetch > How does one disable the solver for fetching packages? It is a bit > annoying (here too) that 'cabal fetch parsec-3.1.0' fails. (It should > maybe warn that constraints can not be fulfilled but the idea here is to > get the packages to change them manually) > > === > > So did I miss anything or can I write a bug report? ;-) > > > > Gruss, > Christian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Parallel build broken
by Florian Weimer 30 Sep '10

30 Sep '10

<http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking> says that parallel builds are supported, but this doesn't seem to be true anymore. This is a bit unfortunate because in theory, builds should parallelize quite well.

2 2

GHC 7.0.1 rc1: Could not deduce (Typeable a) from the context (Typeable a, …)
by Malte Sommerkorn 30 Sep '10

30 Sep '10

While compile failures were easy to fix for syb, X11 and xmonad, here's a more mysterious encounter with xmonad-contrib. The module in question is http://code.haskell.org/XMonadContrib/XMonad/Layout/MultiToggle.hs and the rest of this mail is the error: XMonad/Layout/MultiToggle.hs:194:30: Could not deduce (Typeable a) from the context (Typeable a, Show ts, HList ts a, LayoutClass l a) arising from a use of `fromMessage' Possible fix: add (Typeable a) to the context of the instance declaration In a stmt of a pattern guard for an equation for `handleMessage': Just (Toggle t) <- fromMessage m In an equation for `handleMessage': handleMessage mt m | Just (Toggle t) <- fromMessage m, i@(Just _) <- find (transformers mt) t = case currLayout mt of { EL l det -> do { l' <- fromMaybe l `fmap` handleMessage l (SomeMessage ReleaseResources); .... } where cur = (i == currIndex mt) } | otherwise = case currLayout mt of { EL l det -> fmap (fmap (\ x -> mt {currLayout = EL x det})) $ handleMessage l m } In the instance declaration for `LayoutClass (MultiToggle ts l) a' XMonad/Layout/MultiToggle.hs:195:25: Could not deduce (HList ts a) from the context (Typeable a, Show ts, HList ts a, LayoutClass l a, Transformer t a) arising from a use of `find' Possible fix: add (HList ts a) to the context of the data constructor `Toggle' or the instance declaration In a stmt of a pattern guard for an equation for `handleMessage': i@(Just _) <- find (transformers mt) t In a stmt of a pattern guard for an equation for `handleMessage': Just (Toggle t) <- fromMessage m In an equation for `handleMessage': handleMessage mt m | Just (Toggle t) <- fromMessage m, i@(Just _) <- find (transformers mt) t = case currLayout mt of { EL l det -> do { l' <- fromMaybe l `fmap` handleMessage l (SomeMessage ReleaseResources); .... } where cur = (i == currIndex mt) } | otherwise = case currLayout mt of { EL l det -> fmap (fmap (\ x -> mt {currLayout = EL x det})) $ handleMessage l m }

2 3

report on 7.01-pre
by Serge D. Mechveliani 30 Sep '10

30 Sep '10

Dear GHC developers, http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip contains a bug report on ghc-7.0.0.20100924 tested on Debian Linux, i386-family. Its essence is as follows. At the fragment of --------------------------------------------------------------------- instance (LinSolvRing (Pol a), CommutativeRing a) => -- (1) LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP = f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... --------------------------------------------------------------------- in the module Pol3_.hs, ghc-7.0.0.20100924 reports that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. ghc-6.12.2 compiles this in a correct way: (EuclideanRing a) is not necessary here, while the context (1) is more generic and sufficient. For example, for a = DirectSum Integer Integer, `a' has the instances (1) and has not the instance of Euclidean, and the above code must work. This is the idea of the author of the application; this idea is supported by ghc-6.12.2 and not supported by ghc-7.0.0.20100924. There are the two questions. 1) Whether this intention with instances is correct in the meaning of Haskell + ghcExt (I hope, it is correct, at least, ghc-6.12.2 accepts it). 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? Notices ------- a) This application uses multiparametric classes and overlapping instances (see docon.cabal for language and other options). b) The example code can be reduced further, many times. But I may have time to reduce it maybe only in the middle of December 2010. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0