From daniil.elovkov at googlemail.com Tue Jan 1 06:24:15 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Tue Jan 1 06:18:23 2008 Subject: laura.daun@web.am Message-ID: ?????? ?????! ? ????? ????? ???? ? ??? ???? ?????! ???? ??????? ???? ??? ???? ??????. ???? ????? ??????????. ????? ???? ????? ?????? ? ?????. ?? ???? ?????? ????????, ?????????? ???????? ???????, ???????, ???. ????? ??? ? ???? ????? ???????, ?????????, ???? ???????? ? ???? ??????! Gott nytt ?r till dig, ?ke, Aram och David (och deras flickor ocks?) ! ???? ? ????. From asviraspossible at gmail.com Tue Jan 1 13:27:32 2008 From: asviraspossible at gmail.com (Victor Nazarov) Date: Tue Jan 1 13:21:34 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> Message-ID: On Dec 31, 2007 7:58 PM, Neil Mitchell wrote: > Hi, > > I'm getting errors such as: > > C:/Documents/Uni/packages/base/GHC/Base.lhs:270:12: > Illegal binding of built-in syntax: [] > > When I try and compile GHC/Base.lhs using the GHC API. Is there some > flag I can pass to allow the rebinding of built in syntax? > -package-name base should do the thing -- vir http://vir.comtv.ru/ From daniil.elovkov at googlemail.com Tue Jan 1 14:16:32 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Tue Jan 1 14:10:38 2008 Subject: Was wrong address In-Reply-To: References: Message-ID: Erm, sorry for the spam. I failed to manage my email program :) Happy New Year everybody. On Tue, 01 Jan 2008 14:24:15 +0300, Daniil Elovkov wrote: > ?????? ?????! > ... From simonmarhaskell at gmail.com Wed Jan 2 07:48:28 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 07:42:40 2008 Subject: ANNOUNCE: GHC version 6.8.2 In-Reply-To: References: <20071212184457.GA8806@matrix.chaos.earth.li> <5A789366-EC12-4642-A806-AD009A06BFD1@cse.unsw.edu.au> <2DAAD1F4-80A6-41FC-B8E6-BADF14D69873@cse.unsw.edu.au> <20071223140444.GA22326@matrix.chaos.earth.li> Message-ID: <477B881C.9010802@gmail.com> alpheccar wrote: > Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? > I had no problems to build the 6.8.1 but with 6.8.2, I get the error: > > ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 > -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. > -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir > dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts > -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing > -fgenerics -c Data/Generics/Twins.hs -o > dist/build/Data/Generics/Twins.o -ohi dist/build/Data/Generics/Twins.hi > ghc-6.8.2: panic! (the 'impossible' happened) > (GHC version 6.8.2 for powerpc-apple-darwin): > lookupVers1 base:GHC.Prim sym{tc} This is a new bug in 6.8.2 that we discovered just before Christmas: http://hackage.haskell.org/trac/ghc/ticket/2011 the workaround is simple: just make clean in libraries/base. Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:17:03 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:11:05 2008 Subject: [Haskell-cafe] Re: #haskell works In-Reply-To: <13388119.20071220165420@gmail.com> References: <4762E3A2.1060701@btinternet.com> <625b74080712141257s33b1b49fp71465cbfc7039e0@mail.gmail.com> <4683d9370712142013x1749159fxc5656f51e6d53329@mail.gmail.com> <476A67C7.7040700@microsoft.com> <13388119.20071220165420@gmail.com> Message-ID: <477B8ECF.1020009@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Thursday, December 20, 2007, 4:01:59 PM, you wrote: > >> Fixing it all properly means some fairly significant architectural changes, >> and dropping the via-C backend > > oh, thank you. from my POV, C backend still may be used together with > "non-registerized" compilers. in particular, i hope that win-x64 will > be supported at least in this way > > noone asked my question about plans of win-x64 support. it's important > for my users, so i ask you again - can you please implement it? > > to other GHC users: i'm pretty sure that win-x64 support will not be > implemented if it's required only for me. so, if someone need it - > please write about this to ghc debelopers It'll get implemented when (a) there is a working mingw64, and (b) it is important enough to enough people. As I understand it, (a) is getting closer, but there's still no official release. My guess is that it's a couple of weeks' work. Win64 is quite different from the x86-64 Unix ABI: the calling convention is different, which means that all the FFI stuff has to be ported (the NCG foreign call support, GHCi foreign calls, rts/Adjustor.c). It took me a few days to get these working for x86-64 on Unix. What's more, while x86-64 on Unix is nicer in many ways than the 32-bit ABI, Win64 is significantly more horrible than Win32 (just MHO based on memories of reading a couple of MSDN articles), so I don't expect it to be a very enjoyable couple of weeks work :) Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:42:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:36:41 2008 Subject: --make should not touch the -o file if it doesn't change it In-Reply-To: <476E8F4F.1060009@alexjacobson.com> References: <476E8F4F.1060009@alexjacobson.com> Message-ID: <477B94CD.8020607@gmail.com> Alex Jacobson wrote: > Right now, if you recompile with --make, the exeutable gets a new > timestamp. That seems incorrect. Is this a bug? If the executable was re-linked, then it gets a new timestamp, since the file's contents have changed, but if no compilation or linking was required, then the executable and its timestamp remain unchanged. Seems ok to me, am I missing something? Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:48:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:42:19 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: <477B9621.5040706@gmail.com> Neil Mitchell wrote: > The GHC API uses the <.> operator, which clashes with System.FilePath. > Possibly this might want renaming to something else - I have > absolutely no idea what it does! > > Prelude> :m GHC > Prelude GHC> :i <.> > (<.>) :: HsWrapper -> HsWrapper -> HsWrapper -- Defined in HsBinds I tend to use import qualified GHC import GHC (Name, Id, ...) i.e. qualify most things, but selectively import a few things unqualified. The GHC API is quite huge, I expect clashes to be fairly common if you import it unqualified. Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 09:14:34 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 09:08:43 2008 Subject: [Haskell] garbage collection of Concurrent Haskell threads? In-Reply-To: References: Message-ID: <477B9C4A.5040404@gmail.com> [ moving to glasgow-haskell-users@haskell.org ] Conal Elliott wrote: > Thanks, Simon. If I understand the mechanism you're describing, it > discards readers of an empty MVar when there are no other references to > the MVar *because* the MVar can never get written. And if there are > other readers but no writers, then I'm guessing GC wouldn't know that, > and none of the readers get discarded. Is that so? I'm not sure I understand precisely what you mean here. Do you mean when there are other running threads that might read the MVar in the future? In that case, yes, blocked readers would not be detected and sent an exception. > I think Baker & Hewitt's trick was analogous to discarding writers of an > already full MVar when there are readers (readMVar) but no takers > (takeMVar). (Though not quite, since readMVar is implemented via > takeMVar & putMVar.) It shouldn't be the case that you have a thread doing putMVar on a full MVar simultaneously with another thread doing readMVar, because the readMVar could be preempted between the take and put and then block - this would almost certainly be an undesirable race condition. > I guess that effectively means IVars instead of MVars. > > In either direction (blocked reader or blocked writer), the interface of > MVars (or IVars) would seem to prevent an accurate analysis, since GC > wouldn't know whether a Var reference was for reading or writing. > > Right? A simple solution might be to hide the Var itself and instead > expose reader and writer halves. If there's an analysis problem at all, > does that solution make sense? Absolutely. It ought to be possible to implement this using weak pointers in GHC, because you want relationships like "if a writer is alive, then the readers are alive", and this is the kind of thing you can express with weak pointers. Cheers, Simon > > Cheers, - Conal > > On Dec 24, 2007 1:02 AM, Simon Peyton-Jones > wrote: > > GHC already garbage-collects threads that are blocked on an MVar > that is otherwise inaccessible (and hence cannot be updated). More > precisely, GHC sends the thread an asynchronous exception > (ThreadBlocked or something), so that it has a chance to clean up. > > > > So perhaps the GC you want is already implemented? > > Simon > > > > *From:* haskell-bounces@haskell.org > > [mailto:haskell-bounces@haskell.org > ] *On Behalf Of *Conal Elliott > *Sent:* 24 December 2007 00:15 > *To:* haskell@haskell.org > *Subject:* [Haskell] garbage collection of Concurrent Haskell threads? > > > > The classic paper "The Incremental Garbage Collection of Processes" > (http://citeseer.ist.psu.edu/baker77incremental.html) describes > "futures" and how particularly garbage collecting them when their > pending result is no longer referenced. I've been playing with an > implementation of futures in Concurrent Haskell ( > http://haskell.org/haskellwiki/Reactive), using MVars, and I'm > stumped about how to GC non-winning threads in a race between > futures ("parallel or"). I'm having winner kill loser, which seems > to work fine, though is potentially dangerous w.r.t locked > resources. Still, the elegance of a GC-based solution appeals to > me. Has anyone explored process GC ideas for Concurrent Haskell (or > STM)? > > Futures are implemented using Concurrent Haskell's MVars. I first > tried using STM and TVars, simply using orElse to implement mappend > for futures. However, I didn't see how to avoid nesting > "atomically", which yielded a run-time error. If anyone has ideas > about using STM & TVars for futures, I'd love to hear. > > Thanks, - Conal > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From alex at alexjacobson.com Wed Jan 2 10:18:52 2008 From: alex at alexjacobson.com (Alex Jacobson) Date: Wed Jan 2 10:13:34 2008 Subject: --make should not touch the -o file if it doesn't change it In-Reply-To: <477B94CD.8020607@gmail.com> References: <476E8F4F.1060009@alexjacobson.com> <477B94CD.8020607@gmail.com> Message-ID: <477BAB5C.9050908@alexjacobson.com> I think this was a bug on my part. Some file was getting touched that I wasn't aware of. Sorry. -Alex- Simon Marlow wrote: > Alex Jacobson wrote: >> Right now, if you recompile with --make, the exeutable gets a new >> timestamp. That seems incorrect. Is this a bug? > > If the executable was re-linked, then it gets a new timestamp, since the > file's contents have changed, but if no compilation or linking was > required, then the executable and its timestamp remain unchanged. Seems > ok to me, am I missing something? > > Cheers, > Simon From isaacdupree at charter.net Wed Jan 2 13:12:12 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jan 2 13:06:17 2008 Subject: odd GHC 6.8.2 compile failure Message-ID: <477BD3FC.9010302@charter.net> linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME . It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what? ... make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 make[3]: Entering directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <> ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177c4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177cb): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x17974): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x1797b): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): In function `shme_info': (.text+0x100d): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtq_info': (.text+0xa879): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtC_info': (.text+0xa999): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_info': (.text+0x27d7): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_srt': (.data+0x454): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_closure' collect2: ld returned 1 exit status <> make[3]: *** [stage2/ghc-6.8.2] Error 1 make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[2]: *** [stage2/ghc-6.8.2] Error 2 make[2]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' make: *** [bootstrap2] Error 2 ~Isaac From simonmarhaskell at gmail.com Thu Jan 3 04:30:02 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 04:24:04 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477BD3FC.9010302@charter.net> References: <477BD3FC.9010302@charter.net> Message-ID: <477CAB1A.9070409@gmail.com> Isaac Dupree wrote: > linking the compiled stage2 failed when bootstrapping from 6.6.1, with > --prefix=$HOME . > > It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) > installed as root (it's gone now), and I still have a bunch of > cabal/hackage packages installed in $HOME that were compiled by that > 6.8.2 (in addition to a few things installed by `cabal install` in > ~/.cabal/). Do you think that could be confusing the build process, and > if it is, is that a bug - and a bug in what? It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled. Cheers, Simon > > ... > make[3]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 > make[3]: Entering directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp > -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen > -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c > main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi > < residency (5 samples), 42M in use, 0.00 INIT (0.00 elapsed), 0.83 MUT > (0.91 elapsed), 0.40 GC (0.43 elapsed) :ghc>> > ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc > -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen > -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp > stage2/main/Main.o > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sEZA_info': > (.text+0x177c4): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sEZA_info': > (.text+0x177cb): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sF0s_info': > (.text+0x17974): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sF0s_info': > (.text+0x1797b): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): > In function `shme_info': > (.text+0x100d): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): > In function `swtq_info': > (.text+0xa879): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): > In function `swtC_info': > (.text+0xa999): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): > In function `r7DH_info': > (.text+0x27d7): undefined reference to > `base_TextziParserCombinatorsziReadP_zdschoice_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): > In function `r7DH_srt': > (.data+0x454): undefined reference to > `base_TextziParserCombinatorsziReadP_zdschoice_closure' > collect2: ld returned 1 exit status > < samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (5.00 elapsed), > 0.01 GC (0.02 elapsed) :ghc>> > make[3]: *** [stage2/ghc-6.8.2] Error 1 > make[3]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make[2]: *** [stage2/ghc-6.8.2] Error 2 > make[2]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make[1]: *** [stage2] Error 2 > make[1]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' > make: *** [bootstrap2] Error 2 > > > ~Isaac > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From isaacdupree at charter.net Thu Jan 3 06:34:37 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 3 06:28:34 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CAB1A.9070409@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> Message-ID: <477CC84D.2040704@charter.net> Simon Marlow wrote: > Isaac Dupree wrote: >> linking the compiled stage2 failed when bootstrapping from 6.6.1, with >> --prefix=$HOME . >> >> It's odd because I previously had a 6.8.2 (official x86 Linux >> bin-dist) installed as root (it's gone now), and I still have a bunch >> of cabal/hackage packages installed in $HOME that were compiled by >> that 6.8.2 (in addition to a few things installed by `cabal install` >> in ~/.cabal/). Do you think that could be confusing the build >> process, and if it is, is that a bug - and a bug in what? > > It looks like at some point you've updated your sources and recompiled > without cleaning in stage2, or something similar. The build system > doesn't currently notice when libraries have changed and stage2 needs to > be completely recompiled. It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error. What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?) ~Isaac From simonmarhaskell at gmail.com Thu Jan 3 06:47:56 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 06:42:00 2008 Subject: Readline for Windows in the FAQ In-Reply-To: <6329b9500712121227k2e4e0771j7dfe7a0494f182fc@mail.gmail.com> References: <6329b9500712121227k2e4e0771j7dfe7a0494f182fc@mail.gmail.com> Message-ID: <477CCB6C.9010000@gmail.com> Walt Rorie-Baety wrote: > Maybe I'm just too new at this, but the GCH FAQ entry for readline in > GHCi is confusing for me. Especially since it ends with the sentence > "Instructions for GHC 6.2.2. are here." However, as the quote goes, > "there's no 'here' here." - the location of the instructions are missing. > > Could someone please clue me in to what I'm missing? That way, I could > edit the Wiki page, to clue in others better. I've removed the question now. I think at one time it was possible to compile readline on Windows and to compile GHCi using that readline, but I haven't done it for a long time, and I don't know if it is still possible. If you or anyone else figures out more, please add it to the wiki. Cheers, Simon From simonmarhaskell at gmail.com Thu Jan 3 06:58:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 06:52:22 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CC84D.2040704@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> Message-ID: <477CCDD8.1080905@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Isaac Dupree wrote: >>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>> with --prefix=$HOME . >>> >>> It's odd because I previously had a 6.8.2 (official x86 Linux >>> bin-dist) installed as root (it's gone now), and I still have a bunch >>> of cabal/hackage packages installed in $HOME that were compiled by >>> that 6.8.2 (in addition to a few things installed by `cabal install` >>> in ~/.cabal/). Do you think that could be confusing the build >>> process, and if it is, is that a bug - and a bug in what? >> >> It looks like at some point you've updated your sources and recompiled >> without cleaning in stage2, or something similar. The build system >> doesn't currently notice when libraries have changed and stage2 needs >> to be completely recompiled. > > It sure looks that way! But I didn't do that personally; I think these > are all of my steps: > [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] > cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe > aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 > # this `aunpack` is equivalent to tar -xjf in this case. > cd ghc-6.8.2 > ./configure --prefix=$HOME > # ($HOME is /Users/me/HOME , by the way). > make > > Indeed I just reproduced it, newly unpacking that tarball in a new > location, to make sure, and I got the same error. > > > What if GHC suddenly decided to link with the newer versions of the > boot-libraries than come with 6.8.2, the ones that could be found in > $HOME since I installed them there? (or with the _same_ versions that > happened to be compiled with different flags, perhaps?) And you get different results if you omit the --prefix=$HOME? (if so, that's very strange, and I don't have a clue what's wrong, yet) Cheers, Simon From simonpj at microsoft.com Thu Jan 3 10:44:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 3 10:38:01 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: I've no objection to renaming it, if that's more convenient. It's a kind of composition operator, hence the name. Perhaps <:>? By all means send, or commit, a patch Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Neil Mitchell | Sent: 31 December 2007 15:15 | To: GHC Users | Subject: <.> defined in GHC and System.FilePath | | Hi | | The GHC API uses the <.> operator, which clashes with System.FilePath. | Possibly this might want renaming to something else - I have | absolutely no idea what it does! | | Prelude> :m GHC | Prelude GHC> :i <.> | (<.>) :: HsWrapper -> HsWrapper -> HsWrapper -- Defined in HsBinds | | Thanks | | Neil | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Thu Jan 3 10:47:38 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 3 10:41:34 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] Message-ID: <477D039A.2070102@dfki.de> Hi, can someone explain the linking error below? (on Intel-Mac (Tiger?)) Preprocessing library HDBC-sqlite3-1.1.3.0... Building HDBC-sqlite3-1.1.3.0... [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) [2 of 7] Compiling Database.HDBC.Sqlite3.Types ( Database/HDBC/Sqlite3/ Types.hs, dist/build/Database/HDBC/Sqlite3/Types.o ) [3 of 7] Compiling Database.HDBC.Sqlite3.Utils ( dist/build/Database/ HDBC/Sqlite3/Utils.hs, dist/build/Database/HDBC/Sqlite3/Utils.o ) [4 of 7] Compiling Database.HDBC.Sqlite3.Statement ( dist/build/ Database/HDBC/Sqlite3/Statement.hs, dist/build/Database/HDBC/Sqlite3/ Statement.o ) [5 of 7] Compiling Database.HDBC.Sqlite3.ConnectionImpl ( Database/ HDBC/Sqlite3/ConnectionImpl.hs, dist/build/Database/HDBC/Sqlite3/ ConnectionImpl.o ) [6 of 7] Compiling Database.HDBC.Sqlite3.Connection ( Database/HDBC/ Sqlite3/Connection.hs, dist/build/Database/HDBC/Sqlite3/Connection.o ) [7 of 7] Compiling Database.HDBC.Sqlite3 ( Database/HDBC/Sqlite3.hs, dist/build/Database/HDBC/Sqlite3.o ) ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o From ahey at iee.org Thu Jan 3 12:35:26 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Jan 3 12:29:23 2008 Subject: Is GHC.Base deliberately hidden? Message-ID: <477D1CDE.6010605@iee.org> Hello, Why is it that the haddock docs supplied with GHC omit this module and its exports? Is it because we're not supposed to use them? I'm thinking of the compareInt# function in particular, which I use quite a lot. Thanks -- Adrian Hey From wolfgang.thaller at gmx.net Thu Jan 3 13:04:59 2008 From: wolfgang.thaller at gmx.net (Wolfgang Thaller) Date: Thu Jan 3 12:59:20 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] In-Reply-To: <477D039A.2070102@dfki.de> References: <477D039A.2070102@dfki.de> Message-ID: <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> On 3-Jan-08, at 4:47 PM, Christian Maeder wrote: > Hi, > > can someone explain the linking error below? (on Intel-Mac (Tiger?)) > > Preprocessing library HDBC-sqlite3-1.1.3.0... > Building HDBC-sqlite3-1.1.3.0... > [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ > HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) [...] > ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl [...] To the best of my knowledge, this is harmless and can be ignored. Linking continues after this message is printed, and I haven't yet found any adverse side-effects. The message is triggered (in Apple's recently-rewritten linker) when there are two or more labels pointing to the very end of a section in an object file. This sometimes happens when empty _closure_tbls are emitted by GHC; it's probably not too hard to prevent this from happening. Cheers, Wolfgang From ndmitchell at gmail.com Thu Jan 3 13:23:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 3 13:17:43 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: <404396ef0801031023x54e6ce7crbd5197c01031b71@mail.gmail.com> Hi > Simon Marlow wrote: > i.e. qualify most things, but selectively import a few things unqualified. > The GHC API is quite huge, I expect clashes to be fairly common if you > import it unqualified. > On 1/3/08, Simon Peyton-Jones wrote: > I've no objection to renaming it, if that's more convenient. It's a kind of > composition operator, hence the name. Perhaps <:>? By all means send, or > commit, a patch If the API is intended to be huge and imported qualified, it doesn't matter if there are clashes. It is trivial to use hiding to solve this, so leaving it alone is fine. Thanks Neil From ndmitchell at gmail.com Thu Jan 3 13:29:25 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 3 13:23:20 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> Message-ID: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Hi Victor, > -package-name base > > should do the thing Thanks very much, that is the correct flag to allow built in syntax. However, turning that flag on also does other stuff, which breaks new things. Taking the module Prelude.hs, from a darcs checkout of the libraries: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Prelude. i.e. you can load the Prelude. However, specifying -package-name base: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts -package-name base GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help :1:22: Failed to load interface for `System.IO': it is not a module in the current program, or in any known package. :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' : panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is the same behaviour as loading Prelude without specifying -i. Moving -i to other places still gives the same behaviour. Does package-name base also imply other flags (perhaps -i. ?) which are negatively effecting my particular use. For context, my particular use is to call compileToCore on each file. If the file can be loaded in GHCi, it seems that I can do the compileToCore magic. Thanks Neil From catamorphism at gmail.com Thu Jan 3 14:05:34 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Jan 3 13:59:31 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <4683d9370801031105u3a2aa317p17afa4c8401a22c1@mail.gmail.com> Hi, Neil-- On 1/3/08, Neil Mitchell wrote: > Hi Victor, > > > -package-name base > > > > should do the thing > > Thanks very much, that is the correct flag to allow built in syntax. > However, turning that flag on also does other stuff, which breaks new > things. Taking the module Prelude.hs, from a darcs checkout of the > libraries: > > C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Ok, modules loaded: Prelude. > > i.e. you can load the Prelude. However, specifying -package-name base: > > C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > -package-name base > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > > :1:22: > Failed to load interface for `System.IO': > it is not a module in the current program, or in any known package. > > :1:22: Not in scope: `System.IO.stderr' > > :1:22: Not in scope: `System.IO.stdin' > : panic! (the 'impossible' happened) > (GHC version 6.8.1 for i386-unknown-mingw32): > interactiveUI:setBuffering > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Yeah, I've seen this before. One thing is that I generally avoid running code that uses the GHC API in GHCi, because I saw some reference somewhere to the fact that data structures can get mixed up that way, and it just seems to lead to madness :-) I've definitely seen the setBuffering panic message before, though haven't filed a bug report since I can't reproduce it reliably. In GHC, though, I can compile base package modules to Core just fine, if I provide the right import flags (-i and -I) so it can find all the dependencies. (If you want to see the complete list of flags I'm using, let me know :-) > This is the same behaviour as loading Prelude without specifying -i. > Moving -i to other places still gives the same behaviour. Does > package-name base also imply other flags (perhaps -i. ?) which are > negatively effecting my particular use. > I don't know, but in GHC (as opposed to GHCi), it all works. I can post some sample code if that would help; let me know. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly."--Woody Allen From isaacdupree at charter.net Thu Jan 3 14:36:25 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 3 14:30:27 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CCDD8.1080905@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> Message-ID: <477D3939.7070405@charter.net> Simon Marlow wrote: > Isaac Dupree wrote: >> Simon Marlow wrote: >>> Isaac Dupree wrote: >>>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>>> with --prefix=$HOME . >>>> >>>> It's odd because I previously had a 6.8.2 (official x86 Linux >>>> bin-dist) installed as root (it's gone now), and I still have a >>>> bunch of cabal/hackage packages installed in $HOME that were >>>> compiled by that 6.8.2 (in addition to a few things installed by >>>> `cabal install` in ~/.cabal/). Do you think that could be confusing >>>> the build process, and if it is, is that a bug - and a bug in what? >>> >>> It looks like at some point you've updated your sources and >>> recompiled without cleaning in stage2, or something similar. The >>> build system doesn't currently notice when libraries have changed and >>> stage2 needs to be completely recompiled. >> >> It sure looks that way! But I didn't do that personally; I think >> these are all of my steps: >> [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] >> cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe >> aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 >> # this `aunpack` is equivalent to tar -xjf in this case. >> cd ghc-6.8.2 >> ./configure --prefix=$HOME >> # ($HOME is /Users/me/HOME , by the way). >> make >> >> Indeed I just reproduced it, newly unpacking that tarball in a new >> location, to make sure, and I got the same error. >> >> >> What if GHC suddenly decided to link with the newer versions of the >> boot-libraries than come with 6.8.2, the ones that could be found in >> $HOME since I installed them there? (or with the _same_ versions that >> happened to be compiled with different flags, perhaps?) > > And you get different results if you omit the --prefix=$HOME? (if so, > that's very strange, and I don't have a clue what's wrong, yet) tested a couple more times: - it still fails without --prefix=$HOME - but it succeeds if I `su - east` and have 'east' compile it (without using --prefix here either) ('east' being another user on my machine other than the user 'me' which I usually use) Isaac From twanvl at gmail.com Thu Jan 3 21:22:52 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu Jan 3 21:16:44 2008 Subject: GHC source code improvement ideas Message-ID: <477D987C.2090806@gmail.com> Hello GHC people, I was trying my hand at some GHC hacking, and I couldn't help but notice that much of the code looks (IMHO) horrible. There are some things that look as if they haven't been touched since the Haskell 1.3 days. The most striking is the use of `thenXX` instead of do notation. I was thinking of cleaning up some of this. In particular: 1a. Use do notation where possible instead of `thenXX`. 1b. Even better, use Applicative where possible. For example ds_type (HsFunTy ty1 ty2) = dsHsType ty1 `thenM` \ tau_ty1 -> dsHsType ty2 `thenM` \ tau_ty2 -> returnM (mkFunTy tau_ty1 tau_ty2) Could be rewritten as ds_type (HsFunTy ty1 ty2) = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 2. Investigate the need for all these mappM functions. To quote the source: "Standard combinators, but specialised for this monad (for efficiency)". Wouldn't a SPECIALIZE pragma work just as well? 3. In general, use standard functions when they are available. Currently GHC has its own sort function and its own versions of FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data structures will a) make GHC smaller and therefore easier to maintain, and b) will make the code easier to understand for someone who knows the standard library. 4. A more radical change would be introducing hierarchical modules. This could be just a matter of renaming the directories to start with an upper case character and changing the import declarations. This gives module names like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the GHC api. How do the GHC developers feel about this? Would such paches be gladly excepted? Or will they be directly forwarded to the bit bucket? Twan From simonpj at microsoft.com Fri Jan 4 03:34:22 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 03:28:18 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: Twan, In general I'd be delighted for you to clean up GHC's code -- thank you! There is a slight down-side which is that because you end up touching a lot of code, you get a big patch that means you can't selectively pick patches from before and after the change -- but I'm not too bothered about that, and its balanced by the clean-up. Let's also see what Simon and Ian (or others) have to say. Best to do one change per patch. A very useful thing to do would be to improve the Commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary In fiddling with GHC's codebase you will surely learn stuff that you wish you'd known to start with, and that is the Ideal Moment to capture it in writing on the Wiki. A real service to others. | 1a. Use do notation where possible instead of `thenXX`. Yes. | 1b. Even better, use Applicative where possible. For example | | ds_type (HsFunTy ty1 ty2) | = dsHsType ty1 `thenM` \ tau_ty1 -> | dsHsType ty2 `thenM` \ tau_ty2 -> | returnM (mkFunTy tau_ty1 tau_ty2) | | Could be rewritten as | | ds_type (HsFunTy ty1 ty2) | = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 This works great when you have the pattern above -- but often it's a bit more complicated and then it does not work so well. So it's hard to employ the pattern consistently. Then you have to ask whether a mixture of styles is good. My gut feel is that it's better to use do-notation consistently. | 2. Investigate the need for all these mappM functions. To quote the | source: "Standard combinators, but specialised for this monad (for | efficiency)". Wouldn't a SPECIALIZE pragma work just as well? The trouble is that currently you can only specialise a function at its definition site -- and at the definition of mapM the relevant monad isn't in scope because mapM is in a library. I have no clue whether this has any effect on performance. You could try a small experiment, by defining mappM=mapM and seeing if there was any change. | 3. In general, use standard functions when they are available. Currently | GHC has its own sort function and its own versions of FiniteMap/Data.Map and | Text.PrettyPrint. Using standard functions/data structures will a) make GHC | smaller and therefore easier to maintain, and b) will make the code easier | to understand for someone who knows the standard library. In general yes. But GHC is meant to be compilable with any GHC back to 6.2. So if the interface to a library changes between (say) 6.2 and 6.4, you end up with ifdefs. That can be a royal pain. Having the library code in the compiler source eliminates that problem. The other thing is that it's possible that GHC's version of the library has more functions. Or uses some non-standard feature like unboxed types. So proceed with caution here. Prettyprinting would be a strong candidate. FiniteMap too. But be careful with UniqFM -- it's a very very heavily-used library. | 4. A more radical change would be introducing hierarchical modules. This | could be just a matter of renaming the directories to start with an upper | case character and changing the import declarations. This gives module names | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the | GHC api. I don't think I'd object, but I'm not sure that much is gained here. We don't spend much time on mondule-name clashes. Simon From Christian.Maeder at dfki.de Fri Jan 4 05:21:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:15:39 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] In-Reply-To: <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> References: <477D039A.2070102@dfki.de> <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> Message-ID: <477E08B8.4060203@dfki.de> Did a final "runhaskell Setup.lhs install" work for you, Emmanuel? Thanks, Wolfgang Cheers Christian Wolfgang Thaller wrote: > On 3-Jan-08, at 4:47 PM, Christian Maeder wrote: > >> Hi, >> >> can someone explain the linking error below? (on Intel-Mac (Tiger?)) >> >> Preprocessing library HDBC-sqlite3-1.1.3.0... >> Building HDBC-sqlite3-1.1.3.0... >> [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ >> HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) > [...] >> ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a >> ld: atom sorting error for >> _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl >> > [...] > > To the best of my knowledge, this is harmless and can be ignored. > Linking continues after this message is printed, and I haven't yet found > any adverse side-effects. > > The message is triggered (in Apple's recently-rewritten linker) when > there are two or more labels pointing to the very end of a section in an > object file. This sometimes happens when empty _closure_tbls are emitted > by GHC; it's probably not too hard to prevent this from happening. > > Cheers, > > Wolfgang > From Christian.Maeder at dfki.de Fri Jan 4 05:40:11 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:34:05 2008 Subject: Unrecognized -F flag In-Reply-To: <3978AF5D-3C97-4979-882D-FCD5ACD0D6B0@gmail.com> References: <3978AF5D-3C97-4979-882D-FCD5ACD0D6B0@gmail.com> Message-ID: <477E0D0B.6020802@dfki.de> Thanks, for your report. It was my fault. I should not have modified utils/hsc2hs/Main.hs as described in the following links. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583 http://hackage.haskell.org/trac/ghc/ticket/1395 A fix is to replace your file /lib/ghc-6.8.2/hsc2hs-bin with a new one that you can download from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/hsc2hs-bin (635468 Bytes) a ppc version from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/hsc2hs-bin (800044 Bytes) above is /usr/local (or the one you've configured with) Does someone have a cute command to easily update this file in a binary distribution (without unpacking and repacking), so that Ian can replaced my binary-dists (replacing hsc2hs-bin manually is a bit of a pain). Christian Adam Smyczek wrote: > Hi Christian, > > I'm using your OS X (Tiger) Intel ghc-6.8.2 distribution downloaded from > haskell.org. > So far everything worked great until I run into one problem compiling > zlib 0.4.0.1. > Running build command I get the following error: > > Preprocessing library zlib-0.4.0.1... > ghc-6.8.2: unrecognised flags: -F/Users/asmyczek/Library/Frameworks > Usage: For basic information, try the `--help' option. > compiling dist/build/Codec/Compression/Zlib/Stream_hsc_make.c failed > command was: /opt/local/bin/ghc -c -package base-3.0.1.0 -package > bytestring-0.9.0.1 -F/Users/asmyczek/Library/Frameworks > dist/build/Codec/Compression/Zlib/Stream_hsc_make.c -o > dist/build/Codec/Compression/Zlib/Stream_hsc_make.o > > I'm newbie to Haskell, Cabal etc. and not sure what the root cause of > this problem is. > Google did not find any concrete solution as well. Do you have an idea > what the problem > could be or maybe some hints where I can start to dig into? > > Thanks, > Adam > > From Christian.Maeder at dfki.de Fri Jan 4 06:03:10 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:57:04 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <200801032058.47615.naur@post11.tele.dk> References: <477CE624.3040806@dfki.de> <20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li> <200801032058.47615.naur@post11.tele.dk> Message-ID: <477E126E.90301@dfki.de> (Let's discuss this openly on glasgow-haskell-users) I'm not happy about this framework hick-hack either. I've only pushed it, because we needed a readline solution on macs. The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. Nobody supplied a binary distribution so far, though. I only supplied the binary distributions that I (naively) made anyway. Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed) In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues). HTH Christian Thorkil Naur wrote: > Hello, > > Thanks everybody. However, I believe that using a modified readline library is > debatable, mainly because it adds the burden of keeping this library > up-to-date to the GHC maintenance process. Having a renamed library is one > thing and it does not seem that also modifying the contents of the library is > an improvement. For me to consider this idea, it should be the very last > solution, every other stone having been turned. And I certainly believe that > stones remain to be turned in this case. > > I would very much like to hear your comments to this. > > In addition, if you must replace this framework with another with different > contents, I would suggest the use of some versioning scheme. Otherwise is > seems that a lot of confusion could result. > > Thanks and best regards > Thorkil > > On Thursday 03 January 2008 16:18, Ian Lynagh wrote: >> Hi Christian, >> >> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: >>> Judah's framework (2342543 Bytes) >>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip >>> >>> should replace (my old one) >>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip >> Done! >> >> >> Thanks >> Ian >> >> From simonpj at microsoft.com Fri Jan 4 06:23:48 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 06:17:42 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: | C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts | -package-name base | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help | | :1:22: | Failed to load interface for `System.IO': | it is not a module in the current program, or in any known package. I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion. The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding. Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing... Simon From isaacdupree at charter.net Fri Jan 4 07:17:23 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 07:11:25 2008 Subject: GHC source code improvement ideas In-Reply-To: References: <477D987C.2090806@gmail.com> Message-ID: <477E23D3.1000109@charter.net> Simon Peyton-Jones wrote: > | 4. A more radical change would be introducing hierarchical modules. This > | could be just a matter of renaming the directories to start with an upper > | case character and changing the import declarations. This gives module names > | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > | GHC api. > > I don't think I'd object, but I'm not sure that much is gained here. We don't > spend much time on mondule-name clashes. I vote for this, as it makes it easier to progress to standard module-chasing such as Cabal or `ghc --make`, and everyone supports hierarchical modules nowadays. (I might do it myself, if appropriate) warning: calling them "GHC.*" clashes with base's use of that namespace for implementation-specific functions in compiled programs, INCLUDING ghc (I mean, GHC code sometimes says "import GHC.Exts") ... so let's please find a different name-prefix if we decide we want one. ~Isaac From simonmarhaskell at gmail.com Fri Jan 4 07:27:48 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 07:21:44 2008 Subject: Is GHC.Base deliberately hidden? In-Reply-To: <477D1CDE.6010605@iee.org> References: <477D1CDE.6010605@iee.org> Message-ID: <477E2644.4060707@gmail.com> Adrian Hey wrote: > Why is it that the haddock docs supplied with GHC omit this module and > its exports? Is it because we're not supposed to use them? I'm thinking > of the compareInt# function in particular, which I use quite a lot. We don't intend GHC.Base to be a stable interface for external use, which is why we don't document it. Use at your own risk! If there's useful stuff in GHC.Base, then arguably we should have a published stable interface from which to get it, though. Cheers, Simon From simonpj at microsoft.com Fri Jan 4 08:15:13 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 08:09:06 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: | > The following won't compile for me | > | > isnull :: (forall a . [a]) -> Bool | > isnull ([] :: forall b . [b]) = True | > | > Couldn't match expected type `forall b. [b]' | > against inferred type `[a]' | > In the pattern: [] This is a pretty strange thing to do, to match a polymorphic argument against a data constructor. I guess you'd expect this to work too, perhaps? f :: forall a. (forall b. Either a b) -> a f (Left x) = x I grant that arguably these should work, but I think it'd be quite tricky to make it do so, because it'd involve re-generalising in the pattern. Furthermore, I can't see any use for it. Just remove the type signature from the pattern. One could argue that it's a bad sign that the pattern typechecker should have difficulty with this. But until it turns out to be important I'm not going to lose sleep over it! Interesting example though. Perhaps the error message should be better. Simon From simonmarhaskell at gmail.com Fri Jan 4 08:42:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 08:36:13 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <477E37B8.40701@gmail.com> Simon Peyton-Jones wrote: > | C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > | -package-name base > | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > | > | :1:22: > | Failed to load interface for `System.IO': > | it is not a module in the current program, or in any known package. > > I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. I can't off the top of my head think of a reason why it should fail, unless you use a special -package-name like base, rts, haskell98 or template-haskell. > Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion. This certainly works, because it must be possible to recompile a package P even though P is installed - it happens when you go back in libraries/ and say 'make', for example. Normally the already-installed P is hidden, because Cabal passes -hide-all-packages to GHC, so things work out fine. Probably GHC ought to filter out P and anything that depends on it from the set of installed packages anyway, to prevent strange things from happening. Cheers, Simon From simonmarhaskell at gmail.com Fri Jan 4 09:06:33 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:00:31 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: <477E3D69.5000307@gmail.com> Twan van Laarhoven wrote: > Hello GHC people, > > I was trying my hand at some GHC hacking, and I couldn't help but notice > that much of the code looks (IMHO) horrible. There are some things that > look as if they haven't been touched since the Haskell 1.3 days. The > most striking is the use of `thenXX` instead of do notation. > > I was thinking of cleaning up some of this. In particular: > > 1a. Use do notation where possible instead of `thenXX`. Yes. > 1b. Even better, use Applicative where possible. For example > > ds_type (HsFunTy ty1 ty2) > = dsHsType ty1 `thenM` \ tau_ty1 -> > dsHsType ty2 `thenM` \ tau_ty2 -> > returnM (mkFunTy tau_ty1 tau_ty2) > > Could be rewritten as > > ds_type (HsFunTy ty1 ty2) > = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 No, IMO. This just adds another abstraction that a potential GHC contributor has to learn about. Including me :-) It doesn't hurt to write out the code in full sometimes, and as the GHC coding style guidelines say: Remember: other people have to be able to quickly understand what you've done, and overuse of abstractions just serves to obscure the really tricky stuff, and there's no shortage of that in GHC. http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle (I think I might be quoting myself there, in which case it doesn't really add much credibility to my argument :). Also bear in mind that we have to be able to compile GHC with older versions of itself (currently back to 6.2.2), which explains why we're often conservative with respect to using external libraries. > 2. Investigate the need for all these mappM functions. To quote the > source: "Standard combinators, but specialised for this monad (for > efficiency)". Wouldn't a SPECIALIZE pragma work just as well? It does look like we could do away with some of those, yes. > 3. In general, use standard functions when they are available. > Currently GHC has its own sort function and its own versions of > FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data > structures will a) make GHC smaller and therefore easier to maintain, > and b) will make the code easier to understand for someone who knows the > standard library. In general yes. But bear in mind there's another principle at work here: we want to insulate GHC as much as possible from its environment, to reduce the chances of spurious failures or performance regressions. I believe our version of Text.PrettyPrint has diverged from the library version - last time I looked it wasn't obvious that we could replace it. Regarding Data.Map, I'd be interested in trying out AVL trees instead, to see if they have better performance, but then we'd have to import the code of course. > 4. A more radical change would be introducing hierarchical modules. > This could be just a matter of renaming the directories to start with an > upper case character and changing the import declarations. This gives > module names like "Typecheck.TcGadt". The tc is redundant here, so > perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". > Perhaps even better would be "GHC.Typecheck.GADT", this way some modules > can be exposed as part of the GHC api. Yes, I've wondered about doing this in the past. It does mean more typing, though: clearly 'import BasicTypes.Id' is more painful than just 'import Id' and doesn't add much, so IMO we'd need to put some thought into a structure that makes sense. > How do the GHC developers feel about this? Would such paches be gladly > excepted? Or will they be directly forwarded to the bit bucket? Within the constraints I've outlined above, cleanups are definitely welcome. Another worthwhile gardening-type activity is to go around elimianting warnings. Many modules have {-# OPTIONS -w #-} at the top, waiting for someone to go in and clean up all the warnings. They do catch real bugs, so this is not a waste of time by any means. In addition to this, things like - identifying and removing dead code - commoning up duplicate code fragments - improving test coverage - profiling and optimising hotspots are all useful tasks. Cheers, Simon From ndmitchell at gmail.com Fri Jan 4 09:07:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jan 4 09:01:43 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: <404396ef0801040607p1e1c4e8cv3913a3ac8e864729@mail.gmail.com> Hi Yhc did a few of these things, and our experiences were: > 1a. Use do notation where possible instead of `thenXX`. If it is that simple, yes. Certainly Yhc uses "super-monads" which made this a bit painful. You should probably step this by getting it to the stage where thenXX = >>=, then only flipping to do notation once the things are already monads. > 1b. Even better, use Applicative where possible. For example > > ds_type (HsFunTy ty1 ty2) > = dsHsType ty1 `thenM` \ tau_ty1 -> > dsHsType ty2 `thenM` \ tau_ty2 -> > returnM (mkFunTy tau_ty1 tau_ty2) > > Could be rewritten as > > ds_type (HsFunTy ty1 ty2) > = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 I still don't particularly like applicative, it is a bit confusing to me. If you moved to using the Uniplate library, you could then write: descendM dsHsType Shoter, more concise, and probably works for more cases than just HsFunTy - eliminating even more code. I suspect moving to Uniplate would give GHC massive benefits. > 4. A more radical change would be introducing hierarchical modules. This > could be just a matter of renaming the directories to start with an upper > case character and changing the import declarations. This gives module names > like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > GHC api. We did this in Yhc, and it was really useful just to group files into the same directory. Thanks Neil From simonmarhaskell at gmail.com Fri Jan 4 09:14:55 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:08:50 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477D3939.7070405@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> Message-ID: <477E3F5F.3070804@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Isaac Dupree wrote: >>> Simon Marlow wrote: >>>> Isaac Dupree wrote: >>>>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>>>> with --prefix=$HOME . >>>>> >>>>> It's odd because I previously had a 6.8.2 (official x86 Linux >>>>> bin-dist) installed as root (it's gone now), and I still have a >>>>> bunch of cabal/hackage packages installed in $HOME that were >>>>> compiled by that 6.8.2 (in addition to a few things installed by >>>>> `cabal install` in ~/.cabal/). Do you think that could be >>>>> confusing the build process, and if it is, is that a bug - and a >>>>> bug in what? >>>> >>>> It looks like at some point you've updated your sources and >>>> recompiled without cleaning in stage2, or something similar. The >>>> build system doesn't currently notice when libraries have changed >>>> and stage2 needs to be completely recompiled. >>> >>> It sure looks that way! But I didn't do that personally; I think >>> these are all of my steps: >>> [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] >>> cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe >>> aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 >>> # this `aunpack` is equivalent to tar -xjf in this case. >>> cd ghc-6.8.2 >>> ./configure --prefix=$HOME >>> # ($HOME is /Users/me/HOME , by the way). >>> make >>> >>> Indeed I just reproduced it, newly unpacking that tarball in a new >>> location, to make sure, and I got the same error. >>> >>> >>> What if GHC suddenly decided to link with the newer versions of the >>> boot-libraries than come with 6.8.2, the ones that could be found in >>> $HOME since I installed them there? (or with the _same_ versions that >>> happened to be compiled with different flags, perhaps?) >> >> And you get different results if you omit the --prefix=$HOME? (if so, >> that's very strange, and I don't have a clue what's wrong, yet) > > tested a couple more times: > - it still fails without --prefix=$HOME > - but it succeeds if I `su - east` and have 'east' compile it (without > using --prefix here either) ('east' being another user on my machine > other than the user 'me' which I usually use) Ah, I see. You have packages installed in your home directory for GHC 6.8.2, and these are being picked up by the stage1 compiler. We should be using -no-user-package-conf when running the compiler from the build tree. I'll test this fix. Note however that if you install this compiler, the packages in your home directory won't work any more, because they were compiled by another instance of 6.8.2 against a different set of packages. Cheers, Simon From isaacdupree at charter.net Fri Jan 4 09:24:36 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 09:18:30 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477E3F5F.3070804@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> <477E3F5F.3070804@gmail.com> Message-ID: <477E41A4.20504@charter.net> Simon Marlow wrote: > Note however that if you install this compiler, the packages in your > home directory won't work any more, because they were compiled by > another instance of 6.8.2 true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not counting packages? > against a different set of packages. hmm. different versions? I think it might work out since I installed everything locally, if I just install the versions of the extra-libs that came with the 6.8.2 bindist... Or do I have too great hopes in the reproducibility of ghc compilations? (Not that I have any reason to try that. I would probably just pull from the 6.8-darcs-branch to get your patch (and other post-6.8.2 fixes) and recompile everything anyway.) ~Isaac From simonmarhaskell at gmail.com Fri Jan 4 09:43:15 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:37:11 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477E41A4.20504@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> <477E3F5F.3070804@gmail.com> <477E41A4.20504@charter.net> Message-ID: <477E4603.5060002@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Note however that if you install this compiler, the packages in your >> home directory won't work any more, because they were compiled by >> another instance of 6.8.2 > > true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not > counting packages? Yes, the ABI is the same, but there's no guarantee that the interfaces to all the packages are the same. >> against a different set of packages. > > hmm. different versions? I think it might work out since I installed > everything locally, if I just install the versions of the extra-libs > that came with the 6.8.2 bindist... > > Or do I have too great hopes in the reproducibility of ghc compilations? It's too fragile to rely on getting the same results when you compile a package again, if -O is on. In practice, if the conditions are exactly the same you can often get identical interfaces, but we've never put any effort into figuring out how to guarantee this and under what conditions. Better not to rely on it. Cheers, Simon From Christian.Maeder at dfki.de Fri Jan 4 10:38:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 10:32:34 2008 Subject: Maps, was Re: GHC source code improvement ideas In-Reply-To: <477E3D69.5000307@gmail.com> References: <477D987C.2090806@gmail.com> <477E3D69.5000307@gmail.com> Message-ID: <477E5301.8010700@dfki.de> Simon Marlow wrote: > Regarding Data.Map, I'd be interested in trying out AVL trees instead, > to see if they have better performance, but then we'd have to import the > code of course. Surely, we want the best maps possible for ghc and as public library (and minimize maintenance). The problem is to agree on a suitable interface. I would suggest to take (or only slightly change) Daan's interface (the current Data.Map) and improve the underlying implementation possibly using (i.e. Adrian Hey's) AVL trees. Christian From Christian.Maeder at dfki.de Fri Jan 4 12:03:50 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 11:57:43 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <47682317.6030407@dfki.de> References: <47682317.6030407@dfki.de> Message-ID: <477E66F6.3040504@dfki.de> Christian Maeder wrote: > > http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 these dists are updated now, with a proper (though stripped) file hsc2hs-bin that caused problems http://hackage.haskell.org/trac/ghc/ticket/1395. > The frameworks under > http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm > should do. > The Mac binaries have been built using > gcc version 4.0.1 (Apple Computer, Inc. build 5367) > and a patched Linker.lhs from > http://hackage.haskell.org/trac/ghc/ticket/1798 Also the file compiler/main/DriverPipeline.hs is (still) patched according to http://hackage.haskell.org/trac/ghc/ticket/1395 > The PPC binary still features: > http://hackage.haskell.org/trac/ghc/ticket/1845 Both binaries have a fix for http://hackage.haskell.org/trac/ghc/ticket/1980 now. (Only the PPC dist has been rebuilt, the i386 one was only repacked) Ian, could you replace the dists on the download page? It's possible to overwrite an installation (and loose your later installed packages!), but not necessary in most cases. Still use "make install-strip" after "./configure". Christian From igloo at earth.li Fri Jan 4 12:47:39 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 4 12:41:31 2008 Subject: GHC source code improvement ideas In-Reply-To: References: <477D987C.2090806@gmail.com> Message-ID: <20080104174739.GA8322@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: > > | 4. A more radical change would be introducing hierarchical modules. This > | could be just a matter of renaming the directories to start with an upper > | case character and changing the import declarations. This gives module names > | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > | GHC api. > > I don't think I'd object, but I'm not sure that much is gained here. We don't spend much time on mondule-name clashes. One point is that GHC uses module names like Util and State, which is a bit unfriendly to people using GHC-as-a-library. Also, although "import Types.Generics" is a bit longer to type, it is also a bit easier for someone less familiar with the code to follow the imports (if their editor does not help them). It's a pity that GHC.* is already used in base. I'm not sure what the best thing to do is in the short term. Thanks Ian From kili at outback.escape.de Fri Jan 4 15:54:45 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 4 15:48:54 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: References: Message-ID: <20080104205445.GA30327@petunia.outback.escape.de> [Note: already shortly discussed with Wilhelm] On Fri, Nov 23, 2007 at 12:30:06PM +0000, Wilhelm B. Kloke wrote: > > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi > > Prologue junk?: .type s32x_ret, @function > > s32x_ret: > > pushl %ebp > > movl %esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Regardless of wether there's something wrong with the generated code or wether it's just a bug in the mangler, it's possible to build Process.c with -fviaC *and* -O0.[1] For now, I'm able to build a HC file bundle with this settings in build.mk and running "gmake stage1 hc-file-bundle": SRC_HC_OPTS= -H64 -O -fvia-C -keep-hc-files GhcLibHcOpts= -O0 # Workaround the mangler problem GhcLibWays= GhcRTSWays= SplitObjs= NO I'd appreciate any reports wether people see the same problem on other systems (if so: what gcc version are you using?) and wether GhcLibHcOpts=-O0 fixes it. Ciao, Kili [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Apart from the HC file bundle, this will require some more hacking especially on library/Makefile and the Cabal-generated GNUmakefiles (and/or Makefile.local). pps: I guess, cvs-ghc would be the more correct list for sending patches and discussing the bootstrapping stuff, right? From brianh at metamilk.com Fri Jan 4 19:26:41 2008 From: brianh at metamilk.com (Brian Hulley) Date: Fri Jan 4 19:17:03 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <20080104174739.GA8322@matrix.chaos.earth.li> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> Message-ID: <477ECEC1.8000109@metamilk.com> Ian Lynagh wrote: > On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: >> | 4. A more radical change would be introducing hierarchical modules. >> > > It's a pity that GHC.* is already used in base. I'm not sure what the > best thing to do is in the short term. > How about Language.Haskell.Compiler.GHC.* In the long term, Haskell needs a better module system IMHO, since the problem at the moment is that having to write the full hierarchical name in each module means that you need to know in advance, before you've even started writing a program, where each module will fit into the global namespace, which makes it extraordinarily difficult to do exploratory programming or bottom-up development, and the need to write so many import directives in each module makes it extremely painful not to mention overly hard-wired. A good direction IMHO is the way SML structures are grouped using CM.make (SML/NJ) or MLBasis (MLton and others), so that there are no import directives at all: a separate group definition determines what is in scope, and compilation proceeds by chasing these group definition files rather than chasing modules. Translating this into Haskell, the module syntax could be simplified and other modules could be nested and aliased within a module, so that it is easy to create different hierarchical views of the modules which are in scope to suit the particular module being written or clients of that module: -- Leaf.hs module Leaf where module String where open Data.ByteString.Char8 type T = ByteString module Map = Data.Map module Util where foo :: Int -> Int foo i = i --Other.hs module Other where bar :: Int -> Leaf.String.T bar = Leaf.String.pack . show . Leaf.Util.foo Note that here there is no need for any import directives, since the modules which are in scope when Leaf.hs is compiled would be determined by whatever group Leaf.hs is part of (with respect to that particular program), which would be defined in a separate file: --MyBasis.hsg local $Haskell/StdBase.hsg Leaf.hs Other.hs Within the .hsg files, groups and modules are referenced by filename, and is just a simple list of components that are required and/or exported by the group. In the .hsg file above, MyBasis will export the contents of Leaf.hs and Other.hs, which are compiled in an environment augmented by StdBase (which is not itself exported by MyBasis). (See CM.make and the MLBasis system for more details - in particular, for any given program a module may appear in only one group, but the same module may appear in different groups in different programs thus facilitating easy exploratory programming and re-organization without breaking previous programs.) This can be taken further to get an even more powerful system by using parameterized traits and explicit instantiation for modules: trait T a b where foo :: a -> b bar :: Int -> Int bar i = i + 1 module M where include T Int String foo = show . bar Here, the body of a module is always a trait, and the above is equivalent to: trait T a b = tra foo :: a -> b bar :: Int -> Int bar i = i + 1 module M = new tra include T Int String foo = show . bar which makes it more explicit that conversion of the contents to actual code (ie linking, allocation/identity/initialization of CAFs and foreign objects, generativity of data types etc) happens only in the module decl. The great thing about making instantiation explicit is that traits are pure functional values and so can easily be combined with no side effects, whereas modules may in general contain mutable state eg to interface with some external C library and thus are objects-with-identity. Thus the separation solves the whole problem of applicative vs generative functors in ML, as well as solving the problem of mutually recursive structures (functors become a redundant concept because you can always start with including a trait then overriding some decls with more instantiated (here used in a different sense) decls and/or traits). Last but not least, a trait could also be used similarly to a signature, except that definitions in the trait can be considered to be default implementations. Therefore in this scenario the body of a class or instance decl is just a trait and so could be composed using other traits etc. (Each instance decl instantiates the trait given in the body merged with the trait given in the class leading to a possibly parameterized module.) Anyway these are some of the directions I am currently working on for my new language which is a strict version of Haskell/ML but where explicit type annotations drive name resolution rather than explicit namespace annotations driving type inference. Related work for the above version of traits/mixins includes the Scala language and the approach described in "Evolving Software with Extensible Modules" by Matthias Zenger. Regards, Brian. -- www.metamilk.com From isaacdupree at charter.net Fri Jan 4 20:24:32 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 20:18:25 2008 Subject: wish for more-usable bindist Message-ID: <477EDC50.10308@charter.net> the i386 linux ghc bindist still uses readline 4 , which is hard to get: readline 5.0 came out almost three and a half years ago And I don't want to pollute my Ubuntu system with "compatibility RPMs"; in fact I intend to install the bindist as my local user so I don't pollute it with extra GHCs either, except I can't. Could there be a bindist with modern readline, or perhaps is it possible to statically link with readline? ~Isaac From brianh at metamilk.com Fri Jan 4 21:02:09 2008 From: brianh at metamilk.com (Brian Hulley) Date: Fri Jan 4 20:52:30 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <477ECEC1.8000109@metamilk.com> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> Message-ID: <477EE521.1010207@metamilk.com> Brian Hulley wrote: > Ian Lynagh wrote: >> On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: >>> | 4. A more radical change would be introducing hierarchical modules. >>> Sorry I quoted what Simon PJ replied to not what he wrote so I should have written: > Ian Lynagh wrote: >> >>> On Fri, Jan 04, 2008, Twan van Laarhoven wrote: >>> 4. A more radical change would be introducing hierarchical modules. Though this is again not quite right since Ian did not write line 3... Apologies to Simon PJ and Twan (and now also to Ian) for mis-quoting ;-) Brian. From isaacdupree at charter.net Fri Jan 4 21:36:33 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 21:30:26 2008 Subject: there isn't any difference, is there, with unboxed tuples? Message-ID: <477EED31.6050802@charter.net> --> unboxed types in function results are automatically "lifted"... or what was the term meaning they could be _|_, failing to terminate, (because of the function-ness)? --> unboxed tuples are specially restricted to be only allowed, among useful places, in function results. Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, assuming both are kind-correct (identical in terms of optimization and semantics, not type equality, of course). Is that right? If so, there's never an excuse to use unboxed tuples except to contain unboxed values (because then you don't have the choice of using boxed tuples, which can only contain boxed values of kind *). ~Isaac From stefanor at cox.net Fri Jan 4 21:55:30 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Jan 4 21:49:23 2008 Subject: there isn't any difference, is there, with unboxed tuples? In-Reply-To: <477EED31.6050802@charter.net> References: <477EED31.6050802@charter.net> Message-ID: <20080105025530.GA5339@localhost.localdomain> On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote: > --> unboxed types in function results are automatically "lifted"... or what > was the term meaning they could be _|_, failing to terminate, (because of > the function-ness)? > > --> unboxed tuples are specially restricted to be only allowed, among > useful places, in function results. > > Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, > assuming both are kind-correct (identical in terms of optimization and > semantics, not type equality, of course). Is that right? If so, there's > never an excuse to use unboxed tuples except to contain unboxed values > (because then you don't have the choice of using boxed tuples, which can > only contain boxed values of kind *). Semantically, you are absolutely correct. However, there is a very subtle difference in sharing. Consider these two functions: foo (a,b) = (a,b) bar tuple = tuple These two functions are denotationally identical, but at runtime one performs more allocations. If we use unboxed tuples, then the caller must always allocate if a tuple is needed; thus effectively we always get the allocation behavior of foo. That is, return unboxing is not always an optimization! However, it *is* always safe if the tuple is constructed in the function itself, for then it could not possibly be shared with anything. Having explicit unboxed tuples in the language allows this complexity to be moved out of the code generator, which is a Good Thing. (Incidentally, this is what the CPR analysis is all about - identifying places where a Constructed Product is Returned.) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080104/8d840154/attachment.bin From isaacdupree at charter.net Sat Jan 5 05:45:38 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jan 5 05:39:28 2008 Subject: there isn't any difference, is there, with unboxed tuples? In-Reply-To: <20080105025530.GA5339@localhost.localdomain> References: <477EED31.6050802@charter.net> <20080105025530.GA5339@localhost.localdomain> Message-ID: <477F5FD2.1090408@charter.net> Stefan O'Rear wrote: > Semantically, you are absolutely correct. However, there is a very > subtle difference in sharing. > > Consider these two functions: > > foo (a,b) = (a,b) > bar tuple = tuple > > These two functions are denotationally identical, but at runtime one > performs more allocations. If we use unboxed tuples, then the caller > must always allocate if a tuple is needed; thus effectively we always > get the allocation behavior of foo. That is, return unboxing is not > always an optimization! However, it *is* always safe if the tuple is > constructed in the function itself, for then it could not possibly be > shared with anything. Having explicit unboxed tuples in the language > allows this complexity to be moved out of the code generator, which is a > Good Thing. (Incidentally, this is what the CPR analysis is all about - > identifying places where a Constructed Product is Returned.) hmm. so it might have to be some hypothetical syntax like (... -> {-#UNPACK#-} (a, b)) when in a data type (for some monad definition in GHC's code, so I don't want to lose performance by boxing it). (Either that or it might actually be more efficient if it were boxed!) Am I right that CPR analysis can look at particular functions, but there's no way for it to change the representation of a function stored in a data/newtype? ~Isaac From ndmitchell at gmail.com Sat Jan 5 09:47:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jan 5 09:41:06 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <404396ef0801050647r43cd5312qd41c97e3dae52c4b@mail.gmail.com> Hi > I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. > > The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding. > > > Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing... I think in consultation with Tim (many thanks!) I've figured out why things aren't working, and how I can lightly hack around the problem. The first issue seems to be that I'm trying to compile modules from the base library source against preinstalled versions, not versions I've built myself - meaning I lack .hi-boot files. The second issue seems to concern various flags and meanings of flags. What I'm doing is clearly well beyond anything that was ever contemplated, but is working near enough that I can use it to do the next stages. Once I have everything a bit more stabalised, I'll post up my code and my intentions and try and classify the exact issues I am running into. Thanks Neil From igloo at earth.li Sat Jan 5 11:01:09 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 5 10:54:57 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <477E66F6.3040504@dfki.de> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> Message-ID: <20080105160109.GA18866@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 06:03:50PM +0100, Christian Maeder wrote: > Christian Maeder wrote: > > > > http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 > > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 > > Ian, could you replace the dists on the download page? Done; I assume that these dists include the new hsc2hs-bin from http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013998.html ? Thanks Ian From naur at post11.tele.dk Sat Jan 5 13:29:49 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat Jan 5 13:24:41 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> Message-ID: <200801051929.51180.naur@post11.tele.dk> Hello, On Friday 04 January 2008 12:03, Christian Maeder wrote: > ... Thanks a lot for this response. > I'm not happy about this framework hick-hack either. I am glad we agree about that. > I've only pushed > it, because we needed a readline solution on macs. I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot. > The alternative is to use static linking of gmp (as suggested by chak) > _and_ readline (version 5), so that user programs are also statically > linked with these libs. Again, I am not convinced that this is the only alternative. > ... > Regarding this actual GNUreadline-framework.zip replacement, this is > harmless and seems to matter only for those who build ghc with > frameworks (as only the inclusion of header files changed) It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea. > > In any case we should strive to fix the frameworks issues _and_ add > support for static linking of gmp, readline and possibly other libs > (plus license issues). I fully agree with this. Ideally, the plan would be to, first, figure out what the ideal solution looks like. And then work towards that ideal solution. Making sure that what we introduce on the way as short-term hacks are clearly marked as such, to ensure that they don't impress themselves on people's minds as part of the final solution. I have every intention to work out some ideal (or perhaps more modestly: better) solution. But whether it will emerge in time to make any difference, remains to be seen. > > HTH Christian Thanks and best regards Thorkil From ndmitchell at gmail.com Sat Jan 5 15:00:44 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jan 5 14:54:32 2008 Subject: GHC Core question Message-ID: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Hi I've compiled the Debug.Trace module to Core, but can't understand the resulting output. The original code is: trace string expr = unsafePerformIO $ do putTraceMsg string return expr The core is: Debug.Trace.trace = \ (@ a) -> __letrec { trace :: GHC.Base.String -> a -> a [] trace = \ (string :: GHC.Base.String) (expr :: a) -> GHC.Base.$ @ (GHC.IOBase.IO a) @ a (GHC.IOBase.unsafePerformIO @ a) (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = $dMonad; return :: forall a. a -> GHC.IOBase.IO a [] return = GHC.Base.return @ GHC.IOBase.IO $dMonad; $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = GHC.IOBase.$f16; >> :: forall a b. GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b [] >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; } in trace; And my Haskell reformatting of that is: Debug.Trace.trace = let trace string expr = unsafePerformIO $ putTraceMsg string >> return expr $dMonad = $dMonad; return = GHC.Base.return $dMonad; $dMonad = GHC.IOBase.$f16; >> = GHC.Base.>> $dMonad; in trace However, that let expression has two bindings for $dMonad, one of which looks like a black-hole. Are the semantics of __letrec different from let in some way? Thanks Neil From judah.jacobson at gmail.com Sat Jan 5 15:23:59 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 5 15:17:48 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <200801051929.51180.naur@post11.tele.dk> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> Message-ID: <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: > On Friday 04 January 2008 12:03, Christian Maeder wrote: > > I understand that there are problems in this area, but I am not convinced that > they could not be solved without the renamed and/or modified readline > library. I am sorry if you have done that already elsewhere, but I don't > recall having seen any details about your difficulties. Would you be kind > enough to supply some details? Thanks a lot. > > > The alternative is to use static linking of gmp (as suggested by chak) > > _and_ readline (version 5), so that user programs are also statically > > linked with these libs. > > Again, I am not convinced that this is the only alternative. There is another alternative (which I think we talked about before): Have ghc manually search for frameworks in the standard folders (rather than letting gcc do it automatically). Then if we found e.g. /Library/Frameworks/GNUreadline.framework, we would pass the following flag: -I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers In that case, we would not need modified readline headers. However, I really don't like the above, since we're reimplenting something gcc gives us for free. And if we *do* rely on gcc's standard searching (as is the case now), then I agree with Christian that modified headers are necessary for GNUreadline to work as a framework. Also, the script that builds GNUreadline.framework modifies the header files automatically. So I don't think it's any worse than, say, pre-processing a library as part of a MacPorts distribution. > > ... > > Regarding this actual GNUreadline-framework.zip replacement, this is > > harmless and seems to matter only for those who build ghc with > > frameworks (as only the inclusion of header files changed) > > It is perhaps without any practical consequences, but I have seen many cases > where circumstances managed to create the most glorious confusion out of the > most innocently looking changes. So I would maintain that replacing something > that you have published with something different is not a good idea. I looked into this, and frameworks do already support versioning: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html In particular, one framework can contain multiple versions. So currently GNUreadline.framework contains: Versions/A/GNUreadline (object code file) Versions/A/Headers (a folder containing header files) GNUreadline (symlink to `Versions/A/GNUreadline`) Headers (symlink to `Versions/A/Headers`) And we could distribute instead a GNUreadline.framework which contains: Versions/A/GNUreadline (object code file) Versions/B/GNUreadline (symlink to the above) GNUreadline (symlink to Versions/A/GNUreadline) Versions/A/Headers (a folder containing unmodified headers) Versions/B/Headers (a folder containing modified headers) Headers (symlink to Versions/B/Headers) The above makes version B the default, but version A is still available if you want it. We could do something similar when upgrading to readline 6.0 if it ever comes out. Finally, we could also change the name of the .zip file to reflect the version of the framework, so that users don't confuse the two downloads. Would the above make the modified GNUreadline feel like less of a hack? Best, -Judah From evas at mountaincable.net Sat Jan 5 15:38:58 2008 From: evas at mountaincable.net (Chris Saunders) Date: Sat Jan 5 15:34:20 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <20080105160109.GA18866@matrix.chaos.earth.li> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> <20080105160109.GA18866@matrix.chaos.earth.li> Message-ID: <000601c84fda$ff6abff0$fe403fd0$@net> Will there be a binary release for Windows x86_64? Regards Chris Saunders From waldmann at imn.htwk-leipzig.de Sat Jan 5 17:28:16 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Jan 5 17:22:04 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <477ECEC1.8000109@metamilk.com> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> Message-ID: <47800480.7050808@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Hulley wrote: > In the long term, Haskell needs a better module system IMHO [...] I agree with the symptoms that were described, but I draw a different conclusion. We don't need to change the language - we need better tools (IDEs) that operate not at the textual level, but use the annotated syntax tree, including knowledge on fully qualified names and types. E.g. Java requires to write full package names everywhere, but this is never a problem when working with Eclipse (or any other modern IDE I assume) since it just knows how to rename a package or move a class etc. Try moving some Haskell functions/declarations by hand (e.g. with Emacs) into a different, or a new module. It's a nightmare until you get all the imports and qualified usages right. But it really is conceptually simple, so it should be a one-click operation. Since it's this time of the year, here's my wish for 2008: a version of HaRe (Haskell Refactorer) that knows current ghc language extensions *and is integrated with Eclipse* The way to go seems this: http://eclipsefp.sourceforge.net/cohatoe/ and I dearly hope there will be more progress on that. Best regards, Johannes Waldmann, Leipzig. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgAR23ZnXZuOVyMIRAvYsAJ9DRhuJ3Nxyn+L+elwij5YmqWw89wCgrtLX tBgzlnLUjkNWqPkZgCykLuk= =I3TR -----END PGP SIGNATURE----- From ahey at iee.org Sun Jan 6 07:37:53 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Jan 6 07:31:40 2008 Subject: Maps, was Re: GHC source code improvement ideas In-Reply-To: <477E5301.8010700@dfki.de> References: <477D987C.2090806@gmail.com> <477E3D69.5000307@gmail.com> <477E5301.8010700@dfki.de> Message-ID: <4780CBA1.4040907@iee.org> Christian Maeder wrote: > Simon Marlow wrote: >> Regarding Data.Map, I'd be interested in trying out AVL trees instead, >> to see if they have better performance, but then we'd have to import the >> code of course. > > Surely, we want the best maps possible for ghc and as public library > (and minimize maintenance). > > The problem is to agree on a suitable interface. I would suggest to take > (or only slightly change) Daan's interface (the current Data.Map) and > improve the underlying implementation possibly using (i.e. Adrian Hey's) > AVL trees. The trouble is as far as implementations is concerned the best maps possible is a continually moving target I suspect, not to mention being highly dependent on key type. I certainly wouldn't say AVL tree based Maps are best possible, though they do seem give better performance (particularly for union, intersection etc..). The clone also address some defects in the current Data.Map (like lack of strictness control) and has some other useful stuff. But if this is going to be used at all, I would say this is only a stop gap solution, which leads me to your second point about interfaces. The generalised trie lib I was working on was a serious attempt to see what a real useable non-toy map API should look like. It's the GT class here.. http://code.haskell.org/collections/collections-ghc6.8/Data-Trie-General/Data/Trie/General/Types.hs (Sorry for the long URL). It's already somewhat huge and still incomplete IMO, but even in it's current form it gives a uniform API for Ints, arbitrary Ord instances and Lists. It's a shame it's all completely untested :-( What really needs to happen on this is.. 1 - "Finish" and stabilise the GT class definition. There's still more that's needed but I think the promised type families magic is needed first. 2 - Write a comprehensive test/benchmarking suite for GT instances. 3 - Provide some way to automatically generate the instances for arbitrary user defined types. Which is all rather a lot of work that nobody seems very interested in :-( Regards -- Adrian Hey From jbapple+ghc-users at gmail.com Sun Jan 6 11:20:42 2008 From: jbapple+ghc-users at gmail.com (Jim Apple) Date: Sun Jan 6 11:14:27 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: On Jan 4, 2008 5:15 AM, Simon Peyton-Jones wrote: > | > The following won't compile for me > | > > | > isnull :: (forall a . [a]) -> Bool > | > isnull ([] :: forall b . [b]) = True > | > > | > Couldn't match expected type `forall b. [b]' > | > against inferred type `[a]' > | > In the pattern: [] > > This is a pretty strange thing to do, to match a polymorphic argument against a data constructor. I guess you'd expect this to work too, perhaps? > > f :: forall a. (forall b. Either a b) -> a > f (Left x) = x > > I grant that arguably these should work, but I think it'd be quite tricky to make it do so, because it'd involve re-generalising in the pattern. Furthermore, I can't see any use for it. Just remove the type signature from the pattern. > > One could argue that it's a bad sign that the pattern typechecker should have difficulty with this. But until it turns out to be important I'm not going to lose sleep over it! This is literate Haskell. It's in the LaTeX style, since my mail reader won't change the quoting mark from '>'. It is not a valid LaTeX file. My reason for wanting pattern matching on values of polymorphic types is a kind of first-level refinement types. I'm going to demonstrate using the "risers" function, as presented in Dana N. Xu's ESC/Haskell (http://research.microsoft.com/Users/simonpj/papers/verify/escH-hw.ps or http://www.cl.cam.ac.uk/~nx200/research/escH-hw.ps ), which references Neil Mitchell's Catch (http://www-users.cs.york.ac.uk/~ndm/catch/ ). I'll also be referencing an example from Tim Freeman's thesis on refinement types for ML (http://www.cs.ucla.edu/~palsberg/tba/papers/freeman-thesis94.pdf ) \begin{code} {-# OPTIONS -fglasgow-exts #-} -- The LANGUAGE pragma is usually a pain for exploratory programming. \end{code} This is the risers function, as presented by Xu. It returns the sorted sublists of a list. None of the lists in the return value are empty, and if the argument is non-empty, the return value is also non-empty. \begin{code} risersXu :: (Ord t) => [t] -> [[t]] risersXu [] = [] risersXu [x] = [[x]] risersXu (x:y:etc) = let ss = risersXu (y : etc) in case x <= y of True -> (x : (head ss)) : (tail ss) False -> ([x]) : ss \end{code} Xu uses head and tail. These are safe here by a proof created by ESC/Haskell. Here is the risers function according to Mitchell: \begin{code} risersMitchell :: Ord a => [a] -> [[a]] risersMitchell [] = [] risersMitchell [x] = [[x]] risersMitchell (x:y:etc) = if x <= y then (x:s):ss else [x]:(s:ss) where (s:ss) = risersMitchell (y:etc) \end{code} The unsafe part here is the pattern in the where clause. Mitchell presents a tool to prove this safe. These unsafe operations depend on the second property of the function: non-null inputs generate non-null outputs. We could write a type for this functions using a trusted library with phantom types for branding (http://okmij.org/ftp/Computation/lightweight-dependent-typing.html ). This technique (called lightweight static capabilities) can do this and much else, as well, but clients lose all ability to pattern match (even in case). We could also write a type signature guaranteeing this by using GADTs. Without either one of these, incomplete pattern matching or calling unsafe head and tail on the result of the recursive call seems inevitable. Here's another way to write the function which does away with the need for second property on the recursive call, substituting instead the need for the first property, that no lists in the return value are empty: \begin{code} risersAlt :: (Ord t) => [t] -> [[t]] risersAlt [] = [] risersAlt (x:xs) = case risersAlt xs of [] -> [[x]] w@((y:ys):z) -> if x <= y then (x:y:ys):z else ([x]):w ([]:_) -> error "risersAlt" \end{code} The error is never reached. Though ensuring the second property with our usual types seems tricky, ensuring the first is not too tough: \begin{code} type And1 a = (a,[a]) risersAlt' :: Ord a => [a] -> [And1 a] risersAlt' [] = [] risersAlt' (x:xs) = case risersAlt' xs of [] -> [(x,[])] w@(yys:z) -> if x <= fst yys then (x,fst yys : snd yys):z else (x,[]):w \end{code} It is now much easier to see that risers is safe: There is one pattern match and one case, and each is simple. No unsafe functions like head or tail are called. It does have two disadvantages. First, the second property is still true, but the function type does not enforce it. This means that any other callers of risers may have to use incomplete pattern matching or unsafe functions, since they may not be so easy to transform. It is my intuition that it is not frequently the case that these functions are tricky to transform, but perhaps Neil Mitchell disagrees. We could fix this by writing another risers function with type And1 a -> And1 (And1 a), but this brings us to the second problem: And1 a is not a subtype of [a]. This means that callers of our hypothetical other risers function (as well as consumers of the output from risersAlt') must explicitly coerce the results back to lists. Let's write more expressive signatures using the principle from my original question. \begin{code} data List a n = Nil n | forall r . a :| (List a r) \end{code} [] is the only value of type forall a . [a], assuming no values of type forall a . a. Similarly, the only values of type forall a . List a n use the Nil constructor, and the only values of type forall n . List a n use the :| constructor. \begin{code} infixr :| box x = x :| Nil () type NonEmpty a = forall n . List a n onebox :: NonEmpty Int onebox = box 1 onebox' :: List Int Dummy onebox' = onebox data Dummy -- This doesn't compile -- empty :: NonEmpty a -- empty = Nil () \end{code} NonEmpty a is a subtype of List a x for all types x. Now we get to the disappointing part of the show in which I pine for first-class existentials and pattern matching on polymorphic values. \begin{code} data Some f a = forall n . Some (f a n) safeHead :: NonEmpty a -> a safeHead x = unsafeHead x where unsafeHead (x :| _) = x safeTail :: NonEmpty a -> Some List a safeTail x = unsafeTail x where unsafeTail (_ :| xs) = Some xs \end{code} Unfortunately, we'll be forced to Some and un-Some some values, and it takes some thinking to see that safeHead and safeTail are actually safe. \begin{code} risersMitchell' :: Ord a => List a n -> List (NonEmpty a) n risersMitchell' (Nil x) = (Nil x) risersMitchell' (x :| Nil _) = box (box x) risersMitchell' ((x {- :: a -}) :| y :| etc) = case risersMitchell' (y :| etc) {- :: NonEmpty (NonEmpty a) -} of Nil _ -> error "risersMitchell'" s :| ss -> if x <= y then (x :| s) :| ss else (box x) :| s :| ss \end{code} Since we can't put the recursive call in a where clause, we must use a case with some dead code. The type annotations are commented out here to show they are not needed, but uncommenting them shows that the recursive call really does return a non-empty lists, and so the Nil case really is dead code. This type signature ensures both of the properties listed when introducing risers. The key to the non-empty-arguments-produce-non-empty-results property is that the variable n in the signature is used twice. That means applying risersMitchell' to a list with a fixed (or existential) type as its second parameter can't produce a NonEmpty list. \begin{code} risersXu' :: Ord a => List a r -> List (NonEmpty a) r risersXu' (Nil x) = Nil x risersXu' (x :| Nil _) = box (box x) risersXu' (x :| y :| etc) = let ss = risersXu' (y :| etc) in case x <= y of True -> case safeTail ss of Some v -> (x :| (safeHead ss)) :| v False -> (box x) :| ss \end{code} Here we see that the type annotation isn't necessary to infer that risers applied to a non-empty list returns a non-empty list. The value ss isn't given a type signature, but we can apply safeHead and safeTail. The case matching on safeTail is the pain of boxing up existentials. This is the first version of risers with a type signature that gives us the original invariant Xu and Mitchell can infer, as well as calling no unsafe functions and containing no incomplete case or let matching. It also returns a list of lists, just like the original function. With first-class existentials, this would look just like Xu's risers (modulo built-in syntax for lists). With pattern matching for polymorphic values, risersMitchell' would look just like Mitchell's original risers, but be safe by construction. Pattern matching for polymorphic values would also allow non-trusted implementations of safeTail and safeHead to be actually safe. Since GADTs and lightweight static capabilities are already available, I do not know how compelling this example is. I think there are much more compelling examples for first-class existentials. In any case, here's one more example, this one from Freeman's thesis on refinement types. We create a type of boolean expressions with variables. We can evaluate terms without any free variables, so we distinguish them using the trick above. Unfortunately, this time the constructor restriction isn't just at the top level, but all the way down. We must, therefore, parameterize the recursion in the data type. \begin{code} data BoolExp' a r = And r r | Or r r | Not r | Tru | Fals | Var a String newtype Mu' f = Mu' (forall a . f a (Mu' f)) type Ground = Mu' BoolExp' data Mu f = forall a . Mu (f a (Mu f)) type BoolExp = Mu BoolExp' type Base = forall a r . BoolExp' a r eval :: Ground -> Base eval (Mu' x) = case x of And y z -> case (eval y,eval z) of (Tru,x) -> x _ -> Fals Or y z -> case (eval y,eval z) of (Fals,x) -> x _ -> Tru Not y -> case eval y of Tru -> Fals _ -> Tru Tru -> Tru Fals -> Fals _ -> error "eval" \end{code} The error in eval is never reached. Unfortunately, Ground is not a subtype of BoolExp, so this seems like a less compelling example. From igloo at earth.li Sun Jan 6 11:28:56 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 11:22:42 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <000601c84fda$ff6abff0$fe403fd0$@net> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> <20080105160109.GA18866@matrix.chaos.earth.li> <000601c84fda$ff6abff0$fe403fd0$@net> Message-ID: <20080106162856.GA16507@matrix.chaos.earth.li> Hi Chris, On Sat, Jan 05, 2008 at 03:38:58PM -0500, Chris Saunders wrote: > Will there be a binary release for Windows x86_64? Unfortunately not in the near future; see this ticket for more details: http://hackage.haskell.org/trac/ghc/ticket/1884 Thanks Ian From igloo at earth.li Sun Jan 6 12:20:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 12:14:04 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: <20080104205445.GA30327@petunia.outback.escape.de> References: <20080104205445.GA30327@petunia.outback.escape.de> Message-ID: <20080106172018.GA17018@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 09:54:45PM +0100, Matthias Kilian wrote: > [Note: already shortly discussed with Wilhelm] > > On Fri, Nov 23, 2007 at 12:30:06PM +0000, Wilhelm B. Kloke wrote: > > > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi > > > Prologue junk?: .type s32x_ret, @function > > > s32x_ret: > > > pushl %ebp > > > movl %esp, %ebp > > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the > gcc-3.3.5 included in its base system. Presumably this also happens if you do a normal build with -fvia-C, i.e. it's not specific to building from an HC file bundle? > [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, > it should be -fviaC -keep-hc-files. Someone let me know if I should > correct this in the wiki. GHC will act as if -fvia-C is given if -keep-hc-files is given. It would be nice to update the wiki to say -fvia-C rather than -fasm to avoid confusion, though. > ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's > a must-have for the OpenBSD port. Note that there is a plan to drop the registerised via-C way of compiling GHC at some point, so this isn't going to work in the long term (unless you want to bootstrap via an unregisterised compiler). Would it not be possible to have a ghc-bin package in OpenBSD, which contains a precompiled binary that can be used to compile a ghc source package? I think Gentoo does something like that. > pps: I guess, cvs-ghc would be the more correct list for sending > patches and discussing the bootstrapping stuff, right? Yup. Thanks Ian From kili at outback.escape.de Sun Jan 6 13:01:37 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jan 6 12:58:51 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: <20080106172018.GA17018@matrix.chaos.earth.li> References: <20080104205445.GA30327@petunia.outback.escape.de> <20080106172018.GA17018@matrix.chaos.earth.li> Message-ID: <20080106180137.GA8704@petunia.outback.escape.de> On Sun, Jan 06, 2008 at 05:20:18PM +0000, Ian Lynagh wrote: > > > > Prologue junk?: .type s32x_ret, @function > > > > s32x_ret: > > > > pushl %ebp > > > > movl %esp, %ebp > > > > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the > > gcc-3.3.5 included in its base system. > > Presumably this also happens if you do a normal build with -fvia-C, i.e. > it's not specific to building from an HC file bundle? That's right, it's just -fvia-C that triggers the bug. > > [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, > > it should be -fviaC -keep-hc-files. Someone let me know if I should > > correct this in the wiki. > > GHC will act as if -fvia-C is given if -keep-hc-files is given. It > would be nice to update the wiki to say -fvia-C rather than -fasm to > avoid confusion, though. Done. > > ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's > > a must-have for the OpenBSD port. > > Note that there is a plan to drop the registerised via-C way of > compiling GHC at some point, so this isn't going to work in the long > term (unless you want to bootstrap via an unregisterised compiler). I think I'll be happy with unregisterised bootstrap, too, even if the actual build of the port will take longer. > Would it not be possible to have a ghc-bin package in OpenBSD, which > contains a precompiled binary that can be used to compile a ghc source > package? I think Gentoo does something like that. AFAIK, FreeBSD does it in a similar way. However, this isn't the way we do ports for OpenBSD, so I'll work towards the unregisterised bootstrap. Ciao, Kili From igloo at earth.li Sun Jan 6 17:03:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 16:56:54 2008 Subject: Haddocumentation of 6.8.1 In-Reply-To: <200711301523.04142.daniel.is.fischer@web.de> References: <200711301523.04142.daniel.is.fischer@web.de> Message-ID: <20080106220310.GA2029@matrix.chaos.earth.li> On Fri, Nov 30, 2007 at 03:23:04PM +0100, Daniel Fischer wrote: > Yesterday, doing runghc ./Setup.hs haddock in zlib.0.4.0.1, I noticed that no > Haddock docs have been built for my 6.8.1. > > Feature request: Could the README in future please contain information on how > to build library documentation properly? Good point; I've added this to README: $ echo "XMLDocWays = html" > mk/build.mk $ echo "HADDOCK_DOCS = YES" >> mk/build.mk $ sh boot $ ./configure $ make $ make install $ make install-docs Thanks Ian From catamorphism at gmail.com Sun Jan 6 19:14:43 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun Jan 6 19:08:28 2008 Subject: GHC Core question In-Reply-To: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Message-ID: <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> On 1/5/08, Neil Mitchell wrote: > Hi > > I've compiled the Debug.Trace module to Core, but can't understand the > resulting output. The original code is: > > trace string expr = unsafePerformIO $ do > putTraceMsg string > return expr > > The core is: > > Debug.Trace.trace = > \ (@ a) -> > __letrec { > trace :: GHC.Base.String -> a -> a > [] > trace = > \ (string :: GHC.Base.String) (expr :: a) -> > GHC.Base.$ > @ (GHC.IOBase.IO a) > @ a > (GHC.IOBase.unsafePerformIO @ a) > (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); > $dMonad :: GHC.Base.Monad GHC.IOBase.IO > [] > $dMonad = $dMonad; > return :: forall a. a -> GHC.IOBase.IO a > [] > return = GHC.Base.return @ GHC.IOBase.IO $dMonad; > $dMonad :: GHC.Base.Monad GHC.IOBase.IO > [] > $dMonad = GHC.IOBase.$f16; > >> :: forall a b. > GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b > [] > >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; > } in trace; > > And my Haskell reformatting of that is: > > Debug.Trace.trace = let > trace string expr = unsafePerformIO $ putTraceMsg string >> return expr > $dMonad = $dMonad; > return = GHC.Base.return $dMonad; > $dMonad = GHC.IOBase.$f16; > >> = GHC.Base.>> $dMonad; > in trace > > However, that let expression has two bindings for $dMonad, one of > which looks like a black-hole. Are the semantics of __letrec different > from let in some way? > How are you printing out the Core? It looks like the unique ids are missing (you can see them if you pass the -ppr-debug flag, which can be set using the API) -- if the unique ids were being printed, you would see that the bindings for $dMonad (likely) have different uniques. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "...Losing your mind, like losing your car keys, is a real hassle." -- Andrew Solomon From brianh at metamilk.com Sun Jan 6 22:01:18 2008 From: brianh at metamilk.com (Brian Hulley) Date: Sun Jan 6 21:51:27 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <47800480.7050808@imn.htwk-leipzig.de> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> <47800480.7050808@imn.htwk-leipzig.de> Message-ID: <478195FE.90505@metamilk.com> Johannes Waldmann wrote: > Brian Hulley wrote: > >> In the long term, Haskell needs a better module system IMHO [...] > > I agree with the symptoms that were described, but I draw a different > conclusion. > > We don't need to change the language - we need better tools (IDEs) > that operate not at the textual level, but use the annotated syntax tree, > including knowledge on fully qualified names and types. Hi Johannes, I agree that better tools would be a good thing, and could improve the programming experience considerably, but I still think that an improved module system design would be an orthogonal benefit. Best regards, Brian. From wb at arb-phys.uni-dortmund.de Mon Jan 7 02:07:29 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Mon Jan 7 02:01:25 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? References: <20080104205445.GA30327@petunia.outback.escape.de> <20080106172018.GA17018@matrix.chaos.earth.li> <20080106180137.GA8704@petunia.outback.escape.de> Message-ID: Matthias Kilian schrieb: > On Sun, Jan 06, 2008 at 05:20:18PM +0000, Ian Lynagh wrote: >> > > > Prologue junk?: .type s32x_ret, @function >> > > > s32x_ret: >> > > > pushl %ebp >> > > > movl %esp, %ebp >> > >> > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the >> > gcc-3.3.5 included in its base system. >> >> Presumably this also happens if you do a normal build with -fvia-C, i.e. >> it's not specific to building from an HC file bundle? > > That's right, it's just -fvia-C that triggers the bug. This is not quite the case. I compiled even with -fvia-C without errors on FreeBSD-amd64. This bug is specific for the bootstrap with crosscompiling i386 -> amd64 vi .hc-bundle. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From simonpj at microsoft.com Mon Jan 7 03:50:40 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 7 03:44:23 2008 Subject: GHC Core question In-Reply-To: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Message-ID: If you use -dppr-debug GHC will show you the unique number of each identifier, and that'll show you that the two $dMonads are distinct even though they have the same print-name. CoreTidy makes the print-name unique too. Perhaps the Core printer should be a bit keener to print unique numbers, but it adds a lot of clutter. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Neil Mitchell | Sent: 05 January 2008 20:01 | To: GHC Users | Subject: GHC Core question | | Hi | | I've compiled the Debug.Trace module to Core, but can't understand the | resulting output. The original code is: | | trace string expr = unsafePerformIO $ do | putTraceMsg string | return expr | | The core is: | | Debug.Trace.trace = | \ (@ a) -> | __letrec { | trace :: GHC.Base.String -> a -> a | [] | trace = | \ (string :: GHC.Base.String) (expr :: a) -> | GHC.Base.$ | @ (GHC.IOBase.IO a) | @ a | (GHC.IOBase.unsafePerformIO @ a) | (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); | $dMonad :: GHC.Base.Monad GHC.IOBase.IO | [] | $dMonad = $dMonad; | return :: forall a. a -> GHC.IOBase.IO a | [] | return = GHC.Base.return @ GHC.IOBase.IO $dMonad; | $dMonad :: GHC.Base.Monad GHC.IOBase.IO | [] | $dMonad = GHC.IOBase.$f16; | >> :: forall a b. | GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b | [] | >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; | } in trace; | | And my Haskell reformatting of that is: | | Debug.Trace.trace = let | trace string expr = unsafePerformIO $ putTraceMsg string >> return expr | $dMonad = $dMonad; | return = GHC.Base.return $dMonad; | $dMonad = GHC.IOBase.$f16; | >> = GHC.Base.>> $dMonad; | in trace | | However, that let expression has two bindings for $dMonad, one of | which looks like a black-hole. Are the semantics of __letrec different | from let in some way? | | Thanks | | Neil | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Mon Jan 7 04:18:43 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 7 04:12:33 2008 Subject: wish for more-usable bindist In-Reply-To: <477EDC50.10308@charter.net> References: <477EDC50.10308@charter.net> Message-ID: <4781EE73.9030109@gmail.com> Isaac Dupree wrote: > the i386 linux ghc bindist still uses readline 4 > , which is hard to get: > readline 5.0 came out almost three and a half years ago > > > And I don't want to pollute my Ubuntu system with "compatibility RPMs"; > in fact I intend to install the bindist as my local user so I don't > pollute it with extra GHCs either, except I can't. Could there be a > bindist with modern readline, or perhaps is it possible to statically > link with readline? The i386 machine I use here for building the bindists is running a rather old version of RedHat. I do intend to upgrade it at some point, but it's entirely possible for someone else to build a bindist too. Cheers, Simon From Christian.Maeder at dfki.de Mon Jan 7 04:35:08 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 04:28:54 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <20080105160109.GA18866@matrix.chaos.earth.li> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> <20080105160109.GA18866@matrix.chaos.earth.li> Message-ID: <4781F24C.7010901@dfki.de> Ian Lynagh wrote: > On Fri, Jan 04, 2008 at 06:03:50PM +0100, Christian Maeder wrote: >> Christian Maeder wrote: >>> http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 >>> http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 >> Ian, could you replace the dists on the download page? > > Done; I assume that these dists include the new hsc2hs-bin from > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013998.html > ? Yes, thanks Christian From simonpj at microsoft.com Mon Jan 7 04:37:52 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 7 04:31:37 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: Jim | My reason for wanting pattern matching on values of polymorphic types | is a kind of first-level refinement types. I'm going to demonstrate | using the "risers" function, as presented in Dana N. Xu's ESC/Haskell, which | references Neil Mitchell's Catch. I didn't follow all the details, but I think your main idea is to use the fact that [] is the only value of type (forall a. [a]), and similarly for other polymorphic values, and use that to reason that certain branches are inaccessible. Sadly, it's not true in Haskell, is it? (error "urk") : [] also has type (forall a. [a]). I don't know how to fix this, short of making the constructors strict. Another less-than-satisfying aspect is that Nil has a real value argument (usually () I guess) which is there only to speak to the type system. It's nicer if static properties have static witnesses, and involve no runtime activity. You have a type (NonEmpty (NonEmpty a)). If you expand that out, I think you get a forall n1. List (forall n2. List a n2) n1 So you're instantiating the element type of the outer list with a polytype, which requires impredicativity too, not just existentials! All that said, I never thought of using existentials this way. Ingenious. Simon From Christian.Maeder at dfki.de Mon Jan 7 04:56:45 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 04:50:29 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] In-Reply-To: <97D53000-CBCF-4D92-AACC-B9D942C48911@citycampus.com> References: <477D039A.2070102@dfki.de> <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> <477E08B8.4060203@dfki.de> <7A2586AF-4B7A-4748-82C8-B71540CF5188@citycampus.com> <477E6930.9030107@dfki.de> <97D53000-CBCF-4D92-AACC-B9D942C48911@citycampus.com> Message-ID: <4781F75D.7060106@dfki.de> Hi Emmanuel, sqlite3 must be installed on your mac, i.e. a file "libsqlite3.dylib". (I don't have it, too.) If it is say under /opt/local/lib you may need to pass "-optl-L/opt/local/lib" to ghc's command line (or set LD_LIBRARY_PATH) HTH Christian manu wrote: > Macintosh:blog_old_with_sqlite3 manu$ ghc --make newArticle.hs -o > new_article.c > gi > [3 of 3] Compiling Main ( newArticle.hs, newArticle.o ) > Linking new_article.cgi ... > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in > /usr/local/lib/HDBC-sqlite3-1.1.3.0/ghc-6.8.2/libHSHDBC-sqlite3-1.1.3.0.a(Types.o) > > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in > /usr/local/lib/HDBC-sqlite3-1.1.3.0/ghc-6.8.2/libHSHDBC-sqlite3-1.1.3.0.a(Types.o) > > Undefined symbols: > "_sqlite3_errmsg", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziUtils_zdwccall_info in > libHSHDBC-sqlite3-1.1.3.0.a(Utils.o) > "_sqlite3_bind_null", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall11_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_bind_text", referenced from: > _sqlite3_bind_text2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_name", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall6_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_total_changes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall13_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_close", referenced from: > _sqlite3_close_app in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_text", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall8_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_column_type", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall7_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_libversion", referenced from: > _r6xt_info in libHSHDBC-sqlite3-1.1.3.0.a(Connection.o) > "_sqlite3_finalize", referenced from: > _sqlite3_prepare2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > _sqlite3_finalize_app in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_changes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall12_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_open", referenced from: > _sqlite3_open2 in libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_bind_parameter_count", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall2_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_step", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall3_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_busy_timeout", referenced from: > _sqlite3_busy_timeout2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_count", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall5_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_reset", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall4_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_column_bytes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall9_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_prepare", referenced from: > _sqlite3_prepare2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > > > > > On Jan 4, 2008, at 6:13 PM, Christian Maeder wrote: > >> Please post the full ld error message >> (also to glasgow-haskell-users@haskell.org) >> >> C. >> >> manu wrote: >>> Hi Christian >>> >>> yes it did >>> >>> but, when i tried to compile one of my cgi script where I happen to use >>> HDBC.Sqlite3 >>> it fails with similar 'ld' errors... >>> >>> so I can compile HDBC-Sqlite3, but not programs that use the package... >>> >>> Thanks >>> >>> Emmanuel >>> >>> >>> On Jan 4, 2008, at 11:21 AM, Christian Maeder wrote: >>> >>>> Did a final "runhaskell Setup.lhs install" work for you, Emmanuel? >> >> > From valery.vv at gmail.com Mon Jan 7 04:59:57 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 7 04:53:41 2008 Subject: can't build plugins-1.0 with ghc-6.9 Message-ID: Hi, (The message below contains bunch of "preformatted" sections. I hope it's still readable, otherwise, please, let me know.) My quest is to install lambdabot (for the sake of offline `@hoogle' and `@pl' commands), and the one depends on `plugins'. 1) plugins.cabal should be updated ---------------------------------- A patch to .cabal file[1] is needed to get rid of config-time warning[2] and resolve build-time errors[3]. [1] vvv:~/src/plugins-1.0$ diff -u plugins.cabal{.orig,} --- plugins.cabal.orig 2008-01-06 22:23:44.657177486 +0200 +++ plugins.cabal 2008-01-06 22:25:45.160728537 +0200 @@ -33,6 +33,6 @@ src/Language/Hi/hschooks.c includes: Linker.h extensions: CPP, ForeignFunctionInterface -Build-Depends: base, Cabal, haskell-src +Build-Depends: base, Cabal, haskell-src, array, containers, directory, random, process ghc-options: -Wall -O -fasm -funbox-strict-fields -fno-warn-missing-signatures -hs-source-dir: src +hs-source-dirs: src [2] vvv:~/src/plugins-1.0$ runhaskell Setup configure --prefix=$HOME --user Warning: The field "hs-source-dir" is deprecated, please use "hs-source-dirs" Configuring plugins-1.0... [...] [3] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... src/Language/Hi/Binary.hs:90:7: Could not find module `Data.Array.Base': it is a member of package array-0.1, which is hidden 2) it doesn't build with Cabal-1.3.2 ------------------------------------ `InstalledPackageInfo' is a type alias in GHC's Cabal[4], not a data constructor; `plugins' library[5] gets confused[6]. [4] vvv:~/src$ diff -u cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs --- cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs 2007-11-01 17:02:35.000000000 +0200 +++ ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs 2007-12-17 17:53:21.691532864 +0200 @@ -46,7 +46,7 @@ -- This module is meant to be local-only to Distribution... module Distribution.InstalledPackageInfo ( - InstalledPackageInfo(..), + InstalledPackageInfo_(..), InstalledPackageInfo, ParseResult(..), PError(..), PWarning, emptyInstalledPackageInfo, parseInstalledPackageInfo, @@ -72,8 +72,8 @@ -- ----------------------------------------------------------------------------- -- The InstalledPackageInfo type -data InstalledPackageInfo - = InstalledPackageInfo { +data InstalledPackageInfo_ m + = InstalledPackageInfo_ { -- these parts are exactly the same as PackageDescription package :: PackageIdentifier, license :: License, @@ -87,8 +87,8 @@ category :: String, -- these parts are required by an installed package only: exposed :: Bool, - exposedModules :: [String], - hiddenModules :: [String], + exposedModules :: [m], + hiddenModules :: [m], importDirs :: [FilePath], -- contain sources in case of Hugs libraryDirs :: [FilePath], hsLibraries :: [String], @@ -107,9 +107,11 @@ } deriving (Read, Show) -emptyInstalledPackageInfo :: InstalledPackageInfo +type InstalledPackageInfo = InstalledPackageInfo_ String + +emptyInstalledPackageInfo :: InstalledPackageInfo_ m emptyInstalledPackageInfo - = InstalledPackageInfo { + = InstalledPackageInfo_ { package = PackageIdentifier "" noVersion, license = AllRightsReserved, copyright = "", [5] vvv:~/src/plugins-1.0$ sed -n 64,66p src/System/Plugins/PackageAPI.hs updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = pk { importDirs = f idirs } updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = [6] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... [ 1 of 24] Compiling System.Plugins.Process ( src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) [ 2 of 24] Compiling System.Plugins.Parser ( src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) [ 3 of 24] Compiling System.Plugins.ParsePkgConfCabal ( src/System/Plugins/ParsePkgConfCabal.hs, dist/build/System/Plugins/ParsePkgConfCabal.o ) [ 4 of 24] Compiling System.Plugins.PackageAPI ( src/System/Plugins/PackageAPI.hs, dist/build/System/Plugins/PackageAPI.o ) src/System/Plugins/PackageAPI.hs:64:20: Not in scope: data constructor `InstalledPackageInfo' src/System/Plugins/PackageAPI.hs:66:21: Not in scope: data constructor `InstalledPackageInfo' I would like to hear your suggestions. Should I try harder[7] installing Cabal-1.2.2.0? Or is this a bug of GHC's Cabal? In this case I've just reported it. :) [7] vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base <3, filepath -any vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user -f small_base Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base >=3, pretty -any, directory -any, old-time -any, process -any, containers -any, filepath -any vvv:~/src/cabal-1.2.2.0$ ghc-pkg list /home/vvv/lib/ghc-6.9.20080104/package.conf: Cabal-1.3.2, array-0.1, base-3.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, (ghc-6.9.20080104), haskell98-1.0.1, hpc-0.5, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0, random-1.0, readline-1.0.1, rts-1.0, template-haskell-2.2, unix-2.2 /home/vvv/.ghc/i386-linux-6.9.20080104/package.conf: X11-1.4.1, binary-0.4.1, haskell-src-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, parsec-2.1.0.0, xmonad-0.5, xmonad-contrib-0.5 Thanks a lot. Happy hacking! -- vvv From jbapple+ghc-users at gmail.com Mon Jan 7 05:09:21 2008 From: jbapple+ghc-users at gmail.com (Jim Apple) Date: Mon Jan 7 05:03:04 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: On Jan 7, 2008 1:37 AM, Simon Peyton-Jones wrote: > Sadly, it's not true in Haskell, is it? > (error "urk") : [] > also has type (forall a. [a]). It is a bit sad, but I think that's The Curse of The _|_, which infects any attempt to add static assurance. > It's nicer if static properties have static witnesses, and involve no runtime activity. Maybe The Curse doesn't infect everything. What methods of assuring static properties in GHC have static witnesses? I think no: GADTs, lightweight static capabilities, forall a . [a] trick, nested/non-regular types I think yes: associated types, class constraints > You have a type (NonEmpty (NonEmpty a)). If you expand that out, I think you get a > forall n1. List (forall n2. List a n2) n1 > So you're instantiating the element type of the outer list with a polytype, which requires impredicativity too, not just existentials! It's true, but that seems to work without a hiccup right now Jim From Christian.Maeder at dfki.de Mon Jan 7 05:34:08 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 05:27:51 2008 Subject: wish for more-usable bindist In-Reply-To: <4781EE73.9030109@gmail.com> References: <477EDC50.10308@charter.net> <4781EE73.9030109@gmail.com> Message-ID: <47820020.5090800@dfki.de> You may try my version built on: maeder@denebola:~> uname -a Linux denebola 2.6.18.8-0.7-bigsmp #1 SMP Tue Oct 2 17:21:08 UTC 2007 i686 i686 i386 GNU/Linux using: gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) http://www.dfki.de/sks/hets/linux/versions/ghc-6.8.2-i386-unknown-linux.tar.bz2 ldd output: linux-gate.so.1 => (0xffffe000) libreadline.so.5 => /lib/libreadline.so.5 (0xb7e91000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7e4a000) libutil.so.1 => /lib/libutil.so.1 (0xb7e46000) libdl.so.2 => /lib/libdl.so.2 (0xb7e42000) libm.so.6 => /lib/libm.so.6 (0xb7e1b000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7de5000) librt.so.1 => /lib/librt.so.1 (0xb7ddc000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7dc5000) libc.so.6 => /lib/libc.so.6 (0xb7c97000) /lib/ld-linux.so.2 (0xb7eef000) HTH Christian Simon Marlow wrote: > Isaac Dupree wrote: >> the i386 linux ghc bindist still uses readline 4 >> , which is hard to get: >> readline 5.0 came out almost three and a half years ago >> >> >> And I don't want to pollute my Ubuntu system with "compatibility >> RPMs"; in fact I intend to install the bindist as my local user so I >> don't pollute it with extra GHCs either, except I can't. Could there >> be a bindist with modern readline, or perhaps is it possible to >> statically link with readline? > > The i386 machine I use here for building the bindists is running a > rather old version of RedHat. I do intend to upgrade it at some point, > but it's entirely possible for someone else to build a bindist too. > > Cheers, > Simon From Christian.Maeder at dfki.de Mon Jan 7 05:38:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 05:32:07 2008 Subject: wish for more-usable bindist In-Reply-To: <4781EE73.9030109@gmail.com> References: <477EDC50.10308@charter.net> <4781EE73.9030109@gmail.com> Message-ID: <4782011D.7020706@dfki.de> Simon Marlow wrote: > The i386 machine I use here for building the bindists is running a > rather old version of RedHat. I do intend to upgrade it at some point, > but it's entirely possible for someone else to build a bindist too. I wonder why (all) the (various) buildbots do not produce (tested) bindists. http://hackage.haskell.org/trac/ghc/wiki/BuildBot Christian From jpeliz at icmc.usp.br Mon Jan 7 08:40:22 2008 From: jpeliz at icmc.usp.br (Jorge Marques Pelizzoni) Date: Mon Jan 7 08:34:06 2008 Subject: reifying is-a relation Message-ID: <11446.200.158.222.185.1199713222.squirrel@mail2.icmc.usp.br> Hi, all! I guess what I am about to ask is currently impossible, but as you haskellers always manage to amaze me and there is plenty of new features in GHC I am not familiar with here it goes. Given two type classes A t and B t, I'd like to derive different A t instances depending exactly on whether t is an instance of B. In other words, is it possible to define a class (actually a type-level function) IsB t f such that: IsB t HTrue <=> (B t) exists IsB t HFalse <=> otherwise? If not, is this wish intrisically pointless? Thanks in advance. Cheers, Jorge M. Pelizzoni ICMC - Universidade de S?o Paulo From ndmitchell at gmail.com Mon Jan 7 09:22:09 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 7 09:15:51 2008 Subject: GHC Core question In-Reply-To: <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> Message-ID: <404396ef0801070622l47d50f37t7b3fd899593bada9@mail.gmail.com> Hi > How are you printing out the Core? showSDoc $ ppr c where c :: [CoreBind] > It looks like the unique ids are > missing (you can see them if you pass the -ppr-debug flag, which can > be set using the API) I have now set the -ppr-debug flag, but that has no effect. It's not entirely surprising, as I guess setting the flag only applies through the GHC session, and this code is being run outside that. How can I print the output (to a file) using the unique id's? > Simon Peyton-Jones says: > CoreTidy makes the print-name unique too. Can I invoke CoreTidy using the GHC API? Thanks Neil From Christian.Maeder at dfki.de Mon Jan 7 09:55:52 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 09:50:04 2008 Subject: readline on macs In-Reply-To: <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> Message-ID: <47823D78.6090806@dfki.de> Judah Jacobson wrote: > On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: >> On Friday 04 January 2008 12:03, Christian Maeder wrote: >> >> I understand that there are problems in this area, but I am not convinced that >> they could not be solved without the renamed and/or modified readline >> library. I am sorry if you have done that already elsewhere, but I don't >> recall having seen any details about your difficulties. Would you be kind >> enough to supply some details? Thanks a lot. I'm against a further (renamed or modified) readline library (and I've done nothing in that direction). >>> The alternative is to use static linking of gmp (as suggested by chak) >>> _and_ readline (version 5), so that user programs are also statically >>> linked with these libs. I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting: SRC_HC_OPTS += -optl-Xlinker -optl-search_paths_first in mk/build.mk. This option prevents linking against the wrong dynamic library /usr/lib/libreadline.dylib. >> Again, I am not convinced that this is the only alternative. I don't see an advantage of a renamed or modified readline library (it'll be even more version confusion). > There is another alternative (which I think we talked about before): yes in http://hackage.haskell.org/trac/ghc/ticket/1798 > Have ghc manually search for frameworks in the standard folders > (rather than letting gcc do it automatically). Then if we found e.g. > /Library/Frameworks/GNUreadline.framework, we would pass the following > flag: > -I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers It's not even necessary to specify a version. Enough is: -I/Library/Frameworks/GNUreadline.framework/Headers or in $HOME: -I$HOME/Library/Frameworks/GNUreadline.framework/Headers > In that case, we would not need modified readline headers. This way I wanted to go before (saving some -F trouble for some -I trouble), but proper mac frameworks should also have proper mac framework headers. > However, I really don't like the above, since we're reimplenting > something gcc gives us for free. And if we *do* rely on gcc's > standard searching (as is the case now), then I agree with Christian > that modified headers are necessary for GNUreadline to work as a > framework. yes. [...] With static linking the whole framework issue may become obsolete. Cheers Christian From dons at galois.com Mon Jan 7 11:46:52 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 7 11:40:43 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: References: Message-ID: <20080107164652.GB16760@scytale.galois.com> Please start with the hs-plugins repo on code.haskell.org, since it's already updated for ghc 6.8, http://code.haskell.org/~dons/code/hs-plugins/ valery.vv: > Hi, > > (The message below contains bunch of "preformatted" sections. > I hope it's still readable, otherwise, please, let me know.) > > My quest is to install lambdabot (for the sake of offline `@hoogle' > and `@pl' commands), and the one depends on `plugins'. > > 1) plugins.cabal should be updated > ---------------------------------- > > A patch to .cabal file[1] is needed to get rid of config-time > warning[2] and resolve build-time errors[3]. > > [1] > vvv:~/src/plugins-1.0$ diff -u plugins.cabal{.orig,} > --- plugins.cabal.orig 2008-01-06 22:23:44.657177486 +0200 > +++ plugins.cabal 2008-01-06 22:25:45.160728537 +0200 > @@ -33,6 +33,6 @@ > src/Language/Hi/hschooks.c > includes: Linker.h > extensions: CPP, ForeignFunctionInterface > -Build-Depends: base, Cabal, haskell-src > +Build-Depends: base, Cabal, haskell-src, array, containers, > directory, random, process > ghc-options: -Wall -O -fasm -funbox-strict-fields > -fno-warn-missing-signatures > -hs-source-dir: src > +hs-source-dirs: src > > [2] > vvv:~/src/plugins-1.0$ runhaskell Setup configure --prefix=$HOME --user > Warning: The field "hs-source-dir" is deprecated, please use "hs-source-dirs" > Configuring plugins-1.0... > [...] > > [3] > vvv:~/src/plugins-1.0$ runhaskell Setup build > Preprocessing library plugins-1.0... > Building plugins-1.0... > > src/Language/Hi/Binary.hs:90:7: > Could not find module `Data.Array.Base': > it is a member of package array-0.1, which is hidden > > 2) it doesn't build with Cabal-1.3.2 > ------------------------------------ > > `InstalledPackageInfo' is a type alias in GHC's Cabal[4], not a data > constructor; `plugins' library[5] gets confused[6]. > > [4] > vvv:~/src$ diff -u > cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs > ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs > --- cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs 2007-11-01 > 17:02:35.000000000 +0200 > +++ ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs > 2007-12-17 17:53:21.691532864 +0200 > @@ -46,7 +46,7 @@ > -- This module is meant to be local-only to Distribution... > > module Distribution.InstalledPackageInfo ( > - InstalledPackageInfo(..), > + InstalledPackageInfo_(..), InstalledPackageInfo, > ParseResult(..), PError(..), PWarning, > emptyInstalledPackageInfo, > parseInstalledPackageInfo, > @@ -72,8 +72,8 @@ > -- ----------------------------------------------------------------------------- > -- The InstalledPackageInfo type > > -data InstalledPackageInfo > - = InstalledPackageInfo { > +data InstalledPackageInfo_ m > + = InstalledPackageInfo_ { > -- these parts are exactly the same as PackageDescription > package :: PackageIdentifier, > license :: License, > @@ -87,8 +87,8 @@ > category :: String, > -- these parts are required by an installed package only: > exposed :: Bool, > - exposedModules :: [String], > - hiddenModules :: [String], > + exposedModules :: [m], > + hiddenModules :: [m], > importDirs :: [FilePath], -- contain sources in case of Hugs > libraryDirs :: [FilePath], > hsLibraries :: [String], > @@ -107,9 +107,11 @@ > } > deriving (Read, Show) > > -emptyInstalledPackageInfo :: InstalledPackageInfo > +type InstalledPackageInfo = InstalledPackageInfo_ String > + > +emptyInstalledPackageInfo :: InstalledPackageInfo_ m > emptyInstalledPackageInfo > - = InstalledPackageInfo { > + = InstalledPackageInfo_ { > package = PackageIdentifier "" noVersion, > license = AllRightsReserved, > copyright = "", > > [5] > vvv:~/src/plugins-1.0$ sed -n 64,66p src/System/Plugins/PackageAPI.hs > updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = > pk { importDirs = f idirs } > updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = > > [6] > vvv:~/src/plugins-1.0$ runhaskell Setup build > Preprocessing library plugins-1.0... > Building plugins-1.0... > [ 1 of 24] Compiling System.Plugins.Process ( > src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) > [ 2 of 24] Compiling System.Plugins.Parser ( > src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) > [ 3 of 24] Compiling System.Plugins.ParsePkgConfCabal ( > src/System/Plugins/ParsePkgConfCabal.hs, > dist/build/System/Plugins/ParsePkgConfCabal.o ) > [ 4 of 24] Compiling System.Plugins.PackageAPI ( > src/System/Plugins/PackageAPI.hs, > dist/build/System/Plugins/PackageAPI.o ) > > src/System/Plugins/PackageAPI.hs:64:20: > Not in scope: data constructor `InstalledPackageInfo' > > src/System/Plugins/PackageAPI.hs:66:21: > Not in scope: data constructor `InstalledPackageInfo' > > I would like to hear your suggestions. > > Should I try harder[7] installing Cabal-1.2.2.0? > Or is this a bug of GHC's Cabal? In this case I've just reported it. :) > > [7] > vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user > Configuring Cabal-1.2.2.0... > Setup: At least the following dependencies are missing: > base <3, filepath -any > vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME > --user -f small_base > Configuring Cabal-1.2.2.0... > Setup: At least the following dependencies are missing: > base >=3, > pretty -any, > directory -any, > old-time -any, > process -any, > containers -any, > filepath -any > vvv:~/src/cabal-1.2.2.0$ ghc-pkg list > /home/vvv/lib/ghc-6.9.20080104/package.conf: > Cabal-1.3.2, array-0.1, base-3.0, bytestring-0.9, containers-0.1, > directory-1.0, filepath-1.1, (ghc-6.9.20080104), haskell98-1.0.1, > hpc-0.5, old-locale-1.0, old-time-1.0, packedstring-0.1, > pretty-1.0, process-1.0, random-1.0, readline-1.0.1, rts-1.0, > template-haskell-2.2, unix-2.2 > /home/vvv/.ghc/i386-linux-6.9.20080104/package.conf: > X11-1.4.1, binary-0.4.1, haskell-src-1.0.1.1, mtl-1.1.0.0, > network-2.1.0.0, parsec-2.1.0.0, xmonad-0.5, xmonad-contrib-0.5 > > Thanks a lot. > > Happy hacking! > > -- > vvv > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From judah.jacobson at gmail.com Mon Jan 7 12:19:25 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 7 12:13:07 2008 Subject: readline on macs In-Reply-To: <47823D78.6090806@dfki.de> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> <47823D78.6090806@dfki.de> Message-ID: <6d74b0d20801070919o38b6973csc1d30873f08f4526@mail.gmail.com> On Jan 7, 2008 6:55 AM, Christian Maeder wrote: > Judah Jacobson wrote: > > On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: > >>> The alternative is to use static linking of gmp (as suggested by chak) > >>> _and_ readline (version 5), so that user programs are also statically > >>> linked with these libs. > > I just have succeeded in linking ghc-6.8.2 statically with libreadline.a > and libncurses.a in the compiler directory by setting: Readline is distributed under the GPL, not the LGPL (which gmp is). Does the above cause a licensing problem? (I don't have much experience in that area; hopefully someone can explain this issues involved.) Thanks, -Judah From bos at serpentine.com Mon Jan 7 13:15:56 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Jan 7 13:09:38 2008 Subject: wish for more-usable bindist In-Reply-To: <4781EE73.9030109@gmail.com> References: <477EDC50.10308@charter.net> <4781EE73.9030109@gmail.com> Message-ID: <47826C5C.3050605@serpentine.com> Simon Marlow wrote: > The i386 machine I use here for building the bindists is running a > rather old version of RedHat. Might that be the machine you're using to build the source tarballs, too? That would probably explain http://hackage.haskell.org/trac/ghc/ticket/2020 :-) References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> <47823D78.6090806@dfki.de> <6d74b0d20801070919o38b6973csc1d30873f08f4526@mail.gmail.com> Message-ID: <20080107194615.GA27199@matrix.chaos.earth.li> On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote: > On Jan 7, 2008 6:55 AM, Christian Maeder wrote: > > Judah Jacobson wrote: > > > On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: > > >>> The alternative is to use static linking of gmp (as suggested by chak) > > >>> _and_ readline (version 5), so that user programs are also statically > > >>> linked with these libs. > > > > I just have succeeded in linking ghc-6.8.2 statically with libreadline.a > > and libncurses.a in the compiler directory by setting: > > Readline is distributed under the GPL, not the LGPL (which gmp is). > Does the above cause a licensing problem? (I don't have much > experience in that area; hopefully someone can explain this issues > involved.) Perhaps the best answer is for someone to make editline bindings for Haskell? I believe this would solve the problem twice: OS X comes with editline, and it's BSD licensed so we can happily statically link against it. The latter may help us on Windows too. Everything I know about editline is third-hand, but AIUI the APIs are very similar, so it shouldn't be hard to alter GHC to use editline instead. Thanks Ian From igloo at earth.li Mon Jan 7 14:59:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 7 14:53:05 2008 Subject: wish for more-usable bindist In-Reply-To: <4782011D.7020706@dfki.de> References: <477EDC50.10308@charter.net> <4781EE73.9030109@gmail.com> <4782011D.7020706@dfki.de> Message-ID: <20080107195924.GA27253@matrix.chaos.earth.li> On Mon, Jan 07, 2008 at 11:38:21AM +0100, Christian Maeder wrote: > Simon Marlow wrote: > > The i386 machine I use here for building the bindists is running a > > rather old version of RedHat. I do intend to upgrade it at some point, > > but it's entirely possible for someone else to build a bindist too. > > I wonder why (all) the (various) buildbots do not produce (tested) bindists. Two problems I can think of: It would increase the disk usage: You need another copy of everything that gets installed, plus the tarball of it. We would need a way to publish the bindists that get produced. Currently it's done by a few machines at MSR having passwordless access to www.haskell.org. Thanks Ian From catamorphism at gmail.com Mon Jan 7 15:01:15 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Jan 7 14:54:59 2008 Subject: GHC Core question In-Reply-To: <404396ef0801070622l47d50f37t7b3fd899593bada9@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> <404396ef0801070622l47d50f37t7b3fd899593bada9@mail.gmail.com> Message-ID: <4683d9370801071201r6cf88f86ya7dd5e445c193b96@mail.gmail.com> On 1/7/08, Neil Mitchell wrote: > Hi > > > How are you printing out the Core? > > showSDoc $ ppr c > > where c :: [CoreBind] > > > It looks like the unique ids are > > missing (you can see them if you pass the -ppr-debug flag, which can > > be set using the API) > > I have now set the -ppr-debug flag, but that has no effect. It's not > entirely surprising, as I guess setting the flag only applies through > the GHC session, and this code is being run outside that. How can I > print the output (to a file) using the unique id's? > Good point about the session, I forgot about that. It looks like you can call showSDocDebug instead of showSDoc (see utils/Outputable.lhs), which acts as if -dppr-debug is set, but I haven't actually tried it. > Can I invoke CoreTidy using the GHC API? > Yes, but you'll need to grab a post-Dec-25 build if you haven't already, since I added this recently. Once you have, see compileToCoreSimplified in main/GHC.hs. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's easy to consider women more emotional than men when you don't consider rage to be an emotion." -- Brenda Fine From sjanssen at cse.unl.edu Mon Jan 7 15:27:04 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Mon Jan 7 15:21:05 2008 Subject: wish for more-usable bindist In-Reply-To: <477EDC50.10308@charter.net> References: <477EDC50.10308@charter.net> Message-ID: <20080107202704.GA6570@presario> On Fri, Jan 04, 2008 at 08:24:32PM -0500, Isaac Dupree wrote: > the i386 linux ghc bindist still uses readline 4 > , which is hard to get: > readline 5.0 came out almost three and a half years ago > > > And I don't want to pollute my Ubuntu system with "compatibility RPMs"; in > fact I intend to install the bindist as my local user so I don't pollute it > with extra GHCs either, except I can't. Could there be a bindist with > modern readline, or perhaps is it possible to statically link with > readline? > > ~Isaac Here's a little trick I picked up from Stefan O'Rear: sed -e 's/readline.so.4/readline.so.5' --in-place ~/lib/ghc-6.8.2/ghc-6.8.2 Surprisingly, this produces a working GHC. Cheers, Spencer Janssen From valery.vv at gmail.com Mon Jan 7 15:51:28 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 7 15:45:09 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: <20080107164652.GB16760@scytale.galois.com> References: <20080107164652.GB16760@scytale.galois.com> Message-ID: On 1/7/08, Don Stewart wrote: > Please start with the hs-plugins repo on code.haskell.org, since it's > already updated for ghc 6.8, > > http://code.haskell.org/~dons/code/hs-plugins/ Missed shot. :) vvv:~/src/hs-plugins$ runhaskell Setup build Preprocessing library plugins-1.1... Building plugins-1.1... [ 1 of 16] Compiling System.Plugins.Process ( src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) [ 2 of 16] Compiling System.Plugins.Parser ( src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) [ 3 of 16] Compiling System.Plugins.ParsePkgConfCabal ( src/System/Plugins/ParsePkgConfCabal.hs, dist/build/System/Plugins/ParsePkgConfCabal.o ) [ 4 of 16] Compiling System.Plugins.PackageAPI ( src/System/Plugins/PackageAPI.hs, dist/build/System/Plugins/PackageAPI.o ) src/System/Plugins/PackageAPI.hs:64:20: Not in scope: data constructor `InstalledPackageInfo' src/System/Plugins/PackageAPI.hs:66:21: Not in scope: data constructor `InstalledPackageInfo' No problems with the .cabal file, though. -- vvv From igloo at earth.li Mon Jan 7 16:12:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 7 16:05:44 2008 Subject: wish for more-usable bindist In-Reply-To: <47820020.5090800@dfki.de> References: <477EDC50.10308@charter.net> <4781EE73.9030109@gmail.com> <47820020.5090800@dfki.de> Message-ID: <20080107211203.GA29940@matrix.chaos.earth.li> On Mon, Jan 07, 2008 at 11:34:08AM +0100, Christian Maeder wrote: > You may try my version built on: > > maeder@denebola:~> uname -a > Linux denebola 2.6.18.8-0.7-bigsmp #1 SMP Tue Oct 2 17:21:08 UTC 2007 > i686 i686 i386 GNU/Linux > > using: gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) > > http://www.dfki.de/sks/hets/linux/versions/ghc-6.8.2-i386-unknown-linux.tar.bz2 Greats, I've put this on the download page. Thanks Ian From wferi at niif.hu Mon Jan 7 16:46:05 2008 From: wferi at niif.hu (Wagner Ferenc) Date: Mon Jan 7 16:39:46 2008 Subject: Any Debian Etch packages for GHC 6.8.2? Message-ID: <8763y5cns2.fsf@szonett.ki.iif.hu> Hi, speaking of binary dists, does anybody know of some Debian Etch packages of GHC 6.8.2? If nothing else is available, I'm ready to repackage a .tar.gz as a .deb, but I wonder if there's anything better available already... -- Thanks, Feri. From ravi at bluespec.com Mon Jan 7 17:22:39 2008 From: ravi at bluespec.com (Ravi Nanavati) Date: Mon Jan 7 17:16:21 2008 Subject: Any Debian Etch packages for GHC 6.8.2? In-Reply-To: <8763y5cns2.fsf@szonett.ki.iif.hu> References: <8763y5cns2.fsf@szonett.ki.iif.hu> Message-ID: <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> Well... I built some (not all) of the 6.8.2-related packages in Haskell Unsafe on etch. It's a little tricky because you need to get some build dependencies from unstable and some from Haskell Unsafe (as source and then build them on etch), but it is possible to work that out. I could reconstruct the details, if you're interested (or just put the .debs somewhere they can be downloaded). I should also add that you need to be careful about uninstalling ghc libraries before changing ghc versions. Otherwise the wrong ghc-pkg is used and the uninstallation (or upgrade when you are installing new packages) fails. I wonder if libghc6 libraries shouldn't depend on the particular version of ghc they were compiled with (so they automatically go if you change ghc versions). - Ravi On 1/7/08, Wagner Ferenc wrote: > Hi, > > speaking of binary dists, does anybody know of some Debian Etch > packages of GHC 6.8.2? If nothing else is available, I'm ready to > repackage a .tar.gz as a .deb, but I wonder if there's anything better > available already... > -- > Thanks, > Feri. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ndmitchell at gmail.com Mon Jan 7 17:38:58 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 7 17:32:38 2008 Subject: GHC Core question In-Reply-To: <4683d9370801071201r6cf88f86ya7dd5e445c193b96@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> <404396ef0801070622l47d50f37t7b3fd899593bada9@mail.gmail.com> <4683d9370801071201r6cf88f86ya7dd5e445c193b96@mail.gmail.com> Message-ID: <404396ef0801071438i676e5a21t742e92126a30b0ee@mail.gmail.com> Hi > > I have now set the -ppr-debug flag, but that has no effect. It's not > > entirely surprising, as I guess setting the flag only applies through > > the GHC session, and this code is being run outside that. How can I > > print the output (to a file) using the unique id's? > > > > Good point about the session, I forgot about that. It looks like you > can call showSDocDebug instead of showSDoc (see utils/Outputable.lhs), > which acts as if -dppr-debug is set, but I haven't actually tried it. That does indeed work - and I can now see exactly why you don't leave it on all the time! > > Can I invoke CoreTidy using the GHC API? > > > > Yes, but you'll need to grab a post-Dec-25 build if you haven't > already, since I added this recently. Once you have, see > compileToCoreSimplified in main/GHC.hs. /me upgrades Many thanks, Neil From judah.jacobson at gmail.com Mon Jan 7 19:08:51 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 7 19:02:32 2008 Subject: readline on macs In-Reply-To: <20080107194615.GA27199@matrix.chaos.earth.li> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> <47823D78.6090806@dfki.de> <6d74b0d20801070919o38b6973csc1d30873f08f4526@mail.gmail.com> <20080107194615.GA27199@matrix.chaos.earth.li> Message-ID: <6d74b0d20801071608m761e7148j561661cb34359d37@mail.gmail.com> On Jan 7, 2008 11:46 AM, Ian Lynagh wrote: > > On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote: > > On Jan 7, 2008 6:55 AM, Christian Maeder wrote: > > > Judah Jacobson wrote: > > > > On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: > > > >>> The alternative is to use static linking of gmp (as suggested by chak) > > > >>> _and_ readline (version 5), so that user programs are also statically > > > >>> linked with these libs. > > > > > > I just have succeeded in linking ghc-6.8.2 statically with libreadline.a > > > and libncurses.a in the compiler directory by setting: > > > > Readline is distributed under the GPL, not the LGPL (which gmp is). > > Does the above cause a licensing problem? (I don't have much > > experience in that area; hopefully someone can explain this issues > > involved.) > > Perhaps the best answer is for someone to make editline bindings for > Haskell? > > I believe this would solve the problem twice: OS X comes with editline, > and it's BSD licensed so we can happily statically link against it. The > latter may help us on Windows too. > > Everything I know about editline is third-hand, but AIUI the APIs are > very similar, so it shouldn't be hard to alter GHC to use editline > instead. Editline provides readline/[readline.h,history.h] which provide a subset of the readline API and (I've checked) contain all of the functions that ghci uses. One possiblility is to add a configure --with-libedit flag to the readline package which would permit linking against libedit and #ifdef out all functions that it doesn't support. Note that the package already #defines HAVE_READLINE_4 and HAVE_READLINE_5 to permit compiling against multiple versions of readline, so adding HAVE_GNU_READLINE or HAVE_LIBEDIT wouldn't be much worse, IMHO. Best, -Judah From wferi at niif.hu Tue Jan 8 05:23:59 2008 From: wferi at niif.hu (Wagner Ferenc) Date: Tue Jan 8 05:17:39 2008 Subject: Any Debian Etch packages for GHC 6.8.2? In-Reply-To: <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> (Ravi Nanavati's message of "Mon, 7 Jan 2008 17:22:39 -0500") References: <8763y5cns2.fsf@szonett.ki.iif.hu> <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> Message-ID: <87d4scboow.fsf@szonett.ki.iif.hu> "Ravi Nanavati" writes: > Well... I built some (not all) of the 6.8.2-related packages in > Haskell Unsafe on etch. Hmm. I couldn't find 6.8 stuff on Haskell Unsafe at all. Where is it? Don't you mean Sid instead? Ian uploaded 6.8.2 the day before yesterday... Maybe when he's finished with this work, a rebuild on Etch won't be too difficult. > It's a little tricky because you need to get some build dependencies > from unstable and some from Haskell Unsafe (as source and then build > them on etch), but it is possible to work that out. I could > reconstruct the details, if you're interested (or just put the .debs > somewhere they can be downloaded). I think it's better to wait a little bit for the dust to settle, maybe Ian will also provide some info on this subject. But thanks for the offer, I'll ask you for the packages if that will seem like the best route. > I should also add that you need to be careful about uninstalling ghc > libraries before changing ghc versions. Otherwise the wrong ghc-pkg is > used and the uninstallation (or upgrade when you are installing new > packages) fails. I wonder if libghc6 libraries shouldn't depend on the > particular version of ghc they were compiled with (so they > automatically go if you change ghc versions). Thanks for the warning, I'll take care. -- Regards, Feri. From simonmarhaskell at gmail.com Tue Jan 8 08:39:46 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jan 8 08:33:39 2008 Subject: readline on macs In-Reply-To: <20080107194615.GA27199@matrix.chaos.earth.li> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> <47823D78.6090806@dfki.de> <6d74b0d20801070919o38b6973csc1d30873f08f4526@mail.gmail.com> <20080107194615.GA27199@matrix.chaos.earth.li> Message-ID: <47837D22.70302@gmail.com> Ian Lynagh wrote: > On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote: >> On Jan 7, 2008 6:55 AM, Christian Maeder wrote: >>> Judah Jacobson wrote: >>>> On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: >>>>>> The alternative is to use static linking of gmp (as suggested by chak) >>>>>> _and_ readline (version 5), so that user programs are also statically >>>>>> linked with these libs. >>> I just have succeeded in linking ghc-6.8.2 statically with libreadline.a >>> and libncurses.a in the compiler directory by setting: >> Readline is distributed under the GPL, not the LGPL (which gmp is). >> Does the above cause a licensing problem? (I don't have much >> experience in that area; hopefully someone can explain this issues >> involved.) > > Perhaps the best answer is for someone to make editline bindings for > Haskell? I don't *think* libedit provides the completion functionality that we use in GHC, but I could be wrong. Cheers, Simon From Christian.Maeder at dfki.de Tue Jan 8 09:07:10 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 8 09:00:52 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs Message-ID: <4783838E.7010202@dfki.de> Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) Linking is done using the flag -search_paths_first. Frameworks or dylibs for gmp or readline are no longer required and are not used when linking binaries. http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin-static-libs.tar.bz2 Other static libraries are compatible with those from http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 (in fact HSreadline-1.0.1.0 was created this way) Cheers Christian P.S. ranlib during installation is actually not needed on Intel Macs (only for PPC) From judah.jacobson at gmail.com Tue Jan 8 11:38:56 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 8 11:32:36 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit Message-ID: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> On Jan 8, 2008 5:39 AM, Simon Marlow wrote: > Ian Lynagh wrote: > > Perhaps the best answer is for someone to make editline bindings for > > Haskell? > > I don't *think* libedit provides the completion functionality that we use > in GHC, but I could be wrong. The only way to know for sure is to try it out! Attached is a proof-of-concept patch which adds the --with-libedit flag to the readline package's autoconf scripts. * PROOF OF CONCEPT: add --with-libedit flag to allow building a minimal version of the library against libedit. M ./HsReadline_cbits.c +2 M ./System/Console/Readline.hsc -1 +50 M ./aclocal.m4 +6 M ./configure.ac -4 +10 With this patch (and a small, unrelated hack to statically link gmp) I was able to build a version of ghc which only depends on the dynamic libraries installed on OS X 10.4 by default: $ otool -L ghc-6.9.20071221 ghc-6.9.20071221: /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) I played around with completion of filenames, modules, identifiers and flags in ghci, and it all seems to be working fine. Best, -Judah -------------- next part -------------- A non-text attachment was scrubbed... Name: libedit.patch Type: application/octet-stream Size: 8684 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080108/9b514bb6/libedit-0001.obj From Christian.Maeder at dfki.de Tue Jan 8 14:21:12 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 8 14:15:02 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> Message-ID: <4783CD28.1070001@dfki.de> Could you try to install http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-0.9.1 and http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-readline-0.9 If that works, I'll be content with libedit as well. Christian Judah Jacobson wrote: > On Jan 8, 2008 5:39 AM, Simon Marlow wrote: >> Ian Lynagh wrote: >>> Perhaps the best answer is for someone to make editline bindings for >>> Haskell? >> I don't *think* libedit provides the completion functionality that we use >> in GHC, but I could be wrong. > > The only way to know for sure is to try it out! Attached is a > proof-of-concept patch which adds the --with-libedit flag to the > readline package's autoconf scripts. > > * PROOF OF CONCEPT: add --with-libedit flag to allow building a > minimal version of the library against libedit. > > M ./HsReadline_cbits.c +2 > M ./System/Console/Readline.hsc -1 +50 > M ./aclocal.m4 +6 > M ./configure.ac -4 +10 > > With this patch (and a small, unrelated hack to statically link gmp) I > was able to build a version of ghc which only depends on the dynamic > libraries installed on OS X 10.4 by default: > > $ otool -L ghc-6.9.20071221 > ghc-6.9.20071221: > /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current > version 2.0.0) > /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, > current version 5.4.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.3.9) > > I played around with completion of filenames, modules, identifiers and > flags in ghci, and it all seems to be working fine. > > Best, > -Judah From ravi at bluespec.com Tue Jan 8 14:38:17 2008 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Jan 8 14:31:56 2008 Subject: Any Debian Etch packages for GHC 6.8.2? In-Reply-To: <87d4scboow.fsf@szonett.ki.iif.hu> References: <8763y5cns2.fsf@szonett.ki.iif.hu> <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> <87d4scboow.fsf@szonett.ki.iif.hu> Message-ID: <7b977d860801081138h6743983cw82a5186294990d50@mail.gmail.com> On Jan 8, 2008 5:23 AM, Wagner Ferenc wrote: > "Ravi Nanavati" writes: > Hmm. I couldn't find 6.8 stuff on Haskell Unsafe at all. Where is > it? Don't you mean Sid instead? Ian uploaded 6.8.2 the day before > yesterday... Maybe when he's finished with this work, a rebuild on > Etch won't be too difficult. No. I meant Haskell Unsafe. I built the packages I spoke of last week (there was an earlier upload, as I recall). The binary packages are only there for amd64, but since I was building from source anyway, that didn't make a difference. > I think it's better to wait a little bit for the dust to settle, maybe > Ian will also provide some info on this subject. But thanks for the > offer, I'll ask you for the packages if that will seem like the best > route. If they're in unstable, that helps. The tricky thing turns out to be that some of 6.8.2's build-deps are only in unstable as well (like the most recent haddock), so you need to spend some time chasing down and building dependencies. That's certainly easier if you're not jumping back between unstable and Haskell Unsafe as I was. - Ravi From g9ks157k at acme.softbase.org Tue Jan 8 15:57:42 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jan 8 15:51:25 2008 Subject: Maps, was Re: GHC source code improvement ideas In-Reply-To: <4780CBA1.4040907@iee.org> References: <477D987C.2090806@gmail.com> <477E5301.8010700@dfki.de> <4780CBA1.4040907@iee.org> Message-ID: <200801082157.42918.g9ks157k@acme.softbase.org> Am Sonntag, 6. Januar 2008 13:37 schrieb Adrian Hey: > It's the GT class here.. Short remark: Wouldn?t a longer, more descriptive identifier be better? Best wishes, Wolfgang From judah.jacobson at gmail.com Tue Jan 8 16:23:18 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 8 16:16:56 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <4783CD28.1070001@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> Message-ID: <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> On Jan 8, 2008 11:21 AM, Christian Maeder wrote: > Could you try to install > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-0.9.1 > and > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-readline-0.9 > > If that works, I'll be content with libedit as well. > > Christian They don't work with the patch I sent before, but after adding back a few more functions supported by libedit, I was able to install both packages and successfully run a quick test of shellac-readline in ghci. (Although eventually, someone more familiar with that package may want to run more thorough tests.) I'll work on making a new patch which adds back all of the functionality that libedit supports (including what's needed for shellac-readline). -Judah From diyu60607 at yahoo.com Tue Jan 8 18:06:37 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Tue Jan 8 18:00:16 2008 Subject: problem with GHC installaion on x86_64 Message-ID: <966425.39939.qm@web32208.mail.mud.yahoo.com> Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux), I first downloaded the x86 binary bz2 file and successfully installed it, but when I use that version to compile my programs, I get a lot of error messages like: /tmp/ghc2448_0/ghc2448_0.s:10214:0: Error: suffix or operands invalid for `push' Then I downloaded the x86_64 binary bz2 file and tried to install it, but when I am running "configure --prefix=...", I got: pwd: timer_create: Invalid argument and configure fails. So where should I be able to get a working version for this machine? Thanks! Di, Yu 1.8 ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080108/93c91d05/attachment.htm From bos at serpentine.com Tue Jan 8 23:07:16 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Jan 8 23:00:55 2008 Subject: problem with GHC installaion on x86_64 In-Reply-To: <966425.39939.qm@web32208.mail.mud.yahoo.com> References: <966425.39939.qm@web32208.mail.mud.yahoo.com> Message-ID: <47844874.8080809@serpentine.com> Yu Di wrote: > Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux > ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 > x86_64 GNU/Linux), Since you're using RHEL4, you could try grabbing a GHC source RPM for Fedora and building that. It might take a bit of tweaking, but probably very little. (For instructions on building binary RPMs from source, Google around.) References: <477D987C.2090806@gmail.com> <477E5301.8010700@dfki.de> <4780CBA1.4040907@iee.org> <200801082157.42918.g9ks157k@acme.softbase.org> Message-ID: <47848430.2030602@iee.org> Wolfgang Jeltsch wrote: > Am Sonntag, 6. Januar 2008 13:37 schrieb Adrian Hey: >> It's the GT class here.. > > Short remark: Wouldn?t a longer, more descriptive identifier be better? Like "GeeTee" maybe? or even "GeneralisedTrie"? I like short names myself. But as I have stopped work on this particular lib, it needs a new owner. Anyone who takes it on has renaming priveleges :-) Regards -- Adrian Hey From Christian.Maeder at dfki.de Wed Jan 9 03:59:40 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jan 9 03:53:20 2008 Subject: readline package with libedit In-Reply-To: <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> Message-ID: <47848CFC.3090804@dfki.de> Good! By the way I've the following lines in my ~/.ghci from http://hackage.haskell.org/trac/ghc/ticket/998 :m +System.Console.Readline Data.List getCompleterWordBreakCharacters >>= setCompleterWordBreakCharacters . Data.List.delete '/' :m -System.Console.Readline Data.List Does this work with libedit, too? Christian Judah Jacobson wrote: > On Jan 8, 2008 11:21 AM, Christian Maeder wrote: >> Could you try to install >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-0.9.1 >> and >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-readline-0.9 >> >> If that works, I'll be content with libedit as well. >> >> Christian > > They don't work with the patch I sent before, but after adding back a > few more functions supported by libedit, I was able to install both > packages and successfully run a quick test of shellac-readline in > ghci. (Although eventually, someone more familiar with that package > may want to run more thorough tests.) > > I'll work on making a new patch which adds back all of the > functionality that libedit supports (including what's needed for > shellac-readline). > > -Judah From Christian.Maeder at dfki.de Wed Jan 9 04:07:22 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jan 9 04:01:00 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> Message-ID: <47848ECA.10300@dfki.de> Judah Jacobson wrote: > I'll work on making a new patch which adds back all of the > functionality that libedit supports (including what's needed for > shellac-readline). Let me again stress, that we should make all options work and let us or others decide later on, which option is best for them or which should be the default (taken by configure without arguments). Christian From Christian.Maeder at dfki.de Wed Jan 9 06:47:29 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jan 9 06:41:07 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <4783838E.7010202@dfki.de> References: <4783838E.7010202@dfki.de> Message-ID: <4784B451.8090303@dfki.de> Christian Maeder wrote: > Hi, > > I've succeeded in building a binary distribution that uses static > libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a > with corresponding header files are included. (For license issues ask > someone else.) Linking is done using the flag -search_paths_first. > > Frameworks or dylibs for gmp or readline are no longer required and are > not used when linking binaries. > > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin-static-libs.tar.bz2 > > Other static libraries are compatible with those from > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 > (in fact HSreadline-1.0.1.0 was created this way) Be warned. While static linking seems to work, dynamic linking using ghci does not: ghci -package readline GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. ghc-6.8.2: /Users/Shared/maeder/lib/ghc-6.8.2/lib/readline-1.0.1.0/HSreadline-1.0.1.0.o: unknown symbol `_rl_insert_completions' Loading package readline-1.0.1.0 ... linking ... ghc-6.8.2: unable to load package `readline-1.0.1.0' Has someone an idea how to fix this? > Cheers Christian > > P.S. ranlib during installation is actually not needed on Intel Macs > (only for PPC) From diyu60607 at yahoo.com Wed Jan 9 09:43:58 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Wed Jan 9 09:37:34 2008 Subject: problem with GHC installaion on x86_64 Message-ID: <320973.31870.qm@web32207.mail.mud.yahoo.com> Hi, I found the RHEL4 souce and binary RPMs from http://forte-intl.com/~ronald/haskell/ghc/rhel4/, however, I do not have root privileges on the machine and therefore the installation attempts all failed (for binary RPM, it says can't create transaction lock /var/lock/rpm/transaction, for source RPM, it says cannot write to %sourcedir /usr/src/redhat/SOURCES). Also, I currently have no access to any machine on which there is a working ghc installation so I can't even try the nonregisterised bootstrapping procedure. What should I try now? Thanks! Di, Yu 1.9 ----- Original Message ---- From: Bryan O'Sullivan To: Yu Di Cc: glasgow-haskell-users@haskell.org Sent: Tuesday, January 8, 2008 10:07:16 PM Subject: Re: problem with GHC installaion on x86_64 Yu Di wrote: > Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux > ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 > x86_64 GNU/Linux), Since you're using RHEL4, you could try grabbing a GHC source RPM for Fedora and building that. It might take a bit of tweaking, but probably very little. (For instructions on building binary RPMs from source, Google around.) References: <4783838E.7010202@dfki.de> <4784B451.8090303@dfki.de> Message-ID: <4784DEA3.6090307@dfki.de> Christian Maeder wrote: >> I've succeeded in building a binary distribution that uses static >> libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a >> with corresponding header files are included. (For license issues ask >> someone else.) Linking is done using the flag -search_paths_first. >> >> Frameworks or dylibs for gmp or readline are no longer required and are >> not used when linking binaries. >> >> http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin-static-libs.tar.bz2 The file is updated now. My error was to strip the binaries. That means also "make install-strip" should not be used for installation. > Be warned. > While static linking seems to work, dynamic linking using ghci does not: > > ghci -package readline This works now as expected. Christian > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading package old-locale-1.0.0.0 ... linking ... done. > Loading package old-time-1.0.0.0 ... linking ... done. > Loading package filepath-1.1.0.0 ... linking ... done. > Loading package directory-1.0.0.0 ... linking ... done. > Loading package unix-2.3.0.0 ... linking ... done. > Loading package process-1.0.0.0 ... linking ... done. > ghc-6.8.2: > /Users/Shared/maeder/lib/ghc-6.8.2/lib/readline-1.0.1.0/HSreadline-1.0.1.0.o: > unknown symbol `_rl_insert_completions' > Loading package readline-1.0.1.0 ... linking ... ghc-6.8.2: unable to > load package `readline-1.0.1.0' From judah.jacobson at gmail.com Wed Jan 9 12:10:11 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jan 9 12:03:46 2008 Subject: readline package with libedit In-Reply-To: <47848CFC.3090804@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> <47848CFC.3090804@dfki.de> Message-ID: <6d74b0d20801090910j7652a326t3d0241de8249fa37@mail.gmail.com> On Jan 9, 2008 12:59 AM, Christian Maeder wrote: > > By the way I've the following lines in my ~/.ghci > from > http://hackage.haskell.org/trac/ghc/ticket/998 > > :m +System.Console.Readline Data.List > getCompleterWordBreakCharacters >>= setCompleterWordBreakCharacters . > Data.List.delete '/' > :m -System.Console.Readline Data.List > > Does this work with libedit, too? > > Christian Hm... It runs, but doesn't have any effect. It looks like you need to use setBasicWordBreakCharacters instead of setCompleterWordBreakCharacters. (ghci sets both, which is why I didn't notice this before.) Note that with my fix to #998 (sent to cvs-ghc), that hack should no longer be necessary. -Judah From jim at sdf-eu.org Wed Jan 9 14:42:21 2008 From: jim at sdf-eu.org (jim burton) Date: Wed Jan 9 14:36:08 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? Message-ID: <1199907741.5620.11.camel@unicorn> I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I have the following problem which seems to be same as this one - http://hackage.haskell.org/trac/ghc/ticket/1860 $ ./configure --enable-hc-boot --enable-hc-boot-unregistered checking build system type... alpha-unknown-netbsd2.1.0. checking host system type... alpha-unknown-netbsd2.1.0. checking target system type... alpha-unknown-netbsd2.1.0. Canonicalised to: alpha-unknown-netbsd checking for ghc... no checking for ghc-pkg matching ... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure[3201]: -v0: not found ./configure[3203]: utils/pwd/pwd: not found configure: error: cannot determine current directory there is a temporary solution mentioned in Trac; "to link the binaries generated by the bootstrap compiler statically". How do I make my own statically linked versions of pwd, ghc-pkg and anything else involved? (I don't know anything about C.) Thanks, Jim From kili at outback.escape.de Wed Jan 9 16:00:12 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed Jan 9 15:58:38 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <1199907741.5620.11.camel@unicorn> References: <1199907741.5620.11.camel@unicorn> Message-ID: <20080109210012.GA16066@petunia.outback.escape.de> On Wed, Jan 09, 2008 at 07:42:21PM +0000, jim burton wrote: > I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I > have the following problem which seems to be same as this one - > http://hackage.haskell.org/trac/ghc/ticket/1860 No, I think it's another problem. > $ ./configure --enable-hc-boot --enable-hc-boot-unregistered [...] > checking for ld... /usr/bin/ld > checking for path to top of build tree... ./configure[3201]: -v0: not > found > ./configure[3203]: utils/pwd/pwd: not found > configure: error: cannot determine current directory What happens here is that configure tries to compile some utility program (utils/pwd/pwd) using an existing ghc, which of course is impossible when you're porting ghc a platform not already running ghc. Similar problems are located in libraries and the Cabal-generated GNUmakefiles. For the utils/pwd/pwd problem, I really don't understand why that thing is required at all, since it does little more than get the pwd and add some slash or backslash escaping/quadrupling depending on the argument passed to it. You may try the patch below (and don't forget to re-run autoconf). Note that this is the quick hack I did for OpenBSD. If the forward slash hack of util/pwd is really required (for Windows builds?), something like hardtop=`pwd | tr '\\' /` would be more appropriate. And the other sanity checks I deleted may be necessary in some cases, too, but I really don't see the point in them. Ciao, Kili ps: IMHO, libaries/ifBuildable.hs should die a horrible death, too. It can replaced with a few lines of shell commands.. --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Fri Jan 4 13:58:49 2008 @@ -1098,28 +1098,7 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean && make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` - -if ! test -d "$hardtop"; then - AC_MSG_ERROR([cannot determine current directory]) -fi - -dnl Remove common automounter nonsense -dnl -hardtop=`echo $hardtop | sed 's|^/tmp_mnt.*\(/local/.*\)$|\1|' | sed 's|^/tmp_mnt/|/|'` +hardtop=`pwd` AC_SUBST(hardtop) From diyu60607 at yahoo.com Wed Jan 9 16:47:07 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Wed Jan 9 16:40:42 2008 Subject: problem with GHC installaion on x86_64 Message-ID: <800620.85057.qm@web32202.mail.mud.yahoo.com> Hi, I found that the x86_64 binary package for version 6.4.1 can be installed successfully on my machine (the x86_64 builds for higher versions either require libreadline.so.5 or have problems with timer_create), and then I tried to use that to compile 6.8.2 from source, but I got the following problem: make[2]: Entering directory `.../ghc-6.8.2/libraries/base' ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Control/Concurrent.hs -o dist/build/Control/Concurrent.o -ohi dist/build/Control/Concurrent.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): lookupVers1 base:GHC.Prim sym{tc} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> What is this problem? (I can use 6.4.1 but my programs were last developed with 6.8.1 and contains some function calls that are added later, so I would prefer to use 6.8.1 and above) Thanks, Di, Yu 1.9 ----- Original Message ---- From: Bryan O'Sullivan To: Yu Di Cc: glasgow-haskell-users@haskell.org Sent: Tuesday, January 8, 2008 10:07:16 PM Subject: Re: problem with GHC installaion on x86_64 Yu Di wrote: > Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux > ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 > x86_64 GNU/Linux), Since you're using RHEL4, you could try grabbing a GHC source RPM for Fedora and building that. It might take a bit of tweaking, but probably very little. (For instructions on building binary RPMs from source, Google around.) References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> <47848CFC.3090804@dfki.de> <6d74b0d20801090910j7652a326t3d0241de8249fa37@mail.gmail.com> Message-ID: <87D3025E-2028-434F-B008-F643ABEB5CCA@cse.unsw.edu.au> Judah, I completely agree that, at the least on the Mac, using editline is the best solution (as long all necessary functionality is supported). I am wondering, though, whether you are testing on Tiger or Leopard. When looking at the readline-emulation API of editline after upgrading to Leopard, I had the impression that it included much more functionality than it did on Tiger. Manuel > On Jan 9, 2008 12:59 AM, Christian Maeder > wrote: >> >> By the way I've the following lines in my ~/.ghci >> from >> http://hackage.haskell.org/trac/ghc/ticket/998 >> >> :m +System.Console.Readline Data.List >> getCompleterWordBreakCharacters >>= setCompleterWordBreakCharacters . >> Data.List.delete '/' >> :m -System.Console.Readline Data.List >> >> Does this work with libedit, too? >> >> Christian > > Hm... It runs, but doesn't have any effect. It looks like you need to > use setBasicWordBreakCharacters instead of > setCompleterWordBreakCharacters. (ghci sets both, which is why I > didn't notice this before.) > > Note that with my fix to #998 (sent to cvs-ghc), that hack should no > longer be necessary. > > -Judah From jim at sdf-eu.org Wed Jan 9 17:41:23 2008 From: jim at sdf-eu.org (jim burton) Date: Wed Jan 9 17:35:10 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <20080109210012.GA16066@petunia.outback.escape.de> References: <1199907741.5620.11.camel@unicorn> <20080109210012.GA16066@petunia.outback.escape.de> Message-ID: <1199918483.5620.19.camel@unicorn> Thanks for that, the configure script gets to the end with that help. Following the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform , I then try to make includes but get a big stream of errors from make. Why is this? $ cd includes $ make make: "/arpa/j/jim/ghc-6.8.2/includes/../mk/boilerplate.mk" line 38: Need an operator make: "/arpa/j/jim/ghc-6.8.2/includes/../mk/boilerplate.mk" line 41: Need an operator [...] make: "../mk/../mk/../mk/recurse.mk" line 90: Need an operator make: "../mk/../mk/../mk/recurse.mk" line 91: Need an operator make: "../mk/../mk/../mk/recurse.mk" line 97: Need an operator make: "../mk/../mk/../mk/recurse.mk" line 100: Need an operator make: Fatal errors encountered -- cannot continue Thanks, On Wed, 2008-01-09 at 22:00 +0100, Matthias Kilian wrote: > On Wed, Jan 09, 2008 at 07:42:21PM +0000, jim burton wrote: > > I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I > > have the following problem which seems to be same as this one - > > http://hackage.haskell.org/trac/ghc/ticket/1860 > > No, I think it's another problem. > > > $ ./configure --enable-hc-boot --enable-hc-boot-unregistered > [...] > > checking for ld... /usr/bin/ld > > checking for path to top of build tree... ./configure[3201]: -v0: not > > found > > ./configure[3203]: utils/pwd/pwd: not found > > configure: error: cannot determine current directory > > What happens here is that configure tries to compile some utility > program (utils/pwd/pwd) using an existing ghc, which of course is > impossible when you're porting ghc a platform not already running > ghc. Similar problems are located in libraries and the Cabal-generated > GNUmakefiles. > > For the utils/pwd/pwd problem, I really don't understand why that > thing is required at all, since it does little more than get the > pwd and add some slash or backslash escaping/quadrupling depending > on the argument passed to it. > > You may try the patch below (and don't forget to re-run autoconf). > > Note that this is the quick hack I did for OpenBSD. If the forward slash > hack of util/pwd is really required (for Windows builds?), something > like > > hardtop=`pwd | tr '\\' /` > > would be more appropriate. And the other sanity checks I deleted > may be necessary in some cases, too, but I really don't see the > point in them. > > Ciao, > Kili > > ps: IMHO, libaries/ifBuildable.hs should die a horrible death, too. > It can replaced with a few lines of shell commands.. > > > --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 > +++ aclocal.m4 Fri Jan 4 13:58:49 2008 > @@ -1098,28 +1098,7 @@ AC_REQUIRE([AC_PROG_CC]) > AC_DEFUN([FP_FIND_ROOT],[ > AC_MSG_CHECKING(for path to top of build tree) > > -dnl This would be > -dnl make -C utils/pwd clean && make -C utils/pwd > -dnl except we don't want to have to know what make is called. Sigh. > -if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then > - cd utils/pwd > - rm -f *.o > - rm -f *.hi > - rm -f pwd > - rm -f pwd.exe > - $WithGhc -v0 --make pwd -o pwd > - cd ../.. > -fi > - > -hardtop=`utils/pwd/pwd forwardslash` > - > -if ! test -d "$hardtop"; then > - AC_MSG_ERROR([cannot determine current directory]) > -fi > - > -dnl Remove common automounter nonsense > -dnl > -hardtop=`echo $hardtop | sed 's|^/tmp_mnt.*\(/local/.*\)$|\1|' | sed 's|^/tmp_mnt/|/|'` > +hardtop=`pwd` > > AC_SUBST(hardtop) > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From judah.jacobson at gmail.com Wed Jan 9 18:58:35 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jan 9 18:52:09 2008 Subject: readline package with libedit In-Reply-To: <87D3025E-2028-434F-B008-F643ABEB5CCA@cse.unsw.edu.au> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <4783CD28.1070001@dfki.de> <6d74b0d20801081323ue8fdb5bw3c99add6736b42e@mail.gmail.com> <47848CFC.3090804@dfki.de> <6d74b0d20801090910j7652a326t3d0241de8249fa37@mail.gmail.com> <87D3025E-2028-434F-B008-F643ABEB5CCA@cse.unsw.edu.au> Message-ID: <6d74b0d20801091558t3fe06d6esa8b3a3dcc9b12d1e@mail.gmail.com> Good point. Fortunately, I'm testing everything on Tiger (10.4.10), so this shouldn't be a problem. -Judah On Jan 9, 2008 2:13 PM, Manuel M T Chakravarty wrote: > Judah, > > I completely agree that, at the least on the Mac, using editline is > the best solution (as long all necessary functionality is supported). > > I am wondering, though, whether you are testing on Tiger or Leopard. > When looking at the readline-emulation API of editline after upgrading > to Leopard, I had the impression that it included much more > functionality than it did on Tiger. > > Manuel > > > > On Jan 9, 2008 12:59 AM, Christian Maeder > > wrote: > >> > >> By the way I've the following lines in my ~/.ghci > >> from > >> http://hackage.haskell.org/trac/ghc/ticket/998 > >> > >> :m +System.Console.Readline Data.List > >> getCompleterWordBreakCharacters >>= setCompleterWordBreakCharacters . > >> Data.List.delete '/' > >> :m -System.Console.Readline Data.List > >> > >> Does this work with libedit, too? > >> > >> Christian > > > > Hm... It runs, but doesn't have any effect. It looks like you need to > > use setBasicWordBreakCharacters instead of > > setCompleterWordBreakCharacters. (ghci sets both, which is why I > > didn't notice this before.) > > > > Note that with my fix to #998 (sent to cvs-ghc), that hack should no > > longer be necessary. > > > > -Judah > > From naur at post11.tele.dk Thu Jan 10 03:24:16 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Jan 10 03:19:01 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> Message-ID: <200801100924.19306.naur@post11.tele.dk> Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: > Hi, > > I've succeeded in building a binary distribution that uses static > libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a > with corresponding header files are included. (For license issues ask > someone else.) On http://gmplib.org/ we find: "GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non-free programs." I have not attempted to check whether your distribution fulfills the requirements of the LGPL. Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: "Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license." For your distribution to adhere to this, it appears to require GHC to have a GPL-compatible license. I don't believe it does. > ... Best regards Thorkil From bulat.ziganshin at gmail.com Thu Jan 10 04:00:41 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 10 03:54:54 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <200801100924.19306.naur@post11.tele.dk> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> Message-ID: <1177408385.20080110120041@gmail.com> Hello Thorkil, Thursday, January 10, 2008, 11:24:16 AM, you wrote: >> I've succeeded in building a binary distribution that uses static >> libraries for gmp and readline. > "GMP is distributed under the GNU LGPL. This license makes the library free to > "Readline is free software, distributed under the terms of the GNU General > Public License, version 2. in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Thu Jan 10 04:18:39 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 10 04:12:15 2008 Subject: problem with GHC installaion on x86_64 In-Reply-To: <800620.85057.qm@web32202.mail.mud.yahoo.com> References: <800620.85057.qm@web32202.mail.mud.yahoo.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3108D59DE1D@EA-EXMSG-C334.europe.corp.microsoft.com> This is a fixed bug http://hackage.haskell.org/trac/ghc/ticket/2011 However I hadn't realised that it's in 6.8.2; I thought we'd fixed it prior to the 6.8.2 release. The workaround is simple: do a "make clean". (That's why our tests didn't pick it up; they all start from clean.) Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Yu Di Sent: 09 January 2008 21:47 To: Bryan O'Sullivan Cc: glasgow-haskell-users@haskell.org Subject: Re: problem with GHC installaion on x86_64 Hi, I found that the x86_64 binary package for version 6.4.1 can be installed successfully on my machine (the x86_64 builds for higher versions either require libreadline.so.5 or have problems with timer_create), and then I tried to use that to compile 6.8.2 from source, but I got the following problem: make[2]: Entering directory `.../ghc-6.8.2/libraries/base' ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Control/Concurrent.hs -o dist/build/Control/Concurrent.o -ohi dist/build/Control/Concurrent.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): lookupVers1 base:GHC.Prim sym{tc} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> What is this problem? (I can use 6.4.1 but my programs were last developed with 6.8.1 and contains some function calls that are added later, so I would prefer to use 6.8.1 and above) Thanks, Di, Yu 1.9 ----- Original Message ---- From: Bryan O'Sullivan To: Yu Di Cc: glasgow-haskell-users@haskell.org Sent: Tuesday, January 8, 2008 10:07:16 PM Subject: Re: problem with GHC installaion on x86_64 Yu Di wrote: > Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux > ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 > x86_64 GNU/Linux), Since you're using RHEL4, you could try grabbing a GHC source RPM for Fedora and building that. It might take a bit of tweaking, but probably very little. (For instructions on building binary RPMs from source, Google around.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080110/0d88c263/attachment.htm From gale at sefer.org Thu Jan 10 05:06:12 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 10 04:59:47 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <1177408385.20080110120041@gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> Message-ID: <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> Thorkil Naur wrote: >> "Readline is free software, distributed under the terms of the GNU General >> Public License, version 2. Bulat Ziganshin wrote: > in short, that means that software compiled with this compiler AND > distributed to general audience, should have GPL-compatible license > (i.e. GPL or BSD-like) > (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. -Yitz From bulat.ziganshin at gmail.com Thu Jan 10 05:21:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 10 05:15:34 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> Message-ID: <1645551675.20080110132124@gmail.com> Hello Yitzchak, Thursday, January 10, 2008, 1:06:12 PM, you wrote: >>> "Readline is free software, distributed under the terms of the GNU General >>> Public License, version 2. >> in short, that means that software compiled with this compiler AND >> distributed to general audience, should have GPL-compatible license >> (i.e. GPL or BSD-like) >> (as far as i understand GPL/LGPL terms) > Any software compiled with this compiler, or only > software that uses System.Console.Readline? any software that links with readline.a or gmp.a. which actually means every program because even if you don't use GMP, it's probably still linked in > Isn't this the same on all platforms? If what you are > saying is correct, then isn't it required for any program > compiled with any readline-enabled GHC to have a > GPL-compatible license? I don't think that's > right, but IANAL. GPL license means that any program that uses readline functionality should be *distributed* on GPL-compatible license. are you ever hear how GPL infects computer programs? :) you may also use it for in-house development, without distribution for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Thu Jan 10 06:40:45 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 10 06:34:18 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <1645551675.20080110132124@gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> Message-ID: <2608b8a80801100340q3490355clc41c415e6fde3208@mail.gmail.com> Bulat Ziganshin wrote: >>> in short, that means that software compiled with this compiler AND >>> distributed to general audience, should have GPL-compatible license >>> (i.e. GPL or BSD-like) >>> (as far as i understand GPL/LGPL terms) >> Any software compiled with this compiler, or only >> software that uses System.Console.Readline? > any software that links with readline.a or gmp.a. which actually means > every program because even if you don't use GMP, it's probably still > linked in No, GMP is only LGPL, not GPL. So it only needs to be LGPL compatible unless it uses readline. >> Isn't this the same on all platforms? If what you are >> saying is correct, then isn't it required for any program >> compiled with any readline-enabled GHC to have a >> GPL-compatible license? I don't think that's >> right, but IANAL. > for me, GMP is much more problematic issue. strictly speaking, we > can't say that GHC is BSD-licensed because it includes LGPL-licensed > code (and that much worse, it includes this code in run-time libs) LGPL specifically allows BSD-licensed software to link in object code that is LGPL. But, basically, you need to include the source code of the LGPL parts in your distribution package, and mention in your license notice that part of the code is LGPL. If LGPL is a problem for your project, that is hard to get around right now. We have been reading about efforts to allow alternative multi-precision libraries with GHC. That is very important work, but apparently difficult. However, LGPL is often not a serious problem, even for commercial products. GNU readline, on the other hand, is never suitable for non-free software. The authors of the GNU readline library have publicly stated that the whole reason they are using GPL is to make sure that no non-free software ever uses it. So this work to use editline instead of readline in GHC is very important for all platforms, not just the Mac. editline is BSD licensed. Therefore, I think the focus should be to get the best readline compatibility possible by using a sufficiently recent version of editline. If that causes problems on a specific platform, like Tiger, that is a lower priority. (I say that even though I myself am on Tiger.) We can work around that separately. -Yitz From kili at outback.escape.de Thu Jan 10 17:47:53 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Thu Jan 10 17:43:49 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <1199918483.5620.19.camel@unicorn> References: <1199907741.5620.11.camel@unicorn> <20080109210012.GA16066@petunia.outback.escape.de> <1199918483.5620.19.camel@unicorn> Message-ID: <20080110224753.GA3001@petunia.outback.escape.de> On Wed, Jan 09, 2008 at 10:41:23PM +0000, jim burton wrote: > Thanks for that, the configure script gets to the end with that help. > Following the instructions at > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform > , I then try to make includes but get a big stream of errors from > make. Why is this? The GHC build backs on gmake(1). Ciao, Kili From Christian.Maeder at dfki.de Fri Jan 11 04:52:42 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 11 04:46:15 2008 Subject: GHC 6.8.1 (now ghc-6.8.2) on Mac OS X 10.5 (Leopard) In-Reply-To: References: <4730615D.3090704@dfki.de> <8F73DCAB-6742-45B9-887A-7F840392A13F@cse.unsw.edu.au> Message-ID: <47873C6A.9050502@dfki.de> setting MACOSX_DEPLOYMENT_TARGET=10.4 or MACOSX_DEPLOYMENT_TARGET=10.3 on an Intel Leopard produced binaries executable on Intel Tigers (we have no Intel Panther, though) Without MACOSX_DEPLOYMENT_TARGET binaries from Leopard yield "Bus Error" on Tiger. The binary was built using my own binary-dist for Intel Tiger (Mac OS 10.4) (with GMP and GNUreadline frameworks). Christian Deborah Goldsmith wrote: > On Nov 6, 2007, at 4:06 PM, Manuel M T Chakravarty wrote: >> I wasn't expecting any backwards compatibility from Leopard-built >> software to Tiger, but then I am also a Mac-noob and maybe there are >> ways to achieve that that I don't know of. Any suggestions? > > Sorry, I missed this the first time around... > > To build binaries on Leopard that are compatible with previous releases > of Mac OS X, you need to use the appropriate SDK parameters when > invoking gcc (for includes) and the linker (for libraries). This is > described in the context of building a universal binary in: > > http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_3.html#//apple_ref/doc/uid/TP40002850-BAJCFEBA > > > but the same concepts (-isysroot for gcc and -Wl,-syslibroot for ld) > apply to building against any SDK. > > An SDK is basically a copy of the frameworks and libraries for a > particular OS release, but the libraries are just stubs to link against. > By pointing gcc and ld at an SDK, you use the correct headers and entry > points for a particular release. > > Caveat: I don't know how use of SDKs interacts with use of non-system > libraries (e.g., in /opt/local or /Library/Frameworks). > > Another approach is to set MAC_OS_X_VERSION_MIN_REQUIRED to > MAC_OS_X_VERSION_10_4 (or whatever). You then have to be careful about > how you use APIs that are new in Leopard. I would think the SDK approach > would be easier for something like ghc. > > If you don't do anything, by default binaries built on a particular Mac > OS X release will only run on that release or later. > > Deborah From jim at sdf-eu.org Fri Jan 11 06:06:57 2008 From: jim at sdf-eu.org (Jim Burton) Date: Fri Jan 11 06:00:42 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <20080110224753.GA3001@petunia.outback.escape.de> References: <1199907741.5620.11.camel@unicorn> <20080109210012.GA16066@petunia.outback.escape.de> <1199918483.5620.19.camel@unicorn> <20080110224753.GA3001@petunia.outback.escape.de> Message-ID: <1200049617.6642.1.camel@unicorn> Thanks Kili. I'm afraid I need rather a lot of hand-holding with this and immediately run into the next problem jim@droog:jim/ghc-6.8.2/includes$ gmake Creating ghcautoconf.h... Done. gcc -O -I/arpa/j/jim/ghc-6.8.2/includes -I/arpa/j/jim/ghc-6.8.2/libraries/base/include -I/arpa/j/jim/ghc-6.8.2/libraries/unix/include -I/arpa/j/jim/ghc-6.8.2/libraries/parsec/include -DNO_REGS -DUSE_MINIINTERPRETER -I. -I../rts -I../gmp/gmpbuild -DNOSMP -c mkDerivedConstants.c -o mkDerivedConstants.o In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: Regs.h:30:45: gmp.h: No such file or directory In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: I thought this might mean gmp was missing, but it is installed. There is no ../gmp/gmpbuild however. What now? Thanks! On Thu, 2008-01-10 at 23:47 +0100, Matthias Kilian wrote: > On Wed, Jan 09, 2008 at 10:41:23PM +0000, jim burton wrote: > > Thanks for that, the configure script gets to the end with that help. > > Following the instructions at > > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform > > , I then try to make includes but get a big stream of errors from > > make. Why is this? > > The GHC build backs on gmake(1). > > Ciao, > Kili > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Fri Jan 11 06:09:31 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 11 06:03:04 2008 Subject: GHC 6.8.1 (now ghc-6.8.2) on Mac OS X 10.5 (Leopard) In-Reply-To: <47873C6A.9050502@dfki.de> References: <4730615D.3090704@dfki.de> <8F73DCAB-6742-45B9-887A-7F840392A13F@cse.unsw.edu.au> <47873C6A.9050502@dfki.de> Message-ID: <47874E6B.80200@dfki.de> "man ld" on Tiger says: -macosx_version_min version This overrides the MACOSX_DEPLOYMENT_TARGET environment variable (see below). Unlike other linker options, this one may be spec- ified multiple times; only the last occurrence is effective. The following environment variable is used to control the use of incom- patible features in the output with respect to Mac OS X releases. MACOSX_DEPLOYMENT_TARGET This is set to indicate the oldest Mac OS X version that that the output is to be used on. When this is set to a release that is older than the current release features that are incompatible with that release will be disabled. If a feature is seen in the input that can't be in the output due to this setting a warning is issued. The current allowable values for this are 10.1, 10.2 10.3, and 10.4 with the default being 10.4 for the i386 archi- tecture and 10.1 for all other architectures. "man ld" on Leopard does not mention MACOSX_DEPLOYMENT_TARGET, but "-macosx_version_min" does not work as expected: When passing "-macosx_version_min 10.4" via ghc to gcc and ld using: ghc -v --make Hello.hs \ -optl-Xlinker -optl-macosx_version_min -optl-Xlinker -optl10.4 then "-macosx_version_min 10.4" lands almost at the end of "collect2" and has no effect, because the command starts with "-macosx_version_min 10.5.1" (although the above man page claims that the last occurrence should be effective). Cheers Christian /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.1 -weak_reference_mismatches non-weak [...] Hello.o -macosx_version_min 10.4 -lHSbase-3.0.1.0 -lHSrts -lm -framework GMP -lgcc_s.10.5 -lgcc -lSystem -F/home/maeder/Library/Frameworks Christian Maeder wrote: > setting > MACOSX_DEPLOYMENT_TARGET=10.4 > or > MACOSX_DEPLOYMENT_TARGET=10.3 > > on an Intel Leopard produced binaries executable on Intel Tigers (we > have no Intel Panther, though) > > Without MACOSX_DEPLOYMENT_TARGET binaries from Leopard yield "Bus Error" > on Tiger. > > The binary was built using my own binary-dist for Intel Tiger (Mac OS > 10.4) (with GMP and GNUreadline frameworks). > > Christian From bulat.ziganshin at gmail.com Fri Jan 11 06:38:55 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 11 06:53:54 2008 Subject: ghc 6.6.1 -optl bug? Message-ID: <1611298943.20080111143855@gmail.com> Hello GHC, sorry, i'm still user of 6.6.1 version the following command: ghc --make .... -optl-s strips the executable while the following command ghc --make .... -optl--strip-all has no effect. i made some experiments and it seems that options starting with "--" are not sent to ld at all (you can write -optl--unexisting-option but not -optl-#) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cmb21 at kent.ac.uk Fri Jan 11 07:20:58 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Fri Jan 11 07:16:38 2008 Subject: network package Message-ID: Hi, I have just built and installed ghc-6.8.2 on my linux box but I can't find the network package. Has it been moved or left out? Kind regards, Chris. From Christian.Maeder at dfki.de Fri Jan 11 08:10:36 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 11 08:04:09 2008 Subject: ghc 6.6.1 -optl bug? In-Reply-To: <1611298943.20080111143855@gmail.com> References: <1611298943.20080111143855@gmail.com> Message-ID: <47876ACC.50001@dfki.de> Bulat Ziganshin wrote: > Hello GHC, > > sorry, i'm still user of 6.6.1 version > > the following command: ghc --make .... -optl-s > > strips the executable while the following command > > ghc --make .... -optl--strip-all > > has no effect. i made some experiments and it seems that options > starting with "--" are not sent to ld at all (you can write > -optl--unexisting-option but not -optl-#) Does adding -optl-Xlinker help you? ghc --make Hello.hs -fforce-recomp -optl-Xlinker -optl--strip-all [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... /usr/bin/ld: unknown flag: --strip-all collect2: ld returned 1 exit status (I've use version 6.8.2 though) Christian From diyu60607 at yahoo.com Fri Jan 11 08:39:20 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Fri Jan 11 08:32:49 2008 Subject: problem with GHC installaion on x86_64 Message-ID: <480409.74563.qm@web32203.mail.mud.yahoo.com> Thanks! The clean rebuild worked. Di, Yu 1.11 ----- Original Message ---- From: Simon Peyton-Jones To: Yu Di ; Bryan O'Sullivan Cc: "glasgow-haskell-users@haskell.org" Sent: Thursday, January 10, 2008 3:18:39 AM Subject: RE: problem with GHC installaion on x86_64 This is a fixed bug http://hackage.haskell.org/trac/ghc/ticket/2011 However I hadn?t realised that it?s in 6.8.2; I thought we?d fixed it prior to the 6.8.2 release. The workaround is simple: do a ?make clean?. (That?s why our tests didn?t pick it up; they all start from clean.) Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Yu Di Sent: 09 January 2008 21:47 To: Bryan O'Sullivan Cc: glasgow-haskell-users@haskell.org Subject: Re: problem with GHC installaion on x86_64 Hi, I found that the x86_64 binary package for version 6.4.1 can be installed successfully on my machine (the x86_64 builds for higher versions either require libreadline.so.5 or have problems with timer_create), and then I tried to use that to compile 6.8.2 from source, but I got the following problem: make[2]: Entering directory `.../ghc-6.8.2/libraries/base' ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Control/Concurrent.hs -o dist/build/Control/Concurrent.o -ohi dist/build/Control/Concurrent.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): lookupVers1 base:GHC.Prim sym{tc} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> What is this problem? (I can use 6.4.1 but my programs were last developed with 6.8.1 and contains some function calls that are added later, so I would prefer to use 6.8.1 and above) Thanks, Di, Yu 1.9 ----- Original Message ---- From: Bryan O'Sullivan To: Yu Di Cc: glasgow-haskell-users@haskell.org Sent: Tuesday, January 8, 2008 10:07:16 PM Subject: Re: problem with GHC installaion on x86_64 Yu Di wrote: > Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux > ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 > x86_64 GNU/Linux), Since you're using RHEL4, you could try grabbing a GHC source RPM for Fedora and building that. It might take a bit of tweaking, but probably very little. (For instructions on building binary RPMs from source, Google around.) References: <8763y5cns2.fsf@szonett.ki.iif.hu> <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> <87d4scboow.fsf@szonett.ki.iif.hu> Message-ID: <20080111135202.GA27159@matrix.chaos.earth.li> On Tue, Jan 08, 2008 at 11:23:59AM +0100, Wagner Ferenc wrote: > "Ravi Nanavati" writes: > > > Well... I built some (not all) of the 6.8.2-related packages in > > Haskell Unsafe on etch. > > Ian uploaded 6.8.2 the day before > yesterday... Maybe when he's finished with this work, a rebuild on > Etch won't be too difficult. I do plan to do this at some point, but it's not imminent I'm afraid. > > I wonder if libghc6 libraries shouldn't depend on the > > particular version of ghc they were compiled with (so they > > automatically go if you change ghc versions). They should, e.g. $ dpkg -s libghc6-mtl-dev | grep Dep Depends: ghc6 (>= 6.8.2), ghc6 (<< 6.8.2+), libghc6-base-dev If any don't, please let us know! Thanks Ian From bulat.ziganshin at gmail.com Fri Jan 11 09:05:35 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 11 10:03:01 2008 Subject: ghc 6.6.1 -optl bug? In-Reply-To: <47876ACC.50001@dfki.de> References: <1611298943.20080111143855@gmail.com> <47876ACC.50001@dfki.de> Message-ID: <1002357151.20080111170535@gmail.com> Hello Christian, Friday, January 11, 2008, 4:10:36 PM, you wrote: > Does adding -optl-Xlinker help you? > ghc --make Hello.hs -fforce-recomp -optl-Xlinker -optl--strip-all thank you - it works! -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wferi at niif.hu Fri Jan 11 12:07:35 2008 From: wferi at niif.hu (Ferenc Wagner) Date: Fri Jan 11 12:01:04 2008 Subject: Any Debian Etch packages for GHC 6.8.2? In-Reply-To: <20080111135202.GA27159@matrix.chaos.earth.li> (Ian Lynagh's message of "Fri, 11 Jan 2008 13:52:02 +0000") References: <8763y5cns2.fsf@szonett.ki.iif.hu> <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> <87d4scboow.fsf@szonett.ki.iif.hu> <20080111135202.GA27159@matrix.chaos.earth.li> Message-ID: <87odbss33c.fsf@tac.ki.iif.hu> Ian Lynagh writes: > On Tue, Jan 08, 2008 at 11:23:59AM +0100, Wagner Ferenc wrote: > >> Ian uploaded 6.8.2 the day before yesterday... Maybe when he's >> finished with this work, a rebuild on Etch won't be too difficult. > > I do plan to do this at some point, but it's not imminent I'm afraid. Maybe I can lend you a hand if you describe the plan. I've got some packaging experience, but not with beasts of this complexity. -- Regards, Feri. From dons at galois.com Fri Jan 11 12:32:20 2008 From: dons at galois.com (Don Stewart) Date: Fri Jan 11 12:25:52 2008 Subject: network package In-Reply-To: References: Message-ID: <20080111173220.GA20969@scytale.galois.com> cmb21: > Hi, > > I have just built and installed ghc-6.8.2 on my linux box but I can't find > the network package. Has it been moved or left out? It's not installed by default. You can find it on hackage.haskell.org, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.1.0.0 As the Haskell community is moving to a more distributed development model (with a central archive). You can also build and install 'cabal-install', to make installation easy. $ cabal install network Cheers, Don From igloo at earth.li Fri Jan 11 12:32:42 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 11 12:26:13 2008 Subject: Any Debian Etch packages for GHC 6.8.2? In-Reply-To: <87odbss33c.fsf@tac.ki.iif.hu> References: <8763y5cns2.fsf@szonett.ki.iif.hu> <7b977d860801071422ybc05fdcpc3810a024e96f200@mail.gmail.com> <87d4scboow.fsf@szonett.ki.iif.hu> <20080111135202.GA27159@matrix.chaos.earth.li> <87odbss33c.fsf@tac.ki.iif.hu> Message-ID: <20080111173242.GA31278@matrix.chaos.earth.li> On Fri, Jan 11, 2008 at 06:07:35PM +0100, Ferenc Wagner wrote: > Ian Lynagh writes: > > > On Tue, Jan 08, 2008 at 11:23:59AM +0100, Wagner Ferenc wrote: > > > >> Ian uploaded 6.8.2 the day before yesterday... Maybe when he's > >> finished with this work, a rebuild on Etch won't be too difficult. > > > > I do plan to do this at some point, but it's not imminent I'm afraid. > > Maybe I can lend you a hand if you describe the plan. I've got some > packaging experience, but not with beasts of this complexity. I don't think the packaging should need to be changed much, if at all. The problem is just to rebuild all the packages in the right order. This message has a little more detail, and links to the script I use to do the "build in the right order" part for the libraries (for unstable/amd64, with pbuilder): http://urchin.earth.li/pipermail/debian-haskell/2008-January/000357.html Either the script would have to be generalised, or an alternative would have to be used (perhaps the software used by Debian's buildds?). Thanks Ian From kili at outback.escape.de Fri Jan 11 16:20:11 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 11 16:19:10 2008 Subject: network package In-Reply-To: <20080111173220.GA20969@scytale.galois.com> References: <20080111173220.GA20969@scytale.galois.com> Message-ID: <20080111212011.GA32142@petunia.outback.escape.de> On Fri, Jan 11, 2008 at 09:32:20AM -0800, Don Stewart wrote: > > I have just built and installed ghc-6.8.2 on my linux box but I can't find > > the network package. Has it been moved or left out? > > It's not installed by default. You can find it on hackage.haskell.org, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.1.0.0 Yet it's still available in the extralibs tarball. Real slackers just extract extralibs on top of the normal ghc source tarball to get most (not all) of the beloved packages built for free. Just FYI, here are some notes I scribbled down for myself a few days ago when I did some work on the OpenBSD port of GHC (comparing 6.6.1 against 6.8.2 and comparing that against hackage.haskell.org): New (wrt 6.6.1): array, bytestring, containers, directory, hpc, old-locale, old-time, packedstring, parallel, pretty, process, random. Removed from the ghc sources (make separate ports fetching them from hackage): HGL, X11. Note that X11-extras (i.e. port x11/hs-x11-extras) is obsolete now. Available in the extralibs distfile: HUnit, OpenGL, QuickCheck, cgi, fgl, haskell-src, html, mtl, network, parallel, parsec, regex-base, regex-compat, regex-posix, stm, time, xhtml. Version info for packages (no version in "Hackage" column means same version as for GHC-6.8.2): Name Dist GHC-6.8.2 Hackage Cabal base 1.2.3.0 HUnit extra 1.2.0.0 OpenGL extra 2.2.1.1 QuickCheck extra 1.1.0.0 array base 0.1.0.0 base base 3.0.1.0 n/a bytestring base 0.9.0.1 0.9.0.3 cgi extra 3001.1.5.1 containers base 0.1.0.1 0.1.0.0 (!) directory base 1.0.0.0 fgl extra 5.4.1.1 filepath base 1.1.0.0 ghc base 6.8.2 n/a haskell-src extra 1.0.1.1 haskell98 base 1.0.1.0 hpc base 0.5.0.0 html extra 1.0.1.1 mtl extra 1.1.0.0 network extra 2.1.0.0 old-locale base 1.0.0.0 old-time base 1.0.0.0 packedstring base 0.1.0.0 parallel extra 1.0.0.0 parsec extra 2.1.0.0 pretty base 1.0.0.0 process base 1.0.0.0 random base 1.0.0.0 readline base 1.0.1.0 regex-base extra 0.72.0.1 0.91 regex-compat extra 0.71.0.1 0.90 regex-posix extra 0.72.0.2 0.91 rts base 1.0 n/a stm extra 2.1.1.0 template-haskell base(!) 2.2.0.0 time extra 1.1.2.0 unix base 2.3.0.0 2.2.0.0 (!) xhtml extra 3000.0.2.1 Ciao, Kili From kili at outback.escape.de Fri Jan 11 17:25:33 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 11 17:23:32 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <1200049617.6642.1.camel@unicorn> References: <1199907741.5620.11.camel@unicorn> <20080109210012.GA16066@petunia.outback.escape.de> <1199918483.5620.19.camel@unicorn> <20080110224753.GA3001@petunia.outback.escape.de> <1200049617.6642.1.camel@unicorn> Message-ID: <20080111222533.GA1488@petunia.outback.escape.de> On Fri, Jan 11, 2008 at 11:06:57AM +0000, Jim Burton wrote: > In file included from Stg.h:150, > from Rts.h:19, > from mkDerivedConstants.c:23: > Regs.h:30:45: gmp.h: No such file or directory For a starter, look at http://hackage.haskell.org/trac/ghc/ticket/2009 No idea wether it fixes your problem; you may have to add some more similar changes. Ciao, Kili From mechvel at botik.ru Sat Jan 12 07:58:14 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Jan 12 07:52:20 2008 Subject: `show' in ghci dialogue Message-ID: <20080112125814.GA11379@scico.botik.ru> People, I have a question about usage of `show' in the GHCi dialogue system. I introduce my user class DShow, trying to improve the class Show of Haskell-98. For example, I program --------------------------- class DShow a where dShow :: ShowOptions -> a -> String ... main = let listOfListPairs = [ ([1,2,3], [] ), ([4,5,6], [7] ), ([9,8,0], [0,0,0]) ] :: [ ([Int], [Int]) ] opts = ShowOptions {verbosity = 2, listSepator = ", \n\n", fieldSeparator = ", \n"} in putStr (dShow opts listOfListPairs) --------------------------- Then, the command ./Main outputs ----------------------- [([1, 2, 3], []), ([4, 5, 6], [7]), ([9, 8, 0], [0, 0, 0])] ----------------------- This way of the output format control by dShow and ShowOptions is my goal. But the command > main in the ghci interpreter outputs something like this: "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" How can the user force ghci to output the same output format as in the case of ./Main (how to interprete '\n') ? 1. If we give to the interpreter the line > listOfListPairs , then the ghci dialogue system does interprete the NewLine characters on output as needed -- only for the value of (show listOfListPairs). And I need it for the value of (dShow opts listOfListPairs). Is there any way to substitute a user function instead of `show' in the ghci output? (and dShow has additional argument ...). 2. Which function outputs a string in the ghci dialogue system? Can the user make this function to interprete the NewLine character in the argument string? Thank you in advance for your explanation. ----------------- Serge Mechveliani mechvel@botik.ru From ndmitchell at gmail.com Sat Jan 12 08:11:00 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jan 12 08:04:27 2008 Subject: `show' in ghci dialogue In-Reply-To: <20080112125814.GA11379@scico.botik.ru> References: <20080112125814.GA11379@scico.botik.ru> Message-ID: <404396ef0801120511p384445d5ie51fd65e495864f9@mail.gmail.com> Hi Serge, I think what you are looking for is putStr: ghci> putStr "Test\nhere" Test here Thanks Neil On 1/12/08, Serge D. Mechveliani wrote: > People, > > I have a question about usage of `show' in the GHCi dialogue system. > > I introduce my user class DShow, trying to improve the class Show of > Haskell-98. For example, I program > > --------------------------- > class DShow a where dShow :: ShowOptions -> a -> String > ... > main = let listOfListPairs = [ ([1,2,3], [] ), > ([4,5,6], [7] ), > ([9,8,0], [0,0,0]) > ] :: [ ([Int], [Int]) ] > opts = ShowOptions {verbosity = 2, > listSepator = ", \n\n", > fieldSeparator = ", \n"} > in > putStr (dShow opts listOfListPairs) > --------------------------- > > Then, the command ./Main outputs > > ----------------------- > [([1, 2, 3], []), > > ([4, 5, 6], [7]), > > ([9, 8, 0], [0, 0, 0])] > ----------------------- > > This way of the output format control by dShow and ShowOptions is my goal. > But the command > > > main > > in the ghci interpreter outputs something like this: > > "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" > > How can the user force ghci to output the same output format as in > the case of ./Main > (how to interprete '\n') ? > > 1. If we give to the interpreter the line > > > listOfListPairs > > , then the ghci dialogue system does interprete the NewLine > characters on output as needed -- > only for the value of (show listOfListPairs). > And I need it for the value of (dShow opts listOfListPairs). > Is there any way to substitute a user function instead of `show' in the > ghci output? (and dShow has additional argument ...). > > 2. Which function outputs a string in the ghci dialogue system? > Can the user make this function to interprete the NewLine character > in the argument string? > > Thank you in advance for your explanation. > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From igloo at earth.li Sat Jan 12 08:23:19 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 12 08:16:45 2008 Subject: `show' in ghci dialogue In-Reply-To: <20080112125814.GA11379@scico.botik.ru> References: <20080112125814.GA11379@scico.botik.ru> Message-ID: <20080112132319.GA1404@matrix.chaos.earth.li> Hi Serge, On Sat, Jan 12, 2008 at 03:58:14PM +0300, Serge D. Mechveliani wrote: > > > main > > in the ghci interpreter outputs something like this: > > "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" It shouldn't do; can you give a complete example please? > 1. If we give to the interpreter the line > > > listOfListPairs > > , then the ghci dialogue system does interprete the NewLine > characters on output as needed -- > only for the value of (show listOfListPairs). > And I need it for the value of (dShow opts listOfListPairs). > Is there any way to substitute a user function instead of `show' in the > ghci output? (and dShow has additional argument ...). Not as far as I know. Thanks Ian From mechvel at botik.ru Sat Jan 12 08:40:16 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Jan 12 08:34:11 2008 Subject: `show' in ghci dialogue In-Reply-To: <404396ef0801120511p384445d5ie51fd65e495864f9@mail.gmail.com> References: <20080112125814.GA11379@scico.botik.ru> <404396ef0801120511p384445d5ie51fd65e495864f9@mail.gmail.com> Message-ID: <20080112134016.GA11426@scico.botik.ru> On Sat, Jan 12, 2008 at 01:11:00PM +0000, Neil Mitchell wrote: > Hi Serge, > > I think what you are looking for is putStr: > > ghci> putStr "Test\nhere" > Test > here Thank you. And my `main' function below did apply putStr. I am sorry, I got confused: cannot recall in what situation its output was "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" How strange ... > On 1/12/08, Serge D. Mechveliani wrote: > > [..] > > --------------------------- > > class DShow a where dShow :: ShowOptions -> a -> String > > ... > > main = let listOfListPairs = [ ([1,2,3], [] ), > > ([4,5,6], [7] ), > > ([9,8,0], [0,0,0]) > > ] :: [ ([Int], [Int]) ] > > opts = ShowOptions {verbosity = 2, > > listSepator = ", \n\n", > > fieldSeparator = ", \n"} > > in > > putStr (dShow opts listOfListPairs) > > --------------------------- > > > > Then, the command ./Main outputs > > > > ----------------------- > > [([1, 2, 3], []), > > > > ([4, 5, 6], [7]), > > > > ([9, 8, 0], [0, 0, 0])] > > ----------------------- > > [..] > > But the command > > > > > main > > > > in the ghci interpreter outputs something like this: > > "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" > > > > [..] From mechvel at botik.ru Sat Jan 12 08:43:12 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Jan 12 08:37:05 2008 Subject: `show' in ghci dialogue In-Reply-To: <20080112132319.GA1404@matrix.chaos.earth.li> References: <20080112125814.GA11379@scico.botik.ru> <20080112132319.GA1404@matrix.chaos.earth.li> Message-ID: <20080112134312.GA11444@scico.botik.ru> On Sat, Jan 12, 2008 at 01:23:19PM +0000, Ian Lynagh wrote: > > Hi Serge, > > On Sat, Jan 12, 2008 at 03:58:14PM +0300, Serge D. Mechveliani wrote: > > > > > main > > > > in the ghci interpreter outputs something like this: > > > > "[([1, 2, 3), []),\n\n([4, 5, 6), [7]),\n\n([9, 8, 0],\n\n[0, 0, 0])]" > > It shouldn't do; can you give a complete example please? > I am sorry, I got confused. Cannot recall in what situation it printed this. How strange ... From cmb21 at kent.ac.uk Sun Jan 13 15:44:35 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Sun Jan 13 15:38:31 2008 Subject: network package In-Reply-To: <20080111173220.GA20969@scytale.galois.com> References: <20080111173220.GA20969@scytale.galois.com> Message-ID: Thanks for everyone's help with this so far. However, I'm having some problems using cabal: Whenever I try to runghc Setup.hs install a cabal file (I've tried parsec and network) I get an error message similar to this: Setup.hs: parsec.cabal:15: Unknown field 'build-type' I tried to install Cabal from darcs and I also got an error message when trying to configure: Setup.lhs: cabal-install.cabal:30: Invalid syntax (no colon after field name) Does anyone else have these problems? Or, am I doing something obviously wrong? Thanks, Chris. On Fri, 11 Jan 2008, Don Stewart wrote: > cmb21: > > Hi, > > > > I have just built and installed ghc-6.8.2 on my linux box but I can't find > > the network package. Has it been moved or left out? > > It's not installed by default. You can find it on hackage.haskell.org, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.1.0.0 > > As the Haskell community is moving to a more distributed development > model (with a central archive). > > You can also build and install 'cabal-install', to make installation > easy. > > $ cabal install network > > Cheers, > Don > From dons at galois.com Sun Jan 13 15:53:54 2008 From: dons at galois.com (Don Stewart) Date: Sun Jan 13 15:47:16 2008 Subject: network package In-Reply-To: References: <20080111173220.GA20969@scytale.galois.com> Message-ID: <20080113205354.GB20928@scytale.galois.com> cmb21: > Thanks for everyone's help with this so far. However, I'm having some > problems using cabal: > > Whenever I try to > > runghc Setup.hs install > > a cabal file (I've tried parsec and network) I get an error message > similar to this: > > Setup.hs: parsec.cabal:15: Unknown field 'build-type' > > I tried to install Cabal from darcs and I also got an error message when > trying to configure: > > Setup.lhs: cabal-install.cabal:30: Invalid syntax (no colon after field > name) Looks like your version of cabal is a bit old. Try updating to the 1.2.3 or 1.3 series. You can find it on hackage.haskell.org -- Don From cmb21 at kent.ac.uk Sun Jan 13 17:05:36 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Sun Jan 13 16:59:17 2008 Subject: network package In-Reply-To: <20080113205354.GB20928@scytale.galois.com> References: <20080111173220.GA20969@scytale.galois.com> <20080113205354.GB20928@scytale.galois.com> Message-ID: > Looks like your version of cabal is a bit old. Try updating to the 1.2.3 > or 1.3 series. You can find it on hackage.haskell.org I'm using the runghc command from ghc-6.8.2, is that right? cmb21@localhost ~/filepath-1.0 $ which runghc /usr/local/packages/ghc-6.8.2/bin/runghc Cheers, Chris From dons at galois.com Sun Jan 13 17:09:39 2008 From: dons at galois.com (Don Stewart) Date: Sun Jan 13 17:03:02 2008 Subject: network package In-Reply-To: References: <20080111173220.GA20969@scytale.galois.com> <20080113205354.GB20928@scytale.galois.com> Message-ID: <20080113220939.GE20928@scytale.galois.com> cmb21: > > > Looks like your version of cabal is a bit old. Try updating to the 1.2.3 > > or 1.3 series. You can find it on hackage.haskell.org > > I'm using the runghc command from ghc-6.8.2, is that right? > > cmb21@localhost ~/filepath-1.0 $ which runghc > /usr/local/packages/ghc-6.8.2/bin/runghc That's fine. The issue is that cabal-install requires a new version of 'cabal', which you can find here, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.2.3.0 Though cabal-install may well require the darcs version of cabal (I'm not sure). http://haskell.org/cabal/code.html -- Don From igloo at earth.li Sun Jan 13 17:21:22 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 13 17:14:44 2008 Subject: network package In-Reply-To: References: <20080111173220.GA20969@scytale.galois.com> <20080113205354.GB20928@scytale.galois.com> Message-ID: <20080113222122.GA27829@matrix.chaos.earth.li> On Sun, Jan 13, 2008 at 10:05:36PM +0000, C.M.Brown wrote: > > > Looks like your version of cabal is a bit old. Try updating to the 1.2.3 > > or 1.3 series. You can find it on hackage.haskell.org > > I'm using the runghc command from ghc-6.8.2, is that right? > > cmb21@localhost ~/filepath-1.0 $ which runghc > /usr/local/packages/ghc-6.8.2/bin/runghc runghc finds ghc in the path, so it might be using a ghc from /usr/bin or somesuch. Try compiling Setup with ghc 6.8.2 instead (ghc --make Setup). Thanks Ian From cmb21 at kent.ac.uk Sun Jan 13 17:56:54 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Sun Jan 13 17:50:25 2008 Subject: network package In-Reply-To: <20080113222122.GA27829@matrix.chaos.earth.li> References: <20080111173220.GA20969@scytale.galois.com> <20080113205354.GB20928@scytale.galois.com> <20080113222122.GA27829@matrix.chaos.earth.li> Message-ID: > runghc finds ghc in the path, so it might be using a ghc from /usr/bin > or somesuch. Try compiling Setup with ghc 6.8.2 instead > (ghc --make Setup). Excellent, that worked a treat! thanks. Chris. > > > Thanks > Ian > > From marco-oweber at gmx.de Sun Jan 13 20:05:52 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jan 13 19:59:15 2008 Subject: Jumping to code every and anywhere: What about installing source and a tagfile? Message-ID: <20080114010552.GD26840@gmx.de> See http://hackage.haskell.org/trac/hackage/ticket/207 Discussion takes place on haskell-cafe Marc Weber From jb162 at brighton.ac.uk Mon Jan 14 06:18:04 2008 From: jb162 at brighton.ac.uk (jb162@brighton.ac.uk) Date: Mon Jan 14 06:10:39 2008 Subject: Problem building on NetBSD Alpha - Dynamic link dependency? In-Reply-To: <20080111222533.GA1488@petunia.outback.escape.de> References: <1199907741.5620.11.camel@unicorn> <20080109210012.GA16066@petunia.outback.escape.de> <1199918483.5620.19.camel@unicorn> <20080110224753.GA3001@petunia.outback.escape.de> <1200049617.6642.1.camel@unicorn> <20080111222533.GA1488@petunia.outback.escape.de> Message-ID: <1200309484.5640.4.camel@mowa624-jb162.university.brighton.ac.uk> Thanks. I also needed to make gmp on the target. Would this generally be true as I think it would? I tried to update the wiki but don't have privileges. Jim On Fri, 2008-01-11 at 23:25 +0100, Matthias Kilian wrote: > On Fri, Jan 11, 2008 at 11:06:57AM +0000, Jim Burton wrote: > > In file included from Stg.h:150, > > from Rts.h:19, > > from mkDerivedConstants.c:23: > > Regs.h:30:45: gmp.h: No such file or directory > > For a starter, look at http://hackage.haskell.org/trac/ghc/ticket/2009 > > No idea wether it fixes your problem; you may have to add some more > similar changes. > > Ciao, > Kili > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jb162 at brighton.ac.uk Mon Jan 14 07:41:15 2008 From: jb162 at brighton.ac.uk (jb162@brighton.ac.uk) Date: Mon Jan 14 07:33:50 2008 Subject: Problem building on host machine when trying to cross-compile an unregistered build Message-ID: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> Hi, host machine is Linux i386 and the target is NetBSD alpha, ghc 6.8.2. With the help of the list the first part (on the target) is done and I'm building the compiler on the host -- when building rts I get "cc1: error: unrecognized command line option "-mieee" What's this about? (I notice a couple of seemingly ignorable warnings in the following, about missing gmpbuild and libHSrts.a. Is that relevant?) Thanks. jim@mowa624-jb162:~/ghc-6.8.2/compiler$ cd ../rts && make boot && make gcc -E -undef -traditional -P \ -DIMPORT_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ -DLIB_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ -DINCLUDE_DIR='"/home/jim/ghc-6.8.2/libraries/rts/include"' \ -DDATA_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ -DHTML_DIR='"/home/jim/ghc-6.8.2/libraries/rts/html"' \ -DHADDOCK_IFACE='"/home/jim/ghc-6.8.2/libraries/rts/html/rts.haddock"' \ -DFPTOOLS_TOP_ABS='"/home/jim/ghc-6.8.2"' \ -x c -DGMP_INCLUDE_DIRS='' -DGMP_LIB_DIRS='' -I../includes -Iinclude -DPACKAGE=rts -DVERSION= -DPKG_LIBDIR='"/usr/local/lib/ghc-6.8.2"' -DPKG_DATADIR='"/usr/local/share/ghc-6.8.2"' package.conf.in | \ grep -v '^#pragma GCC' | \ sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.inplace ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files Hi, It seems that GHC's API interface has changed between 6.6 and 6.8. Most notably, JustTypecheck and GHC.dropForAlls are no longer in scope. Are the changes documented anywhere? The notes on the hackage commentary still seem to point to the previous API internals. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API Kind regards, Chris. From valery.vv at gmail.com Mon Jan 14 10:41:20 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 14 10:34:50 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: <20080107164652.GB16760@scytale.galois.com> References: <20080107164652.GB16760@scytale.galois.com> Message-ID: > > valery.vv: > > > > [...] > > > > My quest is to install lambdabot (for the sake of offline `@hoogle' > > and `@pl' commands), and the one depends on `plugins'. > > > > [...] > > > > 2) it doesn't build with Cabal-1.3.2 > > ------------------------------------ > > > > [...] On 1/7/08, Don Stewart wrote: > Please start with the hs-plugins repo on code.haskell.org, since it's > already updated for ghc 6.8, > > http://code.haskell.org/~dons/code/hs-plugins/ Hi, I managed to install hs-plugins with ghc-6.9.20080104 (see attached .dpatch). Now I have two lambdabots to choose from. 1) Lambdabot from hackage: [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lambdabot-4.0] $ sed -n -e 7,8p -e 12,13p /home/vvv/src/lambdabot-4.0/lambdabot.cabal Name: lambdabot Version: 4.0 Maintainer: dons@cse.unsw.edu.au Build-Depends: base, unix, network, parsec, mtl, haskell-src, haskell98, readline, plugins>=1.0, fps>=0.7 2) Lambdabot from darcs [http://code.haskell.org/lambdabot]: $ sed -n -e 7,8p -e 12,15p /home/vvv/hsources/lambdabot/lambdabot.cabal Name: lambdabot Version: 4.0 Maintainer: dons@cse.unsw.edu.au Build-Depends: base, unix, network, parsec, mtl, haskell-src, readline, QuickCheck, arrows, regex-compat, regex-posix, zlib, binary>=0.2, plugins>=1.0, oeis Though the first one has fewer dependencies, it seems to be obsolete[1]. I'm going to install the one from darcs... 1. `fps' is the old name of `bytestring', am I right? [http://www.cse.unsw.edu.au/~dons/fps.html] Don, it looks wrong to have several lambdabot.cabal files with different dependencies sharing the same version number. And the one at HackageDB has [possibly] obsolete `fps' dependency. Thanks. -- vvv -------------- next part -------------- New patches: [make plugins build with ghc-6.9 (darcs version) "Valery V. Vorotyntsev" **20080114143447 + PackageAPI.hs (updImportDirs): `InstalledPackageInfo_' is the proper name + Load.hs: `PackageConfig' does not export `packageIdString', `Module' does + PackageAPI.hs, Load.hs: cleaned of trailing whitespace ] { hunk ./src/System/Plugins/Load.hs 4 --- +-- hunk ./src/System/Plugins/Load.hs 9 --- +-- hunk ./src/System/Plugins/Load.hs 14 --- +-- hunk ./src/System/Plugins/Load.hs 19 --- +-- hunk ./src/System/Plugins/Load.hs 34 - , pdynload + , pdynload hunk ./src/System/Plugins/Load.hs 72 -import Module (moduleName, moduleNameString) -import PackageConfig (packageIdString) +import Module (moduleName, moduleNameString, packageIdString) hunk ./src/System/Plugins/Load.hs 131 --- +-- hunk ./src/System/Plugins/Load.hs 166 - return $ case v of + return $ case v of hunk ./src/System/Plugins/Load.hs 186 -dynload :: Typeable a - => FilePath +dynload :: Typeable a + => FilePath hunk ./src/System/Plugins/Load.hs 219 -pdynload object incpaths pkgconfs ty sym = do +pdynload object incpaths pkgconfs ty sym = do hunk ./src/System/Plugins/Load.hs 227 - if null errors + if null errors hunk ./src/System/Plugins/Load.hs 251 - if null errors + if null errors hunk ./src/System/Plugins/Load.hs 272 - let nm = mkModid (basename tmpf) + let nm = mkModid (basename tmpf) hunk ./src/System/Plugins/Load.hs 294 -mkTest modnm plugin api ty sym = +mkTest modnm plugin api ty sym = hunk ./src/System/Plugins/Load.hs 309 - if ty == ty' + if ty == ty' hunk ./src/System/Plugins/Load.hs 313 - where + where hunk ./src/System/Plugins/Load.hs 330 -dynload2 :: Typeable a => - FilePath -> - FilePath -> +dynload2 :: Typeable a => + FilePath -> + FilePath -> hunk ./src/System/Plugins/Load.hs 334 - Symbol -> + Symbol -> hunk ./src/System/Plugins/Load.hs 384 - + hunk ./src/System/Plugins/Load.hs 390 - return $ case v of + return $ case v of hunk ./src/System/Plugins/Load.hs 471 --- +-- hunk ./src/System/Plugins/Load.hs 488 -loadObject p ky@(Object k) = loadObject' p ky k -loadObject p ky@(Package k) = loadObject' p ky k +loadObject p ky@(Object k) = loadObject' p ky k +loadObject p ky@(Package k) = loadObject' p ky k hunk ./src/System/Plugins/Load.hs 495 - | otherwise + | otherwise hunk ./src/System/Plugins/Load.hs 538 -unloadObj :: Module -> IO () +unloadObj :: Module -> IO () hunk ./src/System/Plugins/Load.hs 542 - when (removed) $ do r <- c_unloadObj c_p + when (removed) $ do r <- c_unloadObj c_p hunk ./src/System/Plugins/Load.hs 557 - if maybe_errmsg == nullPtr + if maybe_errmsg == nullPtr hunk ./src/System/Plugins/Load.hs 603 - r <- c_unloadObj c_p + r <- c_unloadObj c_p hunk ./src/System/Plugins/Load.hs 605 - rmModule (mkModid p) -- unrecord this module + rmModule (mkModid p) -- unrecord this module hunk ./src/System/Plugins/Load.hs 622 - + hunk ./src/System/Plugins/Load.hs 662 - let mods_ = map (\s -> (s, map (\c -> + let mods_ = map (\s -> (s, map (\c -> hunk ./src/System/Plugins/Load.hs 666 - let mods = concatMap (\p -> + let mods = concatMap (\p -> hunk ./src/System/Plugins/Load.hs 691 - when (not (null ps')) $ putStrLn "done" - putStr "Loading object" + when (not (null ps')) $ putStrLn "done" + putStr "Loading object" hunk ./src/System/Plugins/PackageAPI.hs 3 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 8 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 13 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 36 - , updLibraryDirs + , updLibraryDirs hunk ./src/System/Plugins/PackageAPI.hs 48 -packageName :: PackageConfig -> PackageName +packageName :: PackageConfig -> PackageName hunk ./src/System/Plugins/PackageAPI.hs 64 -updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = +updImportDirs f pk@(InstalledPackageInfo_ { importDirs = idirs }) = hunk ./src/System/Plugins/PackageAPI.hs 66 -updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = +updLibraryDirs f pk@(InstalledPackageInfo_ { libraryDirs = ldirs }) = hunk ./src/System/Plugins/PackageAPI.hs 74 -updImportDirs f pk@(Package {import_dirs = idirs}) +updImportDirs f pk@(Package {import_dirs = idirs}) hunk ./src/System/Plugins/PackageAPI.hs 77 -updLibraryDirs f pk@(Package {library_dirs = ldirs}) +updLibraryDirs f pk@(Package {library_dirs = ldirs}) } Context: [Cabal >= 1.2.3 Don Stewart **20071220022555] [TAG plugins 1.1 Don Stewart **20071216071026] Patch bundle hash: 53eceb5ae4bf510dddf9573adc1db28f35669774 From simonpj at microsoft.com Mon Jan 14 11:52:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 14 11:45:50 2008 Subject: GHC Internals Changed In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3144D737709@EA-EXMSG-C334.europe.corp.microsoft.com> Probably not, or at least not well. I'm afraid you'll just have to look at the new API and ask questions. Putting what you learn on the Wiki is a great service for others who walk the same path. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | C.M.Brown | Sent: 14 January 2008 13:29 | To: glasgow-haskell-users@haskell.org | Subject: GHC Internals Changed | | Hi, | | It seems that GHC's API interface has changed between 6.6 and 6.8. Most | notably, JustTypecheck and GHC.dropForAlls are no longer in scope. | | Are the changes documented anywhere? The notes on the hackage commentary | still seem to point to the previous API internals. | | http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API | | Kind regards, | Chris. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mdg at wanadoo.fr Mon Jan 14 16:01:49 2008 From: mdg at wanadoo.fr (Marcus D. Gabriel) Date: Mon Jan 14 15:55:09 2008 Subject: GHC Data.List.sort performance question Message-ID: <478BCDBD.2090302@wanadoo.fr> Hello, By a rather indirect route, I discovered that I obtain an almost factor of two improvement in performance in Data.List.sort if I make one small change in the implementation of the function merge which supports mergesort and hence sortBy and sort. Admittedly, the improvement was only noticeable to me when sorting for example one million random Int. The current code in libraries/base/Data/List.hs for merge is \begin{code} merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] merge cmp xs [] = xs merge cmp [] ys = ys merge cmp (x:xs) (y:ys) = case x `cmp` y of GT -> y : merge cmp (x:xs) ys _ -> x : merge cmp xs (y:ys) \end{code} and all that I did was \begin{code} merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] merge cmp [] ys = ys merge cmp xs [] = xs merge cmp (x:xs) (y:ys) = case x `cmp` y of GT -> y : merge cmp (x:xs) ys _ -> x : merge cmp xs (y:ys) \end{code} that is, I swapped the order of the first two lines. By the way, the second version is much less likely to overflow the stack than the first version. Can some confirm this? If you confirm it, can someone explain to me why one obtains this performance improvement? I currently just do not grasp the point. Thanks, - Marcus -- Marcus D. Gabriel, Ph.D. Email: mdg@wanadoo.fr 213 ter, rue de Mulhouse Tel: +33.3.89.69.05.06 F68300 Saint Louis FRANCE Portable: +33.6.34.56.07.75 From dons at galois.com Mon Jan 14 18:34:11 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 14 18:27:31 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <478BCDBD.2090302@wanadoo.fr> References: <478BCDBD.2090302@wanadoo.fr> Message-ID: <20080114233411.GC25718@scytale.galois.com> mdg: > Hello, > > By a rather indirect route, I discovered that I obtain an almost > factor of two improvement in performance in Data.List.sort if I make > one small change in the implementation of the function merge which > supports mergesort and hence sortBy and sort. Admittedly, the > improvement was only noticeable to me when sorting for example one > million random Int. The current code in libraries/base/Data/List.hs > for merge is > > \begin{code} > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > merge cmp xs [] = xs > merge cmp [] ys = ys > merge cmp (x:xs) (y:ys) > = case x `cmp` y of > GT -> y : merge cmp (x:xs) ys > _ -> x : merge cmp xs (y:ys) > > \end{code} > > and all that I did was > > \begin{code} > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > merge cmp [] ys = ys > merge cmp xs [] = xs > merge cmp (x:xs) (y:ys) > = case x `cmp` y of > GT -> y : merge cmp (x:xs) ys > _ -> x : merge cmp xs (y:ys) > > \end{code} > > that is, I swapped the order of the first two lines. By the way, the > second version is much less likely to overflow the stack than the > first version. > > Can some confirm this? If you confirm it, can someone explain to me > why one obtains this performance improvement? I currently just do not > grasp the point. > > Thanks, > - Marcus Ian, you looked at sort most recently. What to check the generated code (or rerun your benchmarks?) -- Don From simonpj at microsoft.com Tue Jan 15 10:43:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 15 10:36:34 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <478BCDBD.2090302@wanadoo.fr> References: <478BCDBD.2090302@wanadoo.fr> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C315A53A49BD@EA-EXMSG-C334.europe.corp.microsoft.com> Weird. I see no difference in the compiled code (GHC HEAD). Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Marcus D. Gabriel | Sent: 14 January 2008 21:02 | To: glasgow-haskell-users@haskell.org | Subject: GHC Data.List.sort performance question | | Hello, | | By a rather indirect route, I discovered that I obtain an almost | factor of two improvement in performance in Data.List.sort if I make | one small change in the implementation of the function merge which | supports mergesort and hence sortBy and sort. Admittedly, the | improvement was only noticeable to me when sorting for example one | million random Int. The current code in libraries/base/Data/List.hs | for merge is | | \begin{code} | | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] | merge cmp xs [] = xs | merge cmp [] ys = ys | merge cmp (x:xs) (y:ys) | = case x `cmp` y of | GT -> y : merge cmp (x:xs) ys | _ -> x : merge cmp xs (y:ys) | | \end{code} | | and all that I did was | | \begin{code} | | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] | merge cmp [] ys = ys | merge cmp xs [] = xs | merge cmp (x:xs) (y:ys) | = case x `cmp` y of | GT -> y : merge cmp (x:xs) ys | _ -> x : merge cmp xs (y:ys) | | \end{code} | | that is, I swapped the order of the first two lines. By the way, the | second version is much less likely to overflow the stack than the | first version. | | Can some confirm this? If you confirm it, can someone explain to me | why one obtains this performance improvement? I currently just do not | grasp the point. | | Thanks, | - Marcus | | -- | Marcus D. Gabriel, Ph.D. Email: mdg@wanadoo.fr | 213 ter, rue de Mulhouse Tel: +33.3.89.69.05.06 | F68300 Saint Louis FRANCE Portable: +33.6.34.56.07.75 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bertram.felgenhauer at googlemail.com Tue Jan 15 11:16:23 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue Jan 15 11:09:46 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <478BCDBD.2090302@wanadoo.fr> References: <478BCDBD.2090302@wanadoo.fr> Message-ID: <20080115161623.GA4269@zombie.inf.tu-dresden.de> Marcus D. Gabriel wrote: > By a rather indirect route, I discovered that I obtain an almost > factor of two improvement in performance in Data.List.sort if I make > one small change in the implementation of the function merge which > supports mergesort and hence sortBy and sort. Admittedly, the > improvement was only noticeable to me when sorting for example one > million random Int. The current code in libraries/base/Data/List.hs > for merge is > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > merge cmp xs [] = xs > merge cmp [] ys = ys [snip] > > and all that I did was > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > merge cmp [] ys = ys > merge cmp xs [] = xs [snip] > > that is, I swapped the order of the first two lines. By the way, the > second version is much less likely to overflow the stack than the > first version. > > Can some confirm this? If you confirm it, can someone explain to me > why one obtains this performance improvement? I currently just do not > grasp the point. I'm not sure why there is a performance difference, but there is one major difference in the behaviour of these two implementations: The library version evaluates the list from right to left (i.e. it compares the last two elements of the list first), because the third argument of 'merge' is forced before the second one. Swapping those two lines of 'merge' results in a version which compares the first two elements of the list first. This means that the library version produces a stack overflow on lists generated in an iterate like fashion (say, take 1000000 [0..]). The modified version produces a stack overflow on the reverse of that list, but I believe such lists are much rarer in practice. Did you look at the GC stats for the two sort implementations? Bertram From judah.jacobson at gmail.com Tue Jan 15 11:51:26 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 15 11:44:45 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <20080115161623.GA4269@zombie.inf.tu-dresden.de> References: <478BCDBD.2090302@wanadoo.fr> <20080115161623.GA4269@zombie.inf.tu-dresden.de> Message-ID: <6d74b0d20801150851u6da4bb6ekd745d5bc6780f0c0@mail.gmail.com> On Jan 15, 2008 8:16 AM, Bertram Felgenhauer wrote: > Marcus D. Gabriel wrote: > > By a rather indirect route, I discovered that I obtain an almost > > factor of two improvement in performance in Data.List.sort if I make > > one small change in the implementation of the function merge which > > supports mergesort and hence sortBy and sort. Admittedly, the > > improvement was only noticeable to me when sorting for example one > > million random Int. The current code in libraries/base/Data/List.hs > > for merge is > > > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > > merge cmp xs [] = xs > > merge cmp [] ys = ys > [snip] > > > > and all that I did was > > > > merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > > merge cmp [] ys = ys > > merge cmp xs [] = xs > [snip] > > > > that is, I swapped the order of the first two lines. By the way, the > > second version is much less likely to overflow the stack than the > > first version. > > > > Can some confirm this? If you confirm it, can someone explain to me > > why one obtains this performance improvement? I currently just do not > > grasp the point. > > I'm not sure why there is a performance difference, but there is > one major difference in the behaviour of these two implementations: > > The library version evaluates the list from right to left (i.e. it > compares the last two elements of the list first), because the third > argument of 'merge' is forced before the second one. > > Swapping those two lines of 'merge' results in a version which compares > the first two elements of the list first. > > This means that the library version produces a stack overflow on > lists generated in an iterate like fashion (say, take 1000000 [0..]). > The modified version produces a stack overflow on the reverse of > that list, but I believe such lists are much rarer in practice. > Bertram, are you sure that's right? There's already a stack overflow in "take 1000000 [0..]" itself (try just "last $ take 1000000 [0..]"). See the bug http://hackage.haskell.org/trac/ghc/ticket/1997 By using [0..1000000] (which doesn't trigger that bug), I can compute both of last $ sort [0..1000000] last $ sort $ reverse [0..1000000] without any stack overflows. (Using ghc-6.8.2) Best, -Judah From bertram.felgenhauer at googlemail.com Tue Jan 15 12:48:18 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue Jan 15 12:41:41 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <6d74b0d20801150851u6da4bb6ekd745d5bc6780f0c0@mail.gmail.com> References: <478BCDBD.2090302@wanadoo.fr> <20080115161623.GA4269@zombie.inf.tu-dresden.de> <6d74b0d20801150851u6da4bb6ekd745d5bc6780f0c0@mail.gmail.com> Message-ID: <20080115174818.GB4269@zombie.inf.tu-dresden.de> Judah Jacobson wrote: > > This means that the library version produces a stack overflow on > > lists generated in an iterate like fashion (say, take 1000000 [0..]). > > The modified version produces a stack overflow on the reverse of > > that list, but I believe such lists are much rarer in practice. > > Bertram, are you sure that's right? Yes. > There's already a stack overflow > in "take 1000000 [0..]" itself (try just "last $ take 1000000 [0..]"). > See the bug http://hackage.haskell.org/trac/ghc/ticket/1997 No, that's not quite right. The stack overflow happens on evaluating the last element of that list *without evaluating the previous elements first*. To wit, Prelude Data.List> foldl' (+) 0 $ take 1000000 [0..] 499999500000 Prelude Data.List> last $ take 1000000 [0..] *** Exception: stack overflow or Prelude> let t = take 1000000 [0..] Prelude> last t *** Exception: stack overflow Prelude> t !! 500000 500000 Prelude> last t 999999 Bertram From twanvl at gmail.com Tue Jan 15 16:57:14 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 15 16:50:21 2008 Subject: 'backslash' build problems on windows Message-ID: <478D2C3A.4040206@gmail.com> I am having some problems with the latest builds of GHC on windows. For some reason ghc has decided to use backslashes in filenames. This leads to problems when building the stage libraries and the stage 2 compiler. I run the scripts from a mingw bash shell. The following problems occur: - Warnings: .../ghc3228_0/ghc3228_0.lpp:1: warning: unknown escape sequence '\B' these are caused by the #line directive in the preprocessed file, something like #line 1 ".\basicTypes/BasicTypes.lhs" - When building the dependencies (in dist/build/.depend) become something like: dist/build\GHC/PrimopWrappers.o : .\GHC/PrimopWrappers.hs make then ignores these dependencies and tries to build the wrong files. - When testing, some unexpected failures occur, because the error message says ".\Something.hs" instead of "Something.hs". The solution to all these problems is to use a '/' instead of a '\'. I suspect the problem was caused by the patch: Sat Jan 12 18:28:37 W. Europe Standard Time 2008 Ian Lynagh * FilePath fixes Twan From mdg at wanadoo.fr Tue Jan 15 17:28:07 2008 From: mdg at wanadoo.fr (Marcus D. Gabriel) Date: Tue Jan 15 17:21:31 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <20080115161623.GA4269@zombie.inf.tu-dresden.de> References: <478BCDBD.2090302@wanadoo.fr> <20080115161623.GA4269@zombie.inf.tu-dresden.de> Message-ID: <478D3377.30203@wanadoo.fr> By the way, the comment about the stack was an aside for me. The enigma of the performance change is what I would like to understand. To be honest, it bothers me a little bit because I just did not expect it. Also to be frank, some one should check me since I found this out by accident later in the evening which means that you should not trust me too much. I do not believe that I am doing anything silly here; I just do not know. Bertram appears to be on to something, but the experiment below is what I observed. Only the random list for Data.List.sort overflows the default stack which makes sense given Bertram's argument but not has much too me given the sorted, reversed, and same element list below. The command sorting will run Data.List.sort on a list or sortX which is just Data.List.sort with these two aforementioned lines crossed. The random list is made from Random, the sorted list is [1..1000000], the reversed list is [1000000,999999..1], and the list of zeros is just take 1000000 $ repeat 0. % ./sorting --random sort 1000000 Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. % ./sorting --sorted sort 1000000 Length of sorted sorted list = 1000000 % ./sorting --reversed sort 1000000 Length of sorted reversed sorted list = 1000000 % ./sorting --same sort 1000000 Length of sorted list of zeros = 1000000 % ./sorting --random sortX 1000000 Length of sorted random list = 1000000 % ./sorting --sorted sortX 1000000 Length of sorted sorted list = 1000000 % ./sorting --reversed sortX 1000000 Length of sorted reversed sorted list = 1000000 % ./sorting --same sortX 1000000 Length of sorted list of zeros = 1000000 Here is the GC for the random case but only on 100000 Int to avoid the stack overflow. I do not know what to make of this. % ./sorting --random sort 100000 +RTS -sstderr Length of sorted random list = 100000 191,878,444 bytes allocated in the heap 111,808,176 bytes copied during GC (scavenged) 20,928,592 bytes copied during GC (not scavenged) 24,830,520 bytes maximum residency (8 sample(s)) 336 collections in generation 0 ( 0.61s) 8 collections in generation 1 ( 0.24s) 58 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.67s ( 0.66s elapsed) GC time 0.85s ( 0.91s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.52s ( 1.58s elapsed) %GC time 55.8% (57.9% elapsed) Alloc rate 285,514,704 bytes per MUT second Productivity 44.2% of total user, 42.5% of total elapsed % ./sorting --random sortX 100000 +RTS -sstderr Length of sorted random list = 100000 175,301,948 bytes allocated in the heap 100,767,660 bytes copied during GC (scavenged) 20,974,892 bytes copied during GC (not scavenged) 13,687,992 bytes maximum residency (13 sample(s)) 337 collections in generation 0 ( 0.41s) 13 collections in generation 1 ( 0.28s) 38 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.51s ( 0.55s elapsed) GC time 0.69s ( 0.69s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.21s ( 1.24s elapsed) %GC time 57.3% (55.8% elapsed) Alloc rate 339,713,364 bytes per MUT second Productivity 42.4% of total user, 41.3% of total elapsed And for the record, the times on my box: # Needs to be at least 50M for the -K option % time ./sorting --random sort 1000000 +RTS -K50M Length of sorted random list = 1000000 real 0m38.16s user 0m37.34s sys 0m0.61s % time ./sorting --random sortX 1000000 Length of sorted random list = 1000000 real 0m19.36s user 0m18.94s sys 0m0.37s Cheers, - Marcus Bertram Felgenhauer wrote: > Marcus D. Gabriel wrote: > >> By a rather indirect route, I discovered that I obtain an almost >> factor of two improvement in performance in Data.List.sort if I make >> one small change in the implementation of the function merge which >> supports mergesort and hence sortBy and sort. Admittedly, the >> improvement was only noticeable to me when sorting for example one >> million random Int. The current code in libraries/base/Data/List.hs >> for merge is >> >> merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] >> merge cmp xs [] = xs >> merge cmp [] ys = ys >> > [snip] > >> and all that I did was >> >> merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] >> merge cmp [] ys = ys >> merge cmp xs [] = xs >> > [snip] > >> that is, I swapped the order of the first two lines. By the way, the >> second version is much less likely to overflow the stack than the >> first version. >> >> Can some confirm this? If you confirm it, can someone explain to me >> why one obtains this performance improvement? I currently just do not >> grasp the point. >> > > I'm not sure why there is a performance difference, but there is > one major difference in the behaviour of these two implementations: > > The library version evaluates the list from right to left (i.e. it > compares the last two elements of the list first), because the third > argument of 'merge' is forced before the second one. > > Swapping those two lines of 'merge' results in a version which compares > the first two elements of the list first. > > This means that the library version produces a stack overflow on > lists generated in an iterate like fashion (say, take 1000000 [0..]). > The modified version produces a stack overflow on the reverse of > that list, but I believe such lists are much rarer in practice. > > Did you look at the GC stats for the two sort implementations? > > Bertram From twanvl at gmail.com Tue Jan 15 18:41:56 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 15 18:35:02 2008 Subject: FilePath causes problems (was: 'backslash' build problems on windows) In-Reply-To: <478D2C3A.4040206@gmail.com> References: <478D2C3A.4040206@gmail.com> Message-ID: <478D44C4.20207@gmail.com> Twan van Laarhoven wrote: > I am having some problems with the latest builds of GHC on windows. For > some reason ghc has decided to use backslashes in filenames. This leads > to problems when building the stage libraries and the stage 2 compiler. > I run the scripts from a mingw bash shell. After further investigation, it seems the problems are caused by using () instead of joinFileName. These functions differ in two ways: 1. "." as a directory name is no longer ignored "." "x" == "./x" /= "x" == "." `joinFileName` "x" this (among other things) changes compiler messages: -[1 of 4] Compiling OverA ( OverA.hs, OverA.o ) -[2 of 4] Compiling OverB ( OverB.hs, OverB.o ) -[3 of 4] Compiling OverC ( OverC.hs, OverC.o ) +[1 of 4] Compiling OverA ( .\OverA.hs, .\OverA.o ) +[2 of 4] Compiling OverB ( .\OverB.hs, .\OverB.o ) +[3 of 4] Compiling OverC ( .\OverC.hs, .\OverC.o ) 2. a backslash is used on windows instead of a slash. Some things explicitly exect a slash to be used on windows as well: a. main/DriverPipeline.hs:1511: -- We hackily use Option instead of FileOption here, so that the file -- name is not back-slashed on Windows. cpp is capable of -- dealing with / in filenames, so it works fine. Furthermore -- if we put in backslashes, cpp outputs #line directives -- with *double* backslashes. And that in turn means that -- our error messages get double backslashes in them. -- In due course we should arrange that the lexer deals -- with these \\ escapes properly. b. gnu make wants slashes, filenames containing backslashes are outputed through DriverMkDepend. 1 is a minor problem it just requires some test cases to be changed. On the other hand, adding "./" everywhere is needless clutter. 2a results in some warnings, 2b is a big problem, breaking the build on windows. The only good solution I see is to switch back to joinFileName or an equivalent function. Twan From ndmitchell at gmail.com Tue Jan 15 19:33:47 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 15 19:27:02 2008 Subject: FilePath causes problems (was: 'backslash' build problems on windows) In-Reply-To: <478D44C4.20207@gmail.com> References: <478D2C3A.4040206@gmail.com> <478D44C4.20207@gmail.com> Message-ID: <404396ef0801151633u6cc59ff0r8d18ab35d716bd35@mail.gmail.com> Hi > this (among other things) changes compiler messages: > -[1 of 4] Compiling OverA ( OverA.hs, OverA.o ) > -[2 of 4] Compiling OverB ( OverB.hs, OverB.o ) > -[3 of 4] Compiling OverC ( OverC.hs, OverC.o ) > +[1 of 4] Compiling OverA ( .\OverA.hs, .\OverA.o ) > +[2 of 4] Compiling OverB ( .\OverB.hs, .\OverB.o ) > +[3 of 4] Compiling OverC ( .\OverC.hs, .\OverC.o ) Before displaying a FilePath, it is advisable to call normalise on it, which will attempt to reformat it in a manner more pleasing to a human. This will fix that bug. > 2. a backslash is used on windows instead of a slash. Some things explicitly > exect a slash to be used on windows as well: I recommend a "reslash" command, invoked just before each of these actions. This way its explicitly clear exactly where slash directions matters. Thanks Neil From bjpop at csse.unimelb.edu.au Tue Jan 15 20:40:10 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Tue Jan 15 20:27:53 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C315A53A49BD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <478BCDBD.2090302@wanadoo.fr> <638ABD0A29C8884A91BC5FB5C349B1C315A53A49BD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <859D1327-681B-428C-8D81-553CB1F57B79@csse.unimelb.edu.au> Hi all, I was looking into this issue as well, by coincidence. I haven't figured out what is wrong, but I believe Hugs (September 2006) exhibits similar behaviour, so it is not just GHC. I also noticed that in the third equation of merge_pairs, swapping the order of the arguments to merge also avoids the stack overflow: Original third equation: merge_pairs cmp (xs:ys:xss) = merge cmp xs ys : merge_pairs cmp xss Swapped version: merge_pairs cmp (xs:ys:xss) = merge cmp ys xs : merge_pairs cmp xss ^^^^^ And for reference, here is how I was testing it: main = do args <- getArgs let size = (read $ head args) :: Int main' size main' size = do gen <- getStdGen let rs = (randoms gen) :: [Int] let list = take size rs print $ length list print $ sort list I'm keen to find out what is going on here. Cheers, Bernie. On 16/01/2008, at 2:43 AM, Simon Peyton-Jones wrote: > Weird. I see no difference in the compiled code (GHC HEAD). > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > haskell-users-bounces@haskell.org] On Behalf Of > | Marcus D. Gabriel > | Sent: 14 January 2008 21:02 > | To: glasgow-haskell-users@haskell.org > | Subject: GHC Data.List.sort performance question > | > | Hello, > | > | By a rather indirect route, I discovered that I obtain an almost > | factor of two improvement in performance in Data.List.sort if I make > | one small change in the implementation of the function merge which > | supports mergesort and hence sortBy and sort. Admittedly, the > | improvement was only noticeable to me when sorting for example one > | million random Int. The current code in libraries/base/Data/List.hs > | for merge is > | > | \begin{code} > | > | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > | merge cmp xs [] = xs > | merge cmp [] ys = ys > | merge cmp (x:xs) (y:ys) > | = case x `cmp` y of > | GT -> y : merge cmp (x:xs) ys > | _ -> x : merge cmp xs (y:ys) > | > | \end{code} > | > | and all that I did was > | > | \begin{code} > | > | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > | merge cmp [] ys = ys > | merge cmp xs [] = xs > | merge cmp (x:xs) (y:ys) > | = case x `cmp` y of > | GT -> y : merge cmp (x:xs) ys > | _ -> x : merge cmp xs (y:ys) > | > | \end{code} > | > | that is, I swapped the order of the first two lines. By the way, > the > | second version is much less likely to overflow the stack than the > | first version. > | > | Can some confirm this? If you confirm it, can someone explain to me > | why one obtains this performance improvement? I currently just > do not > | grasp the point. > | > | Thanks, > | - Marcus > | > | -- > | Marcus D. Gabriel, Ph.D. Email: > mdg@wanadoo.fr > | 213 ter, rue de Mulhouse Tel: > +33.3.89.69.05.06 > | F68300 Saint Louis FRANCE Portable: > +33.6.34.56.07.75 > | > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Tue Jan 15 22:10:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 15 22:03:33 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <478BCDBD.2090302@wanadoo.fr> References: <478BCDBD.2090302@wanadoo.fr> Message-ID: <20080116031018.GA4440@matrix.chaos.earth.li> Hi Marcus, On Mon, Jan 14, 2008 at 10:01:49PM +0100, Marcus D. Gabriel wrote: > > code in libraries/base/Data/List.hs > for merge is > > merge cmp xs [] = xs > merge cmp [] ys = ys > > merge cmp [] ys = ys > merge cmp xs [] = xs This actually came up a while ago, in this thread: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/30598 I've just applied Bertram's patch from http://www.haskell.org/pipermail/libraries/2007-November/008621.html which makes the change you suggest. Thanks Ian From igloo at earth.li Tue Jan 15 22:14:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 15 22:07:39 2008 Subject: 'backslash' build problems on windows In-Reply-To: <478D2C3A.4040206@gmail.com> References: <478D2C3A.4040206@gmail.com> Message-ID: <20080116031424.GB4440@matrix.chaos.earth.li> On Tue, Jan 15, 2008 at 10:57:14PM +0100, Twan van Laarhoven wrote: > I am having some problems with the latest builds of GHC on windows. Hmm, I thought I'd tested those patches on Windows, but I guess I was mistaken. Thanks for the info, I'll take a look. Sorry for any inconvenience caused! Thanks Ian From bjpop at csse.unimelb.edu.au Wed Jan 16 00:02:05 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Tue Jan 15 23:49:49 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <859D1327-681B-428C-8D81-553CB1F57B79@csse.unimelb.edu.au> References: <478BCDBD.2090302@wanadoo.fr> <638ABD0A29C8884A91BC5FB5C349B1C315A53A49BD@EA-EXMSG-C334.europe.corp.microsoft.com> <859D1327-681B-428C-8D81-553CB1F57B79@csse.unimelb.edu.au> Message-ID: Hi again, Please ignore my last post. I just realised that the problem was in the way I was testing sort. I printed the length of the list out to make sure the spine was evaluated, but the problem is that the elements of the list are thunks which depend on each other in a left-right manner, the rightmost ones becoming very big. It is effectively the same issue as: sort $ take x [1..] that Bertram Felgenhauer identified much earlier. Apologies for the noise. Cheers, Bernie. On 16/01/2008, at 12:40 PM, Bernie Pope wrote: > Hi all, > > I was looking into this issue as well, by coincidence. > > I haven't figured out what is wrong, but I believe Hugs (September > 2006) exhibits similar behaviour, so it is not just GHC. > > I also noticed that in the third equation of merge_pairs, swapping > the order of the arguments to merge also avoids the stack overflow: > > Original third equation: > > merge_pairs cmp (xs:ys:xss) > = merge cmp xs ys : merge_pairs cmp xss > > Swapped version: > > merge_pairs cmp (xs:ys:xss) > = merge cmp ys xs : merge_pairs cmp xss > ^^^^^ > > And for reference, here is how I was testing it: > > main = do > args <- getArgs > let size = (read $ head args) :: Int > main' size > > main' size = do > gen <- getStdGen > let rs = (randoms gen) :: [Int] > let list = take size rs > print $ length list > print $ sort list > > I'm keen to find out what is going on here. > > Cheers, > Bernie. > > On 16/01/2008, at 2:43 AM, Simon Peyton-Jones wrote: > >> Weird. I see no difference in the compiled code (GHC HEAD). >> >> Simon >> >> | -----Original Message----- >> | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- >> haskell-users-bounces@haskell.org] On Behalf Of >> | Marcus D. Gabriel >> | Sent: 14 January 2008 21:02 >> | To: glasgow-haskell-users@haskell.org >> | Subject: GHC Data.List.sort performance question >> | >> | Hello, >> | >> | By a rather indirect route, I discovered that I obtain an almost >> | factor of two improvement in performance in Data.List.sort if I >> make >> | one small change in the implementation of the function merge which >> | supports mergesort and hence sortBy and sort. Admittedly, the >> | improvement was only noticeable to me when sorting for example one >> | million random Int. The current code in libraries/base/Data/ >> List.hs >> | for merge is >> | >> | \begin{code} >> | >> | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] >> | merge cmp xs [] = xs >> | merge cmp [] ys = ys >> | merge cmp (x:xs) (y:ys) >> | = case x `cmp` y of >> | GT -> y : merge cmp (x:xs) ys >> | _ -> x : merge cmp xs (y:ys) >> | >> | \end{code} >> | >> | and all that I did was >> | >> | \begin{code} >> | >> | merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a] >> | merge cmp [] ys = ys >> | merge cmp xs [] = xs >> | merge cmp (x:xs) (y:ys) >> | = case x `cmp` y of >> | GT -> y : merge cmp (x:xs) ys >> | _ -> x : merge cmp xs (y:ys) >> | >> | \end{code} >> | >> | that is, I swapped the order of the first two lines. By the >> way, the >> | second version is much less likely to overflow the stack than the >> | first version. >> | >> | Can some confirm this? If you confirm it, can someone explain >> to me >> | why one obtains this performance improvement? I currently just >> do not >> | grasp the point. >> | >> | Thanks, >> | - Marcus >> | >> | -- >> | Marcus D. Gabriel, Ph.D. Email: >> mdg@wanadoo.fr >> | 213 ter, rue de Mulhouse Tel: >> +33.3.89.69.05.06 >> | F68300 Saint Louis FRANCE Portable: >> +33.6.34.56.07.75 >> | >> | >> | _______________________________________________ >> | Glasgow-haskell-users mailing list >> | Glasgow-haskell-users@haskell.org >> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mdg at wanadoo.fr Wed Jan 16 12:51:22 2008 From: mdg at wanadoo.fr (Marcus D. Gabriel) Date: Wed Jan 16 12:44:35 2008 Subject: GHC Data.List.sort performance question In-Reply-To: <20080116031018.GA4440@matrix.chaos.earth.li> References: <478BCDBD.2090302@wanadoo.fr> <20080116031018.GA4440@matrix.chaos.earth.li> Message-ID: <478E441A.1080802@wanadoo.fr> Hello Ian, Thank you for the two links to the previous threads, I glanced at them and will read them more carefully later so that I can understand the point a little better. Sorry about the duplicate thread relative to the Haskell Cafe. Thanks also for applying Bertram's patch. Cheers, - Marcus Ian Lynagh wrote: > Hi Marcus, > > On Mon, Jan 14, 2008 at 10:01:49PM +0100, Marcus D. Gabriel wrote: > >> code in libraries/base/Data/List.hs >> for merge is >> >> merge cmp xs [] = xs >> merge cmp [] ys = ys >> >> merge cmp [] ys = ys >> merge cmp xs [] = xs >> > > This actually came up a while ago, in this thread: > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/30598 > > I've just applied Bertram's patch from > http://www.haskell.org/pipermail/libraries/2007-November/008621.html > which makes the change you suggest. > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -- Marcus D. Gabriel, Ph.D. Email: mdg@wanadoo.fr 213 ter, rue de Mulhouse Tel: +33.3.89.69.05.06 F68300 Saint Louis FRANCE Portable: +33.6.34.56.07.75 From judah.jacobson at gmail.com Wed Jan 16 16:05:12 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jan 16 15:58:35 2008 Subject: Integrating editline with ghc Message-ID: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah From chak at cse.unsw.edu.au Wed Jan 16 23:24:49 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jan 16 23:18:08 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <200801100924.19306.naur@post11.tele.dk> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> Message-ID: <1D74E417-6A9B-4772-9277-ED070DBE39EB@cse.unsw.edu.au> Thorkil Naur: > Hello, > > On Tuesday 08 January 2008 15:07, Christian Maeder wrote: >> Hi, >> >> I've succeeded in building a binary distribution that uses static >> libraries for gmp and readline. libreadline.a, libncurses.a and >> libgmp.a >> with corresponding header files are included. (For license issues ask >> someone else.) > > On http://gmplib.org/ we find: > > "GMP is distributed under the GNU LGPL. This license makes the > library free to > use, share, and improve, and allows you to pass on the result. The > license > gives freedoms, but also sets firm restrictions on the use with non- > free > programs." > > I have not attempted to check whether your distribution fulfills the > requirements of the LGPL. It does fullfil them. The source code of all components of the system is available enabling users to build the same software with a different version of GMP. That's all that the LGPL requires of software linked against a LGPL library. > > Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: > > "Readline is free software, distributed under the terms of the GNU > General > Public License, version 2. This means that if you want to use > Readline in a > program that you release or distribute to anyone, the program must > be free > software and have a GPL-compatible license." > > For your distribution to adhere to this, it appears to require GHC > to have a > GPL-compatible license. I don't believe it does. It does. GHC's codebase is a mix of BSD3, LGLP, and GPL. They are perfectly compatible. See . Manuel From chak at cse.unsw.edu.au Wed Jan 16 23:49:00 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jan 16 23:42:22 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <1645551675.20080110132124@gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> Message-ID: Bulat Ziganshin: > for me, GMP is much more problematic issue. strictly speaking, we > can't say that GHC is BSD-licensed because it includes LGPL-licensed > code (and that much worse, it includes this code in run-time libs) Of course, GHC is BSD3 licensed. It includes the GMP code as part of its tar ball to save people from the hassle to separately install GMP on platforms that don't have it by default (ie, essentially all non- Linux OSes). That doesn't change the license of GHC at all. It is a mere aggregation of different projects. Even binary distributions of GHC that include libgmp.a and statically link it into compiled code are not a problem. You may even use such GHC distributions to compile proprietary code and distribute it. All that is needed to make this legal is to (a) properly acknowledge the use of GMP in the code and (b) give users access to another version of the proprietary program that links GMP dynamically. Point (b) is sufficient to comply with Section 4(d) of the LGPL, which requires you to enable users to swap one version of GMP for another in a program that uses GMP. Manuel From chak at cse.unsw.edu.au Wed Jan 16 23:54:51 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jan 16 23:48:04 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Message-ID: Judah Jacobson: > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) > - Use the editline package instead of readline when building ghc > stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. Sounds good to me. > Also, should editline be made a boot-package or an extra-package (or > neither)? Given that we like this to be the default on some platforms, I believe it belongs into boot-packages (just like readline). Manuel From naur at post11.tele.dk Thu Jan 17 00:03:12 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Jan 16 23:57:36 2008 Subject: Integrating editline with ghc In-Reply-To: <20080116210542.FMQB5833.fep27.mail.dk@www.haskell.org> References: <20080116210542.FMQB5833.fep27.mail.dk@www.haskell.org> Message-ID: <200801170603.13317.naur@post11.tele.dk> Hello, On Wednesday 16 January 2008 22:05, Judah Jacobson wrote: > Hi all, > > I have managed to build ghc using the initial release of the editline package: > > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). Excellent! > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) That's the way. > - Use the editline package instead of readline when building ghc stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. An alternative that would make the GHC configure script more symmetric with respect to command line editor would be to have --with-line-editor=editline, --with-line-editor=readline and also, perhaps, --with-line-editor=none (or even --with-line-editor=). All of these with, hopefully, obvious meanings. On top of this, one could have --with-edit-line=automatic with some automatic selection taking place. And the default? I'm sure that my favorite --with-line-editor=none will not be considered practical, so I will leave this most difficult choice to others. > > Also, should editline be made a boot-package or an extra-package (or neither)? > > Thanks, > -Judah > ... Thanks a lot again. Best regards Thorkil From Christian.Maeder at dfki.de Thu Jan 17 04:19:52 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 04:13:08 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Message-ID: <478F1DB8.1080807@dfki.de> Judah Jacobson wrote: > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). I would like to see a restructuring of the old readline package: 1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications. 2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name! Cheers Christian From gale at sefer.org Thu Jan 17 08:08:12 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 08:01:27 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Christian Maeder wrote: > The extended packages "2" could go under extra libs or hackageDB, while > "1" remains a boot package for ghc that can link to editline on macs > and readline under linux, but has the same interface and package name! I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline. -Yitz From isaacdupree at charter.net Thu Jan 17 08:27:20 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 08:20:27 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <478F57B8.8060806@charter.net> Yitzchak Gale wrote: > Christian Maeder wrote: >> The extended packages "2" could go under extra libs or hackageDB, while >> "1" remains a boot package for ghc that can link to editline on macs >> and readline under linux, but has the same interface and package name! > > I would hope that ghc will link to editline-ext on all platforms. > That gives ghc the functionality it needs without getting > into legal trouble with the license. Then those who want the full > readline interface can install readline-ext, and those who > want the full editline interface can install editline. GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"? ~Isaac From Christian.Maeder at dfki.de Thu Jan 17 09:00:48 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 08:54:02 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <478F5F90.1030804@dfki.de> Yitzchak Gale wrote: > Christian Maeder wrote: >> The extended packages "2" could go under extra libs or hackageDB, while >> "1" remains a boot package for ghc that can link to editline on macs >> and readline under linux, but has the same interface and package name! > > I would hope that ghc will link to editline-ext on all platforms. > That gives ghc the functionality it needs without getting > into legal trouble with the license. Then those who want the full > readline interface can install readline-ext, and those who > want the full editline interface can install editline. Just to clarify: ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed). The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments). Also editline-ext should only be used rarely, because some installation will still only have "libreadline". The new haskell package "readline" will only contain the common functionality of libedit and libreadline! The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline) Christian From gale at sefer.org Thu Jan 17 11:10:54 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 11:10:56 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> Message-ID: <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> Bulat Ziganshin wrote: >> for me, GMP is much more problematic issue. strictly speaking, we >> can't say that GHC is BSD-licensed because it includes LGPL-licensed >> code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: > ..binary distributions of GHC that include libgmp.a and statically > link it into compiled code... All > that is needed to make this legal is to (a)... > (b) give users access to another version of > the proprietary program that links GMP dynamically. Wow, I didn't realize that. Now I understand Bulat. In a project of any serious size and complexity, the use of static or dynamic linking is often architechted in and cannot be changed. So LGPL is really bad for a general purpose compiler like GHC. We've got to make GMP optional, or get rid of it. -Yitz From gale at sefer.org Thu Jan 17 11:52:34 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 11:52:41 2008 Subject: Integrating editline with ghc In-Reply-To: <478F57B8.8060806@charter.net> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F57B8.8060806@charter.net> Message-ID: <2608b8a80801170852u388fce28vea5af7eb6b6ba628@mail.gmail.com> Isaac Dupree wrote: > GHC is in no legal trouble whatsoever... only if proprietary Haskell > code uses the readline library and doesn't switch to using the editline > backend. Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble. > On Linux here I have readline installed and not editline > currently, so it seems silly to require installing editline by default > ("default" meaning "if I don't want to, I have to figure out the right > configure flag to give to allow readline to be used"). It makes sense > to use editline by default for Mac and Windows builds though, where > readline isn't native, I guess. Statically linking to editline for > binary builds would be alright (not exporting any readline to > ghc-compiled programs by default?). How is "Search for editline first; > if not found, try to use readline"? Yes, I also have a Debian box, and I agree. Regards, Yitz From Christian.Maeder at dfki.de Thu Jan 17 11:57:14 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 11:57:16 2008 Subject: gmp Message-ID: <478F88EA.6020206@dfki.de> I understand that gmp is needed for the certain libraries like the Prelude with Double and Integer. But I do not understand why gmp is so deeply buried in the rts. Are the basic types Int and Pointer not enough to write a compiler like ghc? Cheers Christian From dons at galois.com Thu Jan 17 12:00:48 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 12:01:04 2008 Subject: gmp In-Reply-To: <478F88EA.6020206@dfki.de> References: <478F88EA.6020206@dfki.de> Message-ID: <20080117170048.GD10397@scytale.galois.com> Christian.Maeder: > I understand that gmp is needed for the certain libraries like the > Prelude with Double and Integer. > > But I do not understand why gmp is so deeply buried in the rts. > Are the basic types Int and Pointer not enough to write a compiler like ghc? Integer is a good type :) However, its buried in the rts/distributed with the runtime, so that users may optionally use that version, rather than finding and installing their own external gmp package. On almost all platforms though, the distributed-with-ghc gmp is unused. -- Don From isaacdupree at charter.net Thu Jan 17 12:05:56 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 12:05:54 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> Message-ID: <478F8AF4.6060700@charter.net> Yitzchak Gale wrote: > Bulat Ziganshin wrote: >>> for me, GMP is much more problematic issue. strictly speaking, we >>> can't say that GHC is BSD-licensed because it includes LGPL-licensed >>> code (and that much worse, it includes this code in run-time libs) > > Manuel M T Chakravarty wrote: >> ..binary distributions of GHC that include libgmp.a and statically >> link it into compiled code... All >> that is needed to make this legal is to (a)... >> (b) give users access to another version of >> the proprietary program that links GMP dynamically. > > Wow, I didn't realize that. Now I understand Bulat. In a > project of any serious size and complexity, the use > of static or dynamic linking is often architechted in and > cannot be changed. (b) is a sufficient condition, but not necessary; there are other ways to satisfy the license. It's also possible to just distribute, for example, the .o file(s) and a way to link them with a GMP to get the final result; this doesn't even reveal your source-code any more than your program being dynamically linked, at least if you do it right -- right? ~Isaac From bulat.ziganshin at gmail.com Thu Jan 17 06:55:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 17 12:18:54 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> Message-ID: <858221673.20080117145556@gmail.com> Hello Manuel, Thursday, January 17, 2008, 7:49:00 AM, you wrote: >> for me, GMP is much more problematic issue. strictly speaking, we >> can't say that GHC is BSD-licensed because it includes LGPL-licensed >> code (and that much worse, it includes this code in run-time libs) > use of GMP in the code and (b) give users access to another version of > the proprietary program that links GMP dynamically. Point (b) is > sufficient to comply with Section 4(d) of the LGPL, which requires you > to enable users to swap one version of GMP for another in a program > that uses GMP. how can i provide version of my ghc-compiled program that links GMP dynamically? especially on windows? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Thu Jan 17 12:20:30 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 12:20:37 2008 Subject: Integrating editline with ghc In-Reply-To: <478F5F90.1030804@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F5F90.1030804@dfki.de> Message-ID: <2608b8a80801170920g5c537aebi66616fcd312a310e@mail.gmail.com> Christian Maeder wrote: > ghc will link to "libedit" if it is available on your platform, but the > Haskell package will still have the name "readline" and give ghc all the > functionality it needs (without licence problems). > Only the current readline Haskell package needs "libreadline" and > supplies more functionality than needed by ghc. This extra-functionality > should go into a new Haskell package readline-ext (that will only be > rarely needed). That is one possible solution for GHC. The problem is that the readline package currently provides System.Console.Readline with the full interface to readline. It has been that way for eons, so we must assume that there is software out there that uses all of it, even though ghc only uses part of it. We don't want to break those programs, and that includes creating a situation where the programs will no longer compile unless the user installs some new package with a different name. So I think the package named "readline" needs to continue to provide both the interface and the implementation for full readline. However, if needed, it can provide some or all of the pieces vacuously by simply depending on some new packages. On the other hand, GHC should depend only on a subset of readline that can optionally be provided by editline instead. And in fact, editline should be preferred over readline when available. There should be a smooth upgrade path to the new system for all users, both of GHC and the readline, for any combination of versions installed of any of those things. Everything should happen automatically as people gradually upgrade GHC and/or various readline-like packages to new versions. Can we meet all of those goals? Thanks, Yitz From judah.jacobson at gmail.com Thu Jan 17 12:22:06 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jan 17 12:22:11 2008 Subject: Integrating editline with ghc In-Reply-To: <478F5F90.1030804@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F5F90.1030804@dfki.de> Message-ID: <6d74b0d20801170922u2e1122a8k94d0186c04364efe@mail.gmail.com> On Jan 17, 2008 6:00 AM, Christian Maeder wrote: > > Yitzchak Gale wrote: > > Christian Maeder wrote: > >> The extended packages "2" could go under extra libs or hackageDB, while > >> "1" remains a boot package for ghc that can link to editline on macs > >> and readline under linux, but has the same interface and package name! > > > > I would hope that ghc will link to editline-ext on all platforms. > > That gives ghc the functionality it needs without getting > > into legal trouble with the license. Then those who want the full > > readline interface can install readline-ext, and those who > > want the full editline interface can install editline. > > Just to clarify: > > ghc will link to "libedit" if it is available on your platform, but the > Haskell package will still have the name "readline" and give ghc all the > functionality it needs (without licence problems). > > Only the current readline Haskell package needs "libreadline" and > supplies more functionality than needed by ghc. This extra-functionality > should go into a new Haskell package readline-ext (that will only be > rarely needed). > > The haskell package "editline-ext" is just an add-on that _requires_ > "libedit" (an is only needed for special future developments). > > Also editline-ext should only be used rarely, because some installation > will still only have "libreadline". > > The new haskell package "readline" will only contain the common > functionality of libedit and libreadline! > > The new haskell package "readline" should not be renamed in order to > achieve best backward compatibility in most cases. Renaming it (i.e. to > "editline") would not change the possibility to either link to libedit > _or_ libreadline (but would require to change all packages that > currently use readline) This sounds fine, except I don't think that we should have a package editline-ext. A readline API is either in both libedit and libreadline (in which case it should be in the readline package), or it is only in libreadline (in which case it should be in readline-ext). The functions in System.Console.Editline are unrelated to the readline APIs; I think that they should just go in a package called "editline". -Judah From fmartini at gmail.com Thu Jan 17 12:24:16 2008 From: fmartini at gmail.com (Felix Martini) Date: Thu Jan 17 12:24:20 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <6c0416190801170924r23e6fa8ci45026bf0dd5dbde3@mail.gmail.com> On Jan 17, 2008 2:08 PM, Yitzchak Gale wrote: > I would hope that ghc will link to editline-ext on all platforms. Unfortunately it seems that editline cannot currently be build on Windows. I have tried to build the editline source from http://www.thrysoee.dk/editline/ with MinGW/msys. Pdcurses could be used instead of ncurses, but it also requires termios.h which MinGW does not have. From gale at sefer.org Thu Jan 17 12:28:44 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 12:28:46 2008 Subject: gmp In-Reply-To: <20080117170048.GD10397@scytale.galois.com> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> Message-ID: <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> Don Stewart wrote: > However, its buried in the rts/distributed with the runtime, so that > users may optionally use that version, rather than finding and > installing their own external gmp package. On almost all platforms > though, the distributed-with-ghc gmp is unused. But doesn't that mean that it gets linked into any program compiled with ghc? If so, that is not a good choice for a just-in-case mp lib. -Yitz From phercek at gmail.com Thu Jan 17 12:36:34 2008 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 17 12:40:06 2008 Subject: gmp In-Reply-To: <478F88EA.6020206@dfki.de> References: <478F88EA.6020206@dfki.de> Message-ID: Christian Maeder wrote: > I understand that gmp is needed for the certain libraries like the > Prelude with Double and Integer. Why is GMP needed for Double? Based on the online report Double is "double precision floating"; it does not need to represent arbitrary big numbers. I thought it is there only for Integers and Rationals. Peter. From alex at blackkettle.org Thu Jan 17 12:43:12 2008 From: alex at blackkettle.org (Alex Young) Date: Thu Jan 17 12:43:15 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170852u388fce28vea5af7eb6b6ba628@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F57B8.8060806@charter.net> <2608b8a80801170852u388fce28vea5af7eb6b6ba628@mail.gmail.com> Message-ID: <478F93B0.9070104@blackkettle.org> Yitzchak Gale wrote: > Isaac Dupree wrote: >> GHC is in no legal trouble whatsoever... only if proprietary Haskell >> code uses the readline library and doesn't switch to using the editline >> backend. > > Agreed. I didn't mean that GHC itself was ever in any > legal trouble. But as a compiler, it must be possible for > users to compile with it without getting into legal trouble. Yes. I'm still learning Haskell, and it's my intention to use GHC to produce commercial plugins for an application on Windows (and possibly OS X, haven't decided yet). This whole discussion makes me worry - not because I have any intention to break any licences, but because I might do so by accident. At this point in my learning, I've got no idea what will cause "problem packages" (problems from my point of view being ones that cause a phone call to a lawyer) to be linked in to my binaries. It would be enormously helpful if there was a wiki page somewhere that said "To use GHC/mingw as a compiler for commercial software, it's likely you want to avoid these modules and command-line flags" or alternatively "To guarantee that no LGPL or GPL libraries are linked, use these flags". The last thing I want is to cause myself extra work when someone chucks my plugin through a hex editor, sees a whole load of GMP symbols (for example) and demands some form of compliance that commercially I'd rather avoid. -- Alex From gale at sefer.org Thu Jan 17 13:13:31 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 13:13:34 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <478F8AF4.6060700@charter.net> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> <478F8AF4.6060700@charter.net> Message-ID: <2608b8a80801171013s6bd3dd42r9fb6d3b637ae52b8@mail.gmail.com> Isaac Dupree wrote: > It's also possible to just distribute, for > example, the .o file(s) and a way to link them with a GMP to get the > final result; this doesn't even reveal your source-code any more than > your program being dynamically linked, at least if you do it right -- right? It doesn't matter. In a typical commercial development environment, you just don't have any control over that. At some companies I've gotten free software included in products in a way that required certain extra files from the 3rd party to be included inside our installation package - such as a source code tarball, GNU license, and such. It wasn't easy, but I've done it. But to change the way our own code is distributed - forget it. If you happen to be in a situation where the LGPL thing can be integrated as a dynamic library, fine. Otherwise, I don't see it. -Yitz From dons at galois.com Thu Jan 17 13:14:57 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 13:15:14 2008 Subject: gmp In-Reply-To: <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> Message-ID: <20080117181457.GA10636@scytale.galois.com> gale: > Don Stewart wrote: > > However, its buried in the rts/distributed with the runtime, so that > > users may optionally use that version, rather than finding and > > installing their own external gmp package. On almost all platforms > > though, the distributed-with-ghc gmp is unused. > > But doesn't that mean that it gets linked into any program > compiled with ghc? If so, that is not a good choice for > a just-in-case mp lib. only on systems that, when ghc was built, there was no libgmp available. on any system where an external libgmp is available, it will be dynamically linked into the generated haskell programs, and in-tree gmp isn't used at all (or compiled, or installed) e.g $ ldd `which xmonad` /home/dons/bin/xmonad: Start End Type Open Ref GrpRef Name 0000000048cc0000 00000000490e3000 rlib 0 1 0 /usr/lib/libpthread.so.8.0 0000000050424000 000000005083d000 rlib 0 1 0 /usr/lib/libm.so.2.3 0000000042a92000 0000000042ece000 rlib 0 1 0 /usr/local/lib/libgmp.so.7.0 000000004e3f2000 000000004e8c4000 rlib 0 1 0 /usr/lib/libc.so.42.0 -- Don From dons at galois.com Thu Jan 17 13:15:19 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 13:15:31 2008 Subject: gmp In-Reply-To: References: <478F88EA.6020206@dfki.de> Message-ID: <20080117181519.GB10636@scytale.galois.com> phercek: > Christian Maeder wrote: > >I understand that gmp is needed for the certain libraries like the > >Prelude with Double and Integer. > > Why is GMP needed for Double? Based on the online report Double is > "double precision floating"; it does not need to represent arbitrary > big numbers. > I thought it is there only for Integers and Rationals. > It isn't needed for Double. Double is a native type. From gale at sefer.org Thu Jan 17 13:48:59 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 13:49:03 2008 Subject: gmp In-Reply-To: <20080117181457.GA10636@scytale.galois.com> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> <20080117181457.GA10636@scytale.galois.com> Message-ID: <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> Don Stewart wrote: > on any system where an external libgmp is available, it will > be dynamically linked into the generated haskell programs, > and in-tree gmp isn't used at all (or compiled, or installed) So on linux and *bsd, that should be fine. On Mac OS X (as a special case of *bsd), we have that framework thing. It is a real pain, and it also requires the framework on any client machine where you install your ghc-compiled binary. OK for the time being, but it would be really, really good to be able to compile ghc without gmp. This idea of a Mac OS X binary with statically-linked gmp is nice, it is really convenient. But someone needs to completely clarify the license issues in that case, and make it completely clear to all users. What is the situation on Windows? Does the standard GHC binary on Windows have dynamically linked gmp for binaries produced by ghc? Thanks, Yitz From bulat.ziganshin at gmail.com Thu Jan 17 13:01:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 17 14:48:26 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <478F8AF4.6060700@charter.net> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> <478F8AF4.6060700@charter.net> Message-ID: <736074563.20080117210117@gmail.com> Hello Isaac, Thursday, January 17, 2008, 8:05:56 PM, you wrote: > (b) is a sufficient condition, but not necessary; there are other ways > to satisfy the license. It's also possible to just distribute, for > example, the .o file(s) and a way to link them with a GMP to get the > final result; this doesn't even reveal your source-code any more than > your program being dynamically linked, at least if you do it right -- right? so, any commercial (closed-source) software written using GHC should be also provided in form of object files which can be linked with GMP to produce working executable -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Jan 17 13:01:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 17 14:48:31 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> Message-ID: <476157691.20080117210139@gmail.com> Hello Yitzchak, Thursday, January 17, 2008, 7:10:54 PM, you wrote: > Wow, I didn't realize that. Now I understand Bulat. In a > project of any serious size and complexity, the use > of static or dynamic linking is often architechted in and > cannot be changed. So LGPL is really bad for a general > purpose compiler like GHC. We've got to make GMP > optional, or get rid of it. things are even worse because we just don't have an option of dynamic GMP linkage (and i'm not sure whether it is possible taking into account that many GMP functions should be just inlined in GHC RTS and generated code to make things faster) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Thu Jan 17 15:06:09 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 17 15:06:11 2008 Subject: gmp In-Reply-To: <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> <20080117181457.GA10636@scytale.galois.com> <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> Message-ID: <404396ef0801171206w59cb4ef2i3003f336c8eaa783@mail.gmail.com> Hi > What is the situation on Windows? Does the standard > GHC binary on Windows have dynamically linked gmp > for binaries produced by ghc? No, they are statically linked. (Please, can no one start discussing licensing, people already know there are issues with it, and I get plenty of traffic already!) Thanks Neil From naur at post11.tele.dk Thu Jan 17 15:05:15 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Jan 17 15:06:33 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <20080117042502.CGBB4584.fep28.mail.dk@note.orchestra.cse.unsw.EDU.AU> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <20080117042502.CGBB4584.fep28.mail.dk@note.orchestra.cse.unsw.EDU.AU> Message-ID: <200801172105.17346.naur@post11.tele.dk> Hello, On Thursday 17 January 2008 05:24, Manuel M T Chakravarty wrote: > Thorkil Naur: > > Hello, > > > > On Tuesday 08 January 2008 15:07, Christian Maeder wrote: > >> Hi, > >> > >> I've succeeded in building a binary distribution that uses static > >> libraries for gmp and readline. libreadline.a, libncurses.a and > >> libgmp.a > >> with corresponding header files are included. (For license issues ask > >> someone else.) > > > > On http://gmplib.org/ we find: > > > > "GMP is distributed under the GNU LGPL. This license makes the > > library free to > > use, share, and improve, and allows you to pass on the result. The > > license > > gives freedoms, but also sets firm restrictions on the use with non- > > free > > programs." > > > > I have not attempted to check whether your distribution fulfills the > > requirements of the LGPL. > > It does fullfil them. The source code of all components of the system > is available enabling users to build the same software with a > different version of GMP. That's all that the LGPL requires of > software linked against a LGPL library. > > > > Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: > > > > "Readline is free software, distributed under the terms of the GNU > > General > > Public License, version 2. This means that if you want to use > > Readline in a > > program that you release or distribute to anyone, the program must > > be free > > software and have a GPL-compatible license." > > > > For your distribution to adhere to this, it appears to require GHC > > to have a > > GPL-compatible license. Sorry, my use of the term "GPL-compatible" here is wrong. What I should have written was that "it appears to require GHC to be distributed under the GPL". > > I don't believe it does. > > It does. GHC's codebase is a mix of BSD3, LGLP, and GPL. They are > perfectly compatible. See >. > > Manuel > Best regards Thorkil From naur at post11.tele.dk Thu Jan 17 15:44:15 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Jan 17 15:45:29 2008 Subject: gmp In-Reply-To: <20080117165721.WPJJ1374.fep29.mail.dk@www.haskell.org> References: <20080117165721.WPJJ1374.fep29.mail.dk@www.haskell.org> Message-ID: <200801172144.16341.naur@post11.tele.dk> Hello, On Thursday 17 January 2008 17:57, Christian Maeder wrote: > I understand that gmp is needed for the certain libraries like the > Prelude with Double and Integer. > > But I do not understand why gmp is so deeply buried in the rts. > Are the basic types Int and Pointer not enough to write a compiler like ghc? You probably know about this, but just to make sure: Did you take a look at http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes? > > Cheers Christian > ... Best regards Thorkil From chak at cse.unsw.edu.au Thu Jan 17 19:29:59 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 19:30:08 2008 Subject: bindist for Intel MacOS X 10.4 (Tiger) with static libs In-Reply-To: <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> References: <20080108140722.PULI10334.fep25.mail.dk@www.haskell.org> <200801100924.19306.naur@post11.tele.dk> <1177408385.20080110120041@gmail.com> <2608b8a80801100206n6069387dl864b73625ae8bf03@mail.gmail.com> <1645551675.20080110132124@gmail.com> <2608b8a80801170810w4afed6a6v3be1b147d7c35033@mail.gmail.com> Message-ID: <1967AEA1-A959-40A1-A3DF-582F9DA81EE7@cse.unsw.edu.au> Yitzchak Gale: > Bulat Ziganshin wrote: >>> for me, GMP is much more problematic issue. strictly speaking, we >>> can't say that GHC is BSD-licensed because it includes LGPL-licensed >>> code (and that much worse, it includes this code in run-time libs) > > Manuel M T Chakravarty wrote: >> ..binary distributions of GHC that include libgmp.a and statically >> link it into compiled code... All >> that is needed to make this legal is to (a)... >> (b) give users access to another version of >> the proprietary program that links GMP dynamically. > > Wow, I didn't realize that. Now I understand Bulat. In a > project of any serious size and complexity, the use > of static or dynamic linking is often architechted in and > cannot be changed. So LGPL is really bad for a general > purpose compiler like GHC. We've got to make GMP > optional, or get rid of it. Well, I think you misunderstood what I was trying to say. My point is that the LGPL is *no* reason to worry. As Isaac wrote, there are a number of ways in which a vendor of a proprietary program can successfully work with LGPL'ed code. My proposal of providing a dynamically linked version of the software as an option is just one of these ways (which I think is especially easy to realise). Other ways include distributing the dynamically linked binary in the first place and providing access to .o file to link with a different version of the library (as Isaac outlined). BTW, when I write dynamically linked binary I mean a binary that links dynamically to the LGPL'ed code (ie, here GMP). All other libraries can still be linked statically. As a case in point for my argument, please consider Apple. Mac OS X contains a lot of GPL'ed and LGPL'ed code. Now you can argue that that's a simpler situation because it's a whole OS and many of the programs with GNU licenses are standalone, such as gcc. Now just for fun, go to your nearest Apple store, grab an ipod touch and have a look at its "Copyright" menu. There is lots of LGPL'ed code in there, too. I am sure they had a trillion lawyers making sure that they comply with the licence terms, so that the FSF is not going to come after them. Manuel From chak at cse.unsw.edu.au Thu Jan 17 20:13:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 20:13:24 2008 Subject: Integrating editline with ghc In-Reply-To: <478F93B0.9070104@blackkettle.org> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F57B8.8060806@charter.net> <2608b8a80801170852u388fce28vea5af7eb6b6ba628@mail.gmail.com> <478F93B0.9070104@blackkettle.org> Message-ID: <6FB741F6-18A7-4B69-B592-8F05155EAC5A@cse.unsw.edu.au> Alex Young: > Yitzchak Gale wrote: >> Isaac Dupree wrote: >>> GHC is in no legal trouble whatsoever... only if proprietary Haskell >>> code uses the readline library and doesn't switch to using the >>> editline >>> backend. >> Agreed. I didn't mean that GHC itself was ever in any >> legal trouble. But as a compiler, it must be possible for >> users to compile with it without getting into legal trouble. > > Yes. I'm still learning Haskell, and it's my intention to use GHC > to produce commercial plugins for an application on Windows (and > possibly OS X, haven't decided yet). This whole discussion makes me > worry - not because I have any intention to break any licences, but > because I might do so by accident. At this point in my learning, > I've got no idea what will cause "problem packages" (problems from > my point of view being ones that cause a phone call to a lawyer) to > be linked in to my binaries. It would be enormously helpful if > there was a wiki page somewhere that said "To use GHC/mingw as a > compiler for commercial software, it's likely you want to avoid > these modules and command-line flags" or alternatively "To guarantee > that no LGPL or GPL libraries are linked, use these flags". > > The last thing I want is to cause myself extra work when someone > chucks my plugin through a hex editor, sees a whole load of GMP > symbols (for example) and demands some form of compliance that > commercially I'd rather avoid. The Haskell package system Cabal has a package description format that includes an entry stating the packages license. You can browse packages at http://hackage.haskell.org/packages/hackage.html and the package entries include the license field. For example, the entry for readline http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline-1.0.1.0 says it is GPL'ed - ie, you may not link it into proprietary code. I agree that a wiki page explaining this and the situation with static versus dynamic linking of LGPL'ed code would be helpful. Manuel From chak at cse.unsw.edu.au Thu Jan 17 20:22:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 20:22:35 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> Christian Maeder: > Judah Jacobson wrote: >> - System.Console.Editline.Readline contains the readline APIs >> provided >> by the editline library (mostly a cut/paste of >> System.Console.Readline). > > I would like to see a restructuring of the old readline > package: > > 1. a _new_ readline package that only contains the interface that > can be > implemented using libeditline _or_ libreadline. If this package is > call > "readline" (with a new version number) most libraries i.e. like > Shellac > would not need modifications. I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?) Instead, we should have a new module whose interface coincides with editline's readline emulation. Everybody who wants to use editline when available and readline only if editline is not available can then use that new module (which I called EditReadline in my previous post). GHC will be one of these programs. Manuel From chak at cse.unsw.edu.au Thu Jan 17 20:36:10 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 20:38:28 2008 Subject: gmp In-Reply-To: <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> <20080117181457.GA10636@scytale.galois.com> <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> Message-ID: <5802BB37-7AF1-463F-B993-4DCEE0E74F9D@cse.unsw.edu.au> Yitzchak Gale: > OK for the time > being, but it would be really, really good to be able to compile > ghc without gmp. Well, just go ahead and write an alternative portable & high- performance implementation of Integer. > This idea of a Mac OS X binary with statically-linked > gmp is nice, it is really convenient. But someone needs > to completely clarify the license issues in that case, and > make it completely clear to all users. I completely agree that we need to document the situation clearly. Otherwise, I don't really see what the fuss is about. Most GHC users don't care whether GMP is linked into their code (as its either only used internally or has a GPL-compatible license anyway). If a company wants to distribute GHC compiled binaries of non-GPL compatible code, well, they have to compile their own version of GHC on the Mac that links GMP dynamically, and then, use that version of GHC to link their final product. That is going to be a trivial task compared to developing that product in the first place. So, who cares? Manuel From simonpj at microsoft.com Fri Jan 18 03:05:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 18 03:05:30 2008 Subject: gmp In-Reply-To: <5802BB37-7AF1-463F-B993-4DCEE0E74F9D@cse.unsw.edu.au> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> <20080117181457.GA10636@scytale.galois.com> <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> <5802BB37-7AF1-463F-B993-4DCEE0E74F9D@cse.unsw.edu.au> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C315A5528072@EA-EXMSG-C334.europe.corp.microsoft.com> | > gmp is nice, it is really convenient. But someone needs | > to completely clarify the license issues in that case, and | > make it completely clear to all users. | | I completely agree that we need to document the situation clearly. Although I hate discussing licensing (which is why GHC has a BSD license), this thread has been illuminating. Would anyone who feels they understand the situation feel able to write a few paragraphs explaining the situation, in a form suitable for a random user of GHC to read and understand? If someone wants to know in a year or two's time, they *might* find this thread; but they might not. A GHC wiki page would be ideal "Explanation of GHC's licensing". Thank you! (Meanwhile, we continue to welcome efforts to make the licensing situation simpler, by making it possible to do without GPL stuff in the core libraries, notably GMP and readline.) Simon From Christian.Maeder at dfki.de Fri Jan 18 04:03:54 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 18 04:03:59 2008 Subject: Integrating editline with ghc In-Reply-To: <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> Message-ID: <47906B7A.6050407@dfki.de> Manuel M T Chakravarty wrote: > Christian Maeder: >> 1. a _new_ readline package that only contains the interface that can be >> implemented using libeditline _or_ libreadline. If this package is call >> "readline" (with a new version number) most libraries i.e. like Shellac >> would not need modifications. > > I disagree. Readline should stay as it is. (Why force existing > readline users who use functionality not supported by editline's > emulation layer to change the package they are using?) Your point is also supported by Yitz Gale, my point by Malcolm. Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) Disadvantage of my proposal (to change the readline interface): We have restructured libraries massively between 6.2 and 6.8 (why not for 6.10?) Disadvantage of making a new interface: Everybody who wants to profit from libedit has to do active changes (so many will not bother, although most would want it.) Christian From mechvel at botik.ru Fri Jan 18 04:32:35 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Jan 18 04:33:12 2008 Subject: returning to instance overlap Message-ID: <20080118093235.GA20145@scico.botik.ru> Dear GHC developers, can you exaplain, please, how to use overlapping instances? For example, the following program uses overlapping instances for DShow [a] and DShow String, but ghc-6.8.2 reports an error: ----------------------------------------------------------------- class DShow a where dShows :: a -> String -> String instance DShow Char where dShows = showChar instance DShow Int where dShows = shows instance DShow a => DShow [a] -- (1) where dShows _ = showString "contrived show value" instance DShow String where dShows = shows -- (2) f :: DShow a => [a] -> String f xs = dShows xs "" -- dShows (head xs) "" -- compare to this main = putStr (shows (f "abc", f [1, 2, 3 :: Int]) "\n") ----------------------------------------------------------------- I compile this under -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports But the ghc-6.8.2 compiler reports Overlapping instances for DShow [a] arising from a use of `dShows' at IOverlap.hs:21:23-34 Matching instances: instance [overlap ok] (DShow a) => DShow [a] -- Defined at IOverlap.hs:(14,0)-(16,45) instance [overlap ok] DShow String -- Defined at IOverlap.hs:18:0-42 (The choice depends on the instantiation of `a' To pick the first instance above, use -fallow-incoherent-instances when compiling the other instance declarations) In the expression: dShows xs "" In the definition of `f': f xs = dShows xs "" 1. Will ghc-5.02.3 find this program correct? 2. Applying -fallow-incoherent-instances leads to the result "(contrived show value, contrived show value)" for the function `main', which is not the point. My idea was that in the above program f "abc" will choose the instance (2), because String is a special case of [a]. 3. Also DoCon uses overlapping instances, and works under ghc-6.8.2, somehow (probably, I need to recall what precisely this usage is). 4. Maybe, it is good compile the above declaration f :: DShow a => [a] -> String f xs = dShows xs "" by relating to dShows the _set_ S = {dShows of (1), dShows of (2)} of two instances, putting to the code the set of two implementations. And when the complier comes (maybe in other module) to (f "abc", f [1, 2, 3 :: Int]), it chooses from S dShows of (2) for f in f "abc", -- because [Char] is more special than [a]. And in f [1, 2, 3 :: Int], it chooses dShows of (1). Thank you in advance for your explanation, ----------------- Serge Mechveliani mechvel@botik.ru From Christian.Maeder at dfki.de Fri Jan 18 07:05:03 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 18 07:05:05 2008 Subject: ghc binary on virtualized solaris In-Reply-To: <47909109.6050503@eecs.harvard.edu> References: <47909109.6050503@eecs.harvard.edu> Message-ID: <479095EF.40804@dfki.de> the entry in Makefile-vars is irrelevant for Solaris. it should be: RANLIB = : I did not know that the paths like for ranlib are so deeply burned into each library package (by cabal). Indeed I have: -bash-3.1$ type -all ranlib ranlib is /usr/local/bin/ranlib ranlib is /usr/ccs/bin/ranlib I could try to rebuild my binary dist with a proper PATH. HTH Christian Ryan Wisnesky wrote: > Hi Christian, > > I'm trying to install ghc onto a Joyent accelerator, which is an > instance of virtualized open solaris. I've noticed that even if I set > my RANLIB variable in the Makefile-vars to be its actual location (in > this case, /usr/ccs/bin/ranlib), there are a bunch of files, like > libraries/process/dist/setup-config, where the LocalBuildInfo haskell > structs have an entry for ranlib that looks like "ranlib", > ConfiguredProgram { ... programLocation = FoundOnSystem{locationPath = > /usr/local/bin/ranlib ... }. When I make install haskell, during > installation of the libraries, the installPackage haskell program is > eventually called and it will fail because it tries to invoke a > non-existent ranlib. These ranlib locations aren't set by the configure > script, because they are present even before that script is run. > > Unfortunately I can't just link my ranlib to /usr/local/bin because I > have a virtualized machine... > > Do you have any thoughts? Any help would be greatly appreciated. > > Regards, > Ryan Wisnesky From judah.jacobson at gmail.com Fri Jan 18 12:09:27 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jan 18 12:09:26 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> On Jan 17, 2008 1:19 AM, Christian Maeder wrote: > Judah Jacobson wrote: > > - System.Console.Editline.Readline contains the readline APIs provided > > by the editline library (mostly a cut/paste of > > System.Console.Readline). > > I would like to see a restructuring of the old readline > package: > > 1. a _new_ readline package that only contains the interface that can be > implemented using libeditline _or_ libreadline. If this package is call > "readline" (with a new version number) most libraries i.e. like Shellac > would not need modifications. > > 2. Two further packages for extension of editline and those functions of > readline that are not part of "1". Maybe call these packages > editline-ext and readline-ext A problem with the above proposal: the readline-ext package would depend not just on the readline package, but on an instance of the readline package that was built against libreadline specifically. I don't think that we can enforce that constraint; and even if we could, on a machine with both editline and readline installed it would get confusing pretty quickly. I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues. Best, -Judah From jb162 at brighton.ac.uk Fri Jan 18 13:22:08 2008 From: jb162 at brighton.ac.uk (Jim Burton) Date: Fri Jan 18 13:22:22 2008 Subject: Problem building on host machine when trying to cross-compile an unregistered build In-Reply-To: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> References: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> Message-ID: <1200680528.5324.29.camel@unicorn> Truly sorry to bump this, but does anyone have any pointers about building the host part of a cross-compilation? I've tried to follow the wiki instructions and failed. On Mon, 2008-01-14 at 12:41 +0000, jb162@brighton.ac.uk wrote: > Hi, host machine is Linux i386 and the target is NetBSD alpha, ghc > 6.8.2. With the help of the list the first part (on the target) is done > and I'm building the compiler on the host -- when building rts I get > > "cc1: error: unrecognized command line option "-mieee" > > What's this about? (I notice a couple of seemingly ignorable warnings in > the following, about missing gmpbuild and libHSrts.a. Is that relevant?) > Thanks. > > jim@mowa624-jb162:~/ghc-6.8.2/compiler$ cd ../rts && make boot && make > gcc -E -undef -traditional -P \ > -DIMPORT_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > -DLIB_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > > -DINCLUDE_DIR='"/home/jim/ghc-6.8.2/libraries/rts/include"' \ > -DDATA_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > -DHTML_DIR='"/home/jim/ghc-6.8.2/libraries/rts/html"' \ > > -DHADDOCK_IFACE='"/home/jim/ghc-6.8.2/libraries/rts/html/rts.haddock"' \ > -DFPTOOLS_TOP_ABS='"/home/jim/ghc-6.8.2"' \ > -x c -DGMP_INCLUDE_DIRS='' -DGMP_LIB_DIRS='' > -I../includes -Iinclude -DPACKAGE=rts -DVERSION= > -DPKG_LIBDIR='"/usr/local/lib/ghc-6.8.2"' > -DPKG_DATADIR='"/usr/local/share/ghc-6.8.2"' package.conf.in | \ > grep -v '^#pragma GCC' | \ > sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.inplace > ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files > Reading package info from stdin ... done. > /home/jim/ghc-6.8.2/gmp/gmpbuild doesn't exist or isn't a directory > (ignoring) > cannot find libHSrts.a on library path (ignoring) > Saving old package config file... done. > Writing new package config file... done. > ../utils/mkdependC/mkdependC -f .depend -I. -I../includes -DPROFILING > -DTHREADED_RTS -DDEBUG -Ihooks -Iparallel -Ism -Iposix -I../includes > -s debug -- -O -Wall -W -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Winline -Waggregate-return -I../includes -I. > -Iparallel -Ism -DCOMPILING_RTS -fomit-frame-pointer -DNOSMP > -I../gmp/gmpbuild -fno-strict-aliasing -- Adjustor.c Arena.c > Capability.c ClosureFlags.c Disassembler.c FrontPanel.c Hash.c Hpc.c > HsFFI.c Interpreter.c LdvProfile.c Linker.c Main.c Papi.c Printer.c > ProfHeap.c Profiling.c Proftimer.c RaiseAsync.c RetainerProfile.c > RetainerSet.c RtsAPI.c RtsFlags.c RtsMessages.c RtsStartup.c RtsUtils.c > STM.c Sanity.c Schedule.c Sparks.c Stable.c Stats.c StgCRun.c > StgPrimFloat.c Task.c ThreadLabels.c ThreadPaused.c Threads.c Ticky.c > Timer.c Trace.c Typeable.c Weak.c hooks/FlagDefaults.c > hooks/InitEachPE.c hooks/MallocFail.c hooks/OnExit.c hooks/OutOfHeap.c > hooks/RtsOpts.c hooks/ShutdownEachPEHook.c hooks/StackOverflow.c > parallel/0Hash.c parallel/0Unpack.c parallel/Dist.c parallel/Global.c > parallel/GranSim.c parallel/HLComms.c parallel/LLComms.c parallel/Pack.c > parallel/ParInit.c parallel/ParTicky.c parallel/Parallel.c > parallel/ParallelDebug.c parallel/RBH.c posix/FileLock.c posix/GetTime.c > posix/Itimer.c posix/OSMem.c posix/OSThreads.c posix/Select.c > posix/Signals.c sm/BlockAlloc.c sm/Compact.c sm/Evac.c sm/GC.c > sm/GCUtils.c sm/MBlock.c sm/MarkWeak.c sm/Scav.c sm/Storage.c > ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W > -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return > -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism > -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP > -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -H32m > -keep-hc-files -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild > -I. -#include HCIncludes.h -dcmm-lint -c Adjustor.c -o Adjustor.o > cc1: error: unrecognized command line option "-mieee" > make: *** [Adjustor.o] Error 1 > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bertram.felgenhauer at googlemail.com Sat Jan 19 12:21:13 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Jan 19 12:21:16 2008 Subject: returning to instance overlap In-Reply-To: <20080118093235.GA20145@scico.botik.ru> References: <20080118093235.GA20145@scico.botik.ru> Message-ID: <20080119172113.GB27336@zombie.inf.tu-dresden.de> Serge D. Mechveliani wrote: > Dear GHC developers, I'm not one of them, but maybe I can help anyway. > can you exaplain, please, how to use overlapping instances? > > For example, the following program uses overlapping instances for > DShow [a] and DShow String, but ghc-6.8.2 reports an error: > > ----------------------------------------------------------------- > class DShow a where dShows :: a -> String -> String > > instance DShow Char where dShows = showChar > instance DShow Int where dShows = shows > > instance DShow a => DShow [a] -- (1) > where > dShows _ = showString "contrived show value" > > instance DShow String where dShows = shows -- (2) > > f :: DShow a => [a] -> String > f xs = dShows xs "" > -- dShows (head xs) "" -- compare to this > > main = putStr (shows (f "abc", f [1, 2, 3 :: Int]) "\n") > ----------------------------------------------------------------- Does the trick from the Show class help you? Simplified, it is the following: class Show a where show :: a -> String showList :: [a] -> String showList = default implementation for showList instance Show Char where show = ... showList = specific implementation for String instance Show a => Show [a] where show = showList By putting the showList function into the Show class, we get a special treatment of Strings in Haskell 98, without any overlapping instances at all. > I compile this under > -fglasgow-exts -fallow-overlapping-instances > -fallow-undecidable-instances > -fno-warn-overlapping-patterns -fwarn-unused-binds > -fwarn-unused-matches -fwarn-unused-imports > > But the ghc-6.8.2 compiler reports > > Overlapping instances for DShow [a] > arising from a use of `dShows' at IOverlap.hs:21:23-34 > Matching instances: > instance [overlap ok] (DShow a) => DShow [a] > -- Defined at IOverlap.hs:(14,0)-(16,45) > instance [overlap ok] DShow String > -- Defined at IOverlap.hs:18:0-42 > (The choice depends on the instantiation of `a' > To pick the first instance above, use -fallow-incoherent-instances > when compiling the other instance declarations) > In the expression: dShows xs "" > In the definition of `f': f xs = dShows xs "" If you haven't done so already, you should read http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap (http://tinyurl.com/2cq3zm) What ghc is saying here is that there are two instances of DShow that can potentially match DShow [a]. That's bad because the compiler might pick a 'wrong' instance if it proceeds. Even with -fallow-incoherent-instances, the compiler is free to choose either instance, although it will try to use the most specific instance that fits the requirements. In your case, however, the most specific instance of DShow for [a] that fits the requirements (which are that the instance can be derived from the function's context alone) is DShow a => DShow [a], so the compiler picks that one. (Btw, one key point to keep in mind here is that ghc does not have any run time type information). You can fix your program by declaring f :: DShow [a] => [a] -> String or even f :: (DShow a, DShow [a]) => [a] -> String which will postpone the selection of the instance of DShow [a] to the point where f is called. > 3. Also DoCon uses overlapping instances, and works under ghc-6.8.2, > somehow (probably, I need to recall what precisely this usage is). There's only trouble with overlapping instances when you have several instances for the same type with different behaviour. (I don't know whether that's true or not for DoCon.) > 4. Maybe, it is good compile the above declaration > > f :: DShow a => [a] -> String > f xs = dShows xs "" > > by relating to dShows the _set_ S = {dShows of (1), dShows of (2)} > of two instances, > putting to the code the set of two implementations. That might work to some extent, but I think there are good reasons not to do that. 1) the number of different implementations of f that you have to keep around can be very large. Consider f :: (DShow a, DShow b, DShow c) => [a] -> [b] -> [c] -> String f as bs cs = dShows as . dShows bs . dShows cs $ "" which will need 8 copies of f to work. 2) with higher order functions, the final type the function will get called with may never be known until runtime, say, g :: (forall a . DShow a => [a] -> String) -> Either String [Int] -> String g f (Left a) = f a g f (Right b) = f b (consider g (\xs -> dShows xs "") -- which dShows should be used here?) HTH, Bertram From mechvel at botik.ru Sun Jan 20 09:55:39 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jan 20 09:56:23 2008 Subject: instance overlap Message-ID: <20080120145539.GA22294@scico.botik.ru> I thank Bertram Felgenhauer for his helpful notes on my request on overlapping instances. First, here is the abstract of this my letter. ------------------------------------------------------------------- I address to the GHC developers with the following questions and suggestions. 1. Can you check what ghc-5.02.3 will report on the below small program with DShow (under -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances ) ? >> class DShow a where dShows :: a -> String -> String >> instance DShow Char where dShows = showChar >> instance DShow Int where dShows = shows >> >> instance DShow a => DShow [a] -- (1) >> where >> dShows _ = showString "contrived show value" >> >> instance DShow String where dShows = shows -- (2) >> >> f :: DShow a => [a] -> String >> f xs = dShows xs "" >> -- dShows (head xs) "" -- compare to this >> >> main = putStr (shows (f "abc", f [1, 2, 3 :: Int]) "\n") 2. When GHC fails to select an instance among overlapping ones, it is often useful to report advice to the user: "consider adding such and such instance class assertion to a type context". For example, the user declares above f :: DShow a => [a] -> String, and the compiler advices to consider the declaration f :: (DShow a, DShow [a]) => [a] -> String. With this, the compiler postpones the instance selection in a client function (`main') for f. 2.1. Maybe, it is better for the compiler to automatically add such decls to the context, issue a warning and to continue compilation ? Because, evidently, the programmer presumes this declaration meaning. (?) 3. In my example with DShow, instance overlaps are really redundant. I looked into Prelude.Show, showList, and their usage in List and [Char]. I added an analogue of showList, and now DShow does not need overlapping instances. 4. But there are other situations, when it is much simpler for a programmer to declare overlapping instances than to apply tricks with additional class methods. 5. What the GHC developers think on my suggestion below with the user defined preference for overlapping instances? For any occasion, keep in mind, that sometimes I mistake. ------------------------------------------------------------------------ So, Bertram, (3) is the answer to your response of 19 Jan 2008 > Does the trick from the Show class help you? Simplified, it is > the following: > class Show a where show :: a -> String > showList :: [a] -> String > [..] We also wrote >> 3. Also DoCon uses overlapping instances, and works under ghc-6.8.2, >> somehow (probably, I need to recall what precisely this usage is). > You can fix your program by declaring > > f :: DShow [a] => [a] -> String > > or even > > f :: (DShow a, DShow [a]) => [a] -> String > > which will postpone the selection of the instance of DShow [a] to > the point where f is called. Yes, according to this your note, I suggest the point (2) in the abstract. This was my intention and expectation: I hope for the compiler to postpone, as possible, the instance selection. But it occurs that it needs a little help from the programmer. Probably, you answered by this why do i-overlaps work in DoCon. I recall, old GHC compilation reports adviced me to add the contexts similar to this `DShow [a]'. And I did add them. But in this example with DShow, ghc-6.8.2 does not advice this. I wonder what ghc-5.02.3 will report on this example. I have two large projects in Haskell + GHC. The current one is Dumatel -- a prover. It uses i-overlaps, but not essentially, as I see now, i-overlaps can easily be removed from it. The old project is DoCon -- computer algebra. I think, i-overlaps are essential in all application domains, but in computer mathematics they become visible somehow earlier. > There's only trouble with overlapping instances when you have several > instances for the same type with different behaviour. (I don't know > whether that's true or not for DoCon.) Yes -- with different behaviour. It is true for DoCon, and this is generally in-avoidable. For an applied programmer, this sometimes occurs a natural way to implement a method instance. And the compiler does have a certain technical trouble. It must overcome it by posponing the instance selection as possible. For example, in DoCon, I put (example changed, it is contrived): ---------------------------------------------------------------------- class EuclideanRing a where divideWithRemainder :: a -> a -> a ... class EuclideanRing a => Field a where ... instance EuclideanRing IntegerModulo_2 where divideWithRemainder a b = ... instance Field IntegerModulo_2 where ... instance :: EuclideanRing a => GCD (Polynomial a) where gcd f g = instance GCD (Polynomial IntegerModulo_2) where gcd f g = instance Field a => GCD (Polynomial a) where gcd f g = a > f :: (Field a, GCD (Polynomial a)) => Polynomial a -> Polynomial a f p = gcd p (p*p - 1) main = putSTr (show ( f (x^2+x+1) :: Polynomial IntegerModulo_2 )) ---------------------------------------------------------------------- -- sorry, I do not run this particular example, have not time now, but similar constructs work in DoCon, in practice. Note, that in `f', the three instances for GCD (Polynomial a) overlap. If we remove `GCD (Polynomial a)' from the context of f, then the compiler would not know what instance to set for gcd in RHS of f. Right? And with adding `GCD (Polynomial a)' to the context of f, the compiler postpones instance selection in this example until `main'. And this is my programmer aim. Maybe, this i-overlap can be avoided by the trick of introducing several additional members to the classes EuclideanRing and Field, similarly as with Show.showList. But this will not be so easy as for Prelude.Show. The user program will, probably, complicate considerably. For this example, the trick will require to declare class EuclideanRing a where divideWithRemainder :: a -> a -> a gcdForPolynomials :: Polynomial a -> Polynomial a -> Polynomial a ...ForMatrix :: ... ... Show.showList of the Haskell Prelude is conceptually ugly, because it interferes with usage of classes. But this trick is `small', it appears in a couple of places in Standard Prelude only, and with all the rest, it is hidden, I use `show' and do not recall of showList. But I do not think that in general, adding parasitic class members is a good way to avoid overlapping instances. In computer algebra, this, I think, will be much worse. This member gcdForPolynomials is ugly. But besides this, one would need to also add the member of, say, matrixDeterminant :: Matrix a -> a, and other members. And this is instead of separate plain declaration of determinant :: (... a) => Matrix a -> a This trick spoils the concept, provoces the user to a wrong style. And probably, there will be further complication with implementation. This trick is tricky. And mathematical practice for defining methods is plain, it is as written above, it follows common reason. The simpler (for user) -- the better. The aim is not to provide different algorimths for a same type. The aim is to provide one algorithm for a certain class of types (class of mathematical domains), other algorithm for another class of domains, and so on, for several algorithms. For example, for determinant for (Matrix a) one can find 4-5 different useful generic algorithms, and each one requires its particular conditions on `a', and on construction of `a'. Different algorithms usually are based on different conditions on the domain -- different type contexts (what is set before `=>'). The user aim is to define these algorithms in a generic way, and on the other hand, some of them are defined in a more special way -- for the need of fast computation. This is a natural way to implement a computational method. The description of these domain classes is also natural -- by the Haskell classes and type contexts. This agrees with science. But there is a minor deficiency here: the above domain classes may intersect non-trivially. This cannot be avoided. A pair of the above domain classes may have non-empty intersection. Let a domain D be in this intersection. Now, what if instance-1.gcd f g /= instance-2.gcd f g for some f and g from D ? Then, the programmer is responsible. In this case, one may have wrong result at run time. Also I can even imagine a situation, when such a diversion is intended -- this is on the programmer. This must _not_ be an error for compiler. The compiler could _warn_ about possible result diversion, but we do not require of a compiler such a wisedom. In my practice, different algorithms for instance-1 and instance-2 often have very different computation cost, but they always have the same data result in the end. For example, different algorithms for multiplying matrices correspond to the same symbol "*", and they must produce the same product matrix -- this is science. If the results diverse, then, in my current practice, this is a _programmer_ error. But when the compiler cannot postpone instance selection, what instance (among matching a domain sub-class D) needs the compiler to select for D ? Let it be, -- so far, -- one of the most special instances. This agrees with a) common intuition, b) mathematical practice, c) current GHC solution. And generally, for future, consider the following simple solution. (The compliler reports of overlaps, and then,) the programmer orders in the source program the instances that overlap -- by inserting the precedence declaration: instance-a (Precedence 1), instance-b (Precedence 2), ... -- add possible `(Precedence n)' declaration to instance declaration. This numeration is local for each overlapping set of instances. Then, for a class of domains in the intersection of these instances, the compiler must select among the matching instances the one with the smallest precedence No. For example, for the above instances for GCD, I would set the precedence: ---------------------------------------------------------------------- instance GCD (Polynomial IntegerModulo_2) (Precedence 1) where ... instance Field a => GCD (Polynomial a) (Precedence 2) where ... instance :: EuclideanRing a => GCD (Polynomial a) (Precedence 3) where ... ---------------------------------------------------------------------- -- because the method of (1) is usually faster than (2) and (2) is usually faster than (3). In most situations, it is easy for a programmer to set such a precedence according to programmer's knowledge. This is a more generic mechanism than to relay on the compiler to detect specializations among instances, because one instance can be more preferable but not more special by constructors (I can provide examples). Still there may remain situations when it is not clear even for a programmer, which instance is better for some intersection. In such a case, there still is not any better solution than to relay on the programmer-set ordering. If the programmer cannot decide, he skips some precedence setting in instances, and the compiler would fill the them in any way (but at least, as subdued to `more-special' relation). I wonder: what might be wrong with this programmer-set precedence arrangement? Now, what concerns to "computer algebra and mathematics": do not think that instance overlaps present a specific need for mathematics, generally, mathematics _has not anything_ as specific with respect to programming tools. It would be better to provide simple examples from a "real life". For example, class Vehicle ... instance Vehicle Bicycle ... instance Vehicle Car ... instance Vehicle Ship ..., a Vehicle has a set of MetalDetail-s. A Car has this kinds of MetalDetail-s, a Ship has other kinds of MetalDetail-s, an Object can be constructed of Vehicle-s in such and such ways. A SeaPort is an Object. Finally, the way to compute the function f object = "number of standard details" in an Object may relay on the class of this object and also on its construction. Computing f may be, in general, by class membership and spends much of computation cost. Computing f by a concrete construction of an object is faster, but more special, -- and the result is the same. And there will appear instance overlap. I am sorry, I have not time to invent this real-life example. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From frederik at a5.repetae.net Sun Jan 20 19:14:07 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Jan 20 19:14:00 2008 Subject: Network.CGI changes Message-ID: <20080121001407.GA3695@a5.repetae.net> Hello all, About two years ago, I wrote a web page for one of my projects, using Network.CGI. I chose that over WASH because it had a simple interface and I thought it would be more stable as a result. Now, Bjorn Bringert has replaced the interface with a completely different one. There is a cgi-compat, but it doesn't build with GHC 6.8.2. Does anyone know a quick way to get my web page functioning again? Is there an early version of Network.CGI (with the 'wrapper' interface) that still compiles under GHC 6.8.2? I'm a bit reluctant to convert my code to the new interface, because it will probably change completely again in a year or so, and I'd rather not have to keep revisiting my project and rewriting the web page... Anyway, I am attaching the source file. Thanks in advance, Frederik P.S. Sometimes programmers make a rule of changing the names of things when they change the interface; this makes it possible to keep the old interface alongside the new one, so code which depends on the old interface don't have to change. Is there a reason why the Haskell community does not adopt this practice? It seems that people are always saying that there is a lack of manpower in this community, perhaps that is an excellent reason to make *fewer* incompatible changes, rather than more? -- http://ofb.net/~frederik/ -------------- next part -------------- A non-text attachment was scrubbed... Name: webpage.hs Type: text/x-haskell Size: 4603 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080121/89cb0339/webpage.bin From duncan.coutts at worc.ox.ac.uk Sun Jan 20 20:13:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 20 20:13:11 2008 Subject: Network.CGI changes In-Reply-To: <20080121001407.GA3695@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> Message-ID: <1200878000.5639.420.camel@localhost> On Mon, 2008-01-21 at 00:14 +0000, Frederik Eaton wrote: > Hello all, > > About two years ago, I wrote a web page for one of my projects, using > Network.CGI. I chose that over WASH because it had a simple interface > and I thought it would be more stable as a result. Now, Bjorn Bringert > has replaced the interface with a completely different one. There is a > cgi-compat, but it doesn't build with GHC 6.8.2. You're in luck! It is trivial to get it to build: { hunk ./cgi.cabal 10 -Build-depends: base, network, parsec, mtl, xhtml, fps +Build-depends: base, network, parsec, mtl, xhtml, + bytestring, containers, old-time, old-locale } That's against the current darcs version of the code. I guess it'd be helpful to do that properly so it builds with both ghc-6.6 and 6.8 and get it uploaded to hackage. I'm cc'ing Bjorn. > P.S. Sometimes programmers make a rule of changing the names of things > when they change the interface; this makes it possible to keep the old > interface alongside the new one, so code which depends on the old > interface don't have to change. Is there a reason why the Haskell > community does not adopt this practice? It seems that people are > always saying that there is a lack of manpower in this community, > perhaps that is an excellent reason to make *fewer* incompatible > changes, rather than more? And Bjorn went one better and made a whole package with exactly the same old api. That way there was an easy route for old programs and we don't have to obfuscate the new api by having to avoid using the most obvious names (that were in use in the old api). Duncan From waldmann at imn.htwk-leipzig.de Mon Jan 21 03:50:46 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Jan 21 03:50:48 2008 Subject: Network.CGI changes In-Reply-To: <20080121001407.GA3695@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> Message-ID: <47945CE6.6080409@imn.htwk-leipzig.de> If you need the old "wrapper" function, then use something like this: wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do e <- getInputs a <- lift $ f $ e output $ renderHtml a best regards, Johannes Waldmann. From Christian.Maeder at dfki.de Mon Jan 21 04:27:04 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 04:26:55 2008 Subject: Difference in binaries distribution of ghc 6.8.2 In-Reply-To: <23f17cbc0801181006m76516355t26ce57ed2bba199d@mail.gmail.com> References: <23f17cbc0801181006m76516355t26ce57ed2bba199d@mail.gmail.com> Message-ID: <47946568.5040000@dfki.de> Thanks for pointing this out, though I will not do anything about it. I've used haddock-0.8 to build. (There was maybe a trac entry about broken haddock links.) The ghc team used some (odd) 0.8.0.1 haddock version http://www.haskell.org/ghc/docs/latest/html/libraries/index.html I haven't tried using haddock 2.0.0.0, yet. Somehow the documentation can be obtained separately. (I forgot how.) Someone else from glasgow-haskell-users@haskell.org could tell you. HTH Christian Andr?s Sicard-Ram?rez wrote: > Dear Cristian, > > Thanks for preparate the binary distribution of ghc 6.8.2 that uses > libreadline.so.5. > > In this binary version, I have a different documentation in > ../share/doc/ghc than in the binary version using libreadline.so.4. For > example, I do not have the source links in the libraries documentation. > > Are you aware of it? Is it possible to do something to have the source > links in the documentation? > > All the best, > > -- > Andr?s From Christian.Maeder at dfki.de Mon Jan 21 05:40:07 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 05:39:58 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> Message-ID: <47947687.6020604@dfki.de> Judah Jacobson wrote: > I think it will be much simpler if we keep the readline and editline > packages as they are now, and possibly add a third readline-compat > package which can use either one as a dependency. Then any project > (including GHC) can choose which of those packages to use, based on > API requirements and/or license issues. Could then editline go already into ghc-6.8.3, because interfaces don't change? Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.) I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat). Which version of editline to you require? Our newest version installed (under Solaris) is: editline.h,v 1.5 Which include files are used on Macs? Cheers Christian From simonpj at microsoft.com Mon Jan 21 06:24:53 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 21 06:24:40 2008 Subject: instance overlap In-Reply-To: <20080120145539.GA22294@scico.botik.ru> References: <20080120145539.GA22294@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C315A5528832@EA-EXMSG-C334.europe.corp.microsoft.com> Serge, and others | 1. Can you check what ghc-5.02.3 will report on the below small program | with DShow I don't have ghc 5.02 to hand, but here's what 5.04.3 says about the code you give. ghc-5.04.3 -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances Serge.hs Serge.hs:14: Could not unambiguously deduce (DShow [a]) from the context (DShow a) The choice of (overlapping) instance declaration depends on the instantiation of `a' Probable fix: Add (DShow [a]) to the type signature(s) for `f' Or add an instance declaration for (DShow [a]) arising from use of `dShows' at Serge.hs:14 In the definition of `f': dShows xs "" | 2. When GHC fails to select an instance among overlapping ones, it is | often useful to report advice to the user: "consider adding such and | such instance class assertion to a type context". In general it's quite hard to make suggestions that are never misleading. In this case GHC does suggest something, but it's wrong! GHC 6.08's message is this: Serge.hs:14:23: Overlapping instances for DShow [a] arising from a use of `dShows' at Serge.hs:14:23-34 Matching instances: instance [overlap ok] (DShow a) => DShow [a] -- Defined at Serge.hs:(7,0)-(9,45) instance [overlap ok] DShow String -- Defined at Serge.hs:11:0-42 (The choice depends on the instantiation of `a' To pick the first instance above, use -fallow-incoherent-instances when compiling the other instance declarations) In the expression: dShows xs "" In the definition of `f': f xs = dShows xs "" This is better, although it does not suggest adding (DShow [a]) to the context of f. Adding that could perhaps be possible. | 3. In my example with DShow, instance overlaps are really redundant. | I looked into Prelude.Show, showList, and their usage in List and | [Char]. I added an analogue of showList, and now DShow does not need | overlapping instances. | | 4. But there are other situations, when it is much simpler for a | programmer to declare overlapping instances than to apply tricks with | additional class methods. I don't know what you are actually suggesting here | 5. What the GHC developers think on my suggestion below with the user | defined preference for overlapping instances? I believe your suggestion is: where instances overlap, choose the most specific. Yes, that's possible, and GHC does exactly that *unless* the answer to the match can be changed by instantiating a type variable. Consider f :: DShow a => a -> String If I need (DShow [a]) inside f, then you say, I guess, choose the DShow [a] instance even though there is a (DShow [Char]) instance. But if I changed 'f' to give it a more specific type: f :: Char -> String then we would choose the DShow [Char] instance instead. So making the type signature more specific has changed the semantics of the program. This is precisely what the flag -fallow-incoherent-instances does. So you can get the behaviour you ask for by giving an extra flag. Simon From frederik at a5.repetae.net Mon Jan 21 07:01:47 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Jan 21 07:01:44 2008 Subject: Network.CGI changes In-Reply-To: <47945CE6.6080409@imn.htwk-leipzig.de> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> Message-ID: <20080121120147.GP11635@a5.repetae.net> Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > If you need the old "wrapper" function, then use something like this: > > wrapper :: ([(String,String)] -> IO Html) -> IO () > wrapper f = runCGI $ do > > e <- getInputs > a <- lift $ f $ e > output $ renderHtml a > > best regards, Johannes Waldmann. > -- http://ofb.net/~frederik/ From gale at sefer.org Mon Jan 21 08:18:19 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Jan 21 08:18:13 2008 Subject: Integrating editline with ghc In-Reply-To: <47947687.6020604@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> Message-ID: <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> Hi Christian, Christian Maeder wrote: > ...Even better if the current package readline is renamed to old-readline > and readline-compat to readline. I have been trying to understand why you want to do that. What would we gain? Thanks, Yitz From Christian.Maeder at dfki.de Mon Jan 21 09:13:23 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 09:13:16 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> Message-ID: <4794A883.2070903@dfki.de> Yitzchak Gale wrote: > Hi Christian, > > Christian Maeder wrote: >> ...Even better if the current package readline is renamed to old-readline >> and readline-compat to readline. > > I have been trying to understand why you want to do > that. What would we gain? On Macs I want Shellac-readline to use editline, under linux we don't have editline, so there I want to continue to use Shellac-readline as it is now. But I don't want to use different Haskell packages for different platforms (for the same project). On Macs, the only change I had to make to the Shellac-readline package was to replace "readline >= 1.0" with "editline >= 0.1" in Shellac-readline.cabal and "System.Console.Readline" with "System.Console.Editline.Readline" in src/System/Console/Shell/Backend/Readline.hs These changes were not necessary if readline-compat supplied a module System.Console.Readline and would be named "readline". (A better name for old-readline would be GPL-readline, though) I wonder how many other packages would work without changes and how many would break, because readline-compat supplies only a part of the old readline. Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now). HTH Christian From Christian.Maeder at dfki.de Mon Jan 21 09:42:09 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 09:41:58 2008 Subject: ghc binary on virtualized solaris In-Reply-To: <479095EF.40804@dfki.de> References: <47909109.6050503@eecs.harvard.edu> <479095EF.40804@dfki.de> Message-ID: <4794AF41.8010602@dfki.de> I've created a new binary release with a ranlib path /usr/ccs/bin/ http://www.dfki.de/sks/hets/pc-solaris/versions/ghc-6.8.2-i386-unknown-solaris2.tar.bz2 (46826578 Bytes) and a fixed bug http://hackage.haskell.org/trac/ghc/ticket/1980 I have not tested it, though. I'm not sure, if it should replace http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-solaris2.tar.bz2 The other paths to haddock, alex, happy and hugs in setup-config files are also somehow disturbing for a distribution. Cheers Christian Christian Maeder wrote: > the entry in Makefile-vars is irrelevant for Solaris. it should be: > > RANLIB = : > > I did not know that the paths like for ranlib are so deeply burned into > each library package (by cabal). Indeed I have: > > -bash-3.1$ type -all ranlib > ranlib is /usr/local/bin/ranlib > ranlib is /usr/ccs/bin/ranlib > > I could try to rebuild my binary dist with a proper PATH. > > HTH Christian > > Ryan Wisnesky wrote: >> Hi Christian, >> >> I'm trying to install ghc onto a Joyent accelerator, which is an >> instance of virtualized open solaris. I've noticed that even if I set >> my RANLIB variable in the Makefile-vars to be its actual location (in >> this case, /usr/ccs/bin/ranlib), there are a bunch of files, like >> libraries/process/dist/setup-config, where the LocalBuildInfo haskell >> structs have an entry for ranlib that looks like "ranlib", >> ConfiguredProgram { ... programLocation = FoundOnSystem{locationPath = >> /usr/local/bin/ranlib ... }. When I make install haskell, during >> installation of the libraries, the installPackage haskell program is >> eventually called and it will fail because it tries to invoke a >> non-existent ranlib. These ranlib locations aren't set by the configure >> script, because they are present even before that script is run. >> >> Unfortunately I can't just link my ranlib to /usr/local/bin because I >> have a virtualized machine... >> >> Do you have any thoughts? Any help would be greatly appreciated. >> >> Regards, >> Ryan Wisnesky From Christian.Maeder at dfki.de Mon Jan 21 10:22:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 10:22:35 2008 Subject: Integrating editline with ghc In-Reply-To: <4794A883.2070903@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> Message-ID: <4794B8C4.4080304@dfki.de> Christian Maeder wrote: > Depending on what the ghc team and the library maintainers decide, > "readline" has to be changed to "readline-compat" in *.cabal Maybe someone could point out how the conditional build-depends entry would look like in Shellac-readline.cabal if readline is to be used for older ghc versions (with GNU readline only) and readline-compat for newer ghcs (possible using editline). Will there be a new flag hasReadlineCompat? Cheers C. From simonmarhaskell at gmail.com Mon Jan 21 10:23:54 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 21 10:23:47 2008 Subject: Problem building on host machine when trying to cross-compile an unregistered build In-Reply-To: <1200680528.5324.29.camel@unicorn> References: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> <1200680528.5324.29.camel@unicorn> Message-ID: <4794B90A.9030305@gmail.com> Jim Burton wrote: > Truly sorry to bump this, but does anyone have any pointers about > building the host part of a cross-compilation? I've tried to follow the > wiki instructions and failed. First thing to note is that bootstrapping from HC files has bitrotted in 6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated the wiki instructions to say this. You should go back to 6.6.x, or be prepared to fix things... I thought I remembered someone saying recently they were looking into getting bootstrapping working again, but I can't seem to find it now. > On Mon, 2008-01-14 at 12:41 +0000, jb162@brighton.ac.uk wrote: >> Hi, host machine is Linux i386 and the target is NetBSD alpha, ghc >> 6.8.2. With the help of the list the first part (on the target) is done >> and I'm building the compiler on the host -- when building rts I get >> >> "cc1: error: unrecognized command line option "-mieee" It looks like this comes from mk/bootstrap.mk, which says: ifeq "$(alpha_TARGET_ARCH)" "1" PLATFORM_CC_OPTS += -static -w PLATFORM_HC_BOOT_CC_OPTS += -mieee endif So someone in the past thought it was a good idea to pass this option when compiling .hc files. I can't tell you any more than that - perhaps just removing that line will get you going again. Cheers, Simon >> What's this about? (I notice a couple of seemingly ignorable warnings in >> the following, about missing gmpbuild and libHSrts.a. Is that relevant?) >> Thanks. >> >> jim@mowa624-jb162:~/ghc-6.8.2/compiler$ cd ../rts && make boot && make >> gcc -E -undef -traditional -P \ >> -DIMPORT_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ >> -DLIB_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ >> >> -DINCLUDE_DIR='"/home/jim/ghc-6.8.2/libraries/rts/include"' \ >> -DDATA_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ >> -DHTML_DIR='"/home/jim/ghc-6.8.2/libraries/rts/html"' \ >> >> -DHADDOCK_IFACE='"/home/jim/ghc-6.8.2/libraries/rts/html/rts.haddock"' \ >> -DFPTOOLS_TOP_ABS='"/home/jim/ghc-6.8.2"' \ >> -x c -DGMP_INCLUDE_DIRS='' -DGMP_LIB_DIRS='' >> -I../includes -Iinclude -DPACKAGE=rts -DVERSION= >> -DPKG_LIBDIR='"/usr/local/lib/ghc-6.8.2"' >> -DPKG_DATADIR='"/usr/local/share/ghc-6.8.2"' package.conf.in | \ >> grep -v '^#pragma GCC' | \ >> sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.inplace >> ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files >> > Reading package info from stdin ... done. >> /home/jim/ghc-6.8.2/gmp/gmpbuild doesn't exist or isn't a directory >> (ignoring) >> cannot find libHSrts.a on library path (ignoring) >> Saving old package config file... done. >> Writing new package config file... done. >> ../utils/mkdependC/mkdependC -f .depend -I. -I../includes -DPROFILING >> -DTHREADED_RTS -DDEBUG -Ihooks -Iparallel -Ism -Iposix -I../includes >> -s debug -- -O -Wall -W -Wstrict-prototypes -Wmissing-prototypes >> -Wmissing-declarations -Winline -Waggregate-return -I../includes -I. >> -Iparallel -Ism -DCOMPILING_RTS -fomit-frame-pointer -DNOSMP >> -I../gmp/gmpbuild -fno-strict-aliasing -- Adjustor.c Arena.c >> Capability.c ClosureFlags.c Disassembler.c FrontPanel.c Hash.c Hpc.c >> HsFFI.c Interpreter.c LdvProfile.c Linker.c Main.c Papi.c Printer.c >> ProfHeap.c Profiling.c Proftimer.c RaiseAsync.c RetainerProfile.c >> RetainerSet.c RtsAPI.c RtsFlags.c RtsMessages.c RtsStartup.c RtsUtils.c >> STM.c Sanity.c Schedule.c Sparks.c Stable.c Stats.c StgCRun.c >> StgPrimFloat.c Task.c ThreadLabels.c ThreadPaused.c Threads.c Ticky.c >> Timer.c Trace.c Typeable.c Weak.c hooks/FlagDefaults.c >> hooks/InitEachPE.c hooks/MallocFail.c hooks/OnExit.c hooks/OutOfHeap.c >> hooks/RtsOpts.c hooks/ShutdownEachPEHook.c hooks/StackOverflow.c >> parallel/0Hash.c parallel/0Unpack.c parallel/Dist.c parallel/Global.c >> parallel/GranSim.c parallel/HLComms.c parallel/LLComms.c parallel/Pack.c >> parallel/ParInit.c parallel/ParTicky.c parallel/Parallel.c >> parallel/ParallelDebug.c parallel/RBH.c posix/FileLock.c posix/GetTime.c >> posix/Itimer.c posix/OSMem.c posix/OSThreads.c posix/Select.c >> posix/Signals.c sm/BlockAlloc.c sm/Compact.c sm/Evac.c sm/GC.c >> sm/GCUtils.c sm/MBlock.c sm/MarkWeak.c sm/Scav.c sm/Storage.c >> ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >> -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP >> -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -H32m >> -keep-hc-files -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild >> -I. -#include HCIncludes.h -dcmm-lint -c Adjustor.c -o Adjustor.o >> cc1: error: unrecognized command line option "-mieee" >> make: *** [Adjustor.o] Error 1 >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Mon Jan 21 10:54:31 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 21 10:54:27 2008 Subject: Integrating editline with ghc In-Reply-To: <4794A883.2070903@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> Message-ID: <4794C037.90609@gmail.com> Christian Maeder wrote: > Depending on what the ghc team and the library maintainers decide, > either "readline" has to be changed to "readline-compat" in *.cabal or > (worse) we get packages Shellac-readline and Shellac-editline or (more > worse) Shellac-readline stays as is and I have to fiddle with editline > or readline on Macs myself (like now). It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job. In a similar vein, we should have an editline package that provides a binding to libedit. For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd. So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file. Cheers, Simon From Christian.Maeder at dfki.de Mon Jan 21 12:10:55 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 12:10:47 2008 Subject: Integrating editline with ghc In-Reply-To: <4794C037.90609@gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> <4794C037.90609@gmail.com> Message-ID: <4794D21F.6080201@dfki.de> Simon Marlow wrote: > It would be a bad idea to remove functionality from the readline > package. It's a binding to the GNU readline library, and as such it does > a fine job. I only want to move (not remove). > For convenience, we would like there to be an API that can be supported > by both readline and editline. It would be a bad idea for this to be a > package, because (as I mentioned earlier on libraries@) that package > would have a variant license, depending on whether the API-provider was > readline or editline at build-time (or perhaps in the future link-time > or run-time). If you chose between readline and editline, then you have > to make an explicit choice in your .cabal file - making a package that > abstracts this choice is not good, unless said package is explicitly GPL'd. Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado. > So the compatible API could be in a module that is exposed by *both* > readline and editline, say System.Console.ReadlineCompat. So your > source code wouldn't have to change to switch from one to the other, > just your .cabal file. Things ghc does not support, users have to do. Christian From judah.jacobson at gmail.com Mon Jan 21 12:35:42 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 21 12:35:35 2008 Subject: Integrating editline with ghc In-Reply-To: <47947687.6020604@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> Message-ID: <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> On Jan 21, 2008 2:40 AM, Christian Maeder wrote: > Judah Jacobson wrote: > > I think it will be much simpler if we keep the readline and editline > > packages as they are now, and possibly add a third readline-compat > > package which can use either one as a dependency. Then any project > > (including GHC) can choose which of those packages to use, based on > > API requirements and/or license issues. > > Could then editline go already into ghc-6.8.3, because interfaces don't > change? > > Re-iterating, I would like to see your package readline-compat and hope > it will be sufficient for the packages Shellac and Shellac-readline. > (Even better if the current package readline is renamed to old-readline > and readline-compat to readline.) Hmm...As Christian suggested to me in a private email, I was wrong in my initial testing of Shellac-readline: it relies on a variable (_history_max_entries) that is not in editline. So I think we should definitely keep the readline package the way that it is. Luckily, there are other functions, giving the same functionality, which are shared by readline and editline, and are scheduled to become official parts of readline in a week or two; see (http://www.nabble.com/Readline-read_history-and-write_history-addition-td14967976.html) I'll add those functions to the editline and readline-compat packages. > I wonder how many hackage packages have readline as build-depends (and > how many of them would be content with readline-compat). > > Which version of editline to you require? > > Our newest version installed (under Solaris) is: editline.h,v 1.5 > > Which include files are used on Macs? On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that. Thanks, -Judah From jb162 at brighton.ac.uk Mon Jan 21 16:03:33 2008 From: jb162 at brighton.ac.uk (Jim Burton) Date: Mon Jan 21 16:03:32 2008 Subject: Problem building on host machine when trying to cross-compile an unregistered build In-Reply-To: <4794B90A.9030305@gmail.com> References: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> <1200680528.5324.29.camel@unicorn> <4794B90A.9030305@gmail.com> Message-ID: <1200949413.20938.3.camel@unicorn> On Mon, 2008-01-21 at 15:23 +0000, Simon Marlow wrote: > Jim Burton wrote: [...] > First thing to note is that bootstrapping from HC files has bitrotted in > 6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated > the wiki instructions to say this. You should go back to 6.6.x, or be > prepared to fix things... I thought I remembered someone saying recently > they were looking into getting bootstrapping working again, but I can't > seem to find it now. > Hi,thanks for your help. I'll try 6.6.1 and let you know how I get on. Jim > > > On Mon, 2008-01-14 at 12:41 +0000, jb162@brighton.ac.uk wrote: > >> Hi, host machine is Linux i386 and the target is NetBSD alpha, ghc > >> 6.8.2. With the help of the list the first part (on the target) is done > >> and I'm building the compiler on the host -- when building rts I get > >> > >> "cc1: error: unrecognized command line option "-mieee" > > It looks like this comes from mk/bootstrap.mk, which says: > > ifeq "$(alpha_TARGET_ARCH)" "1" > PLATFORM_CC_OPTS += -static -w > PLATFORM_HC_BOOT_CC_OPTS += -mieee > endif > > So someone in the past thought it was a good idea to pass this option when > compiling .hc files. I can't tell you any more than that - perhaps just > removing that line will get you going again. > > Cheers, > Simon > > > >> What's this about? (I notice a couple of seemingly ignorable warnings in > >> the following, about missing gmpbuild and libHSrts.a. Is that relevant?) > >> Thanks. > >> > >> jim@mowa624-jb162:~/ghc-6.8.2/compiler$ cd ../rts && make boot && make > >> gcc -E -undef -traditional -P \ > >> -DIMPORT_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > >> -DLIB_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > >> > >> -DINCLUDE_DIR='"/home/jim/ghc-6.8.2/libraries/rts/include"' \ > >> -DDATA_DIR='"/home/jim/ghc-6.8.2/libraries/rts"' \ > >> -DHTML_DIR='"/home/jim/ghc-6.8.2/libraries/rts/html"' \ > >> > >> -DHADDOCK_IFACE='"/home/jim/ghc-6.8.2/libraries/rts/html/rts.haddock"' \ > >> -DFPTOOLS_TOP_ABS='"/home/jim/ghc-6.8.2"' \ > >> -x c -DGMP_INCLUDE_DIRS='' -DGMP_LIB_DIRS='' > >> -I../includes -Iinclude -DPACKAGE=rts -DVERSION= > >> -DPKG_LIBDIR='"/usr/local/lib/ghc-6.8.2"' > >> -DPKG_DATADIR='"/usr/local/share/ghc-6.8.2"' package.conf.in | \ > >> grep -v '^#pragma GCC' | \ > >> sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.inplace > >> ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files > >> >> Reading package info from stdin ... done. > >> /home/jim/ghc-6.8.2/gmp/gmpbuild doesn't exist or isn't a directory > >> (ignoring) > >> cannot find libHSrts.a on library path (ignoring) > >> Saving old package config file... done. > >> Writing new package config file... done. > >> ../utils/mkdependC/mkdependC -f .depend -I. -I../includes -DPROFILING > >> -DTHREADED_RTS -DDEBUG -Ihooks -Iparallel -Ism -Iposix -I../includes > >> -s debug -- -O -Wall -W -Wstrict-prototypes -Wmissing-prototypes > >> -Wmissing-declarations -Winline -Waggregate-return -I../includes -I. > >> -Iparallel -Ism -DCOMPILING_RTS -fomit-frame-pointer -DNOSMP > >> -I../gmp/gmpbuild -fno-strict-aliasing -- Adjustor.c Arena.c > >> Capability.c ClosureFlags.c Disassembler.c FrontPanel.c Hash.c Hpc.c > >> HsFFI.c Interpreter.c LdvProfile.c Linker.c Main.c Papi.c Printer.c > >> ProfHeap.c Profiling.c Proftimer.c RaiseAsync.c RetainerProfile.c > >> RetainerSet.c RtsAPI.c RtsFlags.c RtsMessages.c RtsStartup.c RtsUtils.c > >> STM.c Sanity.c Schedule.c Sparks.c Stable.c Stats.c StgCRun.c > >> StgPrimFloat.c Task.c ThreadLabels.c ThreadPaused.c Threads.c Ticky.c > >> Timer.c Trace.c Typeable.c Weak.c hooks/FlagDefaults.c > >> hooks/InitEachPE.c hooks/MallocFail.c hooks/OnExit.c hooks/OutOfHeap.c > >> hooks/RtsOpts.c hooks/ShutdownEachPEHook.c hooks/StackOverflow.c > >> parallel/0Hash.c parallel/0Unpack.c parallel/Dist.c parallel/Global.c > >> parallel/GranSim.c parallel/HLComms.c parallel/LLComms.c parallel/Pack.c > >> parallel/ParInit.c parallel/ParTicky.c parallel/Parallel.c > >> parallel/ParallelDebug.c parallel/RBH.c posix/FileLock.c posix/GetTime.c > >> posix/Itimer.c posix/OSMem.c posix/OSThreads.c posix/Select.c > >> posix/Signals.c sm/BlockAlloc.c sm/Compact.c sm/Evac.c sm/GC.c > >> sm/GCUtils.c sm/MBlock.c sm/MarkWeak.c sm/Scav.c sm/Storage.c > >> ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W > >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes > >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return > >> -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism > >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP > >> -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -H32m > >> -keep-hc-files -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild > >> -I. -#include HCIncludes.h -dcmm-lint -c Adjustor.c -o Adjustor.o > >> cc1: error: unrecognized command line option "-mieee" > >> make: *** [Adjustor.o] Error 1 > >> > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users@haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From kili at outback.escape.de Mon Jan 21 18:21:48 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Jan 21 18:25:45 2008 Subject: Problem building on host machine when trying to cross-compile an unregistered build In-Reply-To: <4794B90A.9030305@gmail.com> References: <1200314475.5640.19.camel@mowa624-jb162.university.brighton.ac.uk> <1200680528.5324.29.camel@unicorn> <4794B90A.9030305@gmail.com> Message-ID: <20080121232147.GA19883@petunia.outback.escape.de> On Mon, Jan 21, 2008 at 03:23:54PM +0000, Simon Marlow wrote: > First thing to note is that bootstrapping from HC files has bitrotted in > 6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated > the wiki instructions to say this. You should go back to 6.6.x, or be > prepared to fix things... I thought I remembered someone saying recently > they were looking into getting bootstrapping working again, but I can't > seem to find it now. That may be me. I've some local patches for obvious offending stuff (like utils/pwd or libraries/ifBuildable), and similar more or less trivia in libraries/Makefile, but I didn't yet even hit the problems I expect for the GNUmakefiles generated by cabal (which I tend to include in a pre-build HC file bundle), not speaking of *real* problems that may (will?) happen on the HC files themselves when all the make issues have been fixed. I asked igloo the other day, and now I ask here: if anyone has *any* attempts for the make problems, even if they don't work, just mail your diffs to me. No promises, no timeline[1], but I really want to get HC bootstrapping back. Ciao, Kili [1] Everytime I expect to have some more time to work on things I want to work on, something bad happens that stops me from doing so. At least within the last 14 months. From p.k.f.holzenspies at utwente.nl Tue Jan 22 03:29:13 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Tue Jan 22 03:25:18 2008 Subject: Bootstrapping for Leopard Message-ID: <200801220929.13869.p.k.f.holzenspies@utwente.nl> Dear All, I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts (handy for installing other ghc-dependent material from MacPorts like gtk2hs). The problem seems to be that the available bootstrap binary http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.bz2 causes a segfault on Leopard (below are the steps I took in my attempt to build ghc with this bootstrap binary). Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386-apple-darwin building ghc-6.8.2 works fine. It seemed to me that the easiest way to fix the bootstrap problem is to boot from C as described on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two things were wrong, however. make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ if test "x$$f" !=3D "x"; then \ echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ fi; \ done; This adds some non-existing .hc files to the hc-files-to-go list that tar will not find, later on, causing an error. I just added a test to see whether the file exists. If it does not, I call make for that .hc file explicitly, which solves the problem for most files. The files that don't have a make target, I simply omitted from the hc-files-to-go. I haven't been able to test the severity of this, because of the second problem. sh -e ./distrib/hc-build --prefix=3D$HOME/src/testbuild [--enable-hc-boot [--enable-hc-boot-unregisterised]] As a minor bug wrt. the wiki page, the hc-build is not executable by default. The more serious problem seems to be that the cold-boot option of configure is broken, because it ends in the error: checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: -v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler. Are these bugs or am I messing things up? Regards, Philip From Christian.Maeder at dfki.de Tue Jan 22 04:09:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 04:09:09 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> Message-ID: <4795B2C1.4090406@dfki.de> Judah Jacobson wrote: > On OS X 10.4, I have readline.h,v 1.11 as the libedit readline > compatibility header. Can you please try linking a simple program > that uses System.Console.Editline.Readline on your Solaris machine and > see if it throws up any link errors? If so, I may be able to fix > that. I wasn't able to install your editline-0.1 package under Solaris. Our installed files are: /usr/local/lib/libeditline.so -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0 -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0.0.0 /usr/local/lib/libeditline.a /usr/local/lib/libeditline.la /usr/local/include/editline.h Christian checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init in -ledit... no checking for readline in -ledit... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes configure: error: editline not found, so this package cannot be built From emmanuel.delaborde at citycampus.com Tue Jan 22 04:34:06 2008 From: emmanuel.delaborde at citycampus.com (manu) Date: Tue Jan 22 04:36:57 2008 Subject: GHC 6.8.2 for mac PPC and HAppS Message-ID: <6618E3D3-207A-4DBC-8CB7-1A81ADC4708C@citycampus.com> I've installed Christian's 6.8.2 binary on my PPC Mac at home (OS X 10.4) and wen I try to install HAppS : manu-2:~/Sites/MyProject manu$ sp ghc -isrc src/Main.hs --make --run -- http-port=5000 I get : downloading modules... <> I had this issue too... > After manually compiling GHC (i was using Debian's package) and then > recompiling sp, It has gone away.... Wonder what it was. So I wonder, to what extent is it due to my ghc install ? Thanks Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080122/8bd564c9/attachment.htm From chak at cse.unsw.edu.au Tue Jan 22 04:41:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Jan 22 04:41:21 2008 Subject: Integrating editline with ghc In-Reply-To: <47906B7A.6050407@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> Message-ID: <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> Christian Maeder: > Manuel M T Chakravarty wrote: >> Christian Maeder: >>> 1. a _new_ readline package that only contains the interface that >>> can be >>> implemented using libeditline _or_ libreadline. If this package is >>> call >>> "readline" (with a new version number) most libraries i.e. like >>> Shellac >>> would not need modifications. >> >> I disagree. Readline should stay as it is. (Why force existing >> readline users who use functionality not supported by editline's >> emulation layer to change the package they are using?) > > Your point is also supported by Yitz Gale, my point by Malcolm. > > Where are the users that use the functionality not supported by > editline's emulation layer? (Shout now or be quiet ever after) Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using? Manuel From Christian.Maeder at dfki.de Tue Jan 22 04:52:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 04:52:32 2008 Subject: Integrating editline with ghc In-Reply-To: <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> Message-ID: <4795BCE9.6080205@dfki.de> Manuel M T Chakravarty wrote: > Christian Maeder: >> Manuel M T Chakravarty wrote: >>> Christian Maeder: >>>> 1. a _new_ readline package that only contains the interface that >>>> can be >>>> implemented using libeditline _or_ libreadline. If this package is call >>>> "readline" (with a new version number) most libraries i.e. like Shellac >>>> would not need modifications. >>> >>> I disagree. Readline should stay as it is. (Why force existing >>> readline users who use functionality not supported by editline's >>> emulation layer to change the package they are using?) >> >> Your point is also supported by Yitz Gale, my point by Malcolm. >> >> Where are the users that use the functionality not supported by >> editline's emulation layer? (Shout now or be quiet ever after) > > Are you seriously suggesting that we mess up users who do not read the > various mailing lists constantly to defend the APIs they are using? I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. Christian From Christian.Maeder at dfki.de Tue Jan 22 05:36:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 05:36:40 2008 Subject: GHC 6.8.2 for mac PPC and HAppS In-Reply-To: References: Message-ID: <4795C743.8070600@dfki.de> manu wrote: > I've installed Christian's 6.8.2 binary on my PPC Mac at home (OS X 10.4) > > and wen I try to install HAppS : > > manu-2:~/Sites/MyProject manu$ sp ghc -isrc src/Main.hs --make --run > --http-port=5000 > > I get : > > downloading modules... > <>Conf {hsFiles = ["src/Main.hs"], modLocs = [], mapLocs = [MapDir "src",MapFile ".searchpath.default.map",MapURI "http://searchpath.org/default.map"], cargs = ["--make"], cacheDir = "/home/maeder/.SearchPath", exe = "ghc", maxAge = 1209600, glasgow = True, start = 1200997905, verbose = 0, target = "Main.exe", useDefaultMap = True, runArgs = Just ["--http-port=5000"]} <>"darcs get --partial http://happs.org/repos/HAppS-Server" Copying patch 192 of 192... done. Applying patch 191 of 191... done. Finished getting. "darcs get --partial http://happs.org/repos/HAppS-State" Copying patch 115 of 115... done. Applying patch 114 of 114... done. Finished getting. <>"darcs get --partial http://happs.org/repos/HAppS-Data" Copying patch 52 of 52... done. Applying patch 51 of 51... done. Finished getting. "darcs get --partial --tag=0.9.1.2 http://happs.org/repos/HAppS-Util util; echo hello world" Copying patch 18 of 18... done. Applying patch 17 of 17... done. darcs: Couldn't find a tag matching "tag-name 0.9.1.2" hello world "darcs get --partial --tag=0.9.1.2 http://happs.org/repos/syb-with-class" Copying patch 24 of 24... done. Applying patch 24 of 24... done. Unapplying 3 patches. Finished getting. <>"/private/var/automount/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz" "tar -xzf http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz" foo bar <<<<<><><><><<<><><><>< <><>"darcs get --partial --tag=0.9.1.2 http://happs.org/repos/HAppS-IxSet" Copying patch 33 of 33... done. Applying patch 32 of 32... done. Unapplying 5 patches. Finished getting. "ghc -isrc -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src -i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src -i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src -i/home/maeder/.SearchPath -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.3_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class -i/home/maeder/.SearchPath -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src -i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src -i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src -i/home/maeder/.SearchPath -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src -i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.3_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-State/HAppS-State/src -i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class -i/home/maeder/.SearchPath -o Main.exe.sp.new -cpp -fth -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances src/Main.hs --make" [ 1 of 83] Compiling HAppS.Crypto.SHA1 ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/SHA1.lhs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/SHA1.o ) [ 2 of 83] Compiling HAppS.Server.HTTP.Clock ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Clock.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Clock.o ) [ 3 of 83] Compiling HAppS.Server.HTTP.LazyLiner ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/LazyLiner.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/LazyLiner.o ) [ 4 of 83] Compiling HAppS.Server.JSON ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/JSON.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/JSON.o ) [ 5 of 83] Compiling HAppS.Server.HTTP.RFC822Headers ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/RFC822Headers.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/RFC822Headers.o ) [ 6 of 83] Compiling HAppS.Server.HTTP.Multipart ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Multipart.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Multipart.o ) [ 7 of 83] Compiling HAppS.Util.ByteStringCompat ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/ByteStringCompat.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/ByteStringCompat.o ) [ 8 of 83] Compiling HAppS.Server.SURI.ParseURI ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SURI/ParseURI.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SURI/ParseURI.o ) [ 9 of 83] Compiling HAppS.Util.Exception ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Exception.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Exception.o ) [10 of 83] Compiling HAppS.Crypto.Base64 ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/Base64.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/Base64.o ) [11 of 83] Compiling HAppS.Util.Concurrent ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Concurrent.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Concurrent.o ) [12 of 83] Compiling HAppS.Util.TimeOut ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/TimeOut.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/TimeOut.o ) [13 of 83] Compiling HAppS.State.Saver.Types ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Types.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Types.o ) [14 of 83] Compiling HAppS.State.Saver.Impl.Queue ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Impl/Queue.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Impl/Queue.o ) [15 of 83] Compiling HAppS.Data.GOps ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/GOps.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/GOps.o ) [16 of 83] Compiling HAppS.Data.Migrate ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Migrate.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Migrate.o ) [17 of 83] Compiling HAppS.Util.TH ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/TH.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/TH.o ) [18 of 83] Compiling Data.Generics.SYB.WithClass.Context ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Context.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Context.o ) [19 of 83] Compiling Data.Generics.SYB.WithClass.Basics ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Basics.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Basics.o ) [20 of 83] Compiling HAppS.Data.Normalize ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Normalize.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Normalize.o ) [21 of 83] Compiling Data.Generics.SYB.WithClass.Derive ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Derive.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Derive.o ) [22 of 83] Compiling Data.Generics.SYB.WithClass.Instances ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Instances.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class/Data/Generics/SYB/WithClass/Instances.o ) Loading package base ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. [23 of 83] Compiling HAppS.Data.Default ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Default.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Default.o ) [24 of 83] Compiling HAppS.Data.DeriveAll ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/DeriveAll.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/DeriveAll.o ) [25 of 83] Compiling HAppS.Data.Xml.Base ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/Base.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/Base.o ) Loading package bytestring-0.9.0.1 ... linking ... done. [26 of 83] Compiling HAppS.Data.HListBase ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/HListBase.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/HListBase.o ) [27 of 83] Compiling System.Log ( /home/maeder/.SearchPath/System/Log.hs, /home/maeder/.SearchPath/System/Log.o ) [28 of 83] Compiling System.Log.Handler ( /home/maeder/.SearchPath/System/Log/Handler.hs, /home/maeder/.SearchPath/System/Log/Handler.o ) [29 of 83] Compiling System.Log.Handler.Simple ( /home/maeder/.SearchPath/System/Log/Handler/Simple.hs, /home/maeder/.SearchPath/System/Log/Handler/Simple.o ) [30 of 83] Compiling System.Log.Logger ( /home/maeder/.SearchPath/System/Log/Logger.hs, /home/maeder/.SearchPath/System/Log/Logger.o ) [31 of 83] Compiling HAppS.State.Saver.Impl.File ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Impl/File.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver/Impl/File.o ) [32 of 83] Compiling HAppS.State.Saver ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Saver.o ) [33 of 83] Compiling System.Log.Handler.Syslog ( /home/maeder/.SearchPath/System/Log/Handler/Syslog.hs, /home/maeder/.SearchPath/System/Log/Handler/Syslog.o ) [34 of 83] Compiling HAppS.Util.Common ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Common.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Common.o ) [35 of 83] Compiling HAppS.Server.Cookie ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/Cookie.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/Cookie.o ) [36 of 83] Compiling HAppS.Server.SURI ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SURI.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SURI.o ) [37 of 83] Compiling HAppS.Server.HTTP.Types ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Types.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Types.o ) [38 of 83] Compiling HAppS.Util.Daemonize ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Daemonize.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Util/Daemonize.o ) [39 of 83] Compiling HAppS.Data.Xml.Instances ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/Instances.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/Instances.o ) Loading package mtl-1.1.0.0 ... linking ... done. [40 of 83] Compiling Text.XML.HaXml.Types ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Types.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Types.o ) [41 of 83] Compiling Text.XML.HaXml.Verbatim ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Verbatim.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Verbatim.o ) [42 of 83] Compiling HAppS.Data.Xml.HaXml ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/HaXml.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/HaXml.o ) [43 of 83] Compiling Text.XML.HaXml.Pretty ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Pretty.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Pretty.o ) [44 of 83] Compiling Text.XML.HaXml.Lex ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Lex.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Lex.o ) [45 of 83] Compiling Text.XML.HaXml.Escape ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Escape.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Escape.o ) [46 of 83] Compiling Text.ParserCombinators.HuttonMeijerWallace ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/ParserCombinators/HuttonMeijerWallace.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/ParserCombinators/HuttonMeijerWallace.o ) [47 of 83] Compiling Text.XML.HaXml.Parse ( /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Parse.hs, /home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src/Text/XML/HaXml/Parse.o ) [48 of 83] Compiling HAppS.Data.Xml.PrintParse ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/PrintParse.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml/PrintParse.o ) [49 of 83] Compiling HAppS.Data.Xml ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Xml.o ) [50 of 83] Compiling HAppS.Data.Pairs ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Pairs.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Pairs.o ) [51 of 83] Compiling HAppS.Data.HList ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/HList.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/HList.o ) /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/HList.hs:37:0: Warning: No explicit method nor default method for `fromPairs'' In the instance declaration for `CoupleClass (Couple a b)' [52 of 83] Compiling HAppS.Data ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data.o ) [53 of 83] Compiling HAppS.Data.Atom ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Atom.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src/HAppS/Data/Atom.o ) [54 of 83] Compiling HAppS.State.Types ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Types.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Types.o ) [55 of 83] Compiling HAppS.State.Monad ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Monad.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Monad.o ) [56 of 83] Compiling HAppS.State.Logger ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Logger.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Logger.o ) [57 of 83] Compiling HAppS.State.Util ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Util.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Util.o ) [58 of 83] Compiling HAppS.State.Serialize ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Serialize.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Serialize.o ) [59 of 83] Compiling HAppS.State.Transaction ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Transaction.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Transaction.o ) [60 of 83] Compiling HAppS.State.ComponentTypes ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/ComponentTypes.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/ComponentTypes.o ) [61 of 83] Compiling HAppS.State.Checkpoint ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Checkpoint.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Checkpoint.o ) [62 of 83] Compiling HAppS.State.OperationModes ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/OperationModes.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/OperationModes.o ) [63 of 83] Compiling HAppS.State.TxControl ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/TxControl.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/TxControl.o ) [64 of 83] Compiling HAppS.State.Control ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Control.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/Control.o ) [65 of 83] Compiling HAppS.State.ComponentTH ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/ComponentTH.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State/ComponentTH.o ) [66 of 83] Compiling HAppS.State ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src/HAppS/State.o ) [67 of 83] Compiling HAppS.Server.Cron ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/Cron.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/Cron.o ) [68 of 83] Compiling HAppS.Data.IxSet.Ix ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src/HAppS/Data/IxSet/Ix.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src/HAppS/Data/IxSet/Ix.o ) [69 of 83] Compiling HAppS.Data.IxSet ( /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src/HAppS/Data/IxSet.hs, /home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src/HAppS/Data/IxSet.o ) [70 of 83] Compiling HAppS.Server.MinHaXML ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/MinHaXML.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/MinHaXML.o ) [71 of 83] Compiling HAppS.Server.XSLT ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/XSLT.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/XSLT.o ) [72 of 83] Compiling HAppS.Server.MessageWrap ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/MessageWrap.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/MessageWrap.o ) [73 of 83] Compiling HAppS.Server.HTTP.Handler ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Handler.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Handler.o ) [74 of 83] Compiling HAppS.Server.HTTP.Listen ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Listen.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Listen.o ) [75 of 83] Compiling HAppS.Server.HTTP.Client ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Client.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Client.o ) [76 of 83] Compiling HAppS.Server.AlternativeHTTP ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/AlternativeHTTP.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/AlternativeHTTP.o ) /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/AlternativeHTTP.hs:26:6: Warning: `Response' is exported by `Response' and `module HAppS.Server.HTTP.Types' [77 of 83] Compiling HAppS.Server.HTTP.AltFileServe ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/AltFileServe.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/AltFileServe.o ) [78 of 83] Compiling HAppS.Server.SimpleHTTP ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SimpleHTTP.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/SimpleHTTP.o ) [79 of 83] Compiling HAppS.Server.HTTP.FileServe ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/FileServe.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/FileServe.o ) [80 of 83] Compiling HAppS.Server.StdConfig ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/StdConfig.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/StdConfig.o ) [81 of 83] Compiling HAppS.Store.Util ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Store/Util.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Store/Util.o ) [82 of 83] Compiling HAppS.Server ( /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server.hs, /home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server.o ) [83 of 83] Compiling Main ( src/Main.hs, src/Main.o ) Linking Main.exe.sp.new ... New executable. (Re-) starting ["/local/home/maeder/haskell/MyProject/Main.exe","--http-port=5000"] From gale at sefer.org Tue Jan 22 06:40:50 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 06:40:40 2008 Subject: Integrating editline with ghc In-Reply-To: <4795BCE9.6080205@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> Message-ID: <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> Christian Maeder wrote: >>> Where are the users that use the functionality not supported by >>> editline's emulation layer? (Shout now or be quiet ever after) > I only wanted to find out which user group would need to change readline > to editline and (if following my suggestion) which group readline to > GPL-readline in cabal files, and which of the two user groups is bigger. > > Since it's not clear yet, what portion of readline can be emulated by > editline this is difficult to estimate. It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz From simonmarhaskell at gmail.com Tue Jan 22 06:52:21 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jan 22 06:52:12 2008 Subject: Integrating editline with ghc In-Reply-To: <4794D21F.6080201@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> <4794C037.90609@gmail.com> <4794D21F.6080201@dfki.de> Message-ID: <4795D8F5.2000405@gmail.com> Christian Maeder wrote: > Simon Marlow wrote: >> It would be a bad idea to remove functionality from the readline >> package. It's a binding to the GNU readline library, and as such it does >> a fine job. > > I only want to move (not remove). I don't think it's necessary to remove (or move) anything from readline at all. That would break clients unnecessarily. By all means add a new module that exports the lowest-common-denominator API. >> For convenience, we would like there to be an API that can be supported >> by both readline and editline. It would be a bad idea for this to be a >> package, because (as I mentioned earlier on libraries@) that package >> would have a variant license, depending on whether the API-provider was >> readline or editline at build-time (or perhaps in the future link-time >> or run-time). If you chose between readline and editline, then you have >> to make an explicit choice in your .cabal file - making a package that >> abstracts this choice is not good, unless said package is explicitly GPL'd. > > Actually, the license is not (so) important for me. I basically want the > convenience to link against libedit on Macs and against libreadline on > other unix system, because these libs are usually there without further ado. But other people really do care about licenses, and it's vitally important that each package has a clearly-defined license. Under my proposal you would be able to do exactly what you want. The difference is that you can't hide the choice between libedit and libreadline in a package of its own, unless that package is GPL. >> So the compatible API could be in a module that is exposed by *both* >> readline and editline, say System.Console.ReadlineCompat. So your >> source code wouldn't have to change to switch from one to the other, >> just your .cabal file. > > Things ghc does not support, users have to do. This isn't about GHC, it's about the readline/editline packages! Cheers, Simon From Christian.Maeder at dfki.de Tue Jan 22 07:29:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 07:29:42 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> Message-ID: <4795E1C1.9020506@dfki.de> Yitzchak Gale wrote: > We should not cause people's programs to break silently by > changing a fundamental API, unless there is no alternative. > In this case there is a reasonable alternative. Anyone who wants > to change over to editline - native or readline-compatible - can > easily do so, at their leisure. Anyone who wants things to stay > the way they are can do nothing. 1. Things don't break silently (I hope), they break during compilation. 2. With every new ghc major version (or library version) there is a list of user visible changes. 3. if ghci is going to use editline (at least on Macs by default) then readline would not need to be a core package und users might need to install package readline explicitely. (Then at least everybody using readline has to do something manually, at least users on Macs who complain most if something does not run out of the box.) > Do you see any problem with that approach? No, I've only pointed out the alternative, I hope. I don't know what fits the needs of the majority most. Let's vote? Christian From gale at sefer.org Tue Jan 22 09:24:24 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 09:24:15 2008 Subject: Integrating editline with ghc In-Reply-To: <4795E1C1.9020506@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> Message-ID: <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> Christian Maeder wrote: > 3. if ghci is going to use editline... then readline would not > need to be a core package und users might need to > install package readline explicitly. OK, I get it. Even if we leave readline as it is, so that the package system will theoretically not force the person to take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz From Christian.Maeder at dfki.de Tue Jan 22 11:28:46 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 11:28:34 2008 Subject: Integrating editline with ghc In-Reply-To: <4796120E.8060101@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk> <4796120E.8060101@dfki.de> Message-ID: <479619BE.5080002@dfki.de> (my previous mail went to the bugs list by accident) Christian Maeder wrote: > I would like to know from package maintainers if there packages can be > easily ported from libreadline to libedit. > > The best indication for this would be if the package is also happy with > a restricted interface of readline (i.e. readline-compat) or requires > the full GNU readline. > > At least testing this compatibility makes sense using a readline package > with a temporarily reduced interface (without the need to change the > packages depending on readline.) In short, consider a split up of the readline package into readline-basics and readline-exts (both with GPL licence). Unfortunately it is not possible to have the package readline to be the union of readline-basics and readline-exts. So readline-basic (or readline-compat) would be a duplication of a reduced readline package. For porting packages from libreadline to libedit it would be sufficient to replace readline-basics with editline (and change the licence) in *.cabal files. Packages depending on more then readline-basics cannot be ported. I'm only worried if any package maintainer would bother to change the build-depends from readline to readline-basic (if not forced to change it anyway, i.e. to readline-basic and readline-ext). Alternatively, if the interface of readline is reduced to that of readline-basic, package maintainers could hope that their package is still okay and if not (after compilation errors) add readline-ext to their build-depends. Is this really such a crazy idea? Christian From bringert at cs.chalmers.se Tue Jan 22 11:31:01 2008 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Tue Jan 22 11:29:22 2008 Subject: Network.CGI changes In-Reply-To: <20080121120147.GP11635@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> Message-ID: <47961A45.2090706@cs.chalmers.se> Hi Frederik, (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.) That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain. The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI. I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs /Bj?rn Frederik Eaton wrote: > Dear Johannes, > > Thanks, that works for me. > > Bjorn, perhaps it would be easier to put these five lines in a module > (Network.CGI.Compat?) in the new package, rather than having people > maintain and download a separate cgi-compat package? Perhaps the two > other functions in the old CGI interface can be implemented in terms > of the new API as well? > > Best wishes, > > Frederik > > On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: >> If you need the old "wrapper" function, then use something like this: >> >> wrapper :: ([(String,String)] -> IO Html) -> IO () >> wrapper f = runCGI $ do >> >> e <- getInputs >> a <- lift $ f $ e >> output $ renderHtml a >> >> best regards, Johannes Waldmann. >> > From frederik at a5.repetae.net Tue Jan 22 12:28:34 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Jan 22 12:28:22 2008 Subject: Network.CGI changes In-Reply-To: <47961A45.2090706@cs.chalmers.se> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> Message-ID: <20080122172834.GV11635@a5.repetae.net> Hi Bjorn, Well, I don't know what the solution is. As I have said, I think it would be best to keep Network.CGI.Compat. That way, users of the old module just have to change the module name, plus they don't have to hack cgi-compat to get it to compile when cgi is already working. A typical project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist... Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility. Frederik On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: > Hi Frederik, > > (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in > the cgi package can shout.) > > That exact module actually used to exist in the cgi package as well (it implemented the > complete API of the old Network.CGI), but after a few releases I removed it since it didn't > seem to have any users. That was quite a long time ago, and you are the first person to > complain. > > The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be > installable on older GHC versions, hence the main module name Network.NewCGI. > > I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi > package. The old Network.CGI seemed to have very few users, due to to it's restrictions. > You can always get Network.CGI.Compat from here, and include it in your program: > http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs > > /Bj?rn > > Frederik Eaton wrote: > >Dear Johannes, > >Thanks, that works for me. > >Bjorn, perhaps it would be easier to put these five lines in a module > >(Network.CGI.Compat?) in the new package, rather than having people > >maintain and download a separate cgi-compat package? Perhaps the two > >other functions in the old CGI interface can be implemented in terms > >of the new API as well? > >Best wishes, > >Frederik > >On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > >>If you need the old "wrapper" function, then use something like this: > >> > >>wrapper :: ([(String,String)] -> IO Html) -> IO () > >>wrapper f = runCGI $ do > >> > >> e <- getInputs > >> a <- lift $ f $ e > >> output $ renderHtml a > >> > >>best regards, Johannes Waldmann. > >> > -- http://ofb.net/~frederik/ From mfn-ghc at cs.york.ac.uk Wed Jan 23 06:16:33 2008 From: mfn-ghc at cs.york.ac.uk (Matthew Naylor) Date: Wed Jan 23 06:21:41 2008 Subject: ghc -O Message-ID: <20080123111633.GA4262@pc149.staff.cs.york.ac.uk> Hello GHC gurus, specifying "-O" or "-O2" to GHC enables various optimisations to the frontend of the compiler, but I wonder does it turn on any optimistions to the backend/code-generator that are independent of the frontend? I can imagine that knowledge such as strictness which is computed by frontend would enable optimisations in the backend, but I'm more interested in whether the backend would do anything independent (e.g. peephole optimistion, C compiler options) with "-O" but not without. Thanks, Matt. From robin.houston at gmail.com Wed Jan 23 11:38:25 2008 From: robin.houston at gmail.com (Robin Houston) Date: Wed Jan 23 11:38:07 2008 Subject: Link failures using GHC 6.8.2 on OS X 10.1.11 (PPC) Message-ID: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> This morning I downloaded and installed ghc-6.8.2-powerpc-apple-darwin.tar.bz2. I'm now getting link errors when I use ghc. For example, the simple program import qualified Data.IntSet as IntSet main = print $ IntSet.empty gives the errors: /usr/bin/ld: Undefined symbols: ___stginit_containerszm0zi1zi0zi1_DataziIntSet_ _containerszm0zi1zi0zi1_DataziIntSet_empty_closure _containerszm0zi1zi0zi1_DataziIntSet_zdf3_closure These symbols are defined in /usr/local/lib/ghc-6.8.2/lib/containers-0.1.0.1/libHScontainers-0.1.0.1.a, so apparently the linker is not finding this library. The same program does work in ghci, and in ghc-6.6 (which I was using previously). I've searched the list archives, and I haven't found any mention of this problem. Any help would be much appreciated! Robin From philip.weaver at gmail.com Wed Jan 23 11:47:34 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Jan 23 11:47:17 2008 Subject: Link failures using GHC 6.8.2 on OS X 10.1.11 (PPC) In-Reply-To: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> References: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> Message-ID: If you're building something that has leftover *.o and *.hi files from a previous version of ghc, that might cause the problem. Try to rm *.o *.hi ? This seemed to work for me one time. - Phil On Jan 23, 2008 8:38 AM, Robin Houston wrote: > This morning I downloaded and installed > ghc-6.8.2-powerpc-apple-darwin.tar.bz2. > I'm now getting link errors when I use ghc. For example, the simple > program > > import qualified Data.IntSet as IntSet > main = print $ IntSet.empty > > gives the errors: > > /usr/bin/ld: Undefined symbols: > ___stginit_containerszm0zi1zi0zi1_DataziIntSet_ > _containerszm0zi1zi0zi1_DataziIntSet_empty_closure > _containerszm0zi1zi0zi1_DataziIntSet_zdf3_closure > > These symbols are defined in > /usr/local/lib/ghc-6.8.2/lib/containers-0.1.0.1/libHScontainers-0.1.0.1.a, > so apparently the linker is not finding this library. > > The same program does work in ghci, and in ghc-6.6 (which I was using > previously). > > I've searched the list archives, and I haven't found any mention of > this problem. Any help would be much appreciated! > > Robin > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080123/b6554d45/attachment.htm From igloo at earth.li Wed Jan 23 11:55:30 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 23 11:55:13 2008 Subject: Link failures using GHC 6.8.2 on OS X 10.1.11 (PPC) In-Reply-To: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> References: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> Message-ID: <20080123165530.GA25291@matrix.chaos.earth.li> Hi Robin, On Wed, Jan 23, 2008 at 04:38:25PM +0000, Robin Houston wrote: > > import qualified Data.IntSet as IntSet > main = print $ IntSet.empty > > gives the errors: > > /usr/bin/ld: Undefined symbols: > ___stginit_containerszm0zi1zi0zi1_DataziIntSet_ > _containerszm0zi1zi0zi1_DataziIntSet_empty_closure > _containerszm0zi1zi0zi1_DataziIntSet_zdf3_closure You don't say what commandline you are using, but it sounds like you need to add either --make or -package containers. Thanks Ian From robin.houston at gmail.com Wed Jan 23 12:07:52 2008 From: robin.houston at gmail.com (Robin Houston) Date: Wed Jan 23 12:07:36 2008 Subject: Link failures using GHC 6.8.2 on OS X 10.1.11 (PPC) In-Reply-To: <20080123165530.GA25291@matrix.chaos.earth.li> References: <1b795e7b0801230838p137207a6o13520fde97cdad36@mail.gmail.com> <20080123165530.GA25291@matrix.chaos.earth.li> Message-ID: <1b795e7b0801230907v20d492dfwba9393463b0e2dea@mail.gmail.com> On 23/01/2008, Ian Lynagh wrote: > You don't say what commandline you are using, but it sounds like you > need to add either --make or -package containers. Aha, that works! Thanks. It worked without, using ghc-6.6. I guess that's because the containers stuff was moved into a separate library in 6.8.1. Robin From valery.vv at gmail.com Wed Jan 23 12:20:19 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Jan 23 12:20:02 2008 Subject: Arrow without `>>>' Message-ID: Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv From dave at zednenem.com Wed Jan 23 13:32:12 2008 From: dave at zednenem.com (David Menendez) Date: Wed Jan 23 13:32:14 2008 Subject: Arrow without `>>>' In-Reply-To: References: Message-ID: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: > I've built GHC from darcs, and... > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' > method? It's derived from the Category superclass. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080123/012bc73e/attachment.htm From Ben.Lippmeier at anu.edu.au Wed Jan 23 20:05:00 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Wed Jan 23 20:04:44 2008 Subject: ghc -O In-Reply-To: <20080123111633.GA4262@pc149.staff.cs.york.ac.uk> References: <20080123111633.GA4262@pc149.staff.cs.york.ac.uk> Message-ID: <4797E43C.4020103@anu.edu.au> Hi Matt, No, I don't think anything extra is done in the native code generator when -O or -O2 are enabled. I believe that strictness information is used in the core stages only, eg to change let bindings (which allocate thunks) to case expressions (which don't) - but I haven't worked on the GHC core so I'm not that familiar with it. There's a plan to turn on the iterative register allocator that I wrote with -O2, but the STG to C-- translation needs to be improved before that will have much effect on performance. This is currently being completely overhauled by Norman Ramsey and co, so perhaps in 6.10. Cheers, Ben. Matthew Naylor wrote: > Hello GHC gurus, > > specifying "-O" or "-O2" to GHC enables various optimisations to the > frontend of the compiler, but I wonder does it turn on any > optimistions to the backend/code-generator that are independent of the > frontend? > > I can imagine that knowledge such as strictness which is computed by > frontend would enable optimisations in the backend, but I'm more > interested in whether the backend would do anything independent (e.g. > peephole optimistion, C compiler options) with "-O" but not without. > > Thanks, > > Matt. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From valery.vv at gmail.com Thu Jan 24 08:10:39 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Jan 24 08:10:19 2008 Subject: Arrow without `>>>' In-Reply-To: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: On 1/23/08, David Menendez wrote: > On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: > > I've built GHC from darcs, and... > > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' > > method? > > It's derived from the Category superclass. Yes, it is. The right question: how to build `arrows' in such circumstances? Here go 2 changes I made to `CoState.hs' accompanied by the error messages. :) Unfortunately, I'm not arrow-capable enough to make _proper_ changes to the code and satisfy GHC... Any help? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change #1: $ darcs w Control/Arrow/Transformer/CoState.hs What's new in "Control/Arrow/Transformer/CoState.hs": { hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } -------------------------------------------------- Error #1: Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' Failed, modules loaded: Control.Arrow.Operations. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change #2: $ darcs diff -u Control/Arrow/Transformer/CoState.hs --- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 14:54:29.852296559 +0200 +++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 14:54:29.852296559 +0200 @@ -20,12 +20,13 @@ import Control.Arrow import Control.Arrow.Operations +import Control.Category ((>>>)) newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c)) instance Arrow a => Arrow (CoStateArrow s a) where arr f = CST (arr (f .)) - CST f >>> CST g = CST (f >>> g) +-- CST f >>> CST g = CST (f >>> g) first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap) zipMap :: (s -> a, s -> b) -> (s -> (a,b)) -------------------------------------------------- Error#2: Control/Arrow/Transformer/CoState.hs:27:0: Could not deduce (Control.Category.Category (CoStateArrow s a)) from the context (Arrow a) arising from the superclasses of an instance declaration at Control/Arrow/Transformer/CoState.hs:27:0 Possible fix: add (Control.Category.Category (CoStateArrow s a)) to the context of the instance declaration or add an instance declaration for (Control.Category.Category (CoStateArrow s a)) In the instance declaration for `Arrow (CoStateArrow s a)' Failed, modules loaded: Control.Arrow.Operations. Thank you. -- vvv From valery.vv at gmail.com Thu Jan 24 08:41:00 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Jan 24 08:40:40 2008 Subject: Fwd: Arrow without `>>>' In-Reply-To: References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> <20080124132116.GA12902@soi.city.ac.uk> Message-ID: The problem has been resolved. Kudos to Ross Paterson. ---------- Forwarded message ---------- From: Valery V. Vorotyntsev Date: Jan 24, 2008 3:34 PM Subject: Re: Arrow without `>>>' To: libraries@haskell.org On 1/24/08, Ross Paterson wrote: > > The right question: how to build `arrows' in such circumstances? > > To build with the darcs version of the base library (built with GHC), > you'll need the darcs version of the arrows library, which I think is > right now: > > darcs get http://darcs.haskell.org/packages/arrows Yes, after pulling the latest change from repo installation went smoothly. Thank you very much, Ross! From bringert at cs.chalmers.se Thu Jan 24 17:03:58 2008 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu Jan 24 17:03:53 2008 Subject: Network.CGI changes In-Reply-To: <20080122172834.GV11635@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> <20080122172834.GV11635@a5.repetae.net> Message-ID: <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> Hi Frederik, I agree with your comments about the headaches of Haskell library stability. I made the change because it seemed like the old library had no users. I should put my money where my mouth is, Network.CGI.Compat is now back in the cgi package. /Bjorn On Jan 22, 2008, at 18:28 , Frederik Eaton wrote: > Hi Bjorn, > > Well, I don't know what the solution is. As I have said, I think it > would be best to keep Network.CGI.Compat. That way, users of the old > module just have to change the module name, plus they don't have to > hack cgi-compat to get it to compile when cgi is already working. > > A typical project of mine uses 10 or more packages, and something that > makes me reluctant to use Haskell is the experience that after a few > years I will end up having to maintain separate versions of > significant numbers of those packages if I want something I wrote to > stay working. Haskell is supposed to be good for writing large > projects, but large projects need stable libraries or they become a > maintenance nightmare. It's rather worrying to see that people seem to > think that if I don't have time to participate actively in the mailing > lists or upload stuff to hackage, then my code doesn't exist... > > Maybe there is a high cost to keeping Network.CGI.Compat in the cgi > package, but I don't see any reason other than an aesthetics, which > seems like less of a priority than backwards compatibility. > > Frederik > > On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: >> Hi Frederik, >> >> (I'm CC:ing the libraries list, so that anyone who wants to have >> Network.CGI.Compat back in >> the cgi package can shout.) >> >> That exact module actually used to exist in the cgi package as >> well (it implemented the >> complete API of the old Network.CGI), but after a few releases I >> removed it since it didn't >> seem to have any users. That was quite a long time ago, and you >> are the first person to >> complain. >> >> The purpose of cgi-compat is actually not to provide >> Network.CGI.Compat, but rather to be >> installable on older GHC versions, hence the main module name >> Network.NewCGI. >> >> I'm not sure if there is sufficient demand for adding >> Network.CGI.Compat back into the cgi >> package. The old Network.CGI seemed to have very few users, due to >> to it's restrictions. >> You can always get Network.CGI.Compat from here, and include it in >> your program: >> http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/ >> Compat.hs >> >> /Bj?rn >> >> Frederik Eaton wrote: >>> Dear Johannes, >>> Thanks, that works for me. >>> Bjorn, perhaps it would be easier to put these five lines in a >>> module >>> (Network.CGI.Compat?) in the new package, rather than having people >>> maintain and download a separate cgi-compat package? Perhaps the two >>> other functions in the old CGI interface can be implemented in terms >>> of the new API as well? >>> Best wishes, >>> Frederik >>> On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: >>>> If you need the old "wrapper" function, then use something like >>>> this: >>>> >>>> wrapper :: ([(String,String)] -> IO Html) -> IO () >>>> wrapper f = runCGI $ do >>>> >>>> e <- getInputs >>>> a <- lift $ f $ e >>>> output $ renderHtml a >>>> >>>> best regards, Johannes Waldmann. >>>> >> > > -- > http://ofb.net/~frederik/ From fmartini at gmail.com Thu Jan 24 17:26:06 2008 From: fmartini at gmail.com (Felix Martini) Date: Thu Jan 24 17:25:46 2008 Subject: GHC on Solaris Nevada Message-ID: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> Hello all, I am trying to get a working GHC on Solaris Nevada (Solaris 11). I've tried the binary versions for Solaris 10 made by Christian Maeder. I couldn't get GHC 6.8.2 to install properly and GHC 6.6 does not work (it crashes the moment it needs to link to a library). After that i tried to make an unregistered bootstrap of GHC 6.6 using Linux as the host OS. The bootstrapping failed on Solaris when making genapply or cabal-setup. The linker reports symbol referencing errors. Has someone already successfully build GHC on Solaris 11? Regards, Felix From frederik at a5.repetae.net Fri Jan 25 02:53:20 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Jan 25 02:53:01 2008 Subject: Network.CGI changes In-Reply-To: <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> <20080122172834.GV11635@a5.repetae.net> <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> Message-ID: <20080125075320.GX11635@a5.repetae.net> Hi Bjorn, Thank you, that is good to hear. Thank you for giving us the better API as well. Frederik On Thu, Jan 24, 2008 at 11:03:58PM +0100, Bjorn Bringert wrote: > Hi Frederik, > > I agree with your comments about the headaches of Haskell library stability. I made the > change because it seemed like the old library had no users. I should put my money where my > mouth is, Network.CGI.Compat is now back in the cgi package. > > /Bjorn > > On Jan 22, 2008, at 18:28 , Frederik Eaton wrote: > > >Hi Bjorn, > > > >Well, I don't know what the solution is. As I have said, I think it > >would be best to keep Network.CGI.Compat. That way, users of the old > >module just have to change the module name, plus they don't have to > >hack cgi-compat to get it to compile when cgi is already working. > > > >A typical project of mine uses 10 or more packages, and something that > >makes me reluctant to use Haskell is the experience that after a few > >years I will end up having to maintain separate versions of > >significant numbers of those packages if I want something I wrote to > >stay working. Haskell is supposed to be good for writing large > >projects, but large projects need stable libraries or they become a > >maintenance nightmare. It's rather worrying to see that people seem to > >think that if I don't have time to participate actively in the mailing > >lists or upload stuff to hackage, then my code doesn't exist... > > > >Maybe there is a high cost to keeping Network.CGI.Compat in the cgi > >package, but I don't see any reason other than an aesthetics, which > >seems like less of a priority than backwards compatibility. > > > >Frederik > > > >On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: > >>Hi Frederik, > >> > >>(I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back > >>in > >>the cgi package can shout.) > >> > >>That exact module actually used to exist in the cgi package as well (it implemented the > >>complete API of the old Network.CGI), but after a few releases I removed it since it > >>didn't > >>seem to have any users. That was quite a long time ago, and you are the first person to > >>complain. > >> > >>The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be > >>installable on older GHC versions, hence the main module name Network.NewCGI. > >> > >>I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the > >>cgi > >>package. The old Network.CGI seemed to have very few users, due to to it's restrictions. > >>You can always get Network.CGI.Compat from here, and include it in your program: > >>http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs > >> > >>/Bj?rn > >> > >>Frederik Eaton wrote: > >>>Dear Johannes, > >>>Thanks, that works for me. > >>>Bjorn, perhaps it would be easier to put these five lines in a module > >>>(Network.CGI.Compat?) in the new package, rather than having people > >>>maintain and download a separate cgi-compat package? Perhaps the two > >>>other functions in the old CGI interface can be implemented in terms > >>>of the new API as well? > >>>Best wishes, > >>>Frederik > >>>On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > >>>>If you need the old "wrapper" function, then use something like this: > >>>> > >>>>wrapper :: ([(String,String)] -> IO Html) -> IO () > >>>>wrapper f = runCGI $ do > >>>> > >>>> e <- getInputs > >>>> a <- lift $ f $ e > >>>> output $ renderHtml a > >>>> > >>>>best regards, Johannes Waldmann. > >>>> > >> > > > >-- > >http://ofb.net/~frederik/ > -- http://ofb.net/~frederik/ From Christian.Maeder at dfki.de Fri Jan 25 03:48:49 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 25 03:48:27 2008 Subject: GHC on Solaris Nevada In-Reply-To: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> Message-ID: <4799A271.6020803@dfki.de> Felix Martini wrote: > Hello all, > > I am trying to get a working GHC on Solaris Nevada (Solaris 11). I've > tried the binary versions for Solaris 10 made by Christian Maeder. I > couldn't get GHC 6.8.2 to install properly and GHC 6.6 does not work > (it crashes the moment it needs to link to a library). After that i What are the exact error messages? Do you have all required libraries (see below)? > tried to make an unregistered bootstrap of GHC 6.6 using Linux as the > host OS. The bootstrapping failed on Solaris when making genapply or > cabal-setup. The linker reports symbol referencing errors. Has someone > already successfully build GHC on Solaris 11? bootstrapping from C seems to be pretty hopeless. Maybe my new binary release is easier to install: http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-solaris2.tar.bz2 see also http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13868 Christian -bash-3.1$ ldd lib/ghc-6.8.2/ghc-6.8.2 librt.so.1 => /lib/librt.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 From Christian.Maeder at dfki.de Fri Jan 25 03:52:43 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 25 03:52:21 2008 Subject: GHC on Solaris Nevada In-Reply-To: <4799A271.6020803@dfki.de> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> <4799A271.6020803@dfki.de> Message-ID: <4799A35B.2030008@dfki.de> Christian Maeder wrote: > Maybe my new binary release is easier to install: > > http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-solaris2.tar.bz2 Sorry, my new binary is at: http://www.dfki.de/sks/hets/pc-solaris/versions/ghc-6.8.2-i386-unknown-solaris2.tar.bz2 C. From simonpj at microsoft.com Fri Jan 25 06:40:49 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 25 06:40:27 2008 Subject: Internships at GHC HQ Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. Simon and I are looking for interns, starting in summer 2008. Lots of background info here: http://hackage.haskell.org/trac/ghc/wiki/Internships including a bunch of possible projects, although you may also have ideas of your own. But the bottom line is - apply by end Feb 2008 for this round - tell one of us that you have done so (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) Simon From dinko.tenev at gmail.com Fri Jan 25 10:37:07 2008 From: dinko.tenev at gmail.com (Dinko Tenev) Date: Fri Jan 25 10:36:44 2008 Subject: GHCi is being too "helpful" Message-ID: Hi everyone, When evaluating an IO monad in GHCi from the 6.6.1 distribution, the REPL tries to be a bit too smart about printing out the returned value. For example, () values are not printed: Prelude System.Directory> setCurrentDirectory "work" Prelude System.Directory> ...but String, or, as far as I can see, any other values, do get printed: Prelude System.Directory> getCurrentDirectory "/home/shinobi" Prelude System.Directory> set In my particular case, the value printed is a 250,000-element list -- waiting for the value to print out is not an option. I don't want to see the whole list at once, but do need to examine parts of it, subject it to intermediate transformations, etc. Is there any way to suppress this output and revert to the old behavior, where the value was simply bound to "it", without being printed? Thanks, D. Tenev From philip.weaver at gmail.com Fri Jan 25 10:57:17 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Jan 25 10:56:54 2008 Subject: GHCi is being too "helpful" In-Reply-To: References: Message-ID: You want -fno-print-bind-results, which can be passed to ghci at the command line or set within ghci using :set. I found your answer in this guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html - Phil On Jan 25, 2008 7:37 AM, Dinko Tenev wrote: > Hi everyone, > > When evaluating an IO monad in GHCi from the 6.6.1 distribution, the > REPL tries to be a bit too smart about printing out the returned > value. For example, () values are not printed: > > Prelude System.Directory> setCurrentDirectory "work" > Prelude System.Directory> > > ...but String, or, as far as I can see, any other values, do get printed: > > Prelude System.Directory> getCurrentDirectory > "/home/shinobi" > Prelude System.Directory> set > > In my particular case, the value printed is a 250,000-element list -- > waiting for the value to print out is not an option. I don't want to > see the whole list at once, but do need to examine parts of it, > subject it to intermediate transformations, etc. > > Is there any way to suppress this output and revert to the old > behavior, where the value was simply bound to "it", without being > printed? > > > Thanks, > > D. Tenev > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080125/49ecf02b/attachment-0001.htm From johan.tibell at gmail.com Fri Jan 25 12:08:22 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Jan 25 12:07:58 2008 Subject: GHCi is being too "helpful" In-Reply-To: References: Message-ID: <90889fe70801250908r19eeb076v260aa6bc41b08561@mail.gmail.com> 2008/1/25 Philip Weaver : > You want -fno-print-bind-results, which can be passed to ghci at the command > line or set within ghci using :set. > > I found your answer in this guide: > http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html You can add the :set command to your .ghci file. From catamorphism at gmail.com Fri Jan 25 15:43:12 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Jan 25 15:43:08 2008 Subject: [Haskell-cafe] Internships at GHC HQ In-Reply-To: <20080125175506.GA28799@cs.cmu.edu> References: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> <20080125175506.GA28799@cs.cmu.edu> Message-ID: <4683d9370801251243l6ac6681bl1e8b224e90ca10f4@mail.gmail.com> On 1/25/08, Dan Licata wrote: > A further plug: > > I did an internship with Simon PJ last summer (implementing view > patterns in GHC, among other things), and this is a great opportunity if > you're interested in PL research. There is a lot of interesting work > going on at MSR Cambridge, the atmosphere is very friendly, and > Cambridge is a lovely place to spend a summer. > > If anyone wants an "intern's-eye" view of the experience, feel free to > e-mail me! > I second most parts of this (including the "feel free to email me part"). I hear that the summer is busiest with respect to interns, but those who can arrange it with their graduate programs ought to consider applying for an internship during the school year. I don't know what things are like now, but I found that there were plenty of other interns around to keep me company even during the fall, and Cambridge is a lovely place to spend an autumn as well. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The more you talk, the more I get / a sense of something that hasn't happened yet / The more you talk, the more I want to know / the way I'll remember you when I go." -- Ani DiFranco From fmartini at gmail.com Sat Jan 26 06:34:13 2008 From: fmartini at gmail.com (Felix Martini) Date: Sat Jan 26 06:33:47 2008 Subject: GHC on Solaris Nevada In-Reply-To: <4799A271.6020803@dfki.de> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> <4799A271.6020803@dfki.de> Message-ID: <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> Christian Maeder wrote: > Maybe my new binary release is easier to install Your new release installed ok, but GHC does not work on my system. I can compile a simple hello world program, but running ghci or doing other compilations result in program termination of GHC and the terminal. GHC 6.6 did the same. > -bash-3.1$ ldd lib/ghc-6.8.2/ghc-6.8.2 > librt.so.1 => /lib/librt.so.1 > libreadline.so.5 => /usr/local/lib/libreadline.so.5 > libncurses.so.5 => /usr/local/lib/libncurses.so.5 > libdl.so.1 => /lib/libdl.so.1 > libm.so.2 => /lib/libm.so.2 > libgmp.so.3 => /usr/local/lib/libgmp.so.3 > libpthread.so.1 => /lib/libpthread.so.1 > libc.so.1 => /lib/libc.so.1 > libaio.so.1 => /lib/libaio.so.1 > libmd5.so.1 => /lib/libmd5.so.1 > libiconv.so.2 => /usr/local/lib/libiconv.so.2 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 > libmp.so.2 => /lib/libmp.so.2 > libscf.so.1 => /lib/libscf.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 My result of ldd is: bash-3.00$ ldd /usr/local/lib/ghc-6.8.2/ghc-6.8.2 librt.so.1 => /lib/librt.so.1 libreadline.so.5 => /usr/lib/libreadline.so.5 libncurses.so.5 => /usr/gnu/lib/libncurses.so.5 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /usr/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libcurses.so.1 => /lib/libcurses.so.1 I've checked that i also have the other so's in your output in my LD_LIBRARY_PATH. The following is the last part of the truss output when trying to run ghci. PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 17910 felix 5184K 2216K sleep 23 0 0:00:00 0.7% bash/1 /1: setcontext(0x08044AD0) /1: ioctl(1, TCGETA, 0x08044CBC) = 0 /1: stat64("/export/home/felix/.terminfo", 0x08044BF0) Err#2 ENOENT /1: stat64("/usr/gnu/share/terminfo", 0x08044BF0) = 0 /1: access("/usr/gnu/share/terminfo/x/xterm", R_OK) = 0 /1: open64("/usr/gnu/share/terminfo/x/xterm", O_RDONLY) = 5 /1: read(5, "1A01 0\0 &\00F\09D01 F05".., 4097) = 2522 /1: close(5) = 0 /1: ioctl(1, TCGETA, 0x08044CBC) = 0 /1: ioctl(1, TCGETS, 0x08FA0898) = 0 /1: ioctl(1, TCGETA, 0x08044C7C) = 0 /1: ioctl(1, TIOCGWINSZ, 0x08044CB8) = 0 /1: ioctl(1, TCSETSW, 0x08FA0874) = 0 /2: pollsys(0xD2AFBE90, 1, 0x00000000, 0x00000000) (sleeping...) /1: Received signal #1, SIGHUP [default] /1: siginfo: SIGHUP pid=17910 uid=65535 Regards, Felix From dbueno at gmail.com Sat Jan 26 15:21:00 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Jan 26 15:20:33 2008 Subject: Read instance of StdGen returns no parse Message-ID: <6dbd4d000801261221k792eee8q3aeebb1a32124288@mail.gmail.com> Hi all, According to http://haskell.org/ghc/docs/latest/html/libraries/random/System-Random.html#t%3AStdGen the Read StdGen instance should never fail. However, in GHC 6.8.2, it appears to: > ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m System.Random Prelude System.Random> read "exsqueeze me" :: StdGen Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. *** Exception: Prelude.read: no parse Prelude System.Random> Leaving GHCi. It first fails for me on strings of length seven. Is this a bug, or have I done something wrong? -- Denis From gale at sefer.org Sat Jan 26 19:01:22 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Jan 26 19:00:55 2008 Subject: Read instance of StdGen returns no parse In-Reply-To: <6dbd4d000801261221k792eee8q3aeebb1a32124288@mail.gmail.com> References: <6dbd4d000801261221k792eee8q3aeebb1a32124288@mail.gmail.com> Message-ID: <2608b8a80801261601y5448fb90i4704b4665719daef@mail.gmail.com> Denis Bueno wrote: > the Read StdGen instance should never fail. However, in GHC 6.8.2, it > appears to: > It first fails for me on strings of length seven. You need to use "fst . head . reads" instead of "read". The Read instance of StdGen only uses part of the string, and politely gives you back the unused portion so that you can use it for something else. But the side effect of that is that you can only use "reads", not "read". Using "read" means that you guarantee that the entire string you supply will be consumed by the parser. When you supply an arbitrary string to the parser for StdGen - i.e., not one produced by the Show instance - there isn't any way for you ever to guarantee that, because the exact amount of the string that will be needed is an internal implementation detail. (Whereas the use of "head" with "reads" is safe, because there is guaranteed to be some parse.) The documentation in System.Random is a bit misleading. It says "the read instance of StdGen has the following properties: It guarantees to succeed on any string..." The word "read" should really be "Read" instead. It also wouldn't hurt to mention that the read *function* may fail, so use reads instead. Hope this helps. -Yitz From fmartini at gmail.com Sun Jan 27 11:19:33 2008 From: fmartini at gmail.com (Felix Martini) Date: Sun Jan 27 11:19:08 2008 Subject: GHC on Solaris Nevada In-Reply-To: <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> <4799A271.6020803@dfki.de> <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> Message-ID: <6c0416190801270819k553552f3k62bcf04d343896d6@mail.gmail.com> I have located the problem i had with GHC. I had compiled the readline library from a spec file. Apparently it is not compatible with the binary GHC release. With the prebuilt readline package from sunfreeware GHC works fine now. Regards, Felix From Christian.Maeder at dfki.de Mon Jan 28 12:09:16 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 28 12:08:44 2008 Subject: GHC on Solaris Nevada In-Reply-To: <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> <4799A271.6020803@dfki.de> <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> Message-ID: <479E0C3C.7050902@dfki.de> Felix Martini wrote: > Christian Maeder wrote: >> Maybe my new binary release is easier to install > > Your new release installed ok, but GHC does not work on my system. I > can compile a simple hello world program, but running ghci or doing > other compilations result in program termination of GHC and the > terminal. GHC 6.6 did the same. > >> -bash-3.1$ ldd lib/ghc-6.8.2/ghc-6.8.2 >> librt.so.1 => /lib/librt.so.1 >> libreadline.so.5 => /usr/local/lib/libreadline.so.5 >> libncurses.so.5 => /usr/local/lib/libncurses.so.5 >> libdl.so.1 => /lib/libdl.so.1 >> libm.so.2 => /lib/libm.so.2 >> libgmp.so.3 => /usr/local/lib/libgmp.so.3 >> libpthread.so.1 => /lib/libpthread.so.1 >> libc.so.1 => /lib/libc.so.1 >> libaio.so.1 => /lib/libaio.so.1 >> libmd5.so.1 => /lib/libmd5.so.1 >> libiconv.so.2 => /usr/local/lib/libiconv.so.2 >> libsocket.so.1 => /lib/libsocket.so.1 >> libnsl.so.1 => /lib/libnsl.so.1 >> libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 >> libmp.so.2 => /lib/libmp.so.2 >> libscf.so.1 => /lib/libscf.so.1 >> libdoor.so.1 => /lib/libdoor.so.1 >> libuutil.so.1 => /lib/libuutil.so.1 >> libgen.so.1 => /lib/libgen.so.1 > > My result of ldd is: > > bash-3.00$ ldd /usr/local/lib/ghc-6.8.2/ghc-6.8.2 > librt.so.1 => /lib/librt.so.1 > libreadline.so.5 => /usr/lib/libreadline.so.5 > libncurses.so.5 => /usr/gnu/lib/libncurses.so.5 > libdl.so.1 => /lib/libdl.so.1 > libm.so.2 => /lib/libm.so.2 > libgmp.so.3 => /usr/lib/libgmp.so.3 > libpthread.so.1 => /lib/libpthread.so.1 > libc.so.1 => /lib/libc.so.1 > libcurses.so.1 => /lib/libcurses.so.1 Your ldd output looks nice. Is it still that simple after you've update your readline lib? Most of my above libs get in via libreadline: -bash-3.1$ ldd /usr/local/lib/libreadline.so.5 warning: ldd: /usr/local/lib/libreadline.so.5: is not executable libiconv.so.2 => /usr/local/lib/libiconv.so.2 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libmp.so.2 => /lib/libmp.so.2 libmd5.so.1 => /lib/libmd5.so.1 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 I've not idea about /lib/libaio.so.1 (Possibly our system is set up suboptimal.) Cheers Christian From trebla at vex.net Mon Jan 28 12:52:44 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon Jan 28 12:52:18 2008 Subject: A suggestion for GHC download pages Message-ID: <479E166C.5060005@vex.net> On GHC version-specific download pages (e.g., http://www.haskell.org/ghc/download_ghc_682.html), under Source Distribution, it would reduce a major confusion of the form "I built GHC from source, now I use it, it says Network.CGI not found" if after the filename ghc-6.8.2-src.tar.bz2 it is also said "compiler and almost no libraries", and after the filename ghc-6.8.2-src-extralibs.tar.bz2 it is also said "most libraries, but it takes hours to build, Hackage has them piecemeal and more". Perhaps it would also be nice to say how to use the latter, e.g., "unpack this over the compiler source before building, before even building the compiler". Does it need to be said? Seems to be yes according my experience in #haskell. Here is how it can be misunderstood. Given the word "extralibs" and the file sizes, and no other words, what would an outsider think? Between the disproportionate 7MB and 2MB, 7MB must be because all the popular libraries are there, 2MB must be because "extralibs" means fringe, niche libraries. There lies the misunderstanding. Isn't it already said in the build guide? Yes it is, but the path between the download page and the build guide is not obvious. There is mention of the build guide, but it is put under the precondition "if your platform is not supported". IMO there should be no precondition; absolutely everyone building from source should be tempted to see the build guide. Perhaps the source section should also be close to the bottom of the download page, not to the top, reflecting what we recommend for most people. From g9ks157k at acme.softbase.org Mon Jan 28 14:47:35 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 28 14:47:06 2008 Subject: A suggestion for GHC download pages In-Reply-To: <479E166C.5060005@vex.net> References: <479E166C.5060005@vex.net> Message-ID: <200801282047.35622.g9ks157k@acme.softbase.org> Am Montag, 28. Januar 2008 18:52 schrieb Albert Y. C. Lai: > On GHC version-specific download pages (e.g., > http://www.haskell.org/ghc/download_ghc_682.html), under Source > Distribution, it would reduce a major confusion of the form "I built GHC > from source, now I use it, it says Network.CGI not found" if after the > filename ghc-6.8.2-src.tar.bz2 it is also said "compiler and almost no > libraries", and after the filename ghc-6.8.2-src-extralibs.tar.bz2 it is > also said "most libraries, but it takes hours to build, Hackage has them > piecemeal and more". Perhaps it would also be nice to say how to use the > latter, e.g., "unpack this over the compiler source before building, > before even building the compiler". > > Does it need to be said? Seems to be yes according my experience in > #haskell. Here is how it can be misunderstood. Given the word > "extralibs" and the file sizes, and no other words, what would an > outsider think? Between the disproportionate 7MB and 2MB, 7MB must be > because all the popular libraries are there, 2MB must be because > "extralibs" means fringe, niche libraries. There lies the misunderstanding. > > Isn't it already said in the build guide? Yes it is, but the path > between the download page and the build guide is not obvious. There is > mention of the build guide, but it is put under the precondition "if > your platform is not supported". IMO there should be no precondition; > absolutely everyone building from source should be tempted to see the > build guide. > > Perhaps the source section should also be close to the bottom of the > download page, not to the top, reflecting what we recommend for most > people. While the situation might be improvable, I want to add that I had no big problems building GHC because, as far as I remember, the README and INSTALL files told me the meaning of extralibs etc. Best wishes, Wolfgang From fmartini at gmail.com Mon Jan 28 16:47:35 2008 From: fmartini at gmail.com (Felix Martini) Date: Mon Jan 28 16:47:02 2008 Subject: GHC on Solaris Nevada In-Reply-To: <479E0C3C.7050902@dfki.de> References: <6c0416190801241426l3050177fr8a365b3bd8333bc0@mail.gmail.com> <4799A271.6020803@dfki.de> <6c0416190801260334n63260c58w967b7dcb1325603@mail.gmail.com> <479E0C3C.7050902@dfki.de> Message-ID: <6c0416190801281347g56b22795q8d5fb908f2721b86@mail.gmail.com> With the readline package from sunfreeware my ldd output is now $ ldd /usr/local/lib/ghc-6.8.2/ghc-6.8.2 librt.so.1 => /lib/librt.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/gnu/lib/libncurses.so.5 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /usr/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 $ ldd /usr/local/lib/libreadline.so.5 warning: ldd: /usr/local/lib/libreadline.so.5: is not executable libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 This is on Solaris Express Developer Edition 9/07. From chak at cse.unsw.edu.au Wed Jan 30 04:13:01 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jan 30 04:12:28 2008 Subject: Bootstrapping for Leopard In-Reply-To: <200801220929.13869.p.k.f.holzenspies@utwente.nl> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> Message-ID: <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> Philip K.F. H?lzenspies: > I'm trying toupdate the Portfile so that ghc-6.8.2 can be built > using MacPorts > (handy for installing other ghc-dependent material from MacPorts like > gtk2hs). The problem seems to be that the available bootstrap binary > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.bz2 > causes a segfault on Leopard (below are the steps I took in my > attempt to > build ghc with this bootstrap binary). > > Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386- > apple-darwin > building ghc-6.8.2 works fine. It seemed to me that the easiest way > to fix > the bootstrap problem is to boot from C as described on the wiki > (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two > things were > wrong, however. > > make hc-file-bundle > > Making the hc-file-bundle target failed, because not all rts/*.cmm had > rts/*.hc counterparts after the build. The make fails because of this > fragment from the Makefile (part of the hc-file-bundle target, > starting from > line 513): > > for f in `$(FIND) ghc-$(ProjectVersion)/compiler > ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ > if test "x$$f" !=3D "x"; then \ > echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ > fi; \ > done; > > This adds some non-existing .hc files to the hc-files-to-go list > that tar will > not find, later on, causing an error. I just added a test to see > whether the > file exists. If it does not, I call make for that .hc file > explicitly, which > solves the problem for most files. The files that don't have a make > target, I > simply omitted from the hc-files-to-go. I haven't been able to test > the > severity of this, because of the second problem. I am not sure what the problem is here. Simon? Ian? > checking for ld... /usr/bin/ld > checking for path to top of build tree... ./configure: line 2651: - > v0: command > not found > ./configure: line 2655: utils/pwd/pwd: No such file or directory > configure: error: cannot determine current directory > > Upon inspection of the configure script, I found out that line 2651 > uses the > variable designating the ghc compiler. This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. It however messes everything up if you want to build from HC files (and so don't have a Haskell compiler). I am not sure whether anybody thought about this problem when the change to using Haskell scripts instead of shell scripts was made. Ian? Simon? The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. Manuel From p.k.f.holzenspies at utwente.nl Wed Jan 30 05:27:09 2008 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Wed Jan 30 05:26:31 2008 Subject: Bootstrapping for Leopard In-Reply-To: <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> Message-ID: <200801301127.09422.p.k.f.holzenspies@utwente.nl> On Wednesday 30 January 2008 10:13:01 Manuel M T Chakravarty wrote: > > Upon inspection of the configure script, I found out that line 2651 > > uses the variable designating the ghc compiler. > > This is due to a change of the configure stage that AFAIK was made to > easy building on windows. Instead, of using shell commands/scripts > (as GHC did previously) to obtain some configuration information (here > the file path at which the top of the GHC build tree is located), the > build system now uses small Haskell programs/scripts. This makes the > build more portable ** if there is already a Haskell compiler on the > system **. It however messes everything up if you want to build from > HC files (and so don't have a Haskell compiler). I am not sure > whether anybody thought about this problem when the change to using > Haskell scripts instead of shell scripts was made. Ian? Simon? > > The only solution that I see is to replace the Haskell scripts by > vanilla shell scripts in HC bundles. Even if that causes problems on > windows (without cygwin), it would make HC bundles viable on Unix > systems again. Dear Manuel, Your explanation makes perfect sense. For those more involved in the build process of GHC: How hard is it to roll back the vanilla shell scripts that once upon a time were used and to have 'configure' default to them when the --enable-hc-boot switch is used? Wrt. to the missing .hc files from rts/*.cmm: Since these weren't built in the make process, are they actually required? If not, it should simply be an extra test in the Makefile for the hc-file-bundle. Regards, Philip From kili at outback.escape.de Wed Jan 30 14:59:56 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed Jan 30 14:59:37 2008 Subject: Bootstrapping for Leopard In-Reply-To: <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> References: <200801220929.13869.p.k.f.holzenspies@utwente.nl> <30A8C446-E593-487B-965B-9CCEFDE4B101@cse.unsw.edu.au> Message-ID: <20080130195956.GA23183@petunia.outback.escape.de> On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: [Philip K.F. H?lzenspies:] > >make hc-file-bundle > > > >Making the hc-file-bundle target failed, because not all rts/*.cmm had > >rts/*.hc counterparts after the build. The make fails because of this > >fragment from the Makefile (part of the hc-file-bundle target, > >starting from > >line 513): > > > >for f in `$(FIND) ghc-$(ProjectVersion)/compiler > >ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ > > if test "x$$f" !=3D "x"; then \ > > echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ > > fi; \ > >done; This is strange. I've all kinds of trouble getting hc-bootstrapping back (for OpenBSD, but also in general), and I didn't see *that* problem. > >checking for path to top of build tree... ./configure: line 2651: - > >v0: command > >not found > >./configure: line 2655: utils/pwd/pwd: No such file or directory > >configure: error: cannot determine current directory [...] > This is due to a change of the configure stage that AFAIK was made to > easy building on windows. Instead, of using shell commands/scripts > (as GHC did previously) to obtain some configuration information (here > the file path at which the top of the GHC build tree is located), the > build system now uses small Haskell programs/scripts. This makes the > build more portable ** if there is already a Haskell compiler on the > system **. But it just doesn't make sense at all. You need a good set of shell commands at all, since they're used by configure as well as in Makefiles. I really can't believe that simple stuff like this doesn't work on windos: --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Sun Jan 20 17:10:07 2008 @@ -1098,20 +1098,14 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean && make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` +case $HostPlatform in +*cygwin32|*mingw32) + hardtop=`pwd | tr \\ /` + ;; +*) + hardtop=`pwd` + ;; +esac if ! test -d "$hardtop"; then AC_MSG_ERROR([cannot determine current directory]) ifBuildable.hs is similar; it can be replaced by a shell script or even done within libraries/Makefile using very basic shell commands. > The only solution that I see is to replace the Haskell scripts by > vanilla shell scripts in HC bundles. Even if that causes problems on > windows (without cygwin), it would make HC bundles viable on Unix > systems again. How is ghc currently built on windows without something like cygwin? >From the source distribution, the only way to build ghc seems to be via configure and (GNU) make. So there must be some shell environment available. Or am I missing something really crucial here? Ciao, Kili From mads_lindstroem at yahoo.dk Wed Jan 30 12:00:16 2008 From: mads_lindstroem at yahoo.dk (Mads =?utf-8?b?TGluZHN0csO4bQ==?=) Date: Wed Jan 30 15:34:23 2008 Subject: Using "GHC as a library" with own functions makes runStmt return RunBreak Message-ID: Hi I am trying to use "GHC as a library". From runStmt, I want to load and run functions from a home-grown module. Lets call my home-grown module HomeGrown.hs. I have tried to model my application after http://haskell.org/sitewiki/images/1/17/Interactive-6.8.hs / http://haskell.org/sitewiki/images/f/f9/MyPrelude.hs from http://haskell.org/haskellwiki/GHC/As_a_library . This library loads MyPrelude.hs and runs myPutStrLn & myGetLine + more. However, when I try to run code from HomeGrown.hs like: runStmt session "HomeGrown.foo" GHC.SingleStep runStmt keeps returning RunBreak (of type RunResult). From what I can read of the WWW, RunBreak is related to some debugger and indicate that GHC encountered some breakpoint. However, I did not set any break points. Comparing Interactive-6.8 and MyPrelude.hs to my own code, the largest difference seemed to be that Interactive-6.8 do not only use MyPrelude.hs by calling `addTarget` and `setContext`, it also imports MyPrelude.hs as a regular Haskell import (import MyPrelude). Thus I tried to remove this import to see what would happen. Interactive-6.8 compiled and started just fine. However, whenever it needed to use any functions in MyPrelude, runStmt also returned RunBreak. So is it only possible to load home-grown/non-standard modules when also doing a regular import? Greetings, Mads Lindstr?m From bbr at informatik.uni-kiel.de Thu Jan 31 07:47:54 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Jan 31 07:47:49 2008 Subject: What does unsafePerformIO do to the stack Message-ID: <47A1C37A.4020700@informatik.uni-kiel.de> Consider the following program: module Stack where import System.IO.Unsafe main = print (sim (replicate 1299959 ())) sim [] = True sim (_:xs) = goodStack (sim xs) goodStack x = fromJust (Just x) --no stack overflow badStack x = unsafePerformIO (return x) --stack overflow fromJust (Just x) = x I always thought that unsafePerformIO would do something similar as goodStack. i.e. be stack neutral: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K0.00001M True But if you exchange goodStack with badStack, the picture changes unfortunately to: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K9.883647M Stack space overflow: current size 9883644 bytes. Use `+RTS -Ksize' to increase it. $ stack +RTS -K9.883648M True I am using: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Is this behaviour necessary? Is there any work around, e.g., employing the foreign function interface? Thanks for your time! Bernd From mads_lindstroem at yahoo.dk Thu Jan 31 11:02:32 2008 From: mads_lindstroem at yahoo.dk (Mads =?utf-8?b?TGluZHN0csO4bQ==?=) Date: Thu Jan 31 11:02:05 2008 Subject: Using References: Message-ID: Mads Lindstr?m yahoo.dk> writes: > So is it only possible to load home-grown/non-standard modules when also > doing a > regular import? > Here I really mean: So is it only possible to load home-grown/non-standard modules _without_ also doing a regular import? I could also pose my question differently as: If I remove this line in Interactive-6.8.hs: import MyPrelude then how would I change Interactive-6.8.hs and/or MyPrelude.hs, so that it was still possible to use the functions in MyPrelude.hs. It seems to me that the import should not be necessary. If it is necessary, then how is one to make use of modules not know at compile-time (of Interactive-6.8.hs or similar)? Note that Interactive-6.8.hs compiles and starts without trouble, even though "import MyPrelude" is removed. The trouble only arises when runStmt calls the functions inside of MyPrelude. For those who cares, I have tested my code on both GHC 6.8.1 and 6.8.2. Also I am using Debian Linux. Greetings, Mads Lindstr?m From hsingchou1 at gmail.com Thu Jan 31 11:03:48 2008 From: hsingchou1 at gmail.com (hsing-chou chen) Date: Thu Jan 31 11:03:07 2008 Subject: Is GHC 6.8.2 on solaris 32 bits or 64 bits Message-ID: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> Thank you for porting GHC 6.8.2 to solaris, I am assigned a job to make sure GHC run 64 bits on solaris. Is your solaris port 64 bits. Or it only 32 BITS. I know 32 bits GHC can still run on 64 bits solaris. However company want to run really 64 bits GHC on solaris. Thanks a lot if you can give me feedback. Sincerely, Hsing-chou chen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080131/dbc87592/attachment.htm From Christian.Maeder at dfki.de Thu Jan 31 11:23:39 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 31 11:23:00 2008 Subject: Is GHC 6.8.2 on solaris 32 bits or 64 bits In-Reply-To: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> References: <31bdb3200801310803v6f06a615l5d862c7ae0340318@mail.gmail.com> Message-ID: <47A1F60B.10900@dfki.de> hsing-chou chen wrote: > Thank you for porting GHC 6.8.2 to solaris, I am assigned a > job to make sure GHC run 64 bits on solaris. Good, I was waiting for (someone like) you! I'm interested in a true 64 bits GHC on solaris, too, but I have no idea how to build one. I hope Ian or Simon can help you/us. > Is your solaris port 64 bits. Or it only 32 BITS. Obviously it's only 32 bits, currently. > I know 32 bits GHC can still run on 64 bits solaris. Yes it does and it is probably faster than a 64 bit version (like under linux). > However company want to run really 64 bits GHC on solaris. How many resources is your company willing to spent on this? (Don't answer this, if it is a problem.) > Thanks a lot if you > can give me feedback. Good luck, Christian From mads_lindstroem at yahoo.dk Thu Jan 31 15:10:23 2008 From: mads_lindstroem at yahoo.dk (Mads =?utf-8?b?TGluZHN0csO4bQ==?=) Date: Thu Jan 31 15:09:53 2008 Subject: Using "GHC as a library" with own functions makes runStmt return RunBreak References: Message-ID: Mads Lindstr?m yahoo.dk> writes: > > Hi > > I am trying to use "GHC as a library". From runStmt, I want to load and run > functions from a home-grown module. Lets call my home-grown module > HomeGrown.hs. > > I have tried to model my application after > http://haskell.org/sitewiki/images/1/17/Interactive-6.8.hs / > http://haskell.org/sitewiki/images/f/f9/MyPrelude.hs from > http://haskell.org/haskellwiki/GHC/As_a_library . This library loads > MyPrelude.hs and runs myPutStrLn & myGetLine + more. > > However, when I try to run code from HomeGrown.hs like: > > runStmt session "HomeGrown.foo" GHC.SingleStep > > runStmt keeps returning RunBreak (of type RunResult). From what I can read of > the WWW, RunBreak is related to some debugger and indicate that GHC > encountered > some breakpoint. However, I did not set any break points. For those interested I figured out how to avoid the RunBreak -returns. Use RunToCompletion in stead of SingleStep in the application of runStmt. I guess Interactive-6.8.hs should also use SingleStep. Greetings, Mads Lindstr?m From robin.houston at gmail.com Thu Jan 31 18:05:32 2008 From: robin.houston at gmail.com (Robin Houston) Date: Thu Jan 31 18:11:49 2008 Subject: Deforesting edtiInt Message-ID: <1b795e7b0801311505g736ff817r3d948809046d9a5f@mail.gmail.com> Recently I wrote a short program that builds an array containing the number of divisors of the first 10^7 natural numbers. (Some of you can guess why I did this, but I won't say explicitly lest this post become a Googleable spoiler.) Here's the relevant part of the code. incElem a i = readArray a i >>= \n -> writeArray a i $! n+1 do -- Create an array with elements initialised to 0 a <- newArray (1,n) 0 :: ST s (STUArray s Int Word16) -- Populate the array forM_ [2..n] $ \i -> forM_ [i, i+i .. n] (incElem a) Of course there are more efficient algorithms for this, but this one has the merit of being extremely simple without being unreasonably slow. Except that it is a lot slower than it needs to be. After digging around a bit, I suspected that the reason for this is that the general form of enumeration [from, then .. to] does not benefit from the deforestation optimisation. When I added some deforestation rules to GHC/Enum.lhs and rebuilt the library, I found my suspicion confirmed: after the change, my code runs roughly twice as fast. Is there any reason not to do this? I attach a diff of the change I made, though I expect it could be done better by someone with experience of this sort of thing. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: deforest-efdtInt.patch Type: application/octet-stream Size: 2762 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080131/2d8bf663/deforest-efdtInt.obj