- Glasgow-haskell-users

Re: GHC ParseTree Module
by Malcolm Wallace 03 Jan '11

03 Jan '11

You will be more likely to get an answer on the ghc-users mailing list (cc'ed). The ghc developers rarely follow -cafe. On 1 Jan 2011, at 20:36, Jane Ren wrote: > Hi, > > Does anyone know what GHC module gets the AST and type info of some > source code? This is the GHC module that converts all of Haskell > into an AST with a small number of pattern cases, where each AST > node is annotated with the Haskell type. > > Thanks > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

GHC > 6.8.2 on IA64-Linux platform (Itanium)
by Karel Gardas 02 Jan '11

02 Jan '11

Hello, [sorry for cross-post, I assume Itanium interest is quite rare these days so to grab attention of Itanium/Haskell people I send to both haskell-cafe and ghc list] I'd like to compile more recent than 6.8.2 GHC on itanium-linux system I do have access to, but I'm kind of unlucky with this. I'm trying unregisterised build (of 6.12.3 and 6.10.4) and it always fails with: "inplace/bin/ghc-stage2" -H32m -O -package-name dph-base-0.4.0 -hide-all-packages -i -ilibraries/dph/dph-base/. -ilibraries/dph/dph-base/dist-install/build -ilibraries/dph/dph-base/dist-install/build/autogen -Ilibraries/dph/dph-base/dist-install/build -Ilibraries/dph/dph-base/dist-install/build/autogen -Ilibraries/dph/dph-base/include -optP-include -optPlibraries/dph/dph-base/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.1 -package base-4.2.0.2 -package ghc-prim-0.2.0.0 -package random-1.0.0.2 -Odph -funbox-strict-fields -haddock -fcpr-off -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O2 -XGenerics -fno-warn-deprecated-flags -Wwarn -odir libraries/dph/dph-base/dist-install/build -hidir libraries/dph/dph-base/dist-install/build -stubdir libraries/dph/dph-base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/dph/dph-base/./Data/Array/Parallel/Base/Hyperstrict.hs -o libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o ghc-stage2: internal error: evacuate: strange closure type 15 (GHC version 6.12.3 for ia64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o] Aborted make: *** [all] Error 2 I even attempted unoptimized build with mk/build.mk containing this: GhcUnregisterised=YES GhcWithNativeCodeGen=NO SplitObjs=NO SRC_HC_OPTS = -H64m -O0 GhcStage1HcOpts = -O0 GhcStage2HcOpts = -O0 GhcLibHcOpts = -O0 but this time ghc segfaults while compiling: "inplace/bin/ghc-stage2" -H64m -O0 -package-name dph-base-0.4.0 -hide-all-packages -i -ilibraries/dph/dph-base/. -ilibraries/dph/dph-base/dist-install/build -ilibraries/dph/dph-base/dist-install/build/autogen -Ilibraries/dph/dph-base/dist-install/build -Ilibraries/dph/dph-base/dist-install/build/autogen -Ilibraries/dph/dph-base/include -optP-include -optPlibraries/dph/dph-base/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.1 -package base-4.2.0.2 -package ghc-prim-0.2.0.0 -package random-1.0.0.2 -Odph -funbox-strict-fields -haddock -fcpr-off -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O0 -fno-warn-deprecated-flags -Wwarn -odir libraries/dph/dph-base/dist-install/build -hidir libraries/dph/dph-base/dist-install/build -stubdir libraries/dph/dph-base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/dph/dph-base/./Data/Array/Parallel/Base/Hyperstrict.hs -o libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o make[1]: *** [libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o] Segmentation fault I've also seen, the last available GHC in Debian for IA64 platform is 6.8.2 -- which I'm using for bootstrap btw so debian will not help me here with some clever patch which would change recent ghc to be buildable... So, I'd like to ask here: is there anybody who was lucky enough to find appropriate set of options or any other magic way how to compile more recent GHC sources to the _stable_ compiler binary on IA64/Linux? If so, please let me know. Thanks a lot, Karel

1 0

Re: SampleVar semantics
by Antoine Latter 02 Jan '11

02 Jan '11

I would file a bug on the GHC bug tracker: http://hackage.haskell.org/trac/ghc/newticket?type=bug You will need to use the guest login to trac, though (in grey text at the bottom of the page). I've also CCed the GHC-users list, as there are folks over there that might have knowledge of the concurrency libraries. Take care, Antoine On Sat, Jan 1, 2011 at 7:03 PM, Eric Stansifer <eric.stansifer+haskell(a)gmail.com> wrote: > Hi, > > I didn't get a response to my question on haskell-cafe, perhaps > libraries is a more appropriate place to ask. > > > doc: http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/Cont… > source: http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/src/… > > The isEmptySampleVar function, > > isEmptySampleVar :: SampleVar a -> IO Bool > isEmptySampleVar (SampleVar svar) = do > (readers, _) <- readMVar svar > return (readers == 0) > > returns False whenever readers < 0. However, readers < 0 occurs when > there are threads waiting on an empty SampleVar. > > The documentation on SampleVar is a bit sparse on explaining the > intended behavior; I wouldn't have expected this behavior if I hadn't > read the source. Can someone clarify the semantics of SampleVar? > > For a contrived example, consider > > > do_something = threadDelay 100000 -- 100 ms > > produce, consume :: SampleVar Int -> IO () > produce svar = do > do_something > b <- isEmptySampleVar svar > if b then randomIO >>= writeSampleVar svar else return () > produce svar > > consume svar = do > x <- readSampleVar svar > print x > consume svar > > main = do > svar <- newEmptySampleVar > forkIO $ produce svar > forkIO $ consume svar > threadDelay 1000000 -- one second > > This code deadlocks instead of printing random numbers. > > Thanks, > Eric > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Building on windows/mingw issues
by Nils Schweinsberg 01 Jan '11

01 Jan '11

Hi, I have some issues building the RTS of GHC on windows. I tried all various versions of mingw, including the latest stable release from mingw.org, the tarballs from the darcs repo in ghc-tarballs/mingw and the version of the currently installed GHC platform with ghc 6.12 (the files in mingw/bin). The error I get is always the same, no matter if I try to build current GHC HEAD or the stable 7.0.1 release: ~~~ "inplace/bin/ghc-stage1.exe" -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-fno-strict-aliasing -optc-fno-common -optc-Ilibffi/build/include -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_thr\" -optc-DTHREADED_RTS -H32m -O -Iincludes -Irts -DCOMPILING_RTS -package-name rts -dcmm-lint -Ilibffi/build/include -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -optc-O2 -c rts/Linker.c -o rts/dist/build/Linker.thr_o rts\Linker.c:1039:1: error: conflicting types for 'mktime' c:\haskell\ghc-src\inplace\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/time.h:104:40: note: previous declaration of 'mktime' was here rts\Linker.c:1039:1: error: conflicting types for 'localtime' c:\haskell\ghc-src\inplace\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/time.h:121:45: note: previous declaration of 'localtime' was here rts\Linker.c:1039:1: error: conflicting types for 'gmtime' c:\haskell\ghc-src\inplace\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/time.h:120:45: note: previous declaration of 'gmtime' was here make[1]: *** [rts/dist/build/Linker.thr_o] Error 1 make: *** [all] Error 2 ~~~ Can anyone confirm this error? Can anyone help me to fix this error? I definitly do not have any other versions of msys/mingw installed/in my path. Thanks, Nils

1 0

Edentv build
by Aswad, Mustafa 31 Dec '10

31 Dec '10

Hi Mesha; I try to build the latest version from edentv, but I have problem to build the depends packages. I am stick to build "cairo", it gives my the following error Preprocessing library cairo-0.12.0... Building cairo-0.12.0... Graphics/Rendering/Cairo.hs:8:0: error: cairo-version.h: No such file or directory It is required by GTK packages. Can you till where I can find the right version that can build with ghc-6.12.3 or to install this package? I have tried the one which in http://hackage.haskell.org/packages/archive/cairo/0.12.0/ but it does not work. cheers -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

2 1

Re: [darcs-users] How to develop on a (GHC) branch with darcs
by Iavor Diatchki 22 Dec '10

22 Dec '10

Hello, Thanks for all your responses (and the --skip-conflicts tip)! I use git for a lot of my development, so I was hoping that I was just experiencing "culture shock" and simply doing things with the wrong mind-set. Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution. For me, switching GHC to git would certainly be a win. In terms of the future of darcs, while better tools for managing rebasing would certainly be useful, I am not confident that any solution based on mutation (i.e., "rewriting history" by rebasing/ amend-recoding) would work well in a distributed environment due to the difficulty of sharing these changes---it seems to require some sort of "higher order" version control where you have to keep track of the changes to the changes :-) In the context of git, I only brought up "rebasing" because it seemed like the closest concept to what I was doing with darcs. If GHC was to switch to git, I think that we should certainly use git's ordinary merge model to keep track of history. -Iavor PS for VCS folks: I think that an interesting idea of combining darcs and git would be to use git's graph-based history model, but to annotate the edges on the graph with semantic patches ala darcs. This would make it possible to write smarter auto-merge strategies for git. On Tue, Dec 7, 2010 at 7:16 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > Ganesh Sittampalam writes: > > > I think there are three things that can help with this problem: > > > > 1) a darcs rebase command. This will give you a nice way to manage the > > workflow already discussed, and you won't have to squish everything > > through into a mega-patch. You'll still have to periodically abandon one > > branch for another though (but I think that's also the case with git > > rebase). > > I'm not sure what you mean by "abandon". > > In a git rebase, you pretty much have to forget the original branch > immediately (everywhere in the world!), or there will be great fun for > all concerned. You really really do not want to merge an original > branch with its rebased descendant in git.[1] Unfortunately, unless > the rebased branch gets dibs on the branch's name, it's all too easy > to perform such a merge inadvertantly (eg, git pull will do it). So > in that sense a git rebase means immediately abandoning the old branch, > and all the commit history of the old branch. (The details of the > history are copied into the rebased commits, but they do not have the > same identity as the originals, so merge conflicts are guaranteed.) > > > I also have some hope, though this is more speculative, of offering > > a clean way of tracking the relationship between the old branch and > > the new branch so that any stray patches against the old branch can > > be cleanly rebased to the new branch later on. > > As explained above, DAG-based VCSes like git can't do this cleanly > (that is one way of expressing the reason why rebase is severely > deprecated in some circles), and I don't think git will be able to do > so in the near future. OTOH, if Darcs gets rebase but can't handle > this, I'd have to count that as a net minus. Recombinant patching is > really what Darcs is all about IMO. > > In practice, git rebase needs to be kept private to a single user, and > is impractical even if private, if the user has propagated the branch > to other local repositories. Because git branching is so lightweight, > nobody really sees this as a big problem; throwaway branches are used > all the time as interim steps in many operations (eg, git stash). > Darcs branches, on the other hand, are much more heavyweight (modulo > the work you propose on colocated branches, but that's farther away > than rebase is). > > IMHO YMMV. But I strongly recommend you think carefully about this. > Analogies to git rebase are a trap here. It's implemented differently > and used to solve different problems from the way rebase is proposed > for use in Darcs. > > > Footnotes: > [1] There may be better ways to deal with this than garbaging the > original commits, but so far nobody really needs it. > >

12 12

Beware: Bad I/O performance on Windows without -threaded
by Simon Marlow 21 Dec '10

21 Dec '10

I just noticed that I/O performane on Windows without -threaded is pretty terrible. The following program: main = getConetnts >>= putStr tested with a 1MB file: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.28s ( 0.49s elapsed) <snip> But if we add -threaded: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs -threaded $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.05s ( 0.07s elapsed) <snip> Several times better. I just made a tweak in my working tree to increase the I/O buffer sizes, and this helps quite a lot: $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.06s ( 0.05s elapsed) <snip> $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs -threaded $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.05s ( 0.05s elapsed) <snip> Why is this? I'm not entirely sure, but I suspect it is the implementation of asynchronous I/O in the RTS that is only used on Windows without -threaded (rts/win32/AsyncIO.c etc.). Every I/O operation in the non-threaded RTS on Windows involves a couple of OS-thread switches. I'll get the buffer size fixes into 7.0.2. Cheers, Simon

1 0

GIO.012.0 installation
by Aswad, Mustafa 21 Dec '10

21 Dec '10

Hi dear; I am try to build Gio package using cabal version cabal-install version 0.8.2 and Ghc version version 6.12.3. Bu I got such error which I can not solve it setup: The pkg-config package gio-2.0 version >=2.16.4 is required but it could not be found. Could any of you till me how come this problem. thanks -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

2 1

client builder issue.
by Karel Gardas 17 Dec '10

17 Dec '10

Hello, I've attempted to update my builder client to the today's source code and compiled it by GHC 7.0.1 (I've hacked cabal files' versions in order to do so). When running against GHC builder server with --do-build option I've got following failure: Running "testing" builder-client-v2: fd:11: hGetLine: invalid argument (Illegal byte sequence) [2010-12-17 12:14:05] [kgardas-opensolaris-x86-head] Sending: "UPLOAD 79 1" builder-client-v2: SSLIOError I guess due to it, my testing fails with: =====> print021(ghci) 286 of 2675 [0, 1, 0] cd ./ghci.debugger/scripts && HC='/buildbot/ghc-head-builder/builder/tempbuild/build/bindisttest/install dir/bin/ghc' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts ' '/buildbot/ghc-head-builder/builder/tempbuild/build/bindisttest/install dir/bin/ghc' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -ignore-dot-ghci <print021.script >print021.run.stdout 2>print021.run.stderr Actual stdout output differs from expected: --- ./ghci.debugger/scripts/print021.stdout.normalised Fri Dec 17 14:14:05 2010 +++ ./ghci.debugger/scripts/print021.run.stdout.normalised Fri Dec 17 14:14:05 2010 @@ -1,2 +1,2 @@ test = (_t1::[T]) Traceback (most recent call last): File "../../driver/runtests.py", line 238, in ? oneTest() File "/buildbot/ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 479, in <lambda> allTests += [lambda : runTest(myTestOpts, name, setup, func, args)] File "/buildbot/ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 469, in runTest test_common_work (name, opts, func, args) File "/buildbot/ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 545, in test_common_work do_test (name, way, func, args) File "/buildbot/ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 666, in do_test framework_fail(name, way, 'do_test exception') File "/buildbot/ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 679, in framework_fail print '*** framework failure for', full_name, reason, ':' IOError: [Errno 32] Broken pipe gmake[2]: *** [test] Error 1 gmake[1]: *** [fast] Broken Pipe gmake: *** [test] Broken Pipe Or is it vice versa? See http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/7… is this a known issue or shall I do something about it? Thanks, Karel

1 0

Newtype deriving mixing up types
by Emil Axelsson 17 Dec '10

17 Dec '10

Hello! I attach a program which I suspect demonstrates a bug in GHC. The important lines are: showType :: forall a . Expr a -> String showType (Lit _) = show (typeOf (undefined :: a)) test1 = showType (mk :: Expr BOOL) -- Prints "Bool" (wrong?) test2 = showType (Lit mk :: Expr BOOL) -- Prints "Main.BOOL" (correct) test1 and test2 give different results, even though showType shouldn't be able to tell them apart. It seems that the Typeable context packed with the Lit constructor is wrong in test2. I had to use two extra classes and newtype deriving to trigger this behavior. Note that if I change deriving instance B BOOL to instance B BOOL the result is correct. Tested with both 6.12.3 and 7.0.1. Should I report this as a bug? Thanks! / Emil

2 1