- Glasgow-haskell-users

GHC7 (on OSX.5)
by wren ng thornton 22 Mar '11

22 Mar '11

So I'm having a go of installing ghc-7.0.2 and haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer supported I've had to compile from source. The good news is, so far as I can tell, everything works right out of the box.[1] But I've noticed when compiling the base libraries and HP a lot of warnings like the following: SpecConstr Function `a_s2Qn{v} [lid]' has three call patterns, but the limit is 1 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations Though the number of call patterns and the limit vary. Googling led me to the SpecConstr file which I read briefly, so I know it has to do with optimizing away constructor allocations, but that's about it. Are these warnings I should be concerned about? [1] OSX 10.5.8 arch x86_64 (though it calls itself i386) Xcode 3.1.2 (not that it matters) gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490) ghc 6.12.1 / hp 2010.1.0.0 -- Live well, ~wren

4 5

testing 7.02-candidate
by Serge D. Mechveliani 20 Mar '11

20 Mar '11

Dear GHC team, I am testing the 7.02 candidate of ghc-7.0.1.20110217 -- compiled from source, compiled by itself, on Debian Linux, i386-family. On my DoCon program, it reports the following. 1. It requires `-fcontext-stack=_' to increase a certain stack: ... [67 of 83] Compiling Pfact__ ( Pfact__.hs, dist/build/Pfact__.o ) [68 of 83] Compiling RsePol_ ( RsePol_.hs, dist/build/RsePol_.o ) RsePol_.hs:214:28: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSet :: Set (UPol (ResidueE Integer)) $dAddSemigroup :: AddSemigroup (UPol (ResidueE Integer)) $dAddMonoid :: AddMonoid (UPol (ResidueE Integer)) ... $dCast :: Prelude_.Cast (ResidueE (UPol (Pfact__.RseUPolRse Integer))) (UPol (Pfact__.RseUPolRse Integer)) In the first argument of `(.)', namely `ct c1' In the expression: ct c1 . toOverK . resRepr In an equation for `toC': toC = ct c1 . toOverK . resRepr ------------------------------------------- So, I add -fcontext-stack=30 to the ghc-options line in docon.cabal. Which one is better at this point, 7.0.1 or 7.0.1.20110217 ? 2. Then, DoCon is built, and the commands cd demotest ghc $doconCpOpt -O -rtsopts --make Main need to `make' the DoCon test under the DoCon library. This reports [ 1 of 17] Compiling T_detinterp ( T_detinterp.hs, T_detinterp.o ) [ 2 of 17] Compiling T_sphGeo ( T_sphGeo.hs, T_sphGeo.o ) [ 3 of 17] Compiling T_cubeext ( T_cubeext.hs, T_cubeext.o ) T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' Matching instances: instance [overlap ok] EuclideanRing a => LinSolvRing (UPol a) -- Defined in docon-2.12:Pol2_ instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) -- Defined in docon-2.12:Pol3_ (The choice depends on the instantiation of `k' To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the first argument of `(.)', namely `ct unE' In the expression: ct unE . kToB In an equation for `kToE': kToE = ct unE . kToB -------------------------------------------------------------------- This looks like a bug of the kind appeared in a couple of earlier GHC versions. ghc-7.0.1 is free of both of these effects. What is your opinion about this? http://www.botik.ru/pub/local/Mechveliani/ghcBugs/702candBug.zip is the archive with the project to make and run under ghc-7.0.1, and ghc-7.0.1.20110217 (follow install.txt). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Documentation build failure
by Daniel Fischer 18 Mar '11

18 Mar '11

make-ing 7.0.2 failed with: -- everything fine up to here, users guide html okay Build users_guide.ps This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/openSUSE) entering extended mode latex failed users_guide_tmp.tex:1631: Undefined control sequence \Documents. users_guide_tmp.tex:1631: leading text: } users_guide_tmp.tex:1631: Undefined control sequence \user. users_guide_tmp.tex:1631: leading text: } users_guide_tmp.tex:3993: Undefined control sequence \Person. users_guide_tmp.tex:3993: leading text: or \nolinkurl{Data\Person.hs} users_guide_tmp.tex:6185: Undefined control sequence \Documents. users_guide_tmp.tex:6185: leading text: ...ts~And~Settings\user\ghc\package.conf.d} users_guide_tmp.tex:6185: Undefined control sequence \user. users_guide_tmp.tex:6185: leading text: ...ts~And~Settings\user\ghc\package.conf.d} users_guide_tmp.tex:6185: Undefined control sequence \ghc. users_guide_tmp.tex:6185: leading text: ...ts~And~Settings\user\ghc\package.conf.d} users_guide_tmp.tex:6185: Undefined control sequence \package. users_guide_tmp.tex:6185: leading text: ...ts~And~Settings\user\ghc\package.conf.d} users_guide_tmp.tex: File ended while scanning use of \hyper@n@rmalise. users_guide_tmp.tex: Emergency stop. Error: latex compilation failed make[1]: *** [docs/users_guide/users_guide.ps] Fehler 1 make: *** [all] Fehler 2 on openSUSE 11.3. I don't know which programme is at fault here, maybe someone can check whether ps/pdf documentation building works on other systems. Re ./configure-ing after setting BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO in mk/build.mk said it would build ps and pdf documentation nevertheless, I had to edit the configure script to convince it not to try. configure just checks for the existence of a dblatex command, so perhaps $ dblatex --version /usr/lib/python2.6/site-packages/dbtexmf/dblatex/grubber/util.py:8: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 dblatex version 0.2.7 is helpful information. Unrelated: The build produces several SpecConstr Function `$j_s8qC{v} [lid]' has four call patterns, but the limit is 3 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations warnings(?) (this is also very common building libraries). a) What does that mean for code generation? Will the specialisations be generated nevertheless? b) Would it be reasonable to have a higher default than 3 for spec-constr- count? Cheers, Daniel

3 5

ANNOUNCE: GHC 7.0.2 Release Candidate 2
by Ian Lynagh 17 Mar '11

17 Mar '11

We are pleased to announce the second release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc2/ This includes the source tarball, the Windows installer, and bindists for 32bit and 64bit Intel OS X, amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Our plan is to make the 7.0.2 release in around a week, and that will be the last release from the 7.0 branch, as we'll then switch to using the git repository for development. The 7.2.1 release will follow shortly. Thanks Ian, on behalf of the GHC team

8 27

Re: [Haskell-cafe] Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
by Antoine Latter 17 Mar '11

17 Mar '11

On Thu, Mar 17, 2011 at 12:51 AM, C K Kashyap <ckkashyap(a)gmail.com> wrote: > I had started exploring the internal - PS constructor route looking at the > base64 encoding implementation by Bryan (which is really fast - > http://www.serpentine.com/blog/2010/09/02/fast-base64-encoding-and-decoding… > )- I was wondering if we don't use the PS constructor can we implement > base64 encoding that's comparable? I mean, can we create an asymptotically > similar implementation? > Regards, > Kashyap I'm a fan of Data.ByteString.Unsafe.unsafeUseAsCStringLen when I need access to the raw buffer. http://hackage.haskell.org/packages/archive/bytestring/0.9.1.10/doc/html/Da… Antoine > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Linker error
by Luca Ciciriello 15 Mar '11

15 Mar '11

Hi All. I've just installed the new Haskell platform (2011.2.0.0) on my MacOS X 10.6.6 with Xcode 4 Now the problem is that when I try to build my Haskel programs I receive the linker error: Linking lexer ... ld: library not found for -lcrt1.10.5.o collect2: ld returned 1 exit status Any idea? Thanks in advance. Luca

3 3

hoogling GHC
by Ranjit Jhala 14 Mar '11

14 Mar '11

Hi all, I'd like to build a hoogle database that indexes the GHC source. Can anyone point me to how I might do that? (Or better, to a preexisting database?) (I've noticed that "make haddock" generates a bunch of .txt files. Is there some easy way to scour the directories and build a single Hoogle database from them?) Thanks! Ranjit.

3 7

GHC build error: cannot satisfy -package ghc-7.1.20110217
by William Knop 14 Mar '11

14 Mar '11

Hi all, I'm building GHC HEAD, and I've encountered the following error a couple times: "/usr/bin/ghc" -M -dep-makefile ghc/stage1/build/.depend.haskell.tmp > -include-pkg-deps -H32m -O -package-conf libraries/bootstrapping.conf > -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen > -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include > -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.3.0.2 -package > base-4.3.1.0 -package bytestring-0.9.1.10 -package directory-1.1.0.0 > -package filepath-1.2.0.0 -package ghc-7.1.20110217 -package process-1.0.1.4 > -package unix-2.4.1.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP > -XPatternGuards -no-user-package-conf -rtsopts -odir ghc/stage1/build -hidir > ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc > ghc/./Main.hs <command line>: cannot satisfy -package ghc-7.1.20110217: ghc-7.1.20110217-b77087559342dd20dfcfb258ea8804c4 is unusable due to > missing or recursive dependencies: Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80 > bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686 > hoopl-3.8.6.1-9f2c1afa2d4e6e1f5dd2821dfd6b919b > hpc-0.5.0.6-71c33aa47ae2440fd78a2a606987bc82 (use -v for more information) make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 make: *** [all] Error 2 The last time I saw this, I realized that `make clean` and even `make maintainer-clean` failed to remove the old .hs and .o files in ./libraries. I ran `find ./libraries | grep "\.hi$\|\.o$" | xargs -n 1 rm` which cleaned things up nicely. Then I had to fiddle around with `ghc-pkg` and unfortunately I don't remember exactly what I did, but everything built fine. This time, the error persists and I'm getting nowhere messing with `ghc-pkg` or manual builds of the offending libraries. It's odd that the dependencies are all shown, although ghc-7.1.20110217 is highlighted in blue (not sure what that means): $ ghc-pkg list -v using cache: > /Users/wknop/.ghc/x86_64-darwin-7.1.20110217/package.conf.d/package.cache using cache: > /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d/package.cache /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d Cabal-1.11.0 (Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80) array-0.3.0.2 (array-0.3.0.2-82b79889a63c9f1c51bec752ba6e74c2) base-4.3.1.0 (base-4.3.1.0-772e705367f0e57fa35bb2732ef27d5f) bin-package-db-0.0.0.0 > (bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686) binary-0.5.0.2 (binary-0.5.0.2-0fc98c736c6f368bb204d82d52e9b985) bytestring-0.9.1.10 > (bytestring-0.9.1.10-9ed25604136f5805a5307d3964bed1a2) containers-0.4.0.0 (containers-0.4.0.0-e65ebc811ae84f909e4426649d5305b6) directory-1.1.0.0 (directory-1.1.0.0-af496658c243f2bddd90748bc896b9cb) extensible-exceptions-0.1.1.2 > (extensible-exceptions-0.1.1.2-d8c5b906654260efd7249f497d17a831) ffi-1.0 (builtin_ffi) filepath-1.2.0.0 (filepath-1.2.0.0-083d27aec2076819a3255aa35e2ce43b) ghc-7.1.20110217 (ghc-7.1.20110217-b77087559342dd20dfcfb258ea8804c4) ghc-prim-0.2.0.0 (ghc-prim-0.2.0.0-dcc46e56b3af1fa9c9fa226ef635850d) haskell2010-1.0.0.0 > (haskell2010-1.0.0.0-5a47cd47ec15d3267342d7569d62be69) haskell98-1.1.0.0 (haskell98-1.1.0.0-ff2f72cc8added329f0e4b03c5cc83e8) hoopl-3.8.6.1 (hoopl-3.8.6.1-9f2c1afa2d4e6e1f5dd2821dfd6b919b) hpc-0.5.0.6 (hpc-0.5.0.6-71c33aa47ae2440fd78a2a606987bc82) integer-gmp-0.2.0.2 > (integer-gmp-0.2.0.2-a1c2a972ace139a643a7e915357c7135) old-locale-1.0.0.2 (old-locale-1.0.0.2-f8974f34bd37bc556cfeca15f8cf9933) old-time-1.0.0.6 (old-time-1.0.0.6-caa2975bbf8e858473e1d88cca412718) pretty-1.0.2.0 (pretty-1.0.2.0-86ef771ce2f9bebde0154187a7714390) process-1.0.1.4 (process-1.0.1.4-8e5c7fd6eb02062956e817290e78052c) random-1.0.0.3 (random-1.0.0.3-ba5d71475c84afcd915bdd0c7896d252) rts-1.0 (builtin_rts) template-haskell-2.5.0.0 > (template-haskell-2.5.0.0-d8450268cce481f1f0f0609421f45d6a) time-1.2.0.3 (time-1.2.0.3-54ba5c61f979a06ebaa014e89cb57800) unix-2.4.1.0 (unix-2.4.1.0-ed4a568ba9e55a6699f0a5637de1eb70) /Users/wknop/.ghc/x86_64-darwin-7.1.20110217/package.conf.d HUnit-1.2.2.3 (HUnit-1.2.2.3-cfbd4873c8348462ffebec9e0e2612ff) QuickCheck-2.4.0.1 (QuickCheck-2.4.0.1-203424cf15ac4e156e45863bdb6c5c3c) ansi-terminal-0.5.5 > (ansi-terminal-0.5.5-572a1d0154fb2632bb4e9431adf0cdb1) ansi-wl-pprint-0.6.3 > (ansi-wl-pprint-0.6.3-875ef2078f6bfbf85f537bf474d4db67) hostname-1.0 (hostname-1.0-fd008e4cbc7e53cd089e95782cd47a3a) mtl-2.0.1.0 (mtl-2.0.1.0-86fd290a44e249d2b21a3e6adc3985a4) regex-base-0.93.2 (regex-base-0.93.2-f611e499723a1c17ae67e04fe4ce3d1e) regex-posix-0.94.4 (regex-posix-0.94.4-9e243c82c4410fcdd8b9c4a9f579cd23) test-framework-0.3.3 > (test-framework-0.3.3-2e089ba99de1028033d51a65ef26cced) test-framework-hunit-0.2.6 > (test-framework-hunit-0.2.6-cd25c078816dfb54dc08cf64d24bcea2) test-framework-quickcheck2-0.2.9 > (test-framework-quickcheck2-0.2.9-0063f8833c46c25ff4d6bb13461990f8) transformers-0.2.2.0 > (transformers-0.2.2.0-5facb5b7c533677975df4a82c67e8639) xml-1.3.7 (xml-1.3.7-eb24b369ce1c655abc9947262d56223e) The other notable thing is that the versions of the installed packages matches the packages I am building with GHC. I initially thought that it would be a good thing, however now I'm thinking that it's leading to some kind of conflict between the build system and the bootstrap system. In the past I've noticed that cabal does not deal well with different versions of GHC, particularly that it doesn't keep track which version of GHC is used to build and register a package (and the .cabal user directory doesn't have separate subdirectories for different cabal versions). This is quite annoying, since it means one can't really have test installs of GHC without fiddling around with prefixes or sandbox construction. Anyway, I wouldn't be surprised if conflicts from that sort of thing could cause the issue I'm having. So I suppose the question now is, what is the actual cause and should it be fixed in GHC's build system or in cabal's source? Thanks, William

3 7

trac ticket spam
by Claus Reinke 14 Mar '11

14 Mar '11

Is there any way to have a "moderate first comment by new submitter" policy for trac, to avoid the kind of ticket spam we have at the moment? They seem to have started commenting on existing tickets now (#4510), which could turn into a real mess really quickly, if the currently known spam accounts aren't blocked soon, btw. Claus

6 10

Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
by Christian Maeder 14 Mar '11

14 Mar '11

Am 14.03.2011 06:26, schrieb C K Kashyap: > Looks like a job for Data.Binary. > > > I'd like to use it with just the libraries that are part of the > platform > > > I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple "ghc-pkg expose ghc-binary". For future versions of ghc and the platform a single ghc-binary or binary version would be better. Cheers Christian

2 1