- Glasgow-haskell-users

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

testsuite missing was: Re: ANNOUNCE: GHC version 7.0.2
by Christian Maeder 14 Mar '11

14 Mar '11

Why is the file still not being updated? http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 C. Am 10.03.2011 03:22, schrieb Jens Petersen: > On 4 March 2011 23:14, Christian Maeder <Christian.Maeder(a)dfki.de> wrote: >> http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 >> >> This archive does not seem to have the actual tests inside the testsuite >> subdirectory. At least the README is identical to the top-level one. > > Not just the readme, but most of the files actually! > > $ tar jxf ghc-7.0.2-src.tar.bz > $ tar jxf testsuite-7.0.2.tar.bz > $ mv ghc-7.0.2/testsuite testsuite-7.0.2 > $ diff -sr ghc-7.0.2 testsuite-7.0.2 | grep "are identical$" | wc -l > 1193 > > A week has passed now - can we please have a fixed > testsuite-7.0.2.tar.bz2? :) > > Thanks, Jens >

1 0

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

14 Mar '11

The ghc-binary package is used internal to GHC, and isn't gauranteed to be present from one version to the next, nor do I expect the GHC team to promise it will have a stable interface. You'd really be better of instaling the package "binary", or something similar. On Mar 14, 2011 5:34 AM, "Christian Maeder" <Christian.Maeder(a)dfki.de> wrote:

1 0

a message from Tokyo
by Kazu Yamamoto 13 Mar '11

13 Mar '11

Dear GHC users and Haskell community members, I'm writing this message to tell you the situation of Japan. As you know, the biggest earthquake since 1900 occurred. North-east of Japan is now like hell. Many towns were destroyed due to Tsunami. Many fires still continue. I guess some of you have been to Sendai which is a central town of North-east of Japan. The situation of Sendai is really really bad. I'm concerning whether or not people of Tohoku University are safe. Thanks to twitter, Eijiro Sumii, who is the chair of ICPF 2011 programming contest is safe. Fortunately, Tokyo is fine. I was working at my office in Tokyo and experienced the biggest earthquake in my life. 16 years ago, I was living in a place which is 200 km away from Kobe. At the time, the earthquake was the biggest for me, of course. But this time, quake was worse than that. All trains and subways in Tokyo stopped. Some people had to stay in their companies. Some chose to walk for many hours. Some had to stay in schools which were opened to everybody. In my case, I got home by my bicycle. I could not communicate with my wife by mobile phone. But my wife walked for four hours with our son and finally got together yesterday. All members of Haskell community in Tokyo are fine. Some of them are twitting. Probably we will be able to hold a study meeting on Yesod tommorrow. I believe this earthquake will not stop ICPF 2011 since Tokyo had little damage. I hope people living in North-east Japan can go home as quickly as possible and their town will recover. If you have any questions, please tell me by e-mail or twitter(@kazu_yamamoto). And I hope you kindly pray for them. Sincerely, --Kazu

1 1