From jakubuv at gmail.com Fri May 1 12:03:32 2009 From: jakubuv at gmail.com (Jan Jakubuv) Date: Fri May 1 11:49:27 2009 Subject: type checking fails with a correct type In-Reply-To: <200904301940.16369.daniel.is.fischer@web.de> References: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> <200904301717.42827.daniel.is.fischer@web.de> <20090430162543.GC27924@lxultra2.macs.hw.ac.uk> <200904301940.16369.daniel.is.fischer@web.de> Message-ID: <20090501160332.GA28043@lxultra2.macs.hw.ac.uk> On Thu, Apr 30, 2009 at 07:40:16PM +0200, Daniel Fischer wrote: > > You can ask GHC by compiling the module without the type signature and with the flag > -ddump-simpl > , the relevant part of the core is: > > ================================================================== > > Nonsense.nonsense :: forall t_agD s_agJ. > (Nonsense.SUBST s_agJ) => > t_agD -> Data.Maybe.Maybe s_agJ > [GlobalId] > [Arity 2] > Nonsense.nonsense = > \ (@ t_agD) -- type of argument > (@ s_agJ) -- type of result is (Maybe s_agJ) > ($dSUBST_agL :: Nonsense.SUBST s_agJ) -- SUBST dictionary for s_agJ > (eta_shh :: t_agD) -> > letrec { > nonsense1_agA :: t_agD -> Data.Maybe.Maybe s_agJ > -- inner nonsense, the type is fixed as that at which the outer nonsense is called, > -- there is *no* forall here! > [Arity 1] Thanks for you detailed explanation. Finally it makes sense ;-) It seems to me that type inference without the type signature added an explicit type annotation itself. So when GHCi says that nonsense :: SUBST s => t -> s then it actually refers to `nonsense` in the core with added annotation and not to the `nonsense` in the source file. I think that this confused me. Thanks again, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From petersen at haskell.org Sat May 2 07:53:42 2009 From: petersen at haskell.org (Jens Petersen) Date: Sat May 2 07:39:30 2009 Subject: runghc failing sometimes on Linux/ppc? In-Reply-To: <9436bffe0904301926m47bfd76dp6d6e347c8cade96f@mail.gmail.com> References: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> <20090425144316.GB26881@matrix.chaos.earth.li> <9436bffe0904301926m47bfd76dp6d6e347c8cade96f@mail.gmail.com> Message-ID: <9436bffe0905020453q23f45cadob05ffaf283e2c93b@mail.gmail.com> 2009/5/1 Jens Petersen : > 2009/4/26 Ian Lynagh : >> Are you using a registerised build? If so, then as PPC/Linux isn't a >> tier 1 platform, it could well have bitrotted. So I tried doing an unregisterised ppc build with: echo "GhcUnregisterised=YES" >> mk/build.mk echo "GhcWithNativeCodeGen=NO" >> mk/build.mk echo "SplitObjs=NO" >> mk/build.mk but this failed with: make -C ../ghc stage=2 make[3]: Entering directory `/builddir/build/BUILD/ghc-6.10.2/ghc' /builddir/build/BUILD/ghc-6.10.2/libraries/cabal-bin /usr/bin/ghc /builddir/build/BUILD/ghc-6.10.2/libraries/bootstrapping.conf 1.6.0.3 configure --distpref dist-stage2 \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --flags=ghci --with-compiler=/builddir/build/BUILD/ghc-6.10.2/ghc/stage1-inplace/ghc --with-hc-pkg=/builddir/build/BUILD/ghc-6.10.2/utils/ghc-pkg/install-inplace/bin/ghc-pkg --ghc-option=-O2 \ --libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --with-happy="/usr/bin/happy" --configure-option='--prefix=/usr' --configure-option='--exec-prefix=/usr' --configure-option='--bindir=/usr/bin' --configure-option='--sbindir=/usr/sbin' --configure-option='--sysconfdir=/etc' --configure-option='--datadir=/usr/share' --configure-option='--includedir=/usr/include' --configure-option='--libdir=/usr/lib' --configure-option='--libexecdir=/usr/libexec' --configure-option='--localstatedir=/var' --configure-option='--sharedstatedir=/var/lib' --configure-option='--mandir=/usr/share/man' --configure-option=--with-cc="gcc" --with-hsc2hs=/builddir/build/BUILD/ghc-6.10.2/utils/hsc2hs/install-inplace/bin/hsc2hs \ --libsubdir=. \ --datadir='$libdir' \ --datasubdir=. Configuring ghc-bin-6.10.2... /builddir/build/BUILD/ghc-6.10.2/libraries/cabal-bin /usr/bin/ghc /builddir/build/BUILD/ghc-6.10.2/libraries/bootstrapping.conf 1.6.0.3 build --distpref dist-stage2 --ghc-option=-H32m --ghc-option=-O --ghc-option=-H32m --ghc-option=-O Preprocessing executables for ghc-bin-6.10.2... Building ghc-bin-6.10.2... [1 of 1] Compiling Main ( Main.hs, dist-stage2/build/ghc/ghc-tmp/Main.o ) Linking dist-stage2/build/ghc/ghc ... /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init': (.text+0x54): relocation truncated to fit: R_PPC_PLTREL24 against symbol `_init' defined in .init section in /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crti.o+8000 collect2: ld returned 1 exit status make[3]: *** [build.stage.2] Error 1 make[3]: Leaving directory `/builddir/build/BUILD/ghc-6.10.2/ghc' make[2]: Leaving directory `/builddir/build/BUILD/ghc-6.10.2/compiler' make[2]: *** [build.stage.2] Error 2 make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/ghc-6.10.2' make: *** [bootstrap2] Error 2 see http://koji.fedoraproject.org/koji/getfile?taskID=1332447&name=build.log for the full buildlog. From Sven.Panne at aedion.de Sat May 2 08:43:50 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Sat May 2 08:29:51 2009 Subject: Linking and constants problems with OpenAL under Windows In-Reply-To: <61D446EF904944DCA170BA87A53D17FE@skinny> References: <61D446EF904944DCA170BA87A53D17FE@skinny> Message-ID: <200905021443.51055.Sven.Panne@aedion.de> Am Sonntag, 15. Februar 2009 08:32:59 schrieb Jared: > The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the > more serious of my problems seems to be with GHC. My platform is GHC > 6.10.1 under Windows XP. This post boils down to two questions. First, > why would GHCi and GHC look for different symbol names when linking, and > second, has anybody had any success working with the OpenAL binding on > Windows? [...] I've just released a new version of the OpenAL package on Hackage. That one and the previous release fixed two things which might be related to your problems (calling convention and #including headers when checking for constant values). Could you please give the new version a try and report the results? If things go wrong, a full transcript of the configuration stage and the generated config.log file would be very helpful. Cheers, S. From igloo at earth.li Sat May 2 11:07:34 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 2 10:54:41 2009 Subject: 6.10.3 prerelease Message-ID: <20090502150733.GA27110@matrix.chaos.earth.li> Hi all, 6.10.3 is now ready to release. There have been very few changes relative to 6.10.2; the release notes are here: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-3.html This is just to give people a chance to report any regressions relative to 6.10.2, in particular, build failures or ghci problems. Source tarballs are here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430-src-extralibs.tar.bz2 Unless any major problems are uncovered, we expect to build the final release in a couple of days. Thanks Ian From nonowarn at gmail.com Sun May 3 00:04:42 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Sat May 2 23:52:08 2009 Subject: 6.10.3 prerelease In-Reply-To: <20090502150733.GA27110@matrix.chaos.earth.li> References: <20090502150733.GA27110@matrix.chaos.earth.li> Message-ID: Hi, I tried to build prerelease from tarball on Intel Mac (OS 10.4.11) by ghc-6.10.1, almost all successfully built but documentations are not. when building documentations, I got error: Preprocessing library base-4.1.0.0... Running hscolour for base-4.1.0.0... Preprocessing library base-4.1.0.0... Running Haddock for base-4.1.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expired (program cc1) Please submit a full bug report. See for instructions. make[2]: *** [doc.library.base] Error 1 make[2]: Leaving directory `/Users/mate/work/2009/05/03/ ghc-6.10.2.20090430/libraries' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/Users/mate/work/2009/05/03/ ghc-6.10.2.20090430' make: *** [bootstrap2] Error 2 Full config.log build.log are here, - http://dl.getdropbox.com/u/360784/build.log - http://dl.getdropbox.com/u/360784/config.log Thanks Hashimoto On 2009/05/03, at 0:07, Ian Lynagh wrote: > > Hi all, > > 6.10.3 is now ready to release. There have been very few changes > relative to 6.10.2; the release notes are here: > http://www.haskell.org/ghc/dist/stable/docs/users_guide/ > release-6-10-3.html > > This is just to give people a chance to report any regressions > relative > to 6.10.2, in particular, build failures or ghci problems. Source > tarballs are here: > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430- > src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430- > src-extralibs.tar.bz2 > > Unless any major problems are uncovered, we expect to build the final > release in a couple of days. > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From petersen at haskell.org Sun May 3 01:02:50 2009 From: petersen at haskell.org (Jens Petersen) Date: Sun May 3 00:48:51 2009 Subject: runghc failing sometimes on Linux/ppc? In-Reply-To: <9436bffe0905020453q23f45cadob05ffaf283e2c93b@mail.gmail.com> References: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> <20090425144316.GB26881@matrix.chaos.earth.li> <9436bffe0904301926m47bfd76dp6d6e347c8cade96f@mail.gmail.com> <9436bffe0905020453q23f45cadob05ffaf283e2c93b@mail.gmail.com> Message-ID: <9436bffe0905022202p4c71cf4ev1a254831408402df@mail.gmail.com> 2009/5/2 Jens Petersen : > So I tried doing an unregisterised ppc build with: > > echo "GhcUnregisterised=YES" >> mk/build.mk > echo "GhcWithNativeCodeGen=NO" >> mk/build.mk > echo "SplitObjs=NO" >> mk/build.mk Are these the right build config settings? > but this failed with: : > Linking dist-stage2/build/ghc/ghc ... : > (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol > `__libc_start_main@@GLIBC_2.0' defined in .glink section in > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtbegin.o:(.fini+0x0): > relocation truncated to fit: R_PPC_REL24 against `.text' I thought maybe it was a gcc44 issue, but similar with gcc43: Building ghc-bin-6.10.2... [1 of 1] Compiling Main ( Main.hs, dist-stage2/build/ghc/ghc-tmp/Main.o ) Linking dist-stage2/build/ghc/ghc ... /usr/lib/gcc/ppc64-redhat-linux/4.3.2/../../../../lib/crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.2/../../../../lib/crt1.o /usr/lib/gcc/ppc64-redhat-linux/4.3.2/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/gcc/ppc64-redhat-linux/4.3.2/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xf_entry': ghc5050_0.hc:(.text+0x448): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xj_entry': ghc5050_0.hc:(.text+0x5ac): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xn_entry': ghc5050_0.hc:(.text+0x6dc): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xp_entry': ghc5050_0.hc:(.text+0x7c4): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xr_entry': ghc5050_0.hc:(.text+0x8ac): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `r6Xv_entry': ghc5050_0.hc:(.text+0xbe8): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `Main_a13_entry': ghc5050_0.hc:(.text+0xcd0): relocation truncated to fit: R_PPC_REL24 against symbol `newCAF' defined in .text section in /builddir/build/BUILD/ghc-6.10.2/rts/libHSrts.a(Storage.o) dist-stage2/build/ghc/ghc-tmp/Main.o: In function `Main_a14_entry': ghc5050_0.hc:(.text+0xdb8): additional relocation overflows omitted from the output collect2: ld returned 1 exit status http://koji.fedoraproject.org/koji/taskinfo?taskID=1333608 Any thoughts? Jens From clawsie at fastmail.fm Mon May 4 02:02:43 2009 From: clawsie at fastmail.fm (brad clawsie) Date: Mon May 4 02:00:21 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 Message-ID: <87tz412ynw.fsf@fastmail.fm> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt it is about 4.4mb thanks brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn+hQMACgkQxRg3RkRK91PGgACfWYJy9sIt6Nx1QxM+nkqXYMl3 pLIAoIDf6yw25VymUFPpdIG5L0B/gF2K =lwwy -----END PGP SIGNATURE----- From clawsie at fastmail.fm Mon May 4 02:03:49 2009 From: clawsie at fastmail.fm (brad clawsie) Date: Mon May 4 02:00:31 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 Message-ID: <87skjl2ym2.fsf@fastmail.fm> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt it is about 4.4mb thanks brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn+hUUACgkQxRg3RkRK91OSCwCfZ2LuR2v1UNYfx1z1gCx/5Kam 4pwAn0+T69nj0qIl4LyCYEsy/mAOdc8h =6alu -----END PGP SIGNATURE----- From semanticphilosopher at googlemail.com Mon May 4 11:35:37 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Mon May 4 11:37:55 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? Message-ID: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> Hi, It does not appear that you can access the 'addrFlags' returned by getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled bits set: 8 Is this just a MacOS issue? Should I raise a ticket for it? Cheers Neil GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Socket Prelude Network.Socket> getAddrInfo Nothing (Just "localhost") Nothing Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1 ... linking ... done. [AddrInfo {addrFlags = *** Exception: unpackBits: unhandled bits set: 8 Prelude Network.Socket> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090504/12973189/attachment.htm From judah.jacobson at gmail.com Mon May 4 11:50:40 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon May 4 11:45:27 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <87tz412ynw.fsf@fastmail.fm> References: <87tz412ynw.fsf@fastmail.fm> Message-ID: <6d74b0d20905040850y37312e54na726c506fe2278ca@mail.gmail.com> On Sun, May 3, 2009 at 11:02 PM, brad clawsie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi > > after some trying, i was unable to get the 6.10.3 prerelease to build on > freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. > > i saved the output of the entire build from ./configure to the point of > failure. it is too long too attach here, you can see it at: > > http://www.b7j0c.org/ghc-6.10.3.log.txt > > it is about 4.4mb > > thanks > brad It looks like the problem occurs when building Haskeline: Configuring haskeline-0.6.1.5... checking whether to use -liconv... using -liconv. Setup: Missing dependency on a foreign library: * Missing C library: iconv The problem is that Cabal isn't getting the right argument to look for iconv in (I'm guessing) /usr/local/lib. (Strangely, the Haskeline custom Setup.hs script which detects whether to use iconv is itself succeeding; I should compare the two and see what's different...) Normally this can be fixed by building Haskeline with the Cabal arguments --extra-include-dirs, --extra-lib-dirs; but I don't know how they can be passed through by to the ghc build system. Can you please try, with your working ghc-6.10.2: cd into libraries/haskeline of the release candidate source directory, run runghc Setup configure --user -v3 and send the output. Thanks, -Judah From bos at serpentine.com Mon May 4 14:20:48 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon May 4 14:06:56 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? In-Reply-To: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> References: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> Message-ID: On Mon, May 4, 2009 at 8:35 AM, Neil Davies < semanticphilosopher@googlemail.com> wrote: > > It does not appear that you can access the 'addrFlags' returned by > getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled > bits set: 8 > Interesting. > Is this just a MacOS issue? Should I raise a ticket for it? > It's presumably Mac-specific, but yes, please file a ticket and I'll take a look. File it against the network package, not GHC itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090504/9e01d012/attachment-0001.htm From johan.tibell at gmail.com Mon May 4 14:24:14 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon May 4 14:09:59 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? In-Reply-To: References: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> Message-ID: <90889fe70905041124x403ae892l8c4324b98b21d6d1@mail.gmail.com> On Mon, May 4, 2009 at 8:20 PM, Bryan O'Sullivan wrote: > On Mon, May 4, 2009 at 8:35 AM, Neil Davies > wrote: >> >> It does not appear that you can access the 'addrFlags' returned by >> getAddrInfo, you get the exception:?*** Exception: unpackBits: unhandled >> bits set: 8 > > Interesting. > >> >> Is this just a MacOS issue? Should I raise a ticket for it? > > It's presumably Mac-specific, but yes, please file a ticket and I'll take a > look. File it against the network package, not GHC itself. The network package now has a new maintainer (me) and a new trac and repo: http://trac.haskell.org/network/ http://code.haskell.org/network/ I've migrated the old tickets to the new trac. Cheers, Johan From semanticphilosopher at googlemail.com Mon May 4 14:58:11 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Mon May 4 14:43:47 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? In-Reply-To: <90889fe70905041124x403ae892l8c4324b98b21d6d1@mail.gmail.com> References: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> <90889fe70905041124x403ae892l8c4324b98b21d6d1@mail.gmail.com> Message-ID: <37c497340905041158j3f8d4d51haeb173d45bb56d2@mail.gmail.com> Johan Ticket (#8) raised - cheers. Neil 2009/5/4 Johan Tibell > On Mon, May 4, 2009 at 8:20 PM, Bryan O'Sullivan > wrote: > > On Mon, May 4, 2009 at 8:35 AM, Neil Davies > > wrote: > >> > >> It does not appear that you can access the 'addrFlags' returned by > >> getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled > >> bits set: 8 > > > > Interesting. > > > >> > >> Is this just a MacOS issue? Should I raise a ticket for it? > > > > It's presumably Mac-specific, but yes, please file a ticket and I'll take > a > > look. File it against the network package, not GHC itself. > > The network package now has a new maintainer (me) and a new trac and repo: > > http://trac.haskell.org/network/ > > http://code.haskell.org/network/ > > I've migrated the old tickets to the new trac. > > Cheers, > > Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090504/e7f9241f/attachment.htm From kili at outback.escape.de Mon May 4 15:36:00 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Mon May 4 15:22:20 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <87skjl2ym2.fsf@fastmail.fm> References: <87skjl2ym2.fsf@fastmail.fm> Message-ID: <20090504193600.GA1250@petunia.outback.escape.de> Hi, On Sun, May 03, 2009 at 11:03:49PM -0700, brad clawsie wrote: > after some trying, i was unable to get the 6.10.3 prerelease to build on > freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. > > i saved the output of the entire build from ./configure to the point of > failure. it is too long too attach here, you can see it at: > > http://www.b7j0c.org/ghc-6.10.3.log.txt Interesting. haskeline seems to break the build in different ways and at different places (and sometimes it doesn't fail at all). In your case, it doesn't find libiconv, thus isn't built, and causes failure later. In my case (a buildbot running OpenBSD-4.5 on i386), the haskeline build itself fails (see `kili-stable' on darcs.haskell.org/buildbots), but at the same time on OpenBSD-current on an amd64 the haskeline build complains about a missing libiconv but builds nevertheless. This all is a little bit confusing, but it should be fixable by telling configure where to find libivonv (i didn't yet have the time to look what's going on for real here). Ciao, Kili From Geraint.Jones at wolfson.ox.ac.uk Mon May 4 19:43:15 2009 From: Geraint.Jones at wolfson.ox.ac.uk (Geraint Jones) Date: Mon May 4 21:06:40 2009 Subject: strictness of interpreted haskell implementations Message-ID: <200905042343.n44NhFp8002395@merc1.comlab.ox.ac.uk> Sorry to revive a year-old thread, but... On Fri, 25 Apr 2008 at 20:17:53 +0100 Duncan Coutts wrote: > On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote: > > Geraint.Jones: > > > Are there well-known differences in the implementations of Haskell in > > > ghci and hugs? I've got some moderately intricate code (simulations > > > of pipelined processors) that behave differently - apparently because > > > ghci Haskell is stricter than hugs Haskell, and I cannot find any > > > obviously relevant claims about strictness in the documentation. > > I think they should give the same answer. It sounds like a bug in one > implementation or the other. > > > Hugs does no optimisations, while GHC does a truckload, including > > strictness analysis. Some of these optimisations prevent space leaks. > > Though none should change the static semantics. > > Post the code. Even if you don't have time to track down the difference, > someone might. At the time I was reluctant to impose all the code on anyone and I found it hard to cut the example down to a manageable size. I've just got it down to a one-liner: it's the implementation of what I think ought to be strict fields in records: data S = S { a :: Int, b :: ! Int } I think ghci is correct: *Main> a (S { a = 0, b = 1 }) 0 *Main> a (S { a = 0, b = undefined }) *** Exception: Prelude.undefined and that hugs had been concealing a bug in my program by not demanding one of the fields of S when it ought to: Main> a (S { a = 0, b = 1 }) 0 Main> a (S { a = 0, b = undefined }) 0 Ho hum. Is this a "known difference"? (What makes you think I'm teaching the same course again this year?) From clawsie at fastmail.fm Mon May 4 23:55:40 2009 From: clawsie at fastmail.fm (brad clawsie) Date: Mon May 4 23:41:29 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <6d74b0d20905040850y37312e54na726c506fe2278ca@mail.gmail.com> (Judah Jacobson's message of "Mon, 4 May 2009 08:50:40 -0700") References: <87tz412ynw.fsf@fastmail.fm> <6d74b0d20905040850y37312e54na726c506fe2278ca@mail.gmail.com> Message-ID: <86zlds19vn.fsf@bsdarch.gateway.2wire.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Judah Jacobson writes: > It looks like the problem occurs when building Haskeline: > > Configuring haskeline-0.6.1.5... > checking whether to use -liconv... using -liconv. > Setup: Missing dependency on a foreign library: > * Missing C library: iconv > > The problem is that Cabal isn't getting the right argument to look for > iconv in (I'm guessing) /usr/local/lib. yeah, when i installed haskeline via cabal, i had to set the flags to look at these dirs in order to get it built > (Strangely, the Haskeline custom Setup.hs script which detects whether > to use iconv is itself succeeding; I should compare the two and see > what's different...) > > Normally this can be fixed by building Haskeline with the Cabal > arguments --extra-include-dirs, --extra-lib-dirs; but I don't know how > they can be passed through by to the ghc build system. > > Can you please try, with your working ghc-6.10.2: > cd into libraries/haskeline of the release candidate source directory, run > > runghc Setup configure --user -v3 $ cd libraries/haskeline/ $ runghc Setup configure --user -v3 Configuring haskeline-0.6.1.5... Creating dist (and its parents) searching for ghc in path. found ghc at /home/brad/local/bin/ghc ("/home/brad/local/bin/ghc",["--numeric-version"]) /home/brad/local/bin/ghc is version 6.10.2 looking for package tool: ghc-pkg near compiler in /home/brad/local/bin found package tool in /home/brad/local/bin/ghc-pkg ("/home/brad/local/bin/ghc-pkg",["--version"]) /home/brad/local/bin/ghc-pkg is version 6.10.2 ("/home/brad/local/bin/ghc",["--supported-languages"]) Reading installed packages... ("/home/brad/local/bin/ghc-pkg",["dump","--global"]) ("/home/brad/local/bin/ghc-pkg",["dump","--user"]) Setup: At least the following dependencies are missing: ghc-mtl ==1.1.* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkn/uLwACgkQxRg3RkRK91PAvwCgnv4c9zoqPwUZLrvwxkQXJpWu E7gAoJz/BCMyZdjr7/fn/S7kE3EdnmDS =Tg3f -----END PGP SIGNATURE----- From jakubuv at gmail.com Tue May 5 06:06:25 2009 From: jakubuv at gmail.com (Jan Jakubuv) Date: Tue May 5 05:55:44 2009 Subject: GHC 6.10.2 the 'impossible' panic with type families Message-ID: <20090505100625.GA3034@lxultra2.macs.hw.ac.uk> Dear haskellers, with the following code: {-# OPTIONS -fglasgow-exts #-} class SUBST s where type STerm s class OBJECT o where type OTerm o apply :: (SUBST s, OTerm o ~ STerm s) => s -> o fce' f = fce . apply $ f fce f = fce' f I have the following message in both GHCi and GHC (tested on GHC 6.10.1 linux and win, and 6.10.2 linux): ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-linux): idInfo co{v agz} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The above is the smallest example I have found that behaves in this way. It is a striped version of an original and more complicated code. What seems interesting to me is that when one defines `fce` as follows (instead of the above): fce = fce' then everything is ok (= no panic message). In my original code `fce'` was a monad computation, something like: fce' f = fce f >>= \s ? fce (apply s) and this produces the same result (= the panic message). Is this a bug or a known issue? Sincerely, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From johan.tibell at gmail.com Tue May 5 14:23:12 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue May 5 14:08:37 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? In-Reply-To: <37c497340905041158j3f8d4d51haeb173d45bb56d2@mail.gmail.com> References: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> <90889fe70905041124x403ae892l8c4324b98b21d6d1@mail.gmail.com> <37c497340905041158j3f8d4d51haeb173d45bb56d2@mail.gmail.com> Message-ID: <90889fe70905051123h1f23a988wb5c62fed600dbc0@mail.gmail.com> On Mon, May 4, 2009 at 8:58 PM, Neil Davies wrote: > Johan > Ticket (#8)?raised - cheers. > Neil Fixed. Thanks to Bryan for the patch. New version (2.2.1.1) on Hackage contains the fix. Cheers, Johan From semanticphilosopher at googlemail.com Tue May 5 16:13:32 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Tue May 5 15:59:01 2009 Subject: Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2? In-Reply-To: <90889fe70905051123h1f23a988wb5c62fed600dbc0@mail.gmail.com> References: <37c497340905040835q1255fb70yaf4d19cbf8696620@mail.gmail.com> <90889fe70905041124x403ae892l8c4324b98b21d6d1@mail.gmail.com> <37c497340905041158j3f8d4d51haeb173d45bb56d2@mail.gmail.com> <90889fe70905051123h1f23a988wb5c62fed600dbc0@mail.gmail.com> Message-ID: <2ED98514-AD05-463F-B8C7-C0D027570ED1@gmail.com> Johan / Bryan Thanks for the prompt response.. Cheers Neil On 5 May 2009, at 19:23, Johan Tibell wrote: > On Mon, May 4, 2009 at 8:58 PM, Neil Davies > wrote: >> Johan >> Ticket (#8) raised - cheers. >> Neil > > Fixed. Thanks to Bryan for the patch. New version (2.2.1.1) on Hackage > contains the fix. > > Cheers, > > Johan From marlowsd at gmail.com Wed May 6 04:11:08 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 6 03:56:32 2009 Subject: Last CFP: Trends in Functional Programming Message-ID: <4A01461C.40104@gmail.com> [ Forwarding on behalf of Horv?th Zolt?n ] Last call for papers 10th SYMPOSIUM ON TRENDS IN FUNCTIONAL PROGRAMMING TFP 2009 SELYE JANOS UNIVERSITY, KOMARNO, SLOVAKIA June 2-4, 2009 http://www.inf.elte.hu/tfp_cefp_2009 *** Submission deadline extended until 10th of May! *** The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results. Acceptance for the conference is based on full papers or extended abstracts, and a formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2009 is hosted by the Selye Janos University, Komarno, Slovakia, and it is co-located with the 3rd Central-European Functional Programming School (CEFP 2009), which is held immediately before TFP 2009 (May 25-30). IMPORTANT DATES (ALL 2009) * Paper Submission: May 10 (extended) * Notification of Acceptance: May 12 * Camera Ready Symposium Proceedings Paper: May 14 * TFP Symposium: June 2-4, 2009 * Post Symposium Paper Submission: June 30 * Notification of Acceptance: September 7 * Camera Ready Revised Paper: September 21 SCOPE OF THE SYMPOSIUM As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research: leading-edge, previously unpublished research. * Position: on what new trends should or should not be. * Project: descriptions of recently started new projects. * Evaluation: what lessons can be drawn from a finished project. * Overview: summarizing work with respect to a trendy subject. Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience- oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional Languages * New Implementation Strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2009 program chairs, Zoltan Horvath and Viktoria Zsok at tfp2009@inf.elte.hu SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the screening process of full papers (15 pages) and extended abstracts (at least 3 pages). TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings. Further details can be found at the TFP 2009 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. PROGRAM COMMITTEE * Peter Achten (symp-chair), Radboud University Nijmegen, NL * John Clements, California Polytechnic State University, USA * Cormac Flanagan, University of California at Santa Cruz, USA * Jurriaan Hage, Utrecht University, NL * Kevin Hammond, University of St. Andrews, UK * Michael Hanus, Christian-Albrechts University zu Kiel, DE * Ralf Hinze, University of Oxford, UK * Zoltan Horvath (PC co-chair), Eotvos Lorand University, HU * Graham Hutton, University of Nottingham, UK * Johan Jeuring, Utrecht University, NL * Pieter Koopman (symp-chair), Radboud University Nijmegen, NL * Hans-Wolfgang Loidl, Ludwig-Maximilians University Munchen, DE * Rita Loogen, Philipps-University Marburg, DE * Greg Michaelson, Heriot-Watt University, UK * Marco T. Morazan, Seton Hall University, USA * Rex L Page, University of Oklahoma, USA * Sven-Bodo Scholz, University of Hertfordshire, UK * Clara Segura, University Complutense de Madrid, ES * Mary Sheeran, Chalmers University of Technology, SE * Phil Trinder, Heriot-Watt University, UK * Marko van Eekelen, Radboud University Nijmegen, NL * Varmo Vene, University of Tartu, EE * Viktoria Zsok (PC co-chair), Eotvos Lorand University, HU LOCATION The Conference Centre of Selye University, Komarno, Slovakia (http://www.selyeuni.sk/) is a new and excellent conference centre with modern equipment, lecture rooms and computer labs. Komarno is on the north bank of river Danube, the northern part of the city Komarom / Komarno. It is a charming old city with about 30 000 inhabitants, 90 km away from Budapest (the capital of Hungary), with good highway and railway connections and 90 km away from Bratislava (the capital of Slovakia), about 100 km from Vienna International Airport. From mechvel at botik.ru Wed May 6 04:50:09 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed May 6 04:37:21 2009 Subject: 6.10.3-pre Message-ID: <20090506085009.GA14912@scico.botik.ru> Dear GHC team, I have tested ghc-6.10.2.20090430 under Debian Linux, processor = (GenuineIntel cpu family 6, Intel(R) Core(TM)2 CPU 6400). It looks all right. The test was: 1) making ghc-6.10.2.20090430 from source by ghc-6.10.2, 2) making DoCon and running its test, 3) making Dumatel-1.06-pre and running its test, also with -enable-library-profiling and a bit of time profiling (for any future occasion: profiling is important). Regards, ----------------- Serge Mechveliani mechvel@botik.ru From gwright at comcast.net Wed May 6 07:49:08 2009 From: gwright at comcast.net (Gregory Wright) Date: Wed May 6 07:35:07 2009 Subject: ghc-6.10.3-pre on OS X 10.5.6 Message-ID: Hi, I built ghc-6.10.2.20090504 on OS X 10.5.6 (Intel). The build succeeded, and the results of running the 6.10.2 (release) testsuite were: OVERALL SUMMARY for test run started at Wed May 6 04:21:54 EDT 2009 2413 total tests, which gave rise to 12919 test cases, of which 0 caused framework failures 2489 were skipped 10033 expected passes 301 expected failures 0 unexpected passes 96 unexpected failures Unexpected failures: 2469(ghci) 2816(ghci) DoParamM(normal) jl_defaults(ghci) jules_xref(ghci) jules_xref2(ghci) launchbury(ghci) lex(ghci) mod133(normal) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) reify (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) rittri(ghci) signals002(ghci,ghci) signals004 (ghci ,threaded1,threaded2,profthreaded,ghci,threaded1,threaded2,profthreaded) tc183(normal,optc,hpc,optasm,profc,profasm) tc217(normal,optc,hpc,optasm,profc,profasm) tc220(normal,optc,hpc,optasm,profc,profasm) tc223(normal,optc,hpc,optasm,profc,profasm) tc232(normal,optc,hpc,optasm,profc,profasm) tcfail126(normal) tree (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) (I assume that I should be testing with the latest released testsuite in the absence of a snapshot. Is that true?) Best Wishes, Greg From igloo at earth.li Wed May 6 11:58:55 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 6 11:44:20 2009 Subject: 6.10.3 prerelease In-Reply-To: References: <20090502150733.GA27110@matrix.chaos.earth.li> Message-ID: <20090506155855.GA13805@matrix.chaos.earth.li> Hi Hashimoto, On Sun, May 03, 2009 at 01:04:42PM +0900, Yusaku Hashimoto wrote: > > I tried to build prerelease from tarball on Intel Mac (OS 10.4.11) by > ghc-6.10.1 Thanks for the testing! > Running Haddock for base-4.1.0.0... > Warning: The documentation for the following packages are not > installed. No > links will be generated to these packages: rts-1.0 > i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expired > (program cc1) Hmm, is that repeatable? And if so, does it happen if you try to build 6.10.2? Building the pre-release on OS X 10.5 (to make the installer) worked for me. Thanks Ian From igloo at earth.li Wed May 6 12:01:00 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 6 11:46:22 2009 Subject: 6.10.3-pre In-Reply-To: <20090506085009.GA14912@scico.botik.ru> References: <20090506085009.GA14912@scico.botik.ru> Message-ID: <20090506160100.GB13805@matrix.chaos.earth.li> Hi Serge, On Wed, May 06, 2009 at 12:50:09PM +0400, Serge D. Mechveliani wrote: > > I have tested ghc-6.10.2.20090430 > under Debian Linux, > processor = (GenuineIntel cpu family 6, > Intel(R) Core(TM)2 CPU 6400). > It looks all right. Thanks for the testing! Thanks Ian From igloo at earth.li Wed May 6 12:03:36 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 6 11:49:00 2009 Subject: ghc-6.10.3-pre on OS X 10.5.6 In-Reply-To: References: Message-ID: <20090506160336.GC13805@matrix.chaos.earth.li> Hi Greg, On Wed, May 06, 2009 at 07:49:08AM -0400, Gregory Wright wrote: > > I built ghc-6.10.2.20090504 on OS X 10.5.6 (Intel). The build > succeeded, and the results > of running the 6.10.2 (release) testsuite were: Thanks for trying it out! > (I assume that I should be testing with the latest released testsuite > in the absence of a > snapshot. Is that true?) You mean the 6.10.2 testsuite tarball? Yes, that's the best one to use. Thanks Ian From ndmitchell at gmail.com Wed May 6 12:19:47 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 6 12:05:09 2009 Subject: runhaskell a parallel program Message-ID: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> Hi, I've got a program which I'd like to run on multiple threads. If I compile it with ghc --make -threaded, then run with +RTS -N2 it runs on 2 cores very nicely. If however I run it with runhaskell Test.hs +RTS -N2 I get told the -N2 flag isn't supported. Is there a way to runhaskell a program on multiple cores? Is this a bug that it doesn't work, a feature request I'm making, or is there some trick to getting it working I haven't thought of? I'll raise a bug report if that turns out to be the right thing. Thanks Neil From simonpj at microsoft.com Wed May 6 12:49:02 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 6 12:34:25 2009 Subject: GHC 6.10.2 the 'impossible' panic with type families In-Reply-To: <20090505100625.GA3034@lxultra2.macs.hw.ac.uk> References: <20090505100625.GA3034@lxultra2.macs.hw.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337E956DEBA@EA-EXMSG-C334.europe.corp.microsoft.com> Definitely a bug, thank you! I've created a Trac ticket for it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jan Jakubuv | Sent: 05 May 2009 11:06 | To: glasgow-haskell-users@haskell.org | Subject: GHC 6.10.2 the 'impossible' panic with type families | | Dear haskellers, | | with the following code: | | {-# OPTIONS -fglasgow-exts #-} | | class SUBST s where | type STerm s | | class OBJECT o where | type OTerm o | apply :: (SUBST s, OTerm o ~ STerm s) => s -> o | | fce' f = fce . apply $ f | | fce f = fce' f | | I have the following message in both GHCi and GHC (tested on GHC 6.10.1 | linux and win, and 6.10.2 linux): | | ghc: panic! (the 'impossible' happened) | (GHC version 6.10.2 for i386-unknown-linux): | idInfo co{v agz} [tv] | | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | | The above is the smallest example I have found that behaves in this way. It | is a striped version of an original and more complicated code. What seems | interesting to me is that when one defines `fce` as follows (instead of the | above): | | fce = fce' | | then everything is ok (= no panic message). In my original code `fce'` was a | monad computation, something like: | | fce' f = fce f >>= \s ? fce (apply s) | | and this produces the same result (= the panic message). | | Is this a bug or a known issue? | | Sincerely, | Jan. | | | | -- | Heriot-Watt University is a Scottish charity | registered under charity number SC000278. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Wed May 6 15:48:04 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 6 15:33:28 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <20090504193600.GA1250@petunia.outback.escape.de> References: <87skjl2ym2.fsf@fastmail.fm> <20090504193600.GA1250@petunia.outback.escape.de> Message-ID: <20090506194804.GA26428@matrix.chaos.earth.li> H Kili, On Mon, May 04, 2009 at 09:36:00PM +0200, Matthias Kilian wrote: > > In your case, it doesn't find libiconv, thus isn't built, and causes > failure later. In my case (a buildbot running OpenBSD-4.5 on i386), > the haskeline build itself fails (see `kili-stable' on > darcs.haskell.org/buildbots), Is iconv installed somewhere on that machine? If so, where is it? (both the library and the header file) Thanks Ian From igloo at earth.li Wed May 6 15:52:36 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 6 15:37:57 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <87skjl2ym2.fsf@fastmail.fm> References: <87skjl2ym2.fsf@fastmail.fm> Message-ID: <20090506195236.GB26428@matrix.chaos.earth.li> Hi brad, On Sun, May 03, 2009 at 11:03:49PM -0700, brad clawsie wrote: > > after some trying, i was unable to get the 6.10.3 prerelease to build on > freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. Thanks for trying it out! Do you have iconv installed? If so, does applying the patch below and putting: EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/some/path --extra-lib-dirs=/some/other/path (where /some/path and /some/other/path are the paths to the iconv header and library respectively) in mk/build.mk before you start the build work? Thanks Ian diff -rN -u old-ghc/libraries/Makefile new-ghc/libraries/Makefile --- old-ghc/libraries/Makefile 2009-05-06 20:49:11.000000000 +0100 +++ new-ghc/libraries/Makefile 2009-05-06 20:49:11.000000000 +0100 @@ -200,7 +200,8 @@ $(COMMON_CONFIGURE_FLAGS) \ --haddock-options="--use-contents=../index.html \ --use-index=../doc-index.html" \ - $(CONFIGURE_OPTS) + $(CONFIGURE_OPTS) \ + $(EXTRA_CABAL_CONFIGURE_FLAGS) stamp/configure.library.build$(CONFIGURE_STAMP_EXTRAS).dph/dph-par: \ dph/dph-par From kili at outback.escape.de Wed May 6 16:14:17 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Wed May 6 16:00:24 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <20090506194804.GA26428@matrix.chaos.earth.li> References: <87skjl2ym2.fsf@fastmail.fm> <20090504193600.GA1250@petunia.outback.escape.de> <20090506194804.GA26428@matrix.chaos.earth.li> Message-ID: <20090506201417.GA14655@petunia.outback.escape.de> On Wed, May 06, 2009 at 08:48:04PM +0100, Ian Lynagh wrote: > H Kili, > > On Mon, May 04, 2009 at 09:36:00PM +0200, Matthias Kilian wrote: > > > > In your case, it doesn't find libiconv, thus isn't built, and causes > > failure later. In my case (a buildbot running OpenBSD-4.5 on i386), > > the haskeline build itself fails (see `kili-stable' on > > darcs.haskell.org/buildbots), > > Is iconv installed somewhere on that machine? If so, where is it? > (both the library and the header file) Binary in /usr/local/bin/iconv, library in /usr/local/lib, header in /usr/local/include. The strange thing isn't that it isn't detected correctly (linking is done a little bit differently on OpenBSD, you have to explicitely specify depending libs), but that the overall build doesn't fail on my fast build machine at home (which i still have to turn into a buildslave) Anyway, i'll look into this next weekend. Don't hold back the release because of this. For FreeBSD, there should be no problem to add some small patches (or probably just some additional arguments to configure), and for OpenBSD, ir just doesn't matter (because I'll wait for ghc 6.12 with our port). Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list From nonowarn at gmail.com Wed May 6 18:33:45 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Wed May 6 18:19:09 2009 Subject: 6.10.3 prerelease In-Reply-To: <20090506155855.GA13805@matrix.chaos.earth.li> References: <20090502150733.GA27110@matrix.chaos.earth.li> <20090506155855.GA13805@matrix.chaos.earth.li> Message-ID: Hi >> Running Haddock for base-4.1.0.0... >> Warning: The documentation for the following packages are not >> installed. No >> links will be generated to these packages: rts-1.0 >> i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expired >> (program cc1) > > Hmm, is that repeatable? Yes. It is occur when making doc.library.whatever in $TOPDIR/library. It seemed to be SIGVTALRM for schedular is gotten by child process. But I couldn't write smaller example to repeat it. So I wrapped gcc with blocking almost all signals before forking, It just worked. > And if so, does it happen if you try to build 6.10.2? Yes. Same error appeared. > Building the pre-release on OS X 10.5 (to make the installer) > worked for > me. I envy you, Should I upgrade OS? :P Thanks Hashimoto From clawsie at fastmail.fm Thu May 7 02:52:38 2009 From: clawsie at fastmail.fm (brad clawsie) Date: Thu May 7 02:38:09 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <20090506195236.GB26428@matrix.chaos.earth.li> (Ian Lynagh's message of "Wed, 6 May 2009 20:52:36 +0100") References: <87skjl2ym2.fsf@fastmail.fm> <20090506195236.GB26428@matrix.chaos.earth.li> Message-ID: <87r5z15rrd.fsf@fastmail.fm> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Ian, thanks for the response. unfortunately my bsd box has had an accident. i will not be able to test your suggestion below. perhaps if someone else has a freebsd box they can try. thanks brad Ian Lynagh writes: > Do you have iconv installed? > > If so, does applying the patch below and putting: > > EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/some/path --extra-lib-dirs=/some/other/path -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoChTcACgkQxRg3RkRK91OgqACbB3XSp6Yhg6NZ0/3VR72at6ay hWQAn0n8ToaIZXMW0oVSYprnV+2T1Mac =WYet -----END PGP SIGNATURE----- From duncan.coutts at worc.ox.ac.uk Thu May 7 05:15:27 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 7 05:01:10 2009 Subject: strictness of interpreted haskell implementations In-Reply-To: <200905042343.n44NhFp8002395@merc1.comlab.ox.ac.uk> References: <200905042343.n44NhFp8002395@merc1.comlab.ox.ac.uk> Message-ID: <1241687727.1620.1492.camel@localhost> On Tue, 2009-05-05 at 00:43 +0100, Geraint Jones wrote: > Sorry to revive a year-old thread, but... > > On Fri, 25 Apr 2008 at 20:17:53 +0100 Duncan Coutts wrote: > > On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote: > > > Geraint.Jones: > > > > Are there well-known differences in the implementations of Haskell in > > > > ghci and hugs? I've got some moderately intricate code (simulations > > > > of pipelined processors) that behave differently - apparently because > > > > ghci Haskell is stricter than hugs Haskell, and I cannot find any > > > > obviously relevant claims about strictness in the documentation. > > > > I think they should give the same answer. It sounds like a bug in one > > implementation or the other. > > > > > Hugs does no optimisations, while GHC does a truckload, including > > > strictness analysis. Some of these optimisations prevent space leaks. > > > > Though none should change the static semantics. > > > > Post the code. Even if you don't have time to track down the difference, > > someone might. > > At the time I was reluctant to impose all the code on anyone and I found > it hard to cut the example down to a manageable size. I've just got it > down to a one-liner: it's the implementation of what I think ought to be > strict fields in records: > > data S = S { a :: Int, b :: ! Int } > > I think ghci is correct: > > *Main> a (S { a = 0, b = 1 }) > 0 > *Main> a (S { a = 0, b = undefined }) > *** Exception: Prelude.undefined > > and that hugs had been concealing a bug in my program by not demanding > one of the fields of S when it ought to: > > Main> a (S { a = 0, b = 1 }) > 0 > Main> a (S { a = 0, b = undefined }) > 0 > > Ho hum. Is this a "known difference"? It's certainly a bug. I suspect it is not well known. It's not documented at http://cvs.haskell.org/Hugs/pages/users_guide/haskell98.html#BUGS-HASKELL98 Also, if we instead define: data S' = S' Int !Int a' (S' x _) = x b' (S' _ x) = x Then: Main> a' (S' 0 undefined) Program error: Prelude.undefined Which is clearly inconsistent. There's something wrong in hugs with the strictness annotations on data defined using the record syntax. > (What makes you think I'm teaching the same course again this year?) :-) As an ex teaching assistant my recommendation is "Use ghci!". Duncan From marlowsd at gmail.com Thu May 7 06:12:51 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 7 05:58:14 2009 Subject: runhaskell a parallel program In-Reply-To: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> Message-ID: <4A02B423.9090303@gmail.com> On 06/05/2009 17:19, Neil Mitchell wrote: > I've got a program which I'd like to run on multiple threads. If I > compile it with ghc --make -threaded, then run with +RTS -N2 it runs > on 2 cores very nicely. > > If however I run it with runhaskell Test.hs +RTS -N2 I get told the > -N2 flag isn't supported. Is there a way to runhaskell a program on > multiple cores? Is this a bug that it doesn't work, a feature request > I'm making, or is there some trick to getting it working I haven't > thought of? I'll raise a bug report if that turns out to be the right > thing. runhaskell is picking up the +RTS options instead of giving them to GHC itself. Unfortunately there isn't a good way to pass these options to GHC, because it is the GHC runtime interpreting them rather than runhaskell itself. Trying the GHCRTS environment variable doesn't work, because runhaskell isn't compiled with -threaded so it rejects -N2. As a workaround you could use 'ghc -e main foo.hs +RTS -N2'. What's interesting to me is whether the byte-code interpreter will work right with +RTS -N2. It's not disabled, and in theory there's no good reason why it shouldn't work, but it hasn't been tested. Still, parallelism is about performance, and if you want performance you should start by compiling your program. Cheers, Simon From ndmitchell at gmail.com Thu May 7 06:27:34 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 7 06:12:55 2009 Subject: runhaskell a parallel program In-Reply-To: <4A02B423.9090303@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> Message-ID: <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> Hi >> If however I run it with runhaskell Test.hs +RTS -N2 I get told the >> -N2 flag isn't supported. Is there a way to runhaskell a program on >> multiple cores? Is this a bug that it doesn't work, a feature request >> I'm making, or is there some trick to getting it working I haven't >> thought of? I'll raise a bug report if that turns out to be the right >> thing. > > As a workaround you could use 'ghc -e main foo.hs +RTS -N2'. That works great :-) Perhaps this trick should be documented? I thought runhaskell was just sugar over ghc -e, so couldn't it share the same mechanism? > What's interesting to me is whether the byte-code interpreter will work right with +RTS -N2 Isn't ghc -e using the byte-code interpreter? > Still, parallelism > is about performance, and if you want performance you should start by > compiling your program. This is a test framework that spawns system commands. My guess is the Haskell accounts for a few milliseconds of execution per hour. Running two system commands in parallel gives a massive boost. A related question I wanted to ask. Is there any way to have my Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At the moment I've set this up with a shell script to translate the -j3, but a nicer method would be preferable. Even something as sledgehammer like as restartWithNProcessors :: Int -> IO (), which aborted the program entirely and restarted main with a completely fresh heap but a given number of processors. Thanks Neil From bulat.ziganshin at gmail.com Thu May 7 06:37:53 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 7 06:26:56 2009 Subject: runhaskell a parallel program In-Reply-To: <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> Message-ID: <1765295760.20090507143753@gmail.com> Hello Neil, Thursday, May 7, 2009, 2:27:34 PM, you wrote: > This is a test framework that spawns system commands. My guess is the > Haskell accounts for a few milliseconds of execution per hour. Running > two system commands in parallel gives a massive boost. > A related question I wanted to ask. Is there any way to have my > Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At my own program creates a lot of parallel threads without using -N the secret is using of forkOS plus C code in threads. since you spend time in system calls this should also work for you -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Thu May 7 09:12:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu May 7 08:57:47 2009 Subject: ghc 6.10.3-prerelease failed build log for freebsd7.2 In-Reply-To: <87r5z15rrd.fsf@fastmail.fm> References: <87skjl2ym2.fsf@fastmail.fm> <20090506195236.GB26428@matrix.chaos.earth.li> <87r5z15rrd.fsf@fastmail.fm> Message-ID: <20090507131227.GA19421@matrix.chaos.earth.li> On Wed, May 06, 2009 at 11:52:38PM -0700, brad clawsie wrote: > > hi Ian, thanks for the response. unfortunately my bsd box has had an > accident. i will not be able to test your suggestion below. OK, no problem. Last night's build on kili went through: http://darcs.haskell.org/buildbot/all/builders/kili%20stable/builds/90 so it looks like we're good to go! Thanks Ian From marlowsd at gmail.com Thu May 7 09:24:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 7 09:10:15 2009 Subject: runhaskell a parallel program In-Reply-To: <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> Message-ID: <4A02E126.1090800@gmail.com> On 07/05/2009 11:27, Neil Mitchell wrote: > Hi > >>> If however I run it with runhaskell Test.hs +RTS -N2 I get told the >>> -N2 flag isn't supported. Is there a way to runhaskell a program on >>> multiple cores? Is this a bug that it doesn't work, a feature request >>> I'm making, or is there some trick to getting it working I haven't >>> thought of? I'll raise a bug report if that turns out to be the right >>> thing. >> As a workaround you could use 'ghc -e main foo.hs +RTS -N2'. > > That works great :-) Perhaps this trick should be documented? I > thought runhaskell was just sugar over ghc -e, so couldn't it share > the same mechanism? > >> What's interesting to me is whether the byte-code interpreter will work right with +RTS -N2 > > Isn't ghc -e using the byte-code interpreter? Yes; apparently it "works", though we still haven't stress-tested it running real parallel programs using GHCi with +RTS -N2. >> Still, parallelism >> is about performance, and if you want performance you should start by >> compiling your program. > > This is a test framework that spawns system commands. My guess is the > Haskell accounts for a few milliseconds of execution per hour. Running > two system commands in parallel gives a massive boost. That still doesn't explain why you need +RTS -N2. You can spawn multiple processes by making multiple calls to runProcess or whatever. If you want to wait for multiple processes simultaneously, compile with -threaded and use forkIO. > A related question I wanted to ask. Is there any way to have my > Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At > the moment I've set this up with a shell script to translate the -j3, > but a nicer method would be preferable. Even something as sledgehammer > like as restartWithNProcessors :: Int -> IO (), which aborted the > program entirely and restarted main with a completely fresh heap but a > given number of processors. We don't have anything like that right now. Personally I think the shell script method is quite reasonable. Cheers, Simon From marlowsd at gmail.com Thu May 7 09:27:04 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 7 09:12:25 2009 Subject: runhaskell a parallel program In-Reply-To: <1765295760.20090507143753@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <1765295760.20090507143753@gmail.com> Message-ID: <4A02E1A8.50804@gmail.com> On 07/05/2009 11:37, Bulat Ziganshin wrote: > Hello Neil, > > Thursday, May 7, 2009, 2:27:34 PM, you wrote: > >> This is a test framework that spawns system commands. My guess is the >> Haskell accounts for a few milliseconds of execution per hour. Running >> two system commands in parallel gives a massive boost. > >> A related question I wanted to ask. Is there any way to have my >> Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At > > my own program creates a lot of parallel threads without using -N > > the secret is using of forkOS plus C code in threads. since you > spend time in system calls this should also work for you Are you sure you need forkOS, and not just forkIO? Why? Cheers, Simon From bulat.ziganshin at gmail.com Thu May 7 09:42:01 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 7 09:27:43 2009 Subject: runhaskell a parallel program In-Reply-To: <4A02E1A8.50804@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <1765295760.20090507143753@gmail.com> <4A02E1A8.50804@gmail.com> Message-ID: <407078912.20090507174201@gmail.com> Hello Simon, Thursday, May 7, 2009, 5:27:04 PM, you wrote: >> my own program creates a lot of parallel threads without using -N >> >> the secret is using of forkOS plus C code in threads. since you >> spend time in system calls this should also work for you > Are you sure you need forkOS, and not just forkIO? Why? well, 4 years ago or so i discovered that my program can perform compression (C) threads simultaneously only if i use forkOS. i don't tried to jump to forkIO later ... just recompiled program with forkIO - it still works. at least on this quad-core cpu. so it was just my laziness, sorry for all those 4-year noise :( -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu May 7 09:45:29 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 7 09:31:09 2009 Subject: runhaskell a parallel program In-Reply-To: <4A02E126.1090800@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <4A02E126.1090800@gmail.com> Message-ID: <1469078827.20090507174529@gmail.com> Hello Simon, Thursday, May 7, 2009, 5:24:54 PM, you wrote: >> A related question I wanted to ask. Is there any way to have my >> Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At >> the moment I've set this up with a shell script to translate the -j3, >> but a nicer method would be preferable. Even something as sledgehammer >> like as restartWithNProcessors :: Int -> IO (), which aborted the >> program entirely and restarted main with a completely fresh heap but a >> given number of processors. Neil, you can implement it by yourself - convert -j3 in cmdline to +RTS -N3 -RTS and run program itself. alternatively, you can use defaultsHook() although i'm not sure that it can change number of Capabilities -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Thu May 7 10:07:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 7 09:52:51 2009 Subject: runhaskell a parallel program In-Reply-To: <1469078827.20090507174529@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <4A02E126.1090800@gmail.com> <1469078827.20090507174529@gmail.com> Message-ID: <404396ef0905070707o3c0e7c3ah5cc78e44477c8b10@mail.gmail.com> Hi Bulat, > Neil, you can implement it by yourself - convert -j3 in cmdline to > +RTS -N3 -RTS and run program itself. alternatively, you can use > defaultsHook() although i'm not sure that it can change number of > Capabilities Can I run a program itself? getProgName doesn't give me enough to invoke myself (unfortunately) I don't want to write any C - that's just more hassle than a shell script wrapping the command. Thanks Neil From ndmitchell at gmail.com Thu May 7 10:12:21 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 7 09:57:41 2009 Subject: runhaskell a parallel program In-Reply-To: <4A02E126.1090800@gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <4A02E126.1090800@gmail.com> Message-ID: <404396ef0905070712p352572b7j32fc13f11e3ebd2b@mail.gmail.com> Hi >> Isn't ghc -e using the byte-code interpreter? > > Yes; apparently it "works", though we still haven't stress-tested it running > real parallel programs using GHCi with +RTS -N2. It seemed perfectly stable when I tried, on a few examples I had knocking around. > >>> Still, parallelism >>> is about performance, and if you want performance you should start by >>> compiling your program. >> >> This is a test framework that spawns system commands. My guess is the >> Haskell accounts for a few milliseconds of execution per hour. Running >> two system commands in parallel gives a massive boost. > > That still doesn't explain why you need +RTS -N2. ?You can spawn multiple > processes by making multiple calls to runProcess or whatever. If you want to > wait for multiple processes simultaneously, compile with -threaded and use > forkIO. I do need to wait for them - so I don't end up firing too many at once. I was hoping to avoid the compile, which the ghc -e will give me. >> A related question I wanted to ask. Is there any way to have my >> Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At >> the moment I've set this up with a shell script to translate the -j3, >> but a nicer method would be preferable. Even something as sledgehammer >> like as restartWithNProcessors :: Int -> ?IO (), which aborted the >> program entirely and restarted main with a completely fresh heap but a >> given number of processors. > > We don't have anything like that right now. ?Personally I think the shell > script method is quite reasonable. My shell script also does -g1, so for the moment it's not too bad. But for example I added parallel execution to HLint over the weekend - I don't want to add a shell script to invoke it, and I'm not entirely comfortable with documenting +RTS -N2 -RTS as the way to -j3 it. If a nicer way ever turned out to be relatively pain free to implement, it would be nice. I'll raise a feature request bug. Thanks Neil From allbery at ece.cmu.edu Thu May 7 13:12:43 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu May 7 12:58:16 2009 Subject: runhaskell a parallel program In-Reply-To: <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> Message-ID: On May 7, 2009, at 06:27 , Neil Mitchell wrote: >>> If however I run it with runhaskell Test.hs +RTS -N2 I get told the >>> -N2 flag isn't supported. Is there a way to runhaskell a program on >> >> As a workaround you could use 'ghc -e main foo.hs +RTS -N2'. > > That works great :-) Perhaps this trick should be documented? I > thought runhaskell was just sugar over ghc -e, so couldn't it share > the same mechanism? I think the problem is that runhaskell invokes the runghc executable in the GHC libdir, which is itself a non-threaded Haskell program and therefore consumes the RTS options. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090507/c3a61164/PGP-0001.bin From duncan.coutts at worc.ox.ac.uk Thu May 7 18:58:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 7 18:44:34 2009 Subject: runhaskell a parallel program In-Reply-To: <404396ef0905070712p352572b7j32fc13f11e3ebd2b@mail.gmail.com> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <4A02E126.1090800@gmail.com> <404396ef0905070712p352572b7j32fc13f11e3ebd2b@mail.gmail.com> Message-ID: <1241737130.1620.2347.camel@localhost> On Thu, 2009-05-07 at 15:12 +0100, Neil Mitchell wrote: > >> This is a test framework that spawns system commands. My guess is the > >> Haskell accounts for a few milliseconds of execution per hour. Running > >> two system commands in parallel gives a massive boost. > > > > That still doesn't explain why you need +RTS -N2. You can spawn multiple > > processes by making multiple calls to runProcess or whatever. If you want to > > wait for multiple processes simultaneously, compile with -threaded and use > > forkIO. > > I do need to wait for them - so I don't end up firing too many at > once. I was hoping to avoid the compile, which the ghc -e will give > me. Right, it works because ghc itself is compiled with the threaded rts. So you don't need the +RTS -N when you call ghc -e. Note that for the next ghc release the process library will use a different implementation of waitForProcess (at least on Unix) so will not need multiple OS threads to wait for multiple processes simultaneously. Duncan From marlowsd at gmail.com Fri May 8 03:57:44 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 8 03:43:04 2009 Subject: runhaskell a parallel program In-Reply-To: <1241737130.1620.2347.camel@localhost> References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> <4A02E126.1090800@gmail.com> <404396ef0905070712p352572b7j32fc13f11e3ebd2b@mail.gmail.com> <1241737130.1620.2347.camel@localhost> Message-ID: <4A03E5F8.6070704@gmail.com> On 07/05/2009 23:58, Duncan Coutts wrote: > Note that for the next ghc release the process library will use a > different implementation of waitForProcess (at least on Unix) so will > not need multiple OS threads to wait for multiple processes > simultaneously. It will if I ever get it finished... Cheers, Simon From marlowsd at gmail.com Fri May 8 03:58:18 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 8 03:43:37 2009 Subject: runhaskell a parallel program In-Reply-To: References: <404396ef0905060919j543bc370u6d040dad8dc0b042@mail.gmail.com> <4A02B423.9090303@gmail.com> <404396ef0905070327xe88ac61h92fcc1ff49a74aae@mail.gmail.com> Message-ID: <4A03E61A.9060409@gmail.com> On 07/05/2009 18:12, Brandon S. Allbery KF8NH wrote: > On May 7, 2009, at 06:27 , Neil Mitchell wrote: >>>> If however I run it with runhaskell Test.hs +RTS -N2 I get told the >>>> -N2 flag isn't supported. Is there a way to runhaskell a program on >>> >>> As a workaround you could use 'ghc -e main foo.hs +RTS -N2'. >> >> That works great :-) Perhaps this trick should be documented? I >> thought runhaskell was just sugar over ghc -e, so couldn't it share >> the same mechanism? > > I think the problem is that runhaskell invokes the runghc executable in > the GHC libdir, which is itself a non-threaded Haskell program and > therefore consumes the RTS options. Exactly. Simon From petersen at haskell.org Sat May 9 03:59:22 2009 From: petersen at haskell.org (Jens Petersen) Date: Sat May 9 03:44:38 2009 Subject: [web] distro page update for Fedora Message-ID: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> Hi, I can't remember if I actually reported this before - I certainly meant too... :) Could you please update the Fedora entry on the distribution packages page: http://haskell.org/ghc/distribution_packages.html Please replace `RPMs are available from Fedora Extras' with `Fedora users can install with "yum install ghc"'. "Fedora Extras" also appears under the openSUSE entry! Could you please remove that. Thank you, Jens on behalf of the Fedora Haskell SIG From igloo at earth.li Sat May 9 09:59:57 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 9 09:45:20 2009 Subject: ANNOUNCE: GHC version 6.10.3 Message-ID: <20090509135957.GA8824@matrix.chaos.earth.li> ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 6.10.2 and better line editing support in GHCi, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.3/html/users_guide/release-6-10-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug From igloo at earth.li Sat May 9 10:07:54 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 9 09:53:10 2009 Subject: [web] distro page update for Fedora In-Reply-To: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> References: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> Message-ID: <20090509140754.GA13005@matrix.chaos.earth.li> On Sat, May 09, 2009 at 05:59:22PM +1000, Jens Petersen wrote: > > Could you please update the Fedora entry on the distribution packages page: > http://haskell.org/ghc/distribution_packages.html > > Please replace `RPMs are available from Fedora Extras' with > `Fedora users can install with "yum > install ghc"'. Thanks for the update; done. > "Fedora Extras" also appears under the openSUSE entry! Could you > please remove that. Ooops, now changed to say openSUSE. Thanks Ian From simonpj at microsoft.com Sun May 10 13:52:09 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sun May 10 13:37:21 2009 Subject: Functions for builtin operators (?) In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C335080DF108@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337E968850A@EA-EXMSG-C334.europe.corp.microsoft.com> sorry, got diverted by paper writing. GHC desugars Hsakell into Core, and it's Core that you are consuming in the ESC stuff. However, Core for an *overloaded* function contains dictionary applications and abstractions. Furthermore, overloaded operators turn into selectors, which pick out a particular field from a dictionary. See any description of how to compile type classes for examples of this. So here you've got something like (>) d x y where (>) is defined like this (>) (MkOrd _ _ gr _) = gr That is, (>) picks out the gr field from the dictionary. So it's all very higher-order in reality. And that is what is giving trouble to the ESC stuff. After all, what do we know about *all* implementations of (>) at *all* types? Not much! Dana and I did not explore much how to give a good treatment to overloaded functions. I would not expect it to "just work". I hope this helps a bit Simon | -----Original Message----- | From: Colin Paul Adams [mailto:colin@colina.demon.co.uk] | Sent: 08 April 2009 11:04 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Functions for builtin operators (?) | | >>>>> "Simon" == Simon Peyton-Jones writes: | | Simon> Nowhere. It's a name generated by GHC itself during | Simon> compilation. | | OK. | Is there some way to recognise what the function is? | | The problem is with ESC/Haskell. I have managed to get the code | integrated into the 6.11 tree, and it works up to a point. | | It produces output like: | | Len.hs:4:0: | Len.pos does not satisfy its contract! | Counter example: | Len.pos with argument(s) x | (Inside _GHC.Classes.>_ ( tpl_B6 )) x ((GHC.Types.I# 0)) | | which is basically saying that it can't trust _GHC.Classes.>_ ( tpl_B6 | ) to do anything in particular, as it doesn't know anything about it. | | So it would be good to add code that recognises these functions. At | best, to know the semantics of each one. | | Colin> | Where is a function with a name like the following | Colin> defined in the ghc source | code? | Colin> | | Colin> | .Classes.>_ ( tpl_B6 ) | | | | -- | Colin Adams | Preston Lancashire From colin at colina.demon.co.uk Sun May 10 14:05:09 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun May 10 13:50:19 2009 Subject: Functions for builtin operators (?) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337E968850A@EA-EXMSG-C334.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Sun\, 10 May 2009 18\:52\:09 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C335080DF108@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C337E968850A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: >>>>> "Simon" == Simon Peyton-Jones writes: Simon> sorry, got diverted by paper writing. Well, I've got diverted by the dragonfly season starting, so i don't suppose I shall look at this again until October. Simon> GHC desugars Hsakell into Core, and it's Core that you are consuming in the ESC Simon> stuff. However, Core for an *overloaded* function contains Simon> dictionary applications and abstractions. Furthermore, Simon> overloaded operators turn into selectors, which pick out a Simon> particular field from a dictionary. See any description of Simon> how to compile type classes for examples of this. Simon> So here you've got something like (>) d x y where (>) is Simon> defined like this (>) (MkOrd _ _ gr _) = gr That is, (>) Simon> picks out the gr field from the dictionary. So it's all Simon> very higher-order in reality. And that is what is giving Simon> trouble to the ESC stuff. After all, what do we know about Simon> *all* implementations of (>) at *all* types? Not much! Simon> Dana and I did not explore much how to give a good Simon> treatment to overloaded functions. I would not expect it Simon> to "just work". Simon> I hope this helps a bit Thanks. I feared it wasn't going to be easy. Maybe I'll think about it in October. -- Colin Adams Preston Lancashire From dons at galois.com Sun May 10 23:55:11 2009 From: dons at galois.com (Don Stewart) Date: Tue May 12 04:01:40 2009 Subject: [johan.tibell@gmail.com: [Haskell-cafe] Heads up: Conflicting versions of network-2.2.1] Message-ID: <20090511035511.GB11217@whirlpool.galois.com> ----- Forwarded message from Johan Tibell ----- Date: Sun, 10 May 2009 19:23:20 +0200 From: Johan Tibell To: haskell-cafe Subject: [Haskell-cafe] Heads up: Conflicting versions of network-2.2.1 Hi, The version of network-2.2.1 that shipped with GHC 6.10 differs from the one on Hackage [1]. The version that was released with GHC was never uploaded to Hackage and was never tagged in the darcs repository. When making a new release of network I forgot to check the version number on the version of network that shipped with GHC. My appologies. If you want the API additions that are present in network-2.2.1 on Hackage use network-2.2.1.1 instead to make sure that e.g. cabal-install doesn't use the version of network that comes with GHC. In the future there won't be any releases directly from the darcs repo. All releases will be made on Hackage to later be picked up by the Haskell Platform. Cheers, Johan 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.2.1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- From bulat.ziganshin at gmail.com Mon May 11 06:01:01 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 12 04:09:29 2009 Subject: defaultsHook isn't documented In-Reply-To: <548069624.20090511122850@gmail.com> References: <548069624.20090511122850@gmail.com> Message-ID: <1986263987.20090511140101@gmail.com> Hello glasgow-haskell-users, it seems that defaultsHook isn't documented on http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-hooks neither anywhere else in user manual -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From petersen at haskell.org Tue May 12 20:21:15 2009 From: petersen at haskell.org (Jens Petersen) Date: Tue May 12 20:06:30 2009 Subject: [web] distro page update for Fedora In-Reply-To: <20090509140754.GA13005@matrix.chaos.earth.li> References: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> <20090509140754.GA13005@matrix.chaos.earth.li> Message-ID: <9436bffe0905121721n5c2f3325re2cf735015c35eac@mail.gmail.com> 2009/5/10 Ian Lynagh : > On Sat, May 09, 2009 at 05:59:22PM +1000, Jens Petersen wrote: >> >> Could you please update the Fedora entry on the distribution packages page: : > Thanks for the update; done. Thank you very much, Ian! Sorry one more thing I forgot: would you mind adding the following text too: The packages are maintained by the Fedora Haskell SIG. Jens From dons at galois.com Wed May 13 00:06:32 2009 From: dons at galois.com (Don Stewart) Date: Tue May 12 23:53:04 2009 Subject: [web] distro page update for Fedora In-Reply-To: <9436bffe0905121721n5c2f3325re2cf735015c35eac@mail.gmail.com> References: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> <20090509140754.GA13005@matrix.chaos.earth.li> <9436bffe0905121721n5c2f3325re2cf735015c35eac@mail.gmail.com> Message-ID: <20090513040632.GA21997@whirlpool.galois.com> petersen: > 2009/5/10 Ian Lynagh : > > On Sat, May 09, 2009 at 05:59:22PM +1000, Jens Petersen wrote: > >> > >> Could you please update the Fedora entry on the distribution packages page: > : > > Thanks for the update; done. > > Thank you very much, Ian! > > Sorry one more thing I forgot: would you mind adding the following text too: > > The packages are maintained by the href="https://fedoraproject.org/wiki/SIGs/Haskell">Fedora Haskell > SIG. Any details on Fedora support for the Haskell Platform? I can update: http://hackage.haskell.org/platform/ if you have info. -- Don From peteg42 at gmail.com Wed May 13 04:32:32 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 13 04:17:55 2009 Subject: GHCi's search path Message-ID: Hello, According to the manual: http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/separate-compilation.html#search-path GHCi is not overly keen to go looking for modules in directories different to where the source resides. The semantics I want is: - use the Cabal-built objects/hi files in dist/build if they're fresh enough - interpret the source otherwise. Is that possible? cheers peter From Alistair.Bayley at invesco.com Wed May 13 04:43:52 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed May 13 04:29:10 2009 Subject: GHCi's search path In-Reply-To: References: Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911025FD6@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Peter Gammie > > http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/se > parate-compilation.html#search-path > > GHCi is not overly keen to go looking for modules in directories > different to where the source resides. > > The semantics I want is: > - use the Cabal-built objects/hi files in dist/build if they're > fresh enough > - interpret the source otherwise. > > Is that possible? I think the -odir and -hidir options will help e.g. -odir dist/build -hidir dist/build http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/separate-com pilation.html#options-output Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From peteg42 at gmail.com Wed May 13 05:01:23 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 13 04:46:38 2009 Subject: GHCi's search path In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA911025FD6@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA911025FD6@GBLONXMB02.corp.amvescap.net> Message-ID: On 13/05/2009, at 6:43 PM, Bayley, Alistair wrote: >> From: glasgow-haskell-users-bounces@haskell.org >> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf >> Of Peter Gammie >> >> http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/se >> parate-compilation.html#search-path >> >> GHCi is not overly keen to go looking for modules in directories >> different to where the source resides. >> >> The semantics I want is: >> - use the Cabal-built objects/hi files in dist/build if they're >> fresh enough >> - interpret the source otherwise. >> >> Is that possible? > > I think the -odir and -hidir options will help > e.g. -odir dist/build -hidir dist/build > > http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/separate-com > pilation.html#options-output I tried these too, no luck. cheers peter From ganesh.sittampalam at credit-suisse.com Wed May 13 05:17:06 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed May 13 05:04:32 2009 Subject: GHCi's search path In-Reply-To: References: <125EACD0CAE4D24ABDB4D148C4593DA911025FD6@GBLONXMB02.corp.amvescap.net> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABAB05@ELON17P32001A.csfb.cs-group.com> Peter Gammie wrote: > On 13/05/2009, at 6:43 PM, Bayley, Alistair wrote: > >>> From: glasgow-haskell-users-bounces@haskell.org >>> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of >>> Peter Gammie >>> The semantics I want is: >>> - use the Cabal-built objects/hi files in dist/build if they're >>> fresh enough >>> - interpret the source otherwise. >>> >>> Is that possible? >> >> I think the -odir and -hidir options will help e.g. -odir >> dist/build -hidir dist/build >> >> http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/separate-c >> om pilation.html#options-output > > I tried these too, no luck. I've done this myself (though my objects were built by my Makefile, not by cabal) and it works fine for me. Note that once something has changed, everything that depends on it will be interpreted, even if it wouldn't actually need recompiling. Not quite sure what you can do to debug it if it's not working for you though :-( Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From donnie at darthik.com Wed May 13 14:53:15 2009 From: donnie at darthik.com (Donnie Jones) Date: Wed May 13 14:38:25 2009 Subject: [Haskell-cafe] ghc ./configure stalls on docbook DTD In-Reply-To: <4A0B1304.7060401@gmail.com> References: <4A0B1304.7060401@gmail.com> Message-ID: Hello Dan, Best place to ask is glasgow-haskell-users@haskell.org since that is the GHC users list. I have CC'd your email to the GHC user list. Cheers. -- Donnie Jones On Wed, May 13, 2009 at 1:35 PM, Dan wrote: > Hi, > > Not sure if this is the right place to ask. > GHC 6.10.3 source dist: ./configure takes about 10 minutes to look for > DocBook DTD and another 10 to look for DocBook XSL directory. ?I was writing > this e-mail thinking it had completely crashed. ?Any reason why it's so > ridiculously slow? A look at 'top' says the CPU is mostly idle during this > time, but xmllint is running. > > Mac OS X > > uname -a: Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST > 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 > > CookBook:ghc-6.10.3 dan$ ./configure > checking build system type... i386-apple-darwin9.6.0 > checking host system type... i386-apple-darwin9.6.0 > checking target system type... i386-apple-darwin9.6.0 > Canonicalised to: i386-apple-darwin > [blah blah blah] > checking for xmllint... /usr/bin/xmllint > checking for DocBook DTD... > (blocks for ages) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From igloo at earth.li Wed May 13 16:54:23 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 13 16:39:26 2009 Subject: [web] distro page update for Fedora In-Reply-To: <9436bffe0905121721n5c2f3325re2cf735015c35eac@mail.gmail.com> References: <9436bffe0905090059l50cc337sb12da752a5bfa52d@mail.gmail.com> <20090509140754.GA13005@matrix.chaos.earth.li> <9436bffe0905121721n5c2f3325re2cf735015c35eac@mail.gmail.com> Message-ID: <20090513205423.GA4076@matrix.chaos.earth.li> On Wed, May 13, 2009 at 10:21:15AM +1000, Jens Petersen wrote: > > Sorry one more thing I forgot: would you mind adding the following text too: > > The packages are maintained by the href="https://fedoraproject.org/wiki/SIGs/Haskell">Fedora Haskell > SIG. Added, thanks! Ian From phercek at gmail.com Thu May 14 17:24:40 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu May 14 17:09:55 2009 Subject: ANN: GhciExt 0.6 for GHC 6.10.3 Message-ID: Hi, I know there were 4 unique IP addresses which checked it out. Since I do not know who they are I just spam this list again :) You can get it here: http://www.hck.sk/users/peter/pub/ If you decide to give it a try then read the README file before installing. It should work with the stock GHC 6.10.2 and higher, but I only tried briefly with GHC 6.10.3 (as it was released) and I use it without any problem with my customized GHC 6.10.3 (dirty support for ansi escape sequences in ':set prompt' for color highlighting of the prompt, patch for ticket http://hackage.haskell.org/trac/ghc/ticket/3084 (allow macros to redefine builtin GHCi commands), and few more details). Here is what it does: Prelude> :defs long :. -- source commands from :* ... -- run times :x ... -- run with stdout suppressed :out -- redirect ghci stdout back to console :redir ... -- execute redirecting stdout to :grep < ... -- run grep on output Runs grep from your OS on the output of . This means all the options of your OS grep are available. '<' separates grep options from the command. :find [-] -- step with until is found Prepend variable name with '-' to disable printing of its value. :locate -- step with until location is hit :bp -- put breakpoint at (adds hit count) :inject -- at location run if and stop if There are two special identifiers which can be used in the breakpoint code () and the breakpoint stop condition (); but which are not usable in the breakpoint code condition (). These are: - ghciExt_BpId - macro name; translates to breakpoint id - ghciExt_HitCnt - macro name; translates to breakpoint hit count :strobe [""] -- at location show hit count if :monitor [""] -- show comma-sep. variables at location if :watch -- break at location when is True :count [] -- count/stop execution at or query bp hits There are three ways how to use this command: - :count 0 - never stops; counts hits and extends trace history - :count N - stops when location is hit N-th time - :count N - shows hit count of a ghciExt breakpoint with number N. :hl ... -- highlight the output of :defs [long] -- list user commands (possibly with long help) General information for all GhciExt commands: - Most arguments may be in quotation marks (to allow spaces in them). - Instead of a regular quotation mark, @x can be used to start a string argument too. In such a case the argument is finished when character x appears again after `@x' string. Use any character in place of x. This was added so that one does not need to escape quotation marks and back-slashes in arguments (especially those representing code). Prelude> Not so much obsolete description of how it works (and how to use it) is here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 Notable changes are: * much better :grep command (you can even get color highlighted output) * you do not need to prefix commands :main, :continute, :step, and :trace with :x any more * :findex replaced with much better :locate It works on linux. The only reason I recall it would not work on windows is the use of '/dev/null'. But I never tried on windows. Enjoy, Peter. From DekuDekuplex at Yahoo.com Fri May 15 00:52:47 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri May 15 00:40:06 2009 Subject: ANNOUNCE: GHC version 6.10.3 References: <20090509135957.GA8824@matrix.chaos.earth.li> Message-ID: What happened to the Windows installation section in the corresponding User's Guide? The User's Guide for GHC version 6.10.2 (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) had section 2.2: Installing on Windows (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), but this section seems to be missing in the corresponding document for version 6.10.3 (see http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). Not only that, but the entire chapter "2: Installing GHC" seems to be missing. -- Benjamin L. Russell On Sat, 9 May 2009 14:59:57 +0100, Ian Lynagh wrote: > > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 6.10.3 > ============================================================== > >The GHC Team is pleased to announce a new patchlevel release of GHC. >This release contains a handful of bugfixes relative to 6.10.2 and >better line editing support in GHCi, so we recommend upgrading. > >Release notes are here: > > http://haskell.org/ghc/docs/6.10.3/html/users_guide/release-6-10-3.html > >How to get it >~~~~~~~~~~~~~ > >The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > >We supply binary builds in the native package format for many >platforms, and the source distribution is available from the same >place. > >Packages will appear as they are built - if the package for your >system isn't available yet, please try again later. > > >Background >~~~~~~~~~~ > >Haskell is a standard lazy functional programming language; the >current language version is Haskell 98, agreed in December 1998 and >revised December 2002. > >GHC is a state-of-the-art programming suite for Haskell. Included is >an optimising compiler generating good code for a variety of >platforms, together with an interactive system for convenient, quick >development. The distribution includes space and time profiling >facilities, a large collection of libraries, and support for various >language extensions, including concurrency, exceptions, and foreign >language interfaces (C, whatever). GHC is distributed under a >BSD-style open source license. > >A wide variety of Haskell related resources (tutorials, libraries, >specifications, documentation, compilers, interpreters, references, >contact information, links to research groups) are available from the >Haskell home page (see below). > > >On-line GHC-related resources >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >Relevant URLs on the World-Wide Web: > >GHC home page http://www.haskell.org/ghc/ >GHC developers' home page http://hackage.haskell.org/trac/ghc/ >Haskell home page http://www.haskell.org/ > > >Supported Platforms >~~~~~~~~~~~~~~~~~~~ > >The list of platforms we support, and the people responsible for them, >is here: > > http://hackage.haskell.org/trac/ghc/wiki/Contributors > >Ports to other platforms are possible with varying degrees of >difficulty. The Building Guide describes how to go about porting to a >new platform: > > http://hackage.haskell.org/trac/ghc/wiki/Building > > >Developers >~~~~~~~~~~ > >We welcome new contributors. Instructions on accessing our source >code repository, and getting started with hacking on GHC, are >available from the GHC's developer's site run by Trac: > > http://hackage.haskell.org/trac/ghc/ > > >Mailing lists >~~~~~~~~~~~~~ > >We run mailing lists for GHC users and bug reports; to subscribe, use >the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > >There are several other haskell and ghc-related mailing lists on >www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > >Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > >Please report bugs using our bug tracking system. Instructions on >reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From mechvel at botik.ru Fri May 15 04:00:20 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri May 15 03:48:44 2009 Subject: comprehension vs `map' Message-ID: <20090515080020.GA14200@scico.botik.ru> Dear GHC team, I would like to write [rl {ruleMode = AlwaysApply} | rl <- rules calc] (I) instead of map (\ rl -> rl {ruleMode = AlwaysApply}) $ rules calc (II) and instead of let rs = rules calc in [rl {ruleMode = AlwaysApply} | rl <- rs] (III). But is this reliable in GHC that the compiler converts (I) into something which is not not worse than III ? What about other implementations? Regards, ----------- Mechveliani mechvel@botik.ru From marlowsd at gmail.com Fri May 15 04:16:13 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 15 04:03:54 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.3 In-Reply-To: References: <20090509135957.GA8824@matrix.chaos.earth.li> Message-ID: <4A0D24CD.30000@gmail.com> On 15/05/2009 05:52, Benjamin L.Russell wrote: > What happened to the Windows installation section in the corresponding > User's Guide? The User's Guide for GHC version 6.10.2 (see > http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) > had section 2.2: Installing on Windows (see > http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), > but this section seems to be missing in the corresponding document for > version 6.10.3 (see > http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). > Not only that, but the entire chapter "2: Installing GHC" seems to be > missing. The "Installing GHC" section was mostly out-of-date and wrong, so I removed it. Some of the material, such as the section on the layout of the tree, has been updated and moved to the GHC Building Guide, here http://hackage.haskell.org/trac/ghc/wiki/Building We also have lots of information on the GHC web site about obtaining and installing GHC, so if we need anything else I think that would be the best place to put it. Cheers, Simon From simonpj at microsoft.com Fri May 15 04:42:06 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 15 04:27:26 2009 Subject: comprehension vs `map' In-Reply-To: <20090515080020.GA14200@scico.botik.ru> References: <20090515080020.GA14200@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FBFCCDD6@EA-EXMSG-C334.europe.corp.microsoft.com> should generate the same code! | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 15 May 2009 09:00 | To: glasgow-haskell-users@haskell.org | Subject: comprehension vs `map' | | Dear GHC team, | | I would like to write | [rl {ruleMode = AlwaysApply} | rl <- rules calc] (I) | | instead of map (\ rl -> rl {ruleMode = AlwaysApply}) $ rules calc (II) | and instead of | let rs = rules calc in [rl {ruleMode = AlwaysApply} | rl <- rs] (III). | | But is this reliable in GHC that the compiler converts (I) into something | which is not not worse than III ? | What about other implementations? | | Regards, | | ----------- | Mechveliani | mechvel@botik.ru | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From DekuDekuplex at Yahoo.com Fri May 15 07:19:20 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri May 15 07:04:29 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.3 References: <20090509135957.GA8824@matrix.chaos.earth.li> <4A0D24CD.30000@gmail.com> Message-ID: On Fri, 15 May 2009 09:16:13 +0100, Simon Marlow wrote: >On 15/05/2009 05:52, Benjamin L.Russell wrote: >> What happened to the Windows installation section in the corresponding >> User's Guide? The User's Guide for GHC version 6.10.2 (see >> http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) >> had section 2.2: Installing on Windows (see >> http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), >> but this section seems to be missing in the corresponding document for >> version 6.10.3 (see >> http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). >> Not only that, but the entire chapter "2: Installing GHC" seems to be >> missing. > >The "Installing GHC" section was mostly out-of-date and wrong, so I >removed it. Some of the material, such as the section on the layout of >the tree, has been updated and moved to the GHC Building Guide, here > >http://hackage.haskell.org/trac/ghc/wiki/Building > >We also have lots of information on the GHC web site about obtaining and >installing GHC, so if we need anything else I think that would be the >best place to put it. Ah, I see. I just checked out that section, but although it includes information about building GHC, it doesn't seem to include information about simply installing GHC using a binary. This could become an issue if a new user unfamiliar with the installation suddenly decides to upgrade; it is unclear without that documentation whether it is necessary to uninstall the previous version first. More specifically, section "2.2.2 Moving GHC Around" indicates that the entire GHC tree can be freely moved around "just by copying the c:/ghc/ghc-version directory" (although it is necessary "to fix up the links in 'Start/All Programs/GHC/ghc-version'" if this is done); however, this information is not evident from the information provided by the Windows installer. This information initially led me to conclude that uninstalling the previous version wasn't necessary to upgrade; without this information, a new user may not be able to determine whether uninstalling a previous version is necessary to upgrade, and could make upgrading more confusing. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From ndmitchell at gmail.com Fri May 15 10:31:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 15 10:16:26 2009 Subject: --out-implib when linking shared libraries Message-ID: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> Hi, I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? I could easily be building 100 of these things and 4Gb of disk for unused files is a little painful. Thanks Neil From duncan.coutts at worc.ox.ac.uk Fri May 15 13:34:26 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 15 13:19:38 2009 Subject: --out-implib when linking shared libraries In-Reply-To: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> References: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> Message-ID: <1242408866.29736.184.camel@localhost> On Fri, 2009-05-15 at 15:31 +0100, Neil Mitchell wrote: > Hi, > > I've just built a Haskell dll on Windows. As part of the process it > generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags > passed to ld I see --out-implib=foo.dll.a. What is the purpose of the > .a file? What might it be needed for? Is it possible to suppress it? I'm less familiar with the windows dlls as I've been working on the unix case first, but as I understand it, .lib files serve a dual purpose as static libs and as import libs for corresponding dlls. To add confusion the windows gnu tools use the .dll.a extension rather than .lib which the MS tools use. It looks like what you're getting is an import lib that also contains a full copy of all the code. I think it's possible to have minimal .lib files that do not contain any code and only refer to the corresponding dll. Further, I think recent gnu ld versions can link directly against dlls without using an import lib (though you may still need the import lib if you want to use MSVC to link to your dll). So my suggestion is remove it, if you're linking using gcc it should work. See also: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html Duncan From ndmitchell at gmail.com Sat May 16 06:07:18 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 16 05:52:11 2009 Subject: --out-implib when linking shared libraries In-Reply-To: <1242408866.29736.184.camel@localhost> References: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> <1242408866.29736.184.camel@localhost> Message-ID: <404396ef0905160307q5012a267xd56cb5e76b9f470f@mail.gmail.com> >> I've just built a Haskell dll on Windows. As part of the process it >> generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags >> passed to ld I see --out-implib=foo.dll.a. What is the purpose of the >> .a file? What might it be needed for? Is it possible to suppress it? > > It looks like what you're getting is an import lib that also contains a > full copy of all the code. Yes, that seems likely. My guess is it's just a cat of the .o's, with header tables etc. > I think it's possible to have minimal .lib files that do not contain any > code and only refer to the corresponding dll. Further, I think recent > gnu ld versions can link directly against dlls without using an import > lib (though you may still need the import lib if you want to use MSVC to > link to your dll). I don't, although having that option wouldn't be a bad thing - having a minimal .lib is perfectly reasonable as a default. Having a massive .lib seems crazy. (The fact that .lib is named .dll.a isn't too much of an issue) > So my suggestion is remove it, if you're linking using gcc it should > work. I'm not linking the .dll at all, only using dynamic linking, which works without the .lib. But I don't really want to start removing files - doing that in a build system seems like a bad idea. Thanks Neil From duncan.coutts at worc.ox.ac.uk Sat May 16 07:26:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 16 07:12:05 2009 Subject: --out-implib when linking shared libraries In-Reply-To: <404396ef0905160307q5012a267xd56cb5e76b9f470f@mail.gmail.com> References: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> <1242408866.29736.184.camel@localhost> <404396ef0905160307q5012a267xd56cb5e76b9f470f@mail.gmail.com> Message-ID: <1242473213.20960.3.camel@localhost> On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: > I don't, although having that option wouldn't be a bad thing - having > a minimal .lib is perfectly reasonable as a default. Having a massive > .lib seems crazy. (The fact that .lib is named .dll.a isn't too much > of an issue) It's possible to create a minimal import lib via a .def file (which lists the exports). I think the dlltool helps with that. > > So my suggestion is remove it, if you're linking using gcc it should > > work. > > I'm not linking the .dll at all, only using dynamic linking, which > works without the .lib. But I don't really want to start removing > files - doing that in a build system seems like a bad idea. Sure, so at least you don't have to install them. Duncan From kr.angelov at gmail.com Sat May 16 08:22:09 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sat May 16 08:07:01 2009 Subject: --out-implib when linking shared libraries In-Reply-To: <1242473213.20960.3.camel@localhost> References: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> <1242408866.29736.184.camel@localhost> <404396ef0905160307q5012a267xd56cb5e76b9f470f@mail.gmail.com> <1242473213.20960.3.camel@localhost> Message-ID: I remember that the .dll.a libraries that GCC produces are not always compatible with MSVC. Sometimes it works if you rename them to .lib but sometimes it doesn't. It is much more realiable to create .lib from .def file via some of the MS tools. If GCC can link dynamic libraries without using the static library then it might be good idea not to build the import libraries at all. Regards, Krasimir On Sat, May 16, 2009 at 1:26 PM, Duncan Coutts wrote: > On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: > >> I don't, although having that option wouldn't be a bad thing - having >> a minimal .lib is perfectly reasonable as a default. Having a massive >> .lib seems crazy. (The fact that .lib is named .dll.a isn't too much >> of an issue) > > It's possible to create a minimal import lib via a .def file (which > lists the exports). I think the dlltool helps with that. > >> > So my suggestion is remove it, if you're linking using gcc it should >> > work. >> >> I'm not linking the .dll at all, only using dynamic linking, which >> works without the .lib. But I don't really want to start removing >> files - doing that in a build system seems like a bad idea. > > Sure, so at least you don't have to install them. > > Duncan > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From anotheraddress at gmx.de Sat May 16 11:11:18 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Sat May 16 10:56:16 2009 Subject: Unqualified names for -ddump-splices? Message-ID: <200905161711.19350.anotheraddress@gmx.de> Hi! is it possible to look at spliced code without fully qualified names? (And maybe with simple integer indices for newNames). Currently it can be pretty hard to decipher sometimes :) Greetings, Daniel From bulat.ziganshin at gmail.com Sat May 16 14:31:36 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 16 14:16:33 2009 Subject: possible alternative to libFFI Message-ID: <1794556591.20090516223136@gmail.com> Hello glasgow-haskell-users, http://www.nongnu.org/cinvoke/faq.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sat May 16 16:27:22 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 16 16:12:30 2009 Subject: possible alternative to libFFI In-Reply-To: <1794556591.20090516223136@gmail.com> References: <1794556591.20090516223136@gmail.com> Message-ID: <1242505642.20960.9.camel@localhost> On Sat, 2009-05-16 at 22:31 +0400, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > http://www.nongnu.org/cinvoke/faq.html >From the page: How does C/Invoke compare to libFFI? At the C API level they're pretty similar, aside from some minor quibbles. libFFI has been around longer and is much more portable, but the last "release" was in 1998. Note that there are separate libffi releases again: http://sourceware.org/libffi/ libffi-3.0.8 was released on December 19, 2008. You can ftp it from ftp://sourceware.org/pub/libffi/libffi-3.0.8.tar.gz Duncan From dons at galois.com Sun May 17 19:53:41 2009 From: dons at galois.com (Don Stewart) Date: Sun May 17 19:40:00 2009 Subject: Should exhaustiveness testing be on by default? Message-ID: <20090517235341.GD13246@whirlpool.galois.com> I'm not sure I'd want -Wall on by default (though being -Wall clean is very good). But exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds. http://ocaml.janestreet.com/?q=node/64 Ron's also wondering why exhaustive pattern checking isn't on ? Anyone know why it isn't the default? -- Don From lennart at augustsson.net Sun May 17 21:18:19 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun May 17 21:03:07 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090517235341.GD13246@whirlpool.galois.com> References: <20090517235341.GD13246@whirlpool.galois.com> Message-ID: The exhaustiveness checker in ghc is not good. It reports non-exhaustive matching a bit too often and also the error messages are often not in terms of the original source but some desugared version. If those things were improved I think it should be always on. On Mon, May 18, 2009 at 12:53 AM, Don Stewart wrote: > > I'm not sure I'd want -Wall on by default (though being -Wall clean is > very good). But exhaustive pattern checking might well help out a lot of > people coming from untyped backgrounds. > > ? ?http://ocaml.janestreet.com/?q=node/64 > > Ron's also wondering why exhaustive pattern checking isn't on ? > > Anyone know why it isn't the default? > > -- Don > _______________________________________________ > 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 May 18 04:38:00 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 18 04:22:48 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: References: <20090517235341.GD13246@whirlpool.galois.com> Message-ID: <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> I'm not a particular fan of exhaustiveness checking. It just encourages people to write: foo (Just 1) [x:xs] = important case foo _ _ = error "doh!" So now when the program crashes, instead of getting a precise and guaranteed correct error message, I get "doh!" - not particularly helpful for debugging. I think it's not that useful for writing personal code, but for writing production code (which you're going to ship off) it's probably important that you cover all cases. However, for that it would be much better to use a tool such as Catch (http://community.haskell.org/~ndm/catch), which actually guarantees you won't crash, rather than a simple syntactic check. As such, I think it's perfect to be included in a set of warnings, but not great to be a default. I also think that if we change our policies every time someone writes a critical blog we'll be going round in circles :-) I'm also not a fan of the overlapping patterns warning being on by default, as I often write: foo (Case1 x y z) = ... foo (Bar x) = ... foo x = error $ show ("Unhandled in foo",x) This is overlapping, and for a very good reason. Thanks Neil On Mon, May 18, 2009 at 2:18 AM, Lennart Augustsson wrote: > The exhaustiveness checker in ghc is not good. ?It reports > non-exhaustive matching a bit too often and also the error messages > are often not in terms of the original source but some desugared > version. > > If those things were improved I think it should be always on. > > On Mon, May 18, 2009 at 12:53 AM, Don Stewart wrote: >> >> I'm not sure I'd want -Wall on by default (though being -Wall clean is >> very good). But exhaustive pattern checking might well help out a lot of >> people coming from untyped backgrounds. >> >> ? ?http://ocaml.janestreet.com/?q=node/64 >> >> Ron's also wondering why exhaustive pattern checking isn't on ? >> >> Anyone know why it isn't the default? >> >> -- Don >> _______________________________________________ >> 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 phercek at gmail.com Mon May 18 05:45:38 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon May 18 05:30:36 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> Message-ID: Neil Mitchell wrote: > I'm not a particular fan of exhaustiveness checking. It just > encourages people to write: > > foo (Just 1) [x:xs] = important case > foo _ _ = error "doh!" > > So now when the program crashes, instead of getting a precise and > guaranteed correct error message, I get "doh!" - not particularly > helpful for debugging Is there some compile option to automatically annotate error call with its source code location (so that one dos not need to mention it in the string argument)? Peter. From marlowsd at gmail.com Mon May 18 07:05:33 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 18 06:50:23 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.3 In-Reply-To: References: <20090509135957.GA8824@matrix.chaos.earth.li> <4A0D24CD.30000@gmail.com> Message-ID: <4A1140FD.4090207@gmail.com> On 15/05/2009 12:19, Benjamin L.Russell wrote: > On Fri, 15 May 2009 09:16:13 +0100, Simon Marlow > wrote: > >> On 15/05/2009 05:52, Benjamin L.Russell wrote: >>> What happened to the Windows installation section in the corresponding >>> User's Guide? The User's Guide for GHC version 6.10.2 (see >>> http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) >>> had section 2.2: Installing on Windows (see >>> http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), >>> but this section seems to be missing in the corresponding document for >>> version 6.10.3 (see >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). >>> Not only that, but the entire chapter "2: Installing GHC" seems to be >>> missing. >> The "Installing GHC" section was mostly out-of-date and wrong, so I >> removed it. Some of the material, such as the section on the layout of >> the tree, has been updated and moved to the GHC Building Guide, here >> >> http://hackage.haskell.org/trac/ghc/wiki/Building >> >> We also have lots of information on the GHC web site about obtaining and >> installing GHC, so if we need anything else I think that would be the >> best place to put it. > > Ah, I see. > > I just checked out that section, but although it includes information > about building GHC, it doesn't seem to include information about > simply installing GHC using a binary. This could become an issue if a > new user unfamiliar with the installation suddenly decides to upgrade; > it is unclear without that documentation whether it is necessary to > uninstall the previous version first. > > More specifically, section "2.2.2 Moving GHC Around" indicates that > the entire GHC tree can be freely moved around "just by copying the > c:/ghc/ghc-version directory" (although it is necessary "to fix up the > links in 'Start/All Programs/GHC/ghc-version'" if this is done); > however, this information is not evident from the information provided > by the Windows installer. This information initially led me to > conclude that uninstalling the previous version wasn't necessary to > upgrade; without this information, a new user may not be able to > determine whether uninstalling a previous version is necessary to > upgrade, and could make upgrading more confusing. I've added a section "Relocating a GHC installation" to the wiki: http://hackage.haskell.org/trac/ghc/wiki/Building/Installing#RelocatingaGHCinstallation I think the rest could be solved by adding a note on the Windows section of the download page to the effect that "This installer will not overwrite previous installed versions of GHC, with the exception that the default handler for .lhs and .hs files will point to the latest installed version". Ian, would you like to add this to the download page? Cheers, Simon From claus.reinke at talk21.com Mon May 18 07:06:51 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon May 18 06:51:45 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com> Message-ID: <093C598E7C344EE195694CEDBD1DFAA7@cr3lt> > I'm not sure I'd want -Wall on by default (though being -Wall clean is > very good). But exhaustive pattern checking might well help out a lot of > people coming from untyped backgrounds. > > http://ocaml.janestreet.com/?q=node/64 > > Ron's also wondering why exhaustive pattern checking isn't on ? > > Anyone know why it isn't the default? The answer to the latter is probably just that it is imprecise. Don't read on if that's all you wanted to hear;-) But before anyone goes suggesting to change the defaults, consider that it would be solving the wrong problem - exhaustiveness of Haskell matching is not decidable, so you end up with an approximation; if you want to enforce this particular approximation, you end up with "defensive programming" - defensive programming may look good in blame-driven development methods, but is actually bad for fault-tolerance (google for "Erlang defensive programming") - if you are serious about correctness, rather than the appearance of correctness, there are other approaches: - non-defensive programming with external recovery management is the "industry-standard" (well, in Erlang industries, at least;-); the idea being that trying to handle all cases everywhere makes for unreadable code that doesn't address the problem, while the combination of checking cases on entry/handling the expected case locally/handling unexpected cases non-locally has been demonstrated to work in high-reliability scenarios. - checking for non-crashing rather than syntactic coverage is slightly better, but will likely only demonstrate that there are cases where you can't put in a useful answer locally; you can add local information to the error before raising it (which would still be reported as a crash), but trying to handle a case locally (just to avoid the local crash) when you don't have the information to do so is just going to hide bugs (which is not what a coding style or warning should encourage); the way forward, if you believe Erlangers, is to embrace localised crashes (google for Erlang motto: "let it crash";-), and have the infrastructure in place to automatically add useful information to crash messages [1], to programatically deal with crashes (preferably in a separate process on an independent machine), and to factor out the recovery code from the business-as-usual code (which is why Erlang programs with good fault-tolerance characteristics are often shorter than non-Erlang programs without). The added benefit is that when a crash happens, in spite of serious efforts spent on proving/testing/model checking, the system doesn't just go "oops!". - if you want coverage to have value semantically, you need to restrict the expressiveness of matching. In Haskell/OCaml, that would probably mean extensible variants/records, or possibly GADTs, (and no guards), so that you get a type error when *using* a value that is not covered (instead of a syntax error when not covering a value that may not ever be used). In particular, if you really care about such things, you should check for the good cases once, then convert to types that do not have the bad cases. That still doesn't help you with the entry check, where the best option for the unexpected case might still be to raise an exception, but such a typing strategy makes exhaustiveness checking slightly more useful. In management brief: enforcing exhaustiveness testing without any other measures just ensures that your team members will never tell you about things they do not know how to handle, so the first sign of trouble you see is when everything comes down. Establishing a non-local framework for dealing with local non-exhaustiveness and encouraging team members to raise alarms when they see trouble gives your team a chance to notice and recover from issues before they become critical. Perhaps syntactic exhaustiveness testing should be renamed to certified-everything-swept-under-the-rug testing?-) Note: this is no excuse for using things like 'head' unguardedly in a large code base! Just that the solution is not to add an empty case to 'head', but to ensure that 'head' is never called with an empty list, so "exhaustiveness everywhere" is the wrong target. Adding an empty case to 'head' is to raise an alert with useful info, working around current weaknesses in the error-reporting infrastructure [1], after we've already run into an unhandled unexpected case. If we get a "non-exhaustive" warning, it might mean a variety of things (you might want to document things like 3/4 in the types): 1 nothing (error in exhaustiveness checking) 2 nothing (approximation in exhaustiveness checking) 3 nothing (missing cases are proven never to arrive here) 4 nothing (exceptional cases crash here, are dealt with properly elsewhere) 5 wrong type used (you shouldn't even try to make this match exhaustive, you should use a type that encodes only the cases you handle) beside the naive expectation - missing case (need to cover the case) These warnings need to be used with care, and with a conscious choice of strategy/framework, not by default. If you have a good strategy/framework in place, switch them on, even make them errors, but doing so by default would only encourage bad coding practices. Just another opinion (should I've put it on a blog instead?-) Claus "Did you want to talk about the weather or were you just making chit-chat?" Weather man, Groundhog Day [1] http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack From marlowsd at gmail.com Mon May 18 07:09:12 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 18 06:54:01 2009 Subject: [Haskell-cafe] ghc ./configure stalls on docbook DTD In-Reply-To: References: <4A0B1304.7060401@gmail.com> Message-ID: <4A1141D8.8070505@gmail.com> On 13/05/2009 19:53, Donnie Jones wrote: > Hello Dan, > > Best place to ask is glasgow-haskell-users@haskell.org since that is > the GHC users list. > I have CC'd your email to the GHC user list. > > Cheers. > -- > Donnie Jones > > On Wed, May 13, 2009 at 1:35 PM, Dan wrote: >> Hi, >> >> Not sure if this is the right place to ask. >> GHC 6.10.3 source dist: ./configure takes about 10 minutes to look for >> DocBook DTD and another 10 to look for DocBook XSL directory. I was writing >> this e-mail thinking it had completely crashed. Any reason why it's so >> ridiculously slow? A look at 'top' says the CPU is mostly idle during this >> time, but xmllint is running. I have the following complaint from Roman in my inbox, which I think is about the same thing: > one big nuisance when building ghc is that configure tries to connect > to the internet. The culprit is the FP_GEN_DOCBOOK_XML macro in > aclocal.m4 which is used when checking for DocBook DTD. It generates > an XML file which references http://www.oasis-open.org/docbook/xml/4.2 > /docbookx.dtd and then runs xmllint which, naturally, wants to load > the dtd. Depending on the quality of my internet connection and on > the availability of oasis-open.org this check sometimes (infrequently > but very annoyingly) takes up to a 2 or 3 minutes for me. Given that > the DTD in question can be freely copied, why not redistribute it > with ghc? > Another www reference is in FP_GEN_FO (to > http://www.w3.org/1999/XSL/Format) but that never seems to bite me. I know almost but not quite exactly nothing about how to find DTDs. But I do recall that Duncan mentioned to me recently that there's a much better way to do this - Duncan? Cheers, Simon From marlowsd at gmail.com Mon May 18 07:11:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 18 06:56:09 2009 Subject: defaultsHook isn't documented In-Reply-To: <1986263987.20090511140101@gmail.com> References: <548069624.20090511122850@gmail.com> <1986263987.20090511140101@gmail.com> Message-ID: <4A114258.40303@gmail.com> On 11/05/2009 11:01, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > it seems that defaultsHook isn't documented on > http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-hooks > neither anywhere else in user manual I think we'd like people to use ghc_rts_opts instead, if possible. Do you have a good reason to need defaultsHook instead? One problem with it is that defaultsHook ends up depending on the representation of the RtsFlags structure, which we change from time to time. Cheers, Simon From marlowsd at gmail.com Mon May 18 07:15:51 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 18 07:00:38 2009 Subject: possible alternative to libFFI In-Reply-To: <1794556591.20090516223136@gmail.com> References: <1794556591.20090516223136@gmail.com> Message-ID: <4A114367.9020403@gmail.com> On 16/05/2009 19:31, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > http://www.nongnu.org/cinvoke/faq.html Is there a good reason to want an alternative to libffi? libffi works pretty well, and seems to be widely used and supported. Cheers, Simon From bulat.ziganshin at gmail.com Mon May 18 07:18:24 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon May 18 07:03:21 2009 Subject: defaultsHook isn't documented In-Reply-To: <4A114258.40303@gmail.com> References: <548069624.20090511122850@gmail.com> <1986263987.20090511140101@gmail.com> <4A114258.40303@gmail.com> Message-ID: <1942026524.20090518151824@gmail.com> Hello Simon, Monday, May 18, 2009, 3:11:20 PM, you wrote: >> it seems that defaultsHook isn't documented on > I think we'd like people to use ghc_rts_opts instead, if possible. Do > you have a good reason to need defaultsHook instead? One problem with > it is that defaultsHook ends up depending on the representation of the > RtsFlags structure, which we change from time to time. afaik, ghc_rts_opts can't built dynamically that means it cannot solve some problems. as example, the following hook allows haskell program to use up to 80% of RAM: void defaultsHook (void) { #ifdef _SC_PHYS_PAGES unsigned long long pagesize = sysconf(_SC_PAGESIZE); unsigned long long numpages = sysconf(_SC_PHYS_PAGES); unsigned long long mhs = numpages*pagesize*8/10; RtsFlags.GcFlags.maxHeapSize = 1ULL+mhs/BLOCK_SIZE_W; #endif } a good idea may be addition of hook that returns *string* with RTS options -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon May 18 07:20:01 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon May 18 07:05:02 2009 Subject: possible alternative to libFFI In-Reply-To: <4A114367.9020403@gmail.com> References: <1794556591.20090516223136@gmail.com> <4A114367.9020403@gmail.com> Message-ID: <981330204.20090518152001@gmail.com> Hello Simon, Monday, May 18, 2009, 3:15:51 PM, you wrote: > Is there a good reason to want an alternative to libffi? libffi works > pretty well, and seems to be widely used and supported. no, i don't have any objections against libffi. it was just for information -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Mon May 18 07:23:37 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 18 07:08:26 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <093C598E7C344EE195694CEDBD1DFAA7@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com> <093C598E7C344EE195694CEDBD1DFAA7@cr3lt> Message-ID: <4A114539.4070709@gmail.com> On 18/05/2009 12:06, Claus Reinke wrote: >> I'm not sure I'd want -Wall on by default (though being -Wall clean is >> very good). But exhaustive pattern checking might well help out a lot of >> people coming from untyped backgrounds. >> >> http://ocaml.janestreet.com/?q=node/64 >> >> Ron's also wondering why exhaustive pattern checking isn't on ? >> >> Anyone know why it isn't the default? > > The answer to the latter is probably just that it is imprecise. Don't > read on if that's all you wanted to hear;-) Two^HThree^HFour reasons really: 1. it's not very good (as Lennart pointed out) 1.1 it's not possible to make it accurate in general (as you point out) 1.1.1. it's not possible to disable it per-definition 2. not everyone wants it (as Neil pointed out) actually reason (2) is the guiding principle we use for whether a warning should be on by default or not. If there's a clear concensus for having a warning on, then we're more than happy to turn it on. Cheers, Simon From claus.reinke at talk21.com Mon May 18 08:14:36 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon May 18 07:59:27 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.3 References: <20090509135957.GA8824@matrix.chaos.earth.li> <4A0D24CD.30000@gmail.com> <4A1140FD.4090207@gmail.com> Message-ID: <1B6497FB77D3443DBA033A0943BF21D6@cr3lt> >> More specifically, section "2.2.2 Moving GHC Around" indicates that >> the entire GHC tree can be freely moved around "just by copying the >> c:/ghc/ghc-version directory" (although it is necessary "to fix up the >> links in 'Start/All Programs/GHC/ghc-version'" if this is done); >> however, this information is not evident from the information provided >> by the Windows installer. This information initially led me to >> conclude that uninstalling the previous version wasn't necessary to >> upgrade; without this information, a new user may not be able to >> determine whether uninstalling a previous version is necessary to >> upgrade, and could make upgrading more confusing. > > I've added a section "Relocating a GHC installation" to the wiki: > > http://hackage.haskell.org/trac/ghc/wiki/Building/Installing#RelocatingaGHCinstallation Relocation on Windows is currently slightly impeded if you're using the Haskell Platform's GHC http://trac.haskell.org/haskell-platform/ticket/19 > I think the rest could be solved by adding a note on the Windows section of the download page to > the effect that "This installer will not overwrite previous installed versions of GHC, with the > exception that the default handler for .lhs and .hs files will point to the latest installed > version". Ian, would you like to add this to the download page? For quite some time now, http://darcs.haskell.org/ghc/distrib/ghc.iss has had this comment (in line with #916): ; this does _not_ follow the "play nice" proposal ; future version should The current version will needlessly assign a different file type, leaving Hugs in the cold (unless you install WinHugs last, which removes the GHCi association..) and overwrite the handlers associated with ghc_haskell (so if you want to use multiple versions of GHCi, you have to add them back in manually). See also: http://hackage.haskell.org/trac/ghc/ticket/916 http://haskell.org/haskellwiki/Installers http://trac.haskell.org/haskell-platform/ticket/6#comment:12 The solution could be as simple as all distributors agreeing on a single haskell file type (so that WinHugs won't switch out the Haskell Platform bindings, and vice versa), and then not mangling the default "verbs" 'open' and 'edit', but to use non-standard verbs like open_with_GHCi-6.10.3, so that Haskell installers add, rather than replace, functionality, as agreed on in that haskellwiki page. Works in Windows XP, and avoids Haskell installer ping-pong http://projects.haskell.org/pipermail/haskell-platform/2009-May/000154.html The MSDN docs seem to be in upheaval at the moment, so I can't verify that this [1] was the most useful documentation link - I think that, before Windows XP, there was no support for non-standard verbs, so on older Windows versions, the current bad system might have to be used as a fallback, but that is no reason to use it on current versions, several years after agreement): Claus [1] http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_intro.asp [2] http://blogs.msdn.com/oldnewthing/archive/2007/04/30/2332224.aspx 'The default verb is not necessarily "open"' From ndmitchell at gmail.com Mon May 18 12:14:56 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 18 11:59:42 2009 Subject: strictness of interpreted haskell implementations In-Reply-To: <1241687727.1620.1492.camel@localhost> References: <200905042343.n44NhFp8002395@merc1.comlab.ox.ac.uk> <1241687727.1620.1492.camel@localhost> Message-ID: <404396ef0905180914k49edbd51jae5aa7a80cca6df7@mail.gmail.com> Hi >> ? ? ? data S = S { a :: Int, b :: ! Int } >> >> ? ? ? Main> a (S { a = 0, b = 1 }) >> ? ? ? 0 >> ? ? ? Main> a (S { a = 0, b = undefined }) >> ? ? ? 0 >> >> Ho hum. ?Is this a "known difference"? I've submitted a bug: http://hackage.haskell.org/trac/hugs/ticket/92 > As an ex teaching assistant my recommendation is "Use ghci!". I helped to teach using WinHugs, which was quite nice. Auto reload cuts out one very frequent source of problems. Thanks Neil From bulat.ziganshin at gmail.com Mon May 18 12:22:04 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon May 18 12:07:03 2009 Subject: strictness of interpreted haskell implementations In-Reply-To: <404396ef0905180914k49edbd51jae5aa7a80cca6df7@mail.gmail.com> References: <200905042343.n44NhFp8002395@merc1.comlab.ox.ac.uk> <1241687727.1620.1492.camel@localhost> <404396ef0905180914k49edbd51jae5aa7a80cca6df7@mail.gmail.com> Message-ID: <1351587575.20090518202204@gmail.com> Hello Neil, Monday, May 18, 2009, 8:14:56 PM, you wrote: >> As an ex teaching assistant my recommendation is "Use ghci!". > I helped to teach using WinHugs, which was quite nice. Auto reload > cuts out one very frequent source of problems. i think we should fill a ticket against it. auto-save in editor + auto-reload make really incredible environment -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From nr at eecs.harvard.edu Mon May 18 16:00:07 2009 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Mon May 18 15:44:51 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090517235341.GD13246@whirlpool.galois.com> (sfid-H-20090517-195707-+59.15-1@multi.osbf.lua) References: <20090517235341.GD13246@whirlpool.galois.com> (sfid-H-20090517-195707-+59.15-1@multi.osbf.lua) Message-ID: <20090518200007.D209013844D@drdoom.eecs.harvard.edu> > ... exhaustive pattern checking might well help out a lot of > people coming from untyped backgrounds... Or even people from typed backgrounds. I worship at the altar of exhaustiveness checking. > Anyone know why it isn't the default? I have been bleating to GHC Central about the generally low level of the default warnings. I even accused them of being tarred with the same brush as Richard Stallman! Their (reasonable) response was that they would rather wait for the user community to reach a consensus on exactly *which* warnings should be on by default. I myself like to compile with -Wall -fno-warn-name-shadowing, but I recognize that these are questions about which reasonable people could differ. I think if we could reach a consensus on the list, we might see a stronger level of warnings in 6.12. Norman P.S. The exhaustiveness checker does need improvement, and it is completely unaware of GADT's. My code is littered with pattern matches where the last case is foo _ = can't match where can't_match :: a can't_match = panic "the GADT pattern matcher is too stupid to live" I would really like to get rid of these. I hate wildcard matches, but I can't put in the constructors because they don't typecheck. And if I put in nothing, the exhaustiveness checker bleats. And I typically compile with -Werror. From robgreayer at gmail.com Mon May 18 22:59:46 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Mon May 18 22:44:29 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090518200007.D209013844D@drdoom.eecs.harvard.edu> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> Message-ID: <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey wrote: > P.S. The exhaustiveness checker does need improvement... Is it documented somewhere what deficiencies the exhaustiveness checker has (where it can report problems that don't exist or fails to report problems that do...), and which deficiencies can't be resolved? Rob From alexander.dunlap at gmail.com Mon May 18 23:56:16 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon May 18 23:41:20 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> Message-ID: <57526e770905182056p49e5b862i9bfd17413a6cc33b@mail.gmail.com> On Mon, May 18, 2009 at 7:59 PM, Robert Greayer wrote: > On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey wrote: >> P.S. The exhaustiveness checker does need improvement... > > Is it documented somewhere what deficiencies the exhaustiveness > checker has (where it can report problems that don't exist or fails to > report problems that do...), and which deficiencies can't be resolved? > > > Rob > One problem is that it reports erroneous errors when combined with ViewPatterns, which certainly ought to be fixed if -fwarn-incomplete-patterns and -fwarn-overlapping-patterns are switched on by default. This isn't the bug others are referring to, though; I don't know where you'd find that information. Alex From simonpj at microsoft.com Tue May 19 03:37:28 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 19 03:22:44 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC48E71C@EA-EXMSG-C334.europe.corp.microsoft.com> No, the shortcomings are not documented I'm afraid. It's a squishy question because when you add guards and view patterns it's undecidable whether patterns overlap or are exhaustive. Still, GHC's current implementation is poor. It's a well-contained project that is awaiting a competent implementor. see http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Robert Greayer | Sent: 19 May 2009 04:00 | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Should exhaustiveness testing be on by default? | | On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey wrote: | > P.S. The exhaustiveness checker does need improvement... | | Is it documented somewhere what deficiencies the exhaustiveness | checker has (where it can report problems that don't exist or fails to | report problems that do...), and which deficiencies can't be resolved? | | | Rob | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Tue May 19 05:04:22 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue May 19 04:49:07 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC48E71C@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <4ec472cb0905181959p230dee1etdd9663b4fc18a911@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48E71C@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A127616.4060704@gmail.com> On 19/05/2009 08:37, Simon Peyton-Jones wrote: > No, the shortcomings are not documented I'm afraid. It's a squishy question because when you add guards and view patterns it's undecidable whether patterns overlap or are exhaustive. There are various open bugs regarding exhaustiveness/incompleteness though. Start here: http://hackage.haskell.org/trac/ghc/ticket/595 and follow the links in the comments. Also http://hackage.haskell.org/trac/ghc/ticket/2395 for view patterns. Cheers, Simon > Still, GHC's current implementation is poor. It's a well-contained project that is awaiting a competent implementor. see http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- > | users-bounces@haskell.org] On Behalf Of Robert Greayer > | Sent: 19 May 2009 04:00 > | Cc: glasgow-haskell-users@haskell.org > | Subject: Re: Should exhaustiveness testing be on by default? > | > | On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey wrote: > |> P.S. The exhaustiveness checker does need improvement... > | > | Is it documented somewhere what deficiencies the exhaustiveness > | checker has (where it can report problems that don't exist or fails to > | report problems that do...), and which deficiencies can't be resolved? > | > | > | Rob > | _______________________________________________ > | 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 ndmitchell at gmail.com Tue May 19 07:01:59 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 19 06:46:42 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090518200007.D209013844D@drdoom.eecs.harvard.edu> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> Message-ID: <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> > ?> ... exhaustive pattern checking might well help out a lot of > ?> people coming from untyped backgrounds... > > Or even people from typed backgrounds. ?I worship at the altar of > exhaustiveness checking. Do you really want exhaustiveness, or is what you actually want safety? With -fwarn-incomplete-patterns: test1 = head [] test2 = x where (x:xs) = [] test3 = (\(x:xs) -> 1) [] test4 = f [] where f [] = 1 GHC reports that test4 has incomplete patterns, but the others don't. However, test4 is safe, but the others aren't. Exhaustiveness is a poor approximation of safety. GHC's exhaustiveness checker is a poor approximation of exhaustiveness. 2 is a poor approximation of pi :-) Using Catch, it reports that test1..3 were faulty, but test4 is safe. Thanks Neil From lennart at augustsson.net Tue May 19 07:18:08 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue May 19 07:02:51 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> Message-ID: Excellent, is there a -fuse-catch flag for ghc? :) On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell wrote: >> ?> ... exhaustive pattern checking might well help out a lot of >> ?> people coming from untyped backgrounds... >> >> Or even people from typed backgrounds. ?I worship at the altar of >> exhaustiveness checking. > > Do you really want exhaustiveness, or is what you actually want safety? > > With -fwarn-incomplete-patterns: > > test1 = head [] > > test2 = x where (x:xs) = [] > > test3 = (\(x:xs) -> 1) [] > > test4 = f [] where f [] = 1 > > GHC reports that test4 has incomplete patterns, but the others don't. > However, test4 is safe, but the others aren't. Exhaustiveness is a > poor approximation of safety. GHC's exhaustiveness checker is a poor > approximation of exhaustiveness. 2 is a poor approximation of pi :-) > > Using Catch, it reports that test1..3 were faulty, but test4 is safe. > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ndmitchell at gmail.com Tue May 19 07:21:49 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 19 07:06:32 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> Message-ID: <404396ef0905190421y775b1be2x9722ad0a0d055497@mail.gmail.com> > Excellent, is there a -fuse-catch flag for ghc? :) No, but there is for Yhc. If you write to the Haskell standard (minus a little bit), don't like libraries and can get Yhc to compile (good luck!) then it's just a few command lines away. If GHC (or GHC + some scripts) could produce a single Core file representing a whole program, including all necessary libraries, then implementing Catch would be a weekends work. Thanks Neil > > On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell wrote: >>> ?> ... exhaustive pattern checking might well help out a lot of >>> ?> people coming from untyped backgrounds... >>> >>> Or even people from typed backgrounds. ?I worship at the altar of >>> exhaustiveness checking. >> >> Do you really want exhaustiveness, or is what you actually want safety? >> >> With -fwarn-incomplete-patterns: >> >> test1 = head [] >> >> test2 = x where (x:xs) = [] >> >> test3 = (\(x:xs) -> 1) [] >> >> test4 = f [] where f [] = 1 >> >> GHC reports that test4 has incomplete patterns, but the others don't. >> However, test4 is safe, but the others aren't. Exhaustiveness is a >> poor approximation of safety. GHC's exhaustiveness checker is a poor >> approximation of exhaustiveness. 2 is a poor approximation of pi :-) >> >> Using Catch, it reports that test1..3 were faulty, but test4 is safe. >> >> Thanks >> >> Neil >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > From jason.dusek at gmail.com Tue May 19 18:07:30 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue May 19 17:52:11 2009 Subject: baffling manual sections Message-ID: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> I'm a little puzzled by these seeming duplicate pages in the manual: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html They give slightly different section numbers to similar stuff. The former page also has a curious discussion of standalone deriving with a `for` keyword: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving -- Jason Dusek From dbueno at gmail.com Tue May 19 21:22:37 2009 From: dbueno at gmail.com (Denis Bueno) Date: Tue May 19 21:07:18 2009 Subject: baffling manual sections In-Reply-To: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> Message-ID: <6dbd4d000905191822o6a6cf139r4c99d54bc8353d08@mail.gmail.com> On Tue, May 19, 2009 at 16:07, Jason Dusek wrote: > ?The former page also has a curious discussion of standalone > ?deriving with a `for` keyword: > > ? ?http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving Without this extension, adding an Eq implementation to a data type for which you do not have source requires an explicit class declaration, even if there is no reason the original data type author couldn't have written "deriving Eq". Standalone deriving allows you to get the convenience of deriving classes everywhere, not just on datatypes for which you can obtain, and use, the source. Denis From twhitehead at gmail.com Tue May 19 22:17:39 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue May 19 22:02:26 2009 Subject: Closure elimination transformation (continuation style passing code) Message-ID: <200905192217.39890.twhitehead@gmail.com> I was wondering about GHC's ability to optimize the following code module Test (test) where newtype Step a b = Step { unStep :: (a -> Step a b -> b) -> b -> b } iter :: [a] -> (a -> Step a b -> b) -> b -> b iter [] next done = done iter (x:xs) next done = next x (Step $ iter xs) count :: Int -> Char -> Step Char Int -> Int count i x step = unStep step (count $ i+1) (i+1) test :: String -> Int test xs = iter xs (count 0) 0 (test implements the string length function). The transformations steps that reduce this to the optimized version are 1- avoid forming the (iter xs) and (count i+1) closures by passing the function and the arguments instead of the function bound to the argument iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter xs count 0 0 2- specialize count for step = iter iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x xs = iter xs count (i+1) (i+1) test xs = iter xs count 0 0 3- specializing iter for next = count iter [] i done = done iter (x:xs) i done = count i x iter xs count i x xs = iter xs (i+1) (i+1) test xs = iter xs 0 0 4- inline count iter [] i done = done iter (x:xs) i done = iter xs (i+1) (i+1) test xs = iter xs 0 0 5- eliminate the done argument as it is always the same as the i argument iter [] i = i iter (x:xs) i = iter xs (i+1) test xs = iter xs 0 Currently 6.10.1 with -O2 seems stuck with regard to step 1 (eliminating the closures). Is there any hope of getting it to these transformations? Thanks! -Tyson From numerodix at gmail.com Tue May 19 23:25:41 2009 From: numerodix at gmail.com (Martin Matusiak) Date: Tue May 19 23:10:22 2009 Subject: 6.8.1 on ubuntu jaunty Message-ID: <5717fc280905192025r12fbd7aeqfffbe34d1d90aeb0@mail.gmail.com> Hello, I need ghc 6.8.1 for a codebase that depends on it and I'm having trouble building it on the current ubuntu. Error output attached. Martin configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h Configuring network-2.1.0.0... rm -f network/GNUmakefile cp Makefile.local network if ifBuildable/ifBuildable network; then \ cd network && setup/Setup makefile -f GNUmakefile; \ fi Socket.hsc: In function ?main?: Socket.hsc:1143: error: invalid application of ?sizeof? to incomplete type ?struct ucred? Socket.hsc:1143: error: invalid application of ?sizeof? to incomplete type ?struct ucred? Socket.hsc:1143: error: invalid application of ?sizeof? to incomplete type ?struct ucred? Socket.hsc:1149: error: invalid use of undefined type ?struct ucred? Socket.hsc:1150: error: invalid use of undefined type ?struct ucred? Socket.hsc:1151: error: invalid use of undefined type ?struct ucred? compiling dist/build/Network/Socket_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/tmp/ghc-6.8.1/includes -I/tmp/ghc-6.8.1/gmp/gmpbuild -D__GLASGOW_HASKELL__=608 -DCALLCONV=ccall -Iinclude dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o Preprocessing library network-2.1.0.0... make[1]: *** [network/GNUmakefile] Error 1 make[1]: Leaving directory `/tmp/ghc-6.8.1/libraries' make: *** [stage1] Error 2 From twhitehead at gmail.com Wed May 20 00:43:00 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed May 20 00:27:52 2009 Subject: Closure elimination transformation (continuation style passing code) In-Reply-To: <200905192217.39890.twhitehead@gmail.com> References: <200905192217.39890.twhitehead@gmail.com> Message-ID: <200905200043.08802.twhitehead@gmail.com> On May 19, 2009 22:17:39 Tyson Whitehead wrote: > 2- specialize count for step = iter > > > > 3- specializing iter for next = count > > > I changed this just before sending it and managed to goof step two and three (the specializations). The whole thing, with the correct steps two and three should have been the following 1- avoid forming the (iter xs) and (count i+1) closures by passing the function and the arguments instead of the function bound to the argument iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter xs count 0 0 2- specialize iter for next = count iter [] next i done = done iter (x:xs) next i done = next i x iter xs iter' [] i done = done iter' (x:xs) i done = count i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter' xs 0 0 3- specialize count for step = iter (and use the specialized iter') iter [] next i done = done iter (x:xs) next i done = next i x iter xs iter' [] i done = done iter' (x:xs) i done = count' i x xs count i x step xs = step xs count (i+1) (i+1) count' i x xs = iter' xs (i+1) (i+1) test xs = iter' xs 0 0 (iter and count are no longer used and can be dropped at this point) 4- inline count' iter' [] i done = done iter' (x:xs) i done = iter' xs (i+1) (i+1) count' i x xs = iter' xs (i+1) (i+1) test xs = iter' xs 0 0 (count is no longer used and can be dropped at this point) 5- eliminate the done argument as it is always the same as the i argument iter'' [] i = i iter'' (x:xs) i = iter'' xs (i+1) test xs = iter'' xs 0 As the first one does not seem to be being performed, I did it manually to see if that would be enough that GHC would pickup on the rest. It seems that this isn't the case. The second two are not being done as well. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090520/b25ec4f8/attachment.bin From alexander.dunlap at gmail.com Wed May 20 00:45:32 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Wed May 20 00:30:32 2009 Subject: baffling manual sections In-Reply-To: <6dbd4d000905191822o6a6cf139r4c99d54bc8353d08@mail.gmail.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> <6dbd4d000905191822o6a6cf139r4c99d54bc8353d08@mail.gmail.com> Message-ID: <57526e770905192145u60b2e270sc5e7bded80cf6df@mail.gmail.com> On Tue, May 19, 2009 at 6:22 PM, Denis Bueno wrote: > On Tue, May 19, 2009 at 16:07, Jason Dusek wrote: >> ?The former page also has a curious discussion of standalone >> ?deriving with a `for` keyword: >> >> ? ?http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving > > Without this extension, adding an Eq implementation to a data type for > which you do not have source requires an explicit class declaration, > even if there is no reason the original data type author couldn't have > written "deriving Eq". ?Standalone deriving allows you to get the > convenience of deriving classes everywhere, not just on datatypes for > which you can obtain, and use, the source. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Denis > _______________________________________________ I think what he's referring to is that StandaloneDeriving actually has the syntax deriving instance Eq Foo not deriving Eq for foo Alex From simonpj at microsoft.com Wed May 20 03:36:30 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 20 03:21:12 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> Yes indeed http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Peter Hercek | Sent: 18 May 2009 10:46 | To: glasgow-haskell-users@haskell.org | Subject: Re: Should exhaustiveness testing be on by default? | | Neil Mitchell wrote: | > I'm not a particular fan of exhaustiveness checking. It just | > encourages people to write: | > | > foo (Just 1) [x:xs] = important case | > foo _ _ = error "doh!" | > | > So now when the program crashes, instead of getting a precise and | > guaranteed correct error message, I get "doh!" - not particularly | > helpful for debugging | Is there some compile option to automatically annotate error call with | its source | code location (so that one dos not need to mention it in the string | argument)? | | Peter. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From batterseapower at hotmail.com Wed May 20 05:35:22 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed May 20 05:20:03 2009 Subject: Closure elimination transformation (continuation style passing code) In-Reply-To: <200905200043.08802.twhitehead@gmail.com> References: <200905192217.39890.twhitehead@gmail.com> <200905200043.08802.twhitehead@gmail.com> Message-ID: <9d4d38820905200235u72bcc2c9ua067027ff4e1df84@mail.gmail.com> 2009/5/20 Tyson Whitehead : > 1- avoid forming the (iter xs) and (count i+1) closures by passing the > function and the arguments instead of the function bound to the argument > > ?iter [] ? ? next i done = done > ?iter (x:xs) next i done = next i x iter xs You have already specialised at this point, because this transformed version of iter only works on functions with closures of particular shape. GRIN based compilers can do this transformation (see Boquist's generalized unboxing), because they can use flow analysis to work out when all the closures are of a particular form. > ?count i x step xs = step xs count (i+1) (i+1) > > ?test xs = iter xs count 0 0 > > 2- specialize iter for next = count > > ?iter ?[] ? ? next i done = done > ?iter ?(x:xs) next i done = next ?i x iter xs > ?iter' [] ? ? ? ? ?i done = done > ?iter' (x:xs) ? ? ?i done = count i x iter xs > > ?count i x step xs = step xs count (i+1) (i+1) > > ?test xs = iter' xs 0 0 GHC basically does not specialise recursive functions for particular values of the arguments (the exception is for dictionaries). IMHO, this is a big blind spot! If it did, then it's quite likely that 'iter' would be a candidate for such a transformation, because it's quite likely that inlining the definition of 'next' would lead to improvement (since 'next' is applied to quite a few arguments, one of them being an argument of function type). > 3- specialize count for step = iter (and use the specialized iter') > > ?iter ?[] ? ? next i done = done > ?iter ?(x:xs) next i done = next i x iter xs > ?iter' [] ? ? ? ? ?i done = done > ?iter' (x:xs) ? ? ?i done = count' i x xs > > ?count ?i x step xs = step ?xs count (i+1) (i+1) > ?count' i x ? ? ?xs = iter' xs ? ? ? (i+1) (i+1) > > ?test xs = iter' xs 0 0 > > (iter and count are no longer used and can be dropped at this point) Given the output of stage 2, I would expect that we would at least be able to inline count into iter. However, there is no mechanism to tie back - again, this is because GHC doesn't really specialise on particular arguments at the moment. > 4- inline count' > > ?iter' [] ? ? i done = done > ?iter' (x:xs) i done = iter' xs (i+1) (i+1) > > ?count' i x xs = iter' xs (i+1) (i+1) > > ?test xs = iter' xs 0 0 > > (count is no longer used and can be dropped at this point) > > 5- eliminate the done argument as it is always the same as the i argument > > ?iter'' [] ? ? i = i > ?iter'' (x:xs) i = iter'' xs (i+1) > > ?test xs = iter'' xs 0 This is a classical loop optimisation, and GHC doesn't implement any of those. As I understand it, this is actively hurting the DPH guys - they end up with a lot of redundant counters in the output code :-( > As the first one does not seem to be being performed, I did it manually to see > if that would be enough that GHC would pickup on the rest. ?It seems that this > isn't the case. ?The second two are not being done as well. GHC's optimizer needs serious work. Personally, I'm rooting for the LHC/JHC guys, because I'm increasingly coming to the conclusion that you need whole-program compilation with flow analysis and bucketloads of specialisation on the back of that to make serious progress at optimizing Haskell. All the best, Max From claus.reinke at talk21.com Wed May 20 05:50:54 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 20 05:35:40 2009 Subject: Closure elimination transformation (continuation style passingcode) References: <200905192217.39890.twhitehead@gmail.com> <200905200043.08802.twhitehead@gmail.com> Message-ID: <4978A7D12FD94A1EAF877FC4EDAB3DE2@cr3lt> >1- avoid forming the (iter xs) and (count i+1) closures by passing the >function and the arguments instead of the function bound to the argument > iter [] next i done = done > iter (x:xs) next i done = next i x iter xs > > count i x step xs = step xs count (i+1) (i+1) > > test xs = iter xs count 0 0 I'm not at all sure what you're aiming for (the above doesn't compile), just some guesses/hints: - your original version allowed both 'next' and 'done' to change at every step, so specializing 'iter' for 'count' would seem to involve something like fixpoint reasoning for the general case or at least unfolding a finite number of recursions for the special case - if 'next' is supposed to be constant, inlining 'iter' would provide enough context to specialize the recursion for that constant parameter, but GHC doesn't inline recursive definitions (see also http://hackage.haskell.org/trac/ghc/ticket/3123 ) and even if it did the equivalent of loop peeling (unfold a few iterations of the recursion at the call site), it might not spot the constant parameter - a common workaround -if there are constant parts to the recursion- is to split the recursive definition into non-recursive wrapper and recursive worker (with some parameters made constant), then to let GHC inline the wrapper; this is particularly interesting if the constant parts are functions So, if you are happy with 'next' being constant throughout the iteration (encoding any variation in the accumulator 'done'), something like this might do: iter next = iterW where iterW done [] = done iterW done (x:xs) = next done x iterW xs count i x step xs = step (i+1) xs test xs = iter count 0 xs GHC should do more wrt recursive definitions, but it can't guess your intentions. There are facilities for library-defined optimizations (RULES), but they wouldn't cover the kind of transformations you seem to be looking for. Work is underway to make library-specified optimizations more expressive (as core2core pass plugins), though I don't know the status of either that (Max?-) or whether #3123 is on anyone's list. Claus From phercek at gmail.com Wed May 20 06:27:46 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed May 20 06:12:42 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A13DB22.2010002@gmail.com> I was looking for something which works in optimized builds too. I know I could do it with preprocessor or (I think) template haskell too but these tools seem to heavy for such a simple goal. The point is the exhaustiveness check saves me from some errors sometimes, but I often need to switch it off for a specific case statement too. Adding an catch all alternative and an error call would be cool way to do it if there is a way to automatically add source code location. This way I could get the best error telling me where it happend and also why I thought the other alternatives should not happen (the error call argument). Thanks, Peter. Simon Peyton-Jones wrote: > Yes indeed > http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Peter Hercek > | Sent: 18 May 2009 10:46 > | To: glasgow-haskell-users@haskell.org > | Subject: Re: Should exhaustiveness testing be on by default? > | > | Neil Mitchell wrote: > | > I'm not a particular fan of exhaustiveness checking. It just > | > encourages people to write: > | > > | > foo (Just 1) [x:xs] = important case > | > foo _ _ = error "doh!" > | > > | > So now when the program crashes, instead of getting a precise and > | > guaranteed correct error message, I get "doh!" - not particularly > | > helpful for debugging > | Is there some compile option to automatically annotate error call with > | its source > | code location (so that one dos not need to mention it in the string > | argument)? > | > | Peter. > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From batterseapower at hotmail.com Wed May 20 07:54:03 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed May 20 07:38:43 2009 Subject: Closure elimination transformation (continuation style passingcode) In-Reply-To: <4978A7D12FD94A1EAF877FC4EDAB3DE2@cr3lt> References: <200905192217.39890.twhitehead@gmail.com> <200905200043.08802.twhitehead@gmail.com> <4978A7D12FD94A1EAF877FC4EDAB3DE2@cr3lt> Message-ID: <9d4d38820905200454pf5b86d5yad5e9cb479777745@mail.gmail.com> 2009/5/20 Claus Reinke : > Work is underway to make library-specified optimizations > more expressive (as core2core pass plugins), though I don't know the status > of either that ?(Max?-) I submitted a final version of the plugins patch to Simon some time ago - it's waiting for him to find some time to review it before hitting HEAD. Cheers, Max From simonpj at microsoft.com Wed May 20 08:23:58 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 20 08:08:39 2009 Subject: baffling manual sections In-Reply-To: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> | I'm a little puzzled by these seeming duplicate pages in the | manual: | | http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html | | http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type- | extensions.html The former is garbage. It's part of an *earlier* iteration of the HEAD user manual, left around by mistake. | They give slightly different section numbers to similar stuff. | The former page also has a curious discussion of standalone | deriving with a `for` keyword: | | http://www.haskell.org/ghc/dist/current/docs/users_guide/type- | extensions.html#stand-alone-deriving Same problem. Standalone deriving is described here http://www.haskell.org/ghc/dist/current/docs/users_guide/deriving.html#stand-alone-deriving The best thing is to start from the user guide root http://www.haskell.org/ghc/dist/current/docs/users_guide (which, incidentally, is the user guide for HEAD, not 6.10), and follow links from there. Simon is removing the earlier droppings. Simon From claus.reinke at talk21.com Wed May 20 08:33:36 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 20 08:18:23 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> <4A13DB22.2010002@gmail.com> Message-ID: <4066F0FC29EC4847900BC8F6D5004E16@cr3lt> >I was looking for something which works in optimized builds too. {-# OPTIONS_GHC -fno-ignore-asserts #-} overrides the -O default setting -fignore-asserts. > I know I could do it with preprocessor or (I think) template haskell too > but these tools seem to heavy for such a simple goal. Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack has been under discussion, it is probably time to provide a short-term workaround in GHC, just a token to be replaced by the current source location. Then assert could be redefined in terms of it, so GHC wouldn't be any more complicated than it is, and users would have access to the same functionality for their uses, while the more useful variations are still being discussed. Below is another hacked-up version, this time using quasiquoting to generate a piece of code that will trigger an error with source location, which will only be forced when we need the source location info:-) It is reasonably easy to use (though one should trim the part of the error message one is not interested in, and I don't like that I can't simply call error in 'f', because that would trigger the nested error before printing 'f's message), but a standard solution in the libraries would be a lot better. Claus ------------------------------------------ {-# LANGUAGE QuasiQuotes #-} {-# OPTIONS_GHC -fno-ignore-asserts #-} import Control.Exception(assert) import SrcLocQQ import Debug.Trace f srcloc Nothing = "okay" f srcloc _ = trace "error: f applied to not-Nothing in: " srcloc main = do print $ f [$srcloc||] Nothing print $ f [$srcloc||] (Just ()) print $ assert False True ------------------------------------------ {-# LANGUAGE TemplateHaskell #-} module SrcLocQQ where import Language.Haskell.TH.Quote import Language.Haskell.TH srcloc = QuasiQuoter (\_->return $ CaseE (ConE 'True) [Match (ConP 'False []) (NormalB (LitE (StringL "srcloc"))) []]) (error "pattern srclocs not supported") ------------------------------------------ $ ghc -e main srcloc.hs "okay" error: f applied to not-Nothing in: : srcloc.hs:13:12-22: Non-exhaustive patterns in case From jason.dusek at gmail.com Wed May 20 09:44:05 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed May 20 09:28:44 2009 Subject: baffling manual sections In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <42784f260905200644u637b78b0lb39ecc73c88873f8@mail.gmail.com> 2009/05/20 Simon Peyton-Jones : > | I'm a little puzzled by these seeming duplicate pages in the > | manual: > | > | ? http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html > | > | ? http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html > > The former is garbage. It's part of an *earlier* iteration of > the HEAD user manual, left around by mistake. > > | They give slightly different section numbers to similar stuff. > | The former page also has a curious discussion of standalone > | deriving with a `for` keyword: > | > | ? http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving > > Same problem.?Standalone deriving is described here... I found it linked from the wiki page on stand-alone deriving (which also happens to have the offending sytnax). -- Jason Dusek |...the wiki page on stand-alone deriving...| http://haskell.org/haskellwiki/?title=GHC/Stand-alone_deriving_declarations&action=history From phercek at gmail.com Wed May 20 10:03:20 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed May 20 09:48:16 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <4066F0FC29EC4847900BC8F6D5004E16@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> <4A13DB22.2010002@gmail.com> <4066F0FC29EC4847900BC8F6D5004E16@cr3lt> Message-ID: <4A140DA8.4030705@gmail.com> Claus Reinke wrote: > Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack > has been under discussion, it is probably time to provide a short-term > workaround in GHC, just a token to be replaced by the current source > location. This would be the best solution. Although -fno-ignore-asserts is acceptable till I do not need asserts for what they are actually supposed to be used for. The second solution requires QuasiQuotes, so I do not know. If I would want to compile with a different compiler it would break. If srcloc can be defined as a simple token (not requiring special extensions at places where it is used) then I could define it to an empty string in some low level module if trying to compile with a different haskell compiler which does not know srcloc. Thanks for the tips, Peter. From claus.reinke at talk21.com Wed May 20 11:18:52 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 20 11:03:39 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> <4A13DB22.2010002@gmail.com><4066F0FC29EC4847900BC8F6D5004E16@cr3lt> <4A140DA8.4030705@gmail.com> Message-ID: <316F3313346D4C0C9A70F220FB26DED3@cr3lt> > The second solution requires QuasiQuotes, so I do not know. If I would > want to compile with a different compiler it would break. If srcloc can be > defined as a simple token (not requiring special extensions at places where > it is used) then I could define it to an empty string in some low level module > if trying to compile with a different haskell compiler which does not know > srcloc. You can do better than that, if you combine the QuasiQuotes hack with the CPP hack (I've also simplified the srcloc handling by adding a version of error that adds source location info, moving the exception manipulation out into SrcLocQQ, avoiding the need for Debug.Trace alltogether). The portable version does get a bit uglier because you need macros, not functions (you'll probably want to check for GHC version or -better, but not supported- QuasiQuotes availability). Also, CPP only gives you the line number, not the position, but that is better than nothing, and often sufficient. Still, it would be much nicer if GHC inserted the location info at the call sites if a pragma at the definition site asked it to do so. Then this {-# SRCLOC f #-} f Nothing = "okay" f _ = error "f applied to not-Nothing in: " could be equivalent to the code below, without QuasiQuotes or CPP or ERRORSRC all over the place. But such niceties are on hold while the discussion of even nicer help is ongoing.. (which is partly justified because we cannot easily build nicer abstractions over a barebones solution, due to the macro vs function issue, so the design does need thought). Perhaps the code below is sufficient as an interim workaround. Claus ----------------------------- {-# LANGUAGE CPP #-} {-# LANGUAGE QuasiQuotes #-} #ifdef __GLASGOW_HASKELL__ #define SRCLOC [$srcloc||] #define ERRORSRC [$errorSrc||] #else #define SRCLOC (show (__FILE__,__LINE__)) #define ERRORSRC (\msg->error $ msg++SRCLOC) #endif import SrcLocQQ f errorSrc Nothing = "okay" f errorSrc _ = errorSrc "f applied to not-Nothing in: " main = do print $ f ERRORSRC Nothing print $ f ERRORSRC (Just ()) print $ SRCLOC ----------------------------- {-# LANGUAGE TemplateHaskell #-} module SrcLocQQ where import Language.Haskell.TH.Quote import Language.Haskell.TH import Control.Exception srcloc = QuasiQuoter (\_->[| mapException (\(PatternMatchFail fail)-> let srcloc = reverse (dropWhile (/=':') (reverse fail)) in PatternMatchFail srcloc) $ case True of False -> "srcloc" |]) (error "pattern srclocs not supported") errorSrc = QuasiQuoter (\_->[| \msg->mapException (\(PatternMatchFail fail)-> let srcloc = reverse (dropWhile (/=':') (reverse fail)) in PatternMatchFail (msg++srcloc)) $ case True of False -> "srcloc" |]) (error "pattern srclocs not supported") ----------------------------- From twhitehead at gmail.com Wed May 20 11:27:32 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed May 20 11:12:24 2009 Subject: Closure elimination transformation (continuation style passingcode) In-Reply-To: <4978A7D12FD94A1EAF877FC4EDAB3DE2@cr3lt> References: <200905192217.39890.twhitehead@gmail.com> <200905200043.08802.twhitehead@gmail.com> <4978A7D12FD94A1EAF877FC4EDAB3DE2@cr3lt> Message-ID: <200905201127.41289.twhitehead@gmail.com> On May 20, 2009 05:50:54 Claus Reinke wrote: > I'm not at all sure what you're aiming for (the above doesn't compile), Yeah. The newtype Step a b was required to break the recursive types, and I dropped it when performing the various transformations, so they don't type check. Here it is again with the newtypes so each bit can be compiled. 0- initial code newtype Step a b = Step { unStep :: (a -> Step a b -> b) -> b -> b } iter :: [a] -> (a -> Step a b -> b) -> b -> b iter [] next done = done iter (x:xs) next done = next x (Step $ iter xs) count :: Int -> Char -> Step Char Int -> Int count i x step = unStep step (count $ i+1) (i+1) test :: String -> Int test xs = iter xs (count 0) 0 1a- avoid forming the (count _) closures by passing the function and the argument instead of the function bound to the argument newtype Step a c b = Step { unStep :: (c -> a -> Step a c b -> b) -> c -> b -> b } iter :: [a] -> (c -> a -> Step a c b -> b) -> c -> b -> b iter [] next i done = done iter (x:xs) next i done = next i x (Step $ iter xs) count :: Int -> Char -> Step Char Int Int -> Int count i x step = unStep step count (i+1) (i+1) test :: String -> Int test xs = iter xs count 0 0 1b- avoid forming the (iter _) closure by passing the function and the argument instead of the function bound to the argument newtype Step a c b = Step { unStep :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b } iter :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b iter [] next i done = done iter (x:xs) next i done = next i x (Step iter) xs count :: Int -> Char -> Step Char Int Int -> String -> Int count i x step xs = unStep step xs count (i+1) (i+1) test :: String -> Int test xs = iter xs count 0 0 2- specialize iter for next = count newtype Step a c b = Step { unStep :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b } iter :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b iter' :: String -> Int -> Int -> Int iter [] next i done = done iter (x:xs) next i done = next i x (Step iter) xs iter' [] i done = done iter' (x:xs) i done = count i x (Step iter) xs count :: Int -> Char -> Step Char Int Int -> String -> Int count i x step xs = unStep step xs count (i+1) (i+1) test :: String -> Int test xs = iter' xs 0 0 3- specialize count for step = iter (and use the specialized iter') newtype Step a c b = Step { unStep :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b } iter :: [a] -> (c -> a -> Step a c b -> [a] -> b) -> c -> b -> b iter' :: String -> Int -> Int -> Int iter [] next i done = done iter (x:xs) next i done = next i x (Step iter) xs iter' [] i done = done iter' (x:xs) i done = count' i x xs count :: Int -> Char -> Step Char Int Int -> String -> Int count' :: Int -> Char -> String -> Int count i x step xs = unStep step xs count (i+1) (i+1) count' i x xs = iter' xs (i+1) (i+1) test :: String -> Int test xs = iter' xs 0 0 (iter and count are no longer used and can be dropped at this point) 4- inline count' iter' :: String -> Int -> Int -> Int iter' [] i done = done iter' (x:xs) i done = iter' xs (i+1) (i+1) count' :: Int -> Char -> String -> Int count' i x xs = iter' xs (i+1) (i+1) test :: String -> Int test xs = iter' xs 0 0 (count' is no longer used and can be dropped at this point) 5- eliminate the done argument as it is always the same as the i argument iter'' :: String -> Int -> Int iter'' [] i = i iter'' (x:xs) i = iter'' xs (i+1) test :: String -> Int test xs = iter'' xs 0 Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090520/841ac54c/attachment.bin From simonpj at microsoft.com Wed May 20 11:32:12 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 20 11:16:53 2009 Subject: baffling manual sections In-Reply-To: <42784f260905200644u637b78b0lb39ecc73c88873f8@mail.gmail.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> <42784f260905200644u637b78b0lb39ecc73c88873f8@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFC09@EA-EXMSG-C334.europe.corp.microsoft.com> Aha. Could you find a moment to fix the wiki page? It's a wiki. thanks S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jason Dusek | Sent: 20 May 2009 14:44 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: baffling manual sections | | 2009/05/20 Simon Peyton-Jones : | > | I'm a little puzzled by these seeming duplicate pages in the | > | manual: | > | | > | http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html | > | | > | http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type- | extensions.html | > | > The former is garbage. It's part of an *earlier* iteration of | > the HEAD user manual, left around by mistake. | > | > | They give slightly different section numbers to similar stuff. | > | The former page also has a curious discussion of standalone | > | deriving with a `for` keyword: | > | | > | http://www.haskell.org/ghc/dist/current/docs/users_guide/type- | extensions.html#stand-alone-deriving | > | > Same problem. Standalone deriving is described here... | | I found it linked from the wiki page on stand-alone deriving | (which also happens to have the offending sytnax). | | -- | Jason Dusek | | | |...the wiki page on stand-alone deriving...| | http://haskell.org/haskellwiki/?title=GHC/Stand- | alone_deriving_declarations&action=history | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Wed May 20 12:45:48 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 20 12:30:33 2009 Subject: Closure elimination transformation (continuation style passing code) In-Reply-To: <9d4d38820905200235u72bcc2c9ua067027ff4e1df84@mail.gmail.com> References: <200905192217.39890.twhitehead@gmail.com> <200905200043.08802.twhitehead@gmail.com> <9d4d38820905200235u72bcc2c9ua067027ff4e1df84@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFCAF@EA-EXMSG-C334.europe.corp.microsoft.com> | GHC's optimizer needs serious work. Personally, I'm rooting for the | LHC/JHC guys, because I'm increasingly coming to the conclusion that | you need whole-program compilation with flow analysis and bucketloads | of specialisation on the back of that to make serious progress at | optimizing Haskell. I think you can get much further than GHC does without whole-program compilation. Notably, GHC does call-pattern specialisation. That is, if GHC sees the call f (C x xs) and f case-analyses its first argument, then GHC makes a specialised copy of f, suitable for such applications. (Paper on my home page.) There's no reason in principle why it should not also look for calls f (c x xs) where c is a function of arity > 2 (so that (c x xs) is a partial application), and f calls its first argument. Then it could make a specialised version of f, suitable for calls of that shape. If you think of the Church encoding of data constructors, it's just the same. There are many engineering details to get right. For example, at the moment GHC mostly concentrates on call patterns in f's right hand side; but for the higher order stuff you may want to focus on calls *elsewhere*. It's not clear how to control code bloat. But just for the record, below is how Tyson's program would go under this regime. Simon ------------ Original program newtype Step a b = Step { unStep :: (a -> Step a b -> b) -> b -> b } iter :: [a] -> (a -> Step a b -> b) -> b -> b iter [] next done = done iter (x:xs) next done = next x (Step $ iter xs) count :: Int -> Char -> Step Char Int -> Int count i x step = unStep step (count $ i+1) (i+1) test :: String -> Int test xs = iter xs (count 0) 0 ------------- -- Specialise iter -- RULE: iter xs (count m) done = iter1 xs m done iter1 [] m done = done iter1 [] m done = count m x (Step (iter xs)) -- count unchanged test xs = iter1 xs 0 0 ------------------ -- Specialise count -- RULE: count m x (Step (iter xs)) = count1 m x xs count1 m x xs = iter xs (count (m+1)) (m+1) = iter1 xs (m+1) (m+1) iter1 [] m done = done iter1 (x:xs) m done = count1 m x xs -------------------- -- Inline count1 in iter1 iter1 [] m done = done iter1 (x:xs) m done = iter1 xs (m+1) (m+1) -- All this is left is the redundant calculation of m+1 From jason.dusek at gmail.com Wed May 20 14:34:11 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed May 20 14:18:51 2009 Subject: baffling manual sections In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFC09@EA-EXMSG-C334.europe.corp.microsoft.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> <42784f260905200644u637b78b0lb39ecc73c88873f8@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFC09@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <42784f260905201134h47f1d8a7hc0265e5e3a1544db@mail.gmail.com> Yes, it is fixed (the link is to the history). -- Jason Dusek From jason.dusek at gmail.com Wed May 20 15:04:38 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed May 20 14:49:16 2009 Subject: baffling manual sections In-Reply-To: <42784f260905201134h47f1d8a7hc0265e5e3a1544db@mail.gmail.com> References: <42784f260905191507t2828a995j3363519968bb0459@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AF9AA@EA-EXMSG-C334.europe.corp.microsoft.com> <42784f260905200644u637b78b0lb39ecc73c88873f8@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFC09@EA-EXMSG-C334.europe.corp.microsoft.com> <42784f260905201134h47f1d8a7hc0265e5e3a1544db@mail.gmail.com> Message-ID: <42784f260905201204l149a0d00pca9d8bfaabfe00c0@mail.gmail.com> Oh, I just realized I had not changed the links, only the examples. They are all fixed now. -- Jason Dusek From twhitehead at gmail.com Wed May 20 15:41:13 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed May 20 15:26:02 2009 Subject: Closure elimination transformation (continuation style passing code) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFCAF@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200905192217.39890.twhitehead@gmail.com> <9d4d38820905200235u72bcc2c9ua067027ff4e1df84@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC5AFCAF@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200905201541.19928.twhitehead@gmail.com> Thanks for all the feedback guys, I already find it pretty amazing how well simple stuff expressed in a higher level manner compiles down to something decent, and it seems like the future is only going to get brighter. I can hardly wait... : ) In the meantime, I'll go back to trying to find the right balance between expressiveness and something GHC can turn into lean mean code. Thanks again! -Tyson PS: Sounds like Boquist's thesis would be an interesting read. I've seen references to it come up a couple of times now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090520/ef733251/attachment.bin From nr at eecs.harvard.edu Wed May 20 17:41:15 2009 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Wed May 20 17:25:55 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> (sfid-h-20090519-070706-+18.72-1@multi.osbf.lua) References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> (sfid-h-20090519-070706-+18.72-1@multi.osbf.lua) Message-ID: <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> > >  > ... exhaustive pattern checking might well help out a lot of > >  > people coming from untyped backgrounds... > > > > Or even people from typed backgrounds.  I worship at the altar of > > exhaustiveness checking. > > Do you really want exhaustiveness, or is what you actually want safety? I want both. Exhaustiveness checking now and forever, because it's a modular property. Safety when somebody gets around to implementing whole-program analysis in the compiler I use, when I feel like waiting around for a whole-program analysis to complete, and when I'm not making local modifications to somebody else's enormous, unsafe Haskell program. Needless to say, safety analysis should identify 'assert False' and confirm at compile time that there are no assertion failures. Norman From igloo at earth.li Wed May 20 19:38:20 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 20 19:22:58 2009 Subject: 6.10.4 plans Message-ID: <20090520233820.GA27413@matrix.chaos.earth.li> Hi all, Unfortunately, since the release of 6.10.3, still more problems have come to light in the 6.10 branch. We are therefore planning to do a 6.10.4 release. For 6.10.4, we will only consider fixes for serious bugs that cannot be easily worked around. So far, we plan to look into: * One of the patches in 6.10.2 introduced a problem where mkWeakForeignEnv# could segfault (already fixed) * readMutVar# is inlined/duplicated http://hackage.haskell.org/trac/ghc/ticket/3207 (already fixed, patch waiting to be merged) * "Permission denied" errors on Windows: http://hackage.haskell.org/trac/ghc/ticket/3231 http://hackage.haskell.org/trac/ghc/ticket/2924 * Some ghci tests fail with hLookAhead errors. We would like to at least understand exactly what is going on here. If you find any other bugs that you think we should look into for 6.10.4, please let us know. We don't have any plans for when to do the release yet, but we would like to be confident that we have waited long enough for any other bugs to surface, and to have time for 6.10.4 to be well-tested. Thanks Ian From marlowsd at gmail.com Thu May 21 04:26:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 21 04:11:25 2009 Subject: 6.10.4 plans In-Reply-To: <20090520233820.GA27413@matrix.chaos.earth.li> References: <20090520233820.GA27413@matrix.chaos.earth.li> Message-ID: <4A151042.1000700@gmail.com> On 21/05/2009 00:38, Ian Lynagh wrote: > Hi all, > > Unfortunately, since the release of 6.10.3, still more problems have > come to light in the 6.10 branch. We are therefore planning to do a > 6.10.4 release. > > For 6.10.4, we will only consider fixes for serious bugs that cannot be > easily worked around. So far, we plan to look into: > > * One of the patches in 6.10.2 introduced a problem where > mkWeakForeignEnv# could segfault > (already fixed) > > * readMutVar# is inlined/duplicated > http://hackage.haskell.org/trac/ghc/ticket/3207 > (already fixed, patch waiting to be merged) > > * "Permission denied" errors on Windows: > http://hackage.haskell.org/trac/ghc/ticket/3231 > http://hackage.haskell.org/trac/ghc/ticket/2924 Not #2924 (we don't know the cause of that one yet). But #2650 is related: http://hackage.haskell.org/trac/ghc/ticket/2650 > * Some ghci tests fail with hLookAhead errors. We would like to at least > understand exactly what is going on here. > > If you find any other bugs that you think we should look into for > 6.10.4, please let us know. Also the problem that causes a GHC build to fail on Windows when you have recent versions of the MSYS binutils (more recent than the ones we recommend in the building guide). base: Wed May 20 04:16:26 PDT 2009 Simon Marlow * remove msvcrt and kernel32 from extra-libraries Win32: Wed May 20 04:16:39 PDT 2009 Simon Marlow * remove kernel32 from extra-libraries ghc: Wed May 20 05:43:10 PDT 2009 Simon Marlow * Windows: load msvcrt and kernel32 manually Cheers, Simon From phercek at gmail.com Thu May 21 09:15:23 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu May 21 09:00:15 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <316F3313346D4C0C9A70F220FB26DED3@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C337FC48EE71@EA-EXMSG-C334.europe.corp.microsoft.com> <4A13DB22.2010002@gmail.com><4066F0FC29EC4847900BC8F6D5004E16@cr3lt> <4A140DA8.4030705@gmail.com> <316F3313346D4C0C9A70F220FB26DED3@cr3lt> Message-ID: <4A1553EB.8030001@gmail.com> Ok, I went with the preprocessor solution only. It is simple, stupid and works well enough ... and template haskell alternative needs it anyway not to be too unportable. Both template haskell alternatives reported "Pattern match(es) are non-exhaustive" of their own. The second alternative moreover needs a change of '$ case True of False -> "srcloc"' to '$ case True of False -> undefined' to be usable. The warning problem is critical by its own since the goal of using it is to selectively disable the very same warning for a specific case statement. Although the warning can be eliminated probably in the first template haskell alternative. Not sure since I do not know template haskell. As well as I still do not know how to write a haskell function in C-- which is the reason there is no :next command in ghci yet :) Thanks, Peter. Claus Reinke wrote: >> The second solution requires QuasiQuotes, so I do not know. If I >> would want to compile with a different compiler it would break. If >> srcloc can be defined as a simple token (not requiring special >> extensions at places where it is used) then I could define it to an >> empty string in some low level module if trying to compile with a >> different haskell compiler which does not know srcloc. > > You can do better than that, if you combine the QuasiQuotes hack with > the CPP hack (I've also simplified the srcloc handling by adding a > version > of error that adds source location info, moving the exception > manipulation > out into SrcLocQQ, avoiding the need for Debug.Trace alltogether). > The portable version does get a bit uglier because you need macros, > not functions (you'll probably want to check for GHC version or > -better, but not supported- QuasiQuotes availability). Also, CPP only > gives you the line number, not the position, but that is better than > nothing, and often sufficient. > > Still, it would be much nicer if GHC inserted the location info at the > call sites if a pragma at the definition site asked it to do so. Then > this > > {-# SRCLOC f #-} > f Nothing = "okay" > f _ = error "f applied to not-Nothing in: " > > could be equivalent to the code below, without QuasiQuotes or CPP > or ERRORSRC all over the place. But such niceties are on hold while > the discussion of even nicer help is ongoing.. (which is partly justified > because we cannot easily build nicer abstractions over a barebones > solution, due to the macro vs function issue, so the design does need > thought). Perhaps the code below is sufficient as an interim workaround. > > Claus > > ----------------------------- > {-# LANGUAGE CPP #-} > {-# LANGUAGE QuasiQuotes #-} > > #ifdef __GLASGOW_HASKELL__ > #define SRCLOC [$srcloc||] > #define ERRORSRC [$errorSrc||] > #else > #define SRCLOC (show (__FILE__,__LINE__)) > #define ERRORSRC (\msg->error $ msg++SRCLOC) > #endif > > import SrcLocQQ > > f errorSrc Nothing = "okay" > f errorSrc _ = errorSrc "f applied to not-Nothing in: " > > main = do > print $ f ERRORSRC Nothing > print $ f ERRORSRC (Just ()) > print $ SRCLOC > > ----------------------------- > {-# LANGUAGE TemplateHaskell #-} > module SrcLocQQ where > import Language.Haskell.TH.Quote > import Language.Haskell.TH > import Control.Exception > > srcloc = QuasiQuoter (\_->[| mapException (\(PatternMatchFail fail)-> > let srcloc = reverse (dropWhile (/=':') > (reverse fail)) > in PatternMatchFail srcloc) > $ case True of False -> "srcloc" |]) > (error "pattern srclocs not supported") > errorSrc = QuasiQuoter > (\_->[| \msg->mapException (\(PatternMatchFail fail)-> > let srcloc = reverse (dropWhile (/=':') > (reverse fail)) > in PatternMatchFail (msg++srcloc)) > $ case True of False -> "srcloc" |]) > (error "pattern srclocs not supported") > ----------------------------- From ndmitchell at gmail.com Thu May 21 09:50:18 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 21 09:34:54 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> Message-ID: <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> > ?> Do you really want exhaustiveness, or is what you actually want safety? > > I want both. ?Exhaustiveness checking now and forever, because it's a > modular property. ?Safety when somebody gets around to implementing > whole-program analysis in the compiler I use, when I feel like waiting > around for a whole-program analysis to complete, and when I'm not > making local modifications to somebody else's enormous, unsafe Haskell > program. Exhaustiveness is handy if every function is exhaustive, then it's a local property contributing to global safety. If you have functions like head floating around, then local exhaustiveness does not equal global safety. I can see why some people want it, but I'm not one of them (which in my mind makes it perfect for a flag). > Needless to say, safety analysis should identify 'assert False' and > confirm at compile time that there are no assertion failures. Catch already does assertion checking (1). Its runtime on moderate to small programs (HsColour in particular) is far less than the time GHC takes to compile them, and I still have no idea what its runtime is on enormous programs (2). An analysis can be whole program and can be slow, one does not imply the other. Thanks Neil 1) To the extent that it can.... It certainly tries to prove the assertions can't fail, and reports each one it fails to prove. 2) I think HsColour was fairly near to the largest program Yhc ever compiled... From dons at galois.com Thu May 21 09:54:09 2009 From: dons at galois.com (Don Stewart) Date: Thu May 21 09:40:18 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> Message-ID: <20090521135409.GC3722@whirlpool.galois.com> > Catch already does assertion checking (1). Its runtime on moderate to > small programs (HsColour in particular) is far less than the time GHC > takes to compile them, and I still have no idea what its runtime is on > enormous programs (2). An analysis can be whole program and can be > slow, one does not imply the other. But the primary problem with Catch is that its analysis not well defined. I have no guarantee regarding the existence or not of false positives or false negatives, as Catch has no underlying formal logic to guide such reasoning. Despite this, it is a useful tool. -- Don From ndmitchell at gmail.com Thu May 21 10:55:53 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 21 10:40:30 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090521135409.GC3722@whirlpool.galois.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> Message-ID: <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> >> Catch already does assertion checking (1). Its runtime on moderate to >> small programs (HsColour in particular) is far less than the time GHC >> takes to compile them, and I still have no idea what its runtime is on >> enormous programs (2). An analysis can be whole program and can be >> slow, one does not imply the other. > > But the primary problem with Catch is that its analysis not well > defined. I have no guarantee regarding the existence or not of false > positives or false negatives, as Catch has no underlying formal logic to > guide such reasoning. If Catch says your program will not crash, then it will not crash. I even gave an argument for correctness in the final appendix of my thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of course, there are engineering concerns (perhaps your Haskell compiler will mis-translate the program to Core, perhaps the libraries will be wrong, perhaps a bit in RAM will flip due to electrical interference), but Catch has a formal basis. I guarantee that there are safe programs Catch can't prove safe, for a proof see Turing 1937 :-) Thanks Neil From dons at galois.com Thu May 21 11:32:17 2009 From: dons at galois.com (Don Stewart) Date: Thu May 21 11:18:29 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> Message-ID: <20090521153217.GA4931@whirlpool.galois.com> ndmitchell: > >> Catch already does assertion checking (1). Its runtime on moderate to > >> small programs (HsColour in particular) is far less than the time GHC > >> takes to compile them, and I still have no idea what its runtime is on > >> enormous programs (2). An analysis can be whole program and can be > >> slow, one does not imply the other. > > > > But the primary problem with Catch is that its analysis not well > > defined. I have no guarantee regarding the existence or not of false > > positives or false negatives, as Catch has no underlying formal logic to > > guide such reasoning. > > If Catch says your program will not crash, then it will not crash. I > even gave an argument for correctness in the final appendix of my > thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of > course, there are engineering concerns (perhaps your Haskell compiler > will mis-translate the program to Core, perhaps the libraries will be > wrong, perhaps a bit in RAM will flip due to electrical interference), > but Catch has a formal basis. Oh, very good! I wasn't aware you'd tried this. I imagine you do something like: * identify all partial functions * bubble that information outwards, crossing off partial functions that are actually total due to tests in callers that effectively reduce the possible inhabitants of the types passed to the partial function * and you have some argument for why your travesal doesn't miss, or mislabel constraints. Is it possible for Catch to print out its reasoning for why some function 'f' is total, such that I could check it (with another tool)? -- Don From ndmitchell at gmail.com Thu May 21 11:49:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 21 11:34:09 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090521153217.GA4931@whirlpool.galois.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> <20090521153217.GA4931@whirlpool.galois.com> Message-ID: <404396ef0905210849w42be9a25l5b775b1b5e20ef1c@mail.gmail.com> >> If Catch says your program will not crash, then it will not crash. I >> even gave an argument for correctness in the final appendix of my >> thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of >> course, there are engineering concerns (perhaps your Haskell compiler >> will mis-translate the program to Core, perhaps the libraries will be >> wrong, perhaps a bit in RAM will flip due to electrical interference), >> but Catch has a formal basis. > > Oh, very good! I wasn't aware you'd tried this. I imagine you do > something like: > > ? ?* identify all partial functions > ? ?* bubble that information outwards, crossing off partial functions > ? ? ?that are actually total due to tests in callers that effectively > ? ? ?reduce the possible inhabitants of the types passed to the partial > ? ? ?function > ? ?* and you have some argument for why your travesal doesn't miss, or > ? ? ?mislabel constraints. Nope, not at all. I assume all missing case branches are replaced with calls to error (as both GHC and Yhc Core do), then prove that: satE $ pre e ==> not $ isBottom $ eval e If the preconditions generated by Catch on an expression are a tautology, that implies the evaluation of e won't contain any _|_ terms at any level. If the precondition Catch generates is const True, then that implies the evaluation is never bottom. I then proceed by induction with a few lemmas, and fusing things - the "proof" is all at the level of Haskell equational reasoning. > Is it possible for Catch to print out its reasoning for why some > function 'f' is total, such that I could check it (with another tool)? It already does. My plan was always to output the reasoning into an ESC/Haskell file, and then have the "Catch" process run the Catch algorithm, and then check the results with ESC/Haskell - this way I hoped to avoid writing a proof for Catch... Things didn't quite turn out that way, as I needed to submit my thesis, I didn't have a copy of ESC/Haskell good enough to do what I wanted, and every thesis needs a nice proof in the appendix. Thanks, Neil From dons at galois.com Thu May 21 11:56:39 2009 From: dons at galois.com (Don Stewart) Date: Thu May 21 11:42:47 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905210849w42be9a25l5b775b1b5e20ef1c@mail.gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com> <20090518200007.D209013844D@drdoom.eecs.harvard.edu> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> <20090521153217.GA4931@whirlpool.galois.com> <404396ef0905210849w42be9a25l5b775b1b5e20ef1c@mail.gmail.com> Message-ID: <20090521155639.GA5032@whirlpool.galois.com> ndmitchell: > >> If Catch says your program will not crash, then it will not crash. I > >> even gave an argument for correctness in the final appendix of my > >> thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of > >> course, there are engineering concerns (perhaps your Haskell compiler > >> will mis-translate the program to Core, perhaps the libraries will be > >> wrong, perhaps a bit in RAM will flip due to electrical interference), > >> but Catch has a formal basis. > > > > Oh, very good! I wasn't aware you'd tried this. I imagine you do > > something like: > > > > ? ?* identify all partial functions > > ? ?* bubble that information outwards, crossing off partial functions > > ? ? ?that are actually total due to tests in callers that effectively > > ? ? ?reduce the possible inhabitants of the types passed to the partial > > ? ? ?function > > ? ?* and you have some argument for why your travesal doesn't miss, or > > ? ? ?mislabel constraints. > > Nope, not at all. I assume all missing case branches are replaced with > calls to error (as both GHC and Yhc Core do), then prove that: > > satE $ pre e ==> not $ isBottom $ eval e > > If the preconditions generated by Catch on an expression are a > tautology, that implies the evaluation of e won't contain any _|_ > terms at any level. If the precondition Catch generates is const True, > then that implies the evaluation is never bottom. I then proceed by > induction with a few lemmas, and fusing things - the "proof" is all at > the level of Haskell equational reasoning. OK. i'm just trying to get an intuition for the analysis. What is the nature of the preconditions generated? In order for them to cancel out the calls to error, are they constructed from information in the caller (as I speculated) about how the function under analysis is used? Obviously, you're also using a restricted notion of "bottom". -- Don From ndmitchell at gmail.com Thu May 21 12:14:23 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 21 11:59:00 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <20090521155639.GA5032@whirlpool.galois.com> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> <20090521153217.GA4931@whirlpool.galois.com> <404396ef0905210849w42be9a25l5b775b1b5e20ef1c@mail.gmail.com> <20090521155639.GA5032@whirlpool.galois.com> Message-ID: <404396ef0905210914m37cfc10cr27a050789bd64bdd@mail.gmail.com> > OK. i'm just trying to get an intuition for the analysis. Catch is defined by a small Haskell program. You can write a small Haskell evaluation for a Core language. The idea is to write the QuickCheck style property, then proceed using Haskell style proof steps. The checker is recursive - it assigns a precondition to an expression based on the precondition of subexpressions, therefore I just induct upwards proving that each step is correct individually. There wasn't an intention of trying to move partiality around, but perhaps it has worked out that way. > What is the nature of the preconditions generated? A precondition is a proposition of pairs of (expression, constraint), where an pair is satisfied if the expression satisfies the constraint. I prove that given a couple of lemmas about the constraint language, the analysis is correct. I then prove that 2 particular constraint languages have these necessary lemmas. As a side note, I'm pretty certain that the constraint languages I give aren't the best choice. The second one (MP constraints) is good, but lacks an obvious normal form, which makes the fixed point stuff a little more fragile/slow. I'm sure someone could come up with something better, and providing it meets a few simple lemmas, it's suitable for Catch. > In order for them to > cancel out the calls to error, are they constructed from information in > the caller (as I speculated) about how the function under analysis is used? Yes, information from case branches add to the constraint, so: case xs of [] -> [] _:_ -> head xs becomes: xs == [] \/ safe (head xs) xs == [] \/ xs == _:_ True > Obviously, you're also using a restricted notion of "bottom". For my purposes, bottom = call to error. Things such as missing case branches and asserts are translated to error. I actually consider non-termination to be a safe outcome, for example Catch says: assert (last xs) True This is safe if all elements of the list are True (Catch approximates here), or if the list xs is infinite. Thanks Neil From dons at galois.com Thu May 21 12:17:36 2009 From: dons at galois.com (Don Stewart) Date: Thu May 21 12:03:42 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <404396ef0905210914m37cfc10cr27a050789bd64bdd@mail.gmail.com> References: <404396ef0905190401s701a63acq2601fabf5d6626e5@mail.gmail.com> <20090520214115.A63ED13844D@drdoom.eecs.harvard.edu> <404396ef0905210650n297caabcud20a5cf0113bf0cf@mail.gmail.com> <20090521135409.GC3722@whirlpool.galois.com> <404396ef0905210755t2e8f3264i743ac5594119ddef@mail.gmail.com> <20090521153217.GA4931@whirlpool.galois.com> <404396ef0905210849w42be9a25l5b775b1b5e20ef1c@mail.gmail.com> <20090521155639.GA5032@whirlpool.galois.com> <404396ef0905210914m37cfc10cr27a050789bd64bdd@mail.gmail.com> Message-ID: <20090521161736.GB5032@whirlpool.galois.com> ndmitchell: > > OK. i'm just trying to get an intuition for the analysis. > > Catch is defined by a small Haskell program. You can write a small > Haskell evaluation for a Core language. The idea is to write the > QuickCheck style property, then proceed using Haskell style proof > steps. The checker is recursive - it assigns a precondition to an > expression based on the precondition of subexpressions, therefore I > just induct upwards proving that each step is correct individually. > There wasn't an intention of trying to move partiality around, but > perhaps it has worked out that way. > > > What is the nature of the preconditions generated? > > A precondition is a proposition of pairs of (expression, constraint), > where an pair is satisfied if the expression satisfies the constraint. > I prove that given a couple of lemmas about the constraint language, > the analysis is correct. I then prove that 2 particular constraint > languages have these necessary lemmas. > > As a side note, I'm pretty certain that the constraint languages I > give aren't the best choice. The second one (MP constraints) is good, > but lacks an obvious normal form, which makes the fixed point stuff a > little more fragile/slow. I'm sure someone could come up with > something better, and providing it meets a few simple lemmas, it's > suitable for Catch. > > > In order for them to > > cancel out the calls to error, are they constructed from information in > > the caller (as I speculated) about how the function under analysis is used? > > Yes, information from case branches add to the constraint, so: > > case xs of > [] -> [] > _:_ -> head xs > > becomes: > xs == [] \/ safe (head xs) > xs == [] \/ xs == _:_ > True > > > Obviously, you're also using a restricted notion of "bottom". > > For my purposes, bottom = call to error. Things such as missing case > branches and asserts are translated to error. I actually consider > non-termination to be a safe outcome, for example Catch says: > > assert (last xs) True > > This is safe if all elements of the list are True (Catch approximates > here), or if the list xs is infinite. Thanks, that's helpful, and much what I expected. -- Don From igloo at earth.li Fri May 22 07:58:59 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri May 22 07:43:33 2009 Subject: ANNOUNCE: GHC porting works again Message-ID: <20090522115859.GA29040@matrix.chaos.earth.li> Hi all, The instructions for porting GHC to a new architecture now work again with the HEAD: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting If you get stuck when trying to do a port, then please feel free to ask us on cvs-ghc@haskell.org or in #ghc on freenode. Thanks Ian From igloo at earth.li Fri May 22 08:01:45 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri May 22 07:46:18 2009 Subject: Mac OS X 64bit unregisterised port Message-ID: <20090522120145.GA24228@matrix.chaos.earth.li> Hi all, There is an unregisterised bindist for Mac OS X 64bit here: http://www.haskell.org/ghc/dist/current/ports/ghc-6.11.20090521-x86_64-apple-darwin.tar.bz2 Thanks Ian From as at nijoruj.org Fri May 22 18:50:00 2009 From: as at nijoruj.org (austin s) Date: Fri May 22 18:34:34 2009 Subject: Mac OS X 64bit unregisterised port In-Reply-To: <20090522120145.GA24228@matrix.chaos.earth.li> References: <20090522120145.GA24228@matrix.chaos.earth.li> Message-ID: <1243032364-sup-772@existential.local> Excerpts from Ian Lynagh's message of Fri May 22 07:01:45 -0500 2009: > > Hi all, > > There is an unregisterised bindist for Mac OS X 64bit here: > > http://www.haskell.org/ghc/dist/current/ports/ghc-6.11.20090521-x86_64-apple-dar > win.tar.bz2 > > > Thanks > Ian > Hello Ian, I'm currently the owner of trac 2965, which is a task for a full, registered OS X x86_64 port - from my understanding and reading of cvs-ghc (amongst other things,) the runtime system still needs to be split and modified to support 64bit OS X before we can get a registered port. With this unregistered port you've made available, we should be well on our way to doing this, correct? (if so, I would like to start working on a registered x86_64 port.) Austin From john at repetae.net Fri May 22 20:05:12 2009 From: john at repetae.net (John Meacham) Date: Fri May 22 19:49:46 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <316F3313346D4C0C9A70F220FB26DED3@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com> <404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com> <4A140DA8.4030705@gmail.com> <316F3313346D4C0C9A70F220FB26DED3@cr3lt> Message-ID: <20090523000511.GA3344@sliver.repetae.net> JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'. It is actually mentioned on this page: http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack I am not entirely sure whether I will keep the current syntax (it doesn't really make sense for operators), but if ghc implements something related, then it would be good to be compatible. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From igloo at earth.li Fri May 22 20:41:25 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri May 22 20:25:58 2009 Subject: Mac OS X 64bit unregisterised port In-Reply-To: <1243032364-sup-772@existential.local> References: <20090522120145.GA24228@matrix.chaos.earth.li> <1243032364-sup-772@existential.local> Message-ID: <20090523004125.GA21344@matrix.chaos.earth.li> On Fri, May 22, 2009 at 05:50:00PM -0500, austin s wrote: > > With this unregistered port you've made available, we should be well > on our way to doing this, correct? Right, by starting from that bindist you won't have to do the bootstrapping. Now you "just" need to do a registerised build and fix any problems / fill in any missing bits. > (if so, I would like to start > working on a registered x86_64 port.) Great! As you probably already know, pumpkin on IRC is also interested in this. Thanks Ian From duncan.coutts at worc.ox.ac.uk Sat May 23 06:40:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 23 06:24:56 2009 Subject: [Haskell-cafe] A problem with par and modules boundaries... In-Reply-To: <20090522123015.GT5994@whirlpool.galois.com> References: <.1242961191@magma.ca> <200905221404.59102.daniel.is.fischer@web.de> <20090522123015.GT5994@whirlpool.galois.com> Message-ID: <1243075208.20307.108.camel@localhost> On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote: > Answer recorded at: > > http://haskell.org/haskellwiki/Performance/Parallel I have to complain, this answer doesn't explain anything. This isn't like straight-line performance, there's no reason as far as I can see that inlining should change the operational behaviour of parallel evaluation, unless there's some mistake in the original such as accidentally relying on an unspecified evaluation order. Now, I tried the example using two versions of ghc and I get different behaviour from what other people are seeing. With the original code, (ie parallelize function in the same module) with ghc-6.10.1 I get no speedup at all from -N2 and with 6.11 I get a very good speedup (though single threaded performance is slightly lower in 6.11) Original code ghc-6.10.1, -N1 -N2 real 0m9.435s 0m9.328s user 0m9.369s 0m9.249s ghc-6.11, -N1 -N2 real 0m10.262s 0m6.117s user 0m10.161s 0m11.093s With the parallelize function moved into another module I get no change whatsoever. Indeed even when I force it *not* to be inlined with {-# NOINLINE parallelize #-} then I still get no change in behaviour (as indeed I expected). So I view this advice to force inlining with great suspicion (at worst it encourages people not to think and to look at it as magic). That said, why it does not get any speedup with ghc-6.10 is also a mystery to me (there's very little GC going on). Don: can we change the advice on the wiki please? It currently makes it look like a known and understood issue. If anything we should suggest using a later ghc version. Duncan From duncan.coutts at worc.ox.ac.uk Sat May 23 07:06:04 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 23 06:50:50 2009 Subject: [Haskell-cafe] A problem with par and modules boundaries... In-Reply-To: <200905221634.19133.daniel.is.fischer@web.de> References: <.1242961191@magma.ca> <200905221404.59102.daniel.is.fischer@web.de> <4A16A484.9080304@stilo.com> <200905221634.19133.daniel.is.fischer@web.de> Message-ID: <1243076764.20307.123.camel@localhost> On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > That's great, thank you. I am still baffled, though. I'm baffled too! I don't see the same behaviour at all (see the other email). > > Must every exported function that uses `par' be INLINEd? Does every > > exported caller of such a function need the same treatment? It really should not be necessary. > > Is `par' really a macro, rather than a function? It's a function. > As far as I understand, par doesn't guarantee that both arguments are > evaluated in parallel, it's just a suggestion to the compiler, and if > whatever heuristics the compiler uses say it may be favourable to do > it in parallel, it will produce code to calculate it in parallel > (given appropriate compile- and run-time flags), otherwise it produces > purely sequential code. > > With parallelize in a separate module, when compiling that, the > compiler has no way to see whether parallelizing the computation may > be beneficial, so doesn't produce (potentially) parallel code. At the > use site, in the other module, it doesn't see the 'par', so has no > reason to even consider producing parallel code. I don't think this is right. As I understand it, par always creates a spark. It has nothing to do with heuristics. Whether the spark actually gets evaluated in parallel depends on the runtime system and whether the spark "fizzles" before it gets a chance to run. Of course when using the single threaded rts then the sparks are never evaluated in parallel. With the threaded rts and given enough CPUs, the rts will try to schedule the sparks onto idle CPUs. This business of getting sparks running on other CPUs has improved significantly since ghc-6.10. The current development version uses a better concurrent queue data structure to manage the spark pool. That's probably the underlying reason for why the example works well in ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what exactly is going wrong that means it doesn't work well in 6.10. Generally I'd expect the effect of par to be pretty insensitive to inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert commentary. Duncan From daniel.is.fischer at web.de Sat May 23 08:35:47 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat May 23 08:20:59 2009 Subject: [Haskell-cafe] A problem with par and modules boundaries... In-Reply-To: <1243076764.20307.123.camel@localhost> References: <.1242961191@magma.ca> <200905221634.19133.daniel.is.fischer@web.de> <1243076764.20307.123.camel@localhost> Message-ID: <200905231435.48289.daniel.is.fischer@web.de> Am Samstag 23 Mai 2009 13:06:04 schrieb Duncan Coutts: > On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > > That's great, thank you. I am still baffled, though. > > I'm baffled too! I don't see the same behaviour at all (see the other > email). > > > > Must every exported function that uses `par' be INLINEd? Does every > > > exported caller of such a function need the same treatment? > > It really should not be necessary. > > > > Is `par' really a macro, rather than a function? > > It's a function. > > > As far as I understand, par doesn't guarantee that both arguments are > > evaluated in parallel, it's just a suggestion to the compiler, and if > > whatever heuristics the compiler uses say it may be favourable to do > > it in parallel, it will produce code to calculate it in parallel > > (given appropriate compile- and run-time flags), otherwise it produces > > purely sequential code. > > > > With parallelize in a separate module, when compiling that, the > > compiler has no way to see whether parallelizing the computation may > > be beneficial, so doesn't produce (potentially) parallel code. At the > > use site, in the other module, it doesn't see the 'par', so has no > > reason to even consider producing parallel code. > > I don't think this is right. As I understand it, par always creates a > spark. It has nothing to do with heuristics. Quite possible. I was only guessing from the fact that sometimes par evaluates things in parallel and sometimes not, plus when thinking what might cause the described behaviour, cross-module inlining came to mind, I tried adding an INLINE pragma and it worked - or so it seemed. Then I threw together an explanation of the observed behaviour. That explanation must be wrong, though, see below. > > Whether the spark actually gets evaluated in parallel depends on the > runtime system and whether the spark "fizzles" before it gets a chance > to run. Of course when using the single threaded rts then the sparks are > never evaluated in parallel. With the threaded rts and given enough > CPUs, the rts will try to schedule the sparks onto idle CPUs. This > business of getting sparks running on other CPUs has improved > significantly since ghc-6.10. The current development version uses a > better concurrent queue data structure to manage the spark pool. That's > probably the underlying reason for why the example works well in > ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what > exactly is going wrong that means it doesn't work well in 6.10. I have tried with 6.10.3 and 6.10.1, with parallelize in the same module and in a separate module - with no pragma - with an INLINE pragma - with a NOINLINE pragma 6.10.1 did not parallelize in any of these settings 6.10.3 parallelized in all these settings except "separate module, no pragma". Then I tried a few other settigns with 6.10.3, got parallel evaluation if there's an INLINE or a NOINLINE pragma on parallelize, or the module header of Main is module Main (main) where, not if Main exports all top level definitions and parallelize is neither INLINEd nor NOINLINEd. Weird. > > Generally I'd expect the effect of par to be pretty insensitive to > inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert > commentary. That would be good. > > Duncan > Daniel From claus.reinke at talk21.com Sat May 23 09:53:54 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat May 23 09:38:28 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net> Message-ID: <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> > JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'. > > It is actually mentioned on this page: > http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack Yes, I know, but the discussion on that page wanted to go beyond this (possibly triggered by your demonstration that one can go beyond plain SRCLOC;-), which is why GHC still has neither of SRCLOC or SRCLOC_ANNOTATE (apart from the various SRCLOC hacks). What is really frustrating is that GHC has the machinery to do this trivially (RULES, soon core2core phase plugins as well), only that this machinery gets applied when source location information is no longer available, so it is useless for this problem:-( One thing that wasn't available when this discussion was last active is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions' would be useful). For instance, appended below is the example from that wiki page, with entirely local transformations to add source locations and to use that info to augment 'ErrorCall' exceptions (we should really augment 'PatternMatchFail' exception messages as well..). $ ghc -e main callstack.hs : hd: empty list ("callstack.hs",25) ("callstack.hs",21) ("callstack.hs",16) ("callstack.hs",13) JHC could probably easily adapt its SRCLOC_ANNOTATE scheme to use a mapException-based scheme instead?-) So one could use the original code, and just add {-# SRCLOC_mapException e, f, hd #-} With GHC, I'm always tempted to write something like {-# RULES "hd->loc(hd)" hd = mapError SRCLOC . hd #-} but that uses the source location of the rule and, worse, when the rule is actually applied, 'hd's source location info is no longer available, so one cannot simply augment the 'RULES' mechanism to supply the source location of its main left-hand side symbol.. Claus ------------------------------ {-# LANGUAGE CPP #-} import Control.Exception #define SRCLOC (show (__FILE__,__LINE__)) #define ERRORSRC (\msg->error $ msg++SRCLOC) mapError src = mapException (\(ErrorCall e)->ErrorCall $ e++"\n"++src) errorSrc src = error . (++"\n"++src) main = print d d :: Int d = mapError SRCLOC (e []) {- line 13 -} e :: [Int] -> Int e = mapError SRCLOC . f 10 {- line 16 -} f :: Int -> [Int] -> Int f = \x -> case fac x < 10 of True -> \_ -> 3 False -> mapError SRCLOC . hd {- line 21 -} hd :: [a] -> a hd = \x -> case x of [] -> errorSrc SRCLOC "hd: empty list" {- line 25 -} (x:_) -> x fac :: Int -> Int fac = \n -> case n == 0 of True -> 1 False -> n * fac (n - 1) From igloo at earth.li Sat May 23 09:55:48 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 23 09:40:19 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.3 In-Reply-To: <4A1140FD.4090207@gmail.com> References: <20090509135957.GA8824@matrix.chaos.earth.li> <4A0D24CD.30000@gmail.com> <4A1140FD.4090207@gmail.com> Message-ID: <20090523135548.GA23771@matrix.chaos.earth.li> On Mon, May 18, 2009 at 12:05:33PM +0100, Simon Marlow wrote: > > I think the rest could be solved by adding a note on the Windows section > of the download page to the effect that "This installer will not > overwrite previous installed versions of GHC, with the exception that > the default handler for .lhs and .hs files will point to the latest > installed version". Ian, would you like to add this to the download > page? Done. Thanks Ian From dons at galois.com Sat May 23 10:58:26 2009 From: dons at galois.com (Don Stewart) Date: Sat May 23 10:44:32 2009 Subject: [Haskell-cafe] A problem with par and modules boundaries... In-Reply-To: <1243075208.20307.108.camel@localhost> References: <.1242961191@magma.ca> <200905221404.59102.daniel.is.fischer@web.de> <20090522123015.GT5994@whirlpool.galois.com> <1243075208.20307.108.camel@localhost> Message-ID: <20090523145826.GA15361@whirlpool.galois.com> duncan.coutts: > On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote: > > Answer recorded at: > > > > http://haskell.org/haskellwiki/Performance/Parallel > > I have to complain, this answer doesn't explain anything. This isn't > like straight-line performance, there's no reason as far as I can see > that inlining should change the operational behaviour of parallel > evaluation, unless there's some mistake in the original such as > accidentally relying on an unspecified evaluation order. > > Now, I tried the example using two versions of ghc and I get different > behaviour from what other people are seeing. With the original code, (ie > parallelize function in the same module) with ghc-6.10.1 I get no > speedup at all from -N2 and with 6.11 I get a very good speedup (though > single threaded performance is slightly lower in 6.11) > > Original code > ghc-6.10.1, -N1 -N2 > real 0m9.435s 0m9.328s > user 0m9.369s 0m9.249s > > ghc-6.11, -N1 -N2 > real 0m10.262s 0m6.117s > user 0m10.161s 0m11.093s > > With the parallelize function moved into another module I get no change > whatsoever. Indeed even when I force it *not* to be inlined with {-# > NOINLINE parallelize #-} then I still get no change in behaviour (as > indeed I expected). > > So I view this advice to force inlining with great suspicion (at worst > it encourages people not to think and to look at it as magic). That > said, why it does not get any speedup with ghc-6.10 is also a mystery to > me (there's very little GC going on). > > Don: can we change the advice on the wiki please? It currently makes it > look like a known and understood issue. If anything we should suggest > using a later ghc version. Please do so. Especially if GHC HEAD *does the right thing*. Then the advice should be first: upgrade to GHC HEAD. From igloo at earth.li Sat May 23 12:09:49 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 23 11:54:19 2009 Subject: Extensible Exceptions and IO In-Reply-To: <57526e770904251118t37c68159k1f8e3e09c5c68374@mail.gmail.com> References: <57526e770904251118t37c68159k1f8e3e09c5c68374@mail.gmail.com> Message-ID: <20090523160949.GA4149@matrix.chaos.earth.li> On Sat, Apr 25, 2009 at 11:18:43AM -0700, Alexander Dunlap wrote: > In the extensible exceptions paper[1], which I believe is the guide > behind the current Control.Exception in GHC 6.10, a SomeIOException > type is discussed so that it would be possible to use the nice > interface for IOExceptions. Is this implemented anywhere? In the GHC > libraries, all I see is the old interface just plugged into a simple > wrapper, so you have to use guard . isDoesNotExistError (for example) > with catchJust to catch a certain type of exception. If not, are there > any plans to implement it? I'm not aware of anyone currently working on putting the various core libs' exceptions into a sensible hierarchy, but it would be great if someone was to do so! I'd suggest that the best way to do this would be initially a combination of discussions on the mailing list (if anything is non-obvious) and building a design (and, if appropriate, rationale) on a wiki page, and ending with a library submissions proposal once you have a design worked out: http://www.haskell.org/haskellwiki/Library_submissions Thanks Ian From igloo at earth.li Sat May 23 12:26:56 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat May 23 12:11:27 2009 Subject: runghc failing sometimes on Linux/ppc? In-Reply-To: <9436bffe0905022202p4c71cf4ev1a254831408402df@mail.gmail.com> References: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> <20090425144316.GB26881@matrix.chaos.earth.li> <9436bffe0904301926m47bfd76dp6d6e347c8cade96f@mail.gmail.com> <9436bffe0905020453q23f45cadob05ffaf283e2c93b@mail.gmail.com> <9436bffe0905022202p4c71cf4ev1a254831408402df@mail.gmail.com> Message-ID: <20090523162656.GB4149@matrix.chaos.earth.li> On Sun, May 03, 2009 at 03:02:50PM +1000, Jens Petersen wrote: > 2009/5/2 Jens Petersen : > > So I tried doing an unregisterised ppc build with: > > > > echo "GhcUnregisterised=YES" >> mk/build.mk > > echo "GhcWithNativeCodeGen=NO" >> mk/build.mk > > echo "SplitObjs=NO" >> mk/build.mk > > Are these the right build config settings? Yes. > > but this failed with: > : > > Linking dist-stage2/build/ghc/ghc ... > : > > (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol > > `__libc_start_main@@GLIBC_2.0' defined in .glink section in > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtbegin.o:(.fini+0x0): > > relocation truncated to fit: R_PPC_REL24 against `.text' Does using -mlongcall help? e.g.: SRC_CC_OPTS += -mlongcall SRC_HC_OPTS += -optc-mlongcall (you can probably get away with something rather more specific, but hopefully this will work). Thanks Ian From heringtonlacey at mindspring.com Sat May 23 15:58:08 2009 From: heringtonlacey at mindspring.com (Dean Herington) Date: Sat May 23 15:42:55 2009 Subject: can't run Grapefruit Message-ID: I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could not load DLL) From claus.reinke at talk21.com Sat May 23 18:34:20 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat May 23 18:18:55 2009 Subject: error stack traces/source locations (was: Should exhaustiveness testing be on by default?) References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt><20090523000511.GA3344@sliver.repetae.net> <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> Message-ID: <49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> > What is really frustrating is that GHC has the machinery to do this > trivially (RULES, soon core2core phase plugins as well), only that this machinery gets applied > when source location information is no longer available, so it is useless for this problem:-( I'd be happy to be proven wrong in this, of course!-) I had the feeling that there'd been some recent work on all this and, indeed, reddit has: http://www.reddit.com/r/haskell/comments/8mbar/finding_the_needle_stack_traces_for_ghc_pdf/ Right on topic, and I assume the authors are on this list!-) It appears that the bulk of the paper is concerned with performance improvements - if we just want to recreate the user view, the mapException approach would appear to be a lot simpler (perhaps the paper could discuss it as a poor man's alternative, in particular since its source rewrites seem less intrusive?). Of course, having any support for this in GHC will be an improvement. However, it is interesting that the paper suggests an implementation using a core2core transformation, *with access to source location l*: [|x_l|]s = x deb (push l s), if x has (Debugged ?x deb) ann (Figure 1, page 4) Does that mean it would be possible to add an extension to RULES that would allow things like: {-# RULES "f->f_" forall x. f{SRCLOC} x = mapError SRCLOC (f_ x) #-} ie, referring to the source location of 'f' in the right hand side? That would seem to be the smallest possible change permitting a user-level implementation of error stack traces. And it might be more generally useful as well. Attached is another example source, again doing the expansion by hand ( (f x) -> mapError SRCLOC (f x); error ".." -> errorSrc SRCLOC "..") and relying on mapException to collect the traces, with a few recursive examples suggested by the paper, and three variations of eliding recursive call sites from the stack traces (note that this only elides when presenting the trace, the real implementation from the paper elides when constructing the trace). Claus ------------------------------------ example output: $ ghc -e main stacktraces.hs -DPLAIN -- fib 5 fib with non-positive number: 0 ("stacktraces.hs",46) ("stacktraces.hs",45) ("stacktraces.hs",45) ("stacktraces.hs",45) ("stacktraces.hs",45) ("stacktraces.hs",36) -- odd_ 5 odd_: no match ("stacktraces.hs",51) ("stacktraces.hs",54) ("stacktraces.hs",50) ("stacktraces.hs",54) ("stacktraces.hs",50) ("stacktraces.hs",38) -- firstLetters2 Prelude.head: empty list ("stacktraces.hs",58) ("stacktraces.hs",62) ("stacktraces.hs",62) ("stacktraces.hs",62) $ ghc -e main stacktraces.hs -- fib 5 fib with non-positive number: 0 ("stacktraces.hs",46) ... ("stacktraces.hs",45) ("stacktraces.hs",36) -- odd_ 5 odd_: no match ("stacktraces.hs",51) ... ("stacktraces.hs",54) ("stacktraces.hs",50) ("stacktraces.hs",38) -- firstLetters2 Prelude.head: empty list ("stacktraces.hs",58) ... ("stacktraces.hs",62) -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktraces.hs Type: application/octet-stream Size: 3248 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090523/4c0ed3f1/stacktraces.obj From ml at isaac.cedarswampstudios.org Sat May 23 19:11:17 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat May 23 18:56:00 2009 Subject: error stack traces/source locations In-Reply-To: <49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt><20090523000511.GA3344@sliver.repetae.net> <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> <49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> Message-ID: <4A188295.1090500@isaac.cedarswampstudios.org> Claus Reinke wrote: > the mapException approach I'm afraid it won't work as you hope for functions that return lazy data structures. The 'evaluate' implicit in mapException only catches top-level errors/exceptions, like 'seq' and not like 'deepSeq'. -Isaac From claus.reinke at talk21.com Sun May 24 05:49:21 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun May 24 05:33:53 2009 Subject: error stack traces/source locations References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt><20090523000511.GA3344@sliver.repetae.net> <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt><49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> <4A188295.1090500@isaac.cedarswampstudios.org> Message-ID: >> the mapException approach > > I'm afraid it won't work as you hope for functions that return lazy data > structures. The 'evaluate' implicit in mapException only catches > top-level errors/exceptions, like 'seq' and not like 'deepSeq'. Have a look at 'firstLetters2' in the example I provided. Perhaps it is easier to see if you change the 'map_' to 'map', or at least put the definition on two lines (since the CPP-based SRCLOC doesn't include columns), but it is there in any case. The initial call to 'map_' is not part of the stack trace, nor are any of the recursive calls. Nor should they be, I think - if 'map' delivers as much as '[]' or 'undefined : undefined' without raising an error, it has done its job. If evaluating any part of the non-strict data structure runs into trouble, the inspection, not the generation, is to blame. That may be inconvenient when one actually wants to see where the parts of the data structure came from, but there are established techniques for forcing strictness, or one can annotate data with producer info (in ways similar to what Hood does: make sure the producer info is there if the part is ever inspected, but don't actually force the part). Here is a slightly rewritten 'firstLetters2', to illustrate: firstLetters2 = mapError SRCLOC $ -- 58 map_ (mapError SRCLOC . head) ["hi", "world", "", "!"] -- 59 map_ f [] = [] map_ f (h:t) = f1 h : mapError SRCLOC (map_ f2 t) -- 62 where f1 = mapError SRCLOC . f -- 63 f2 = mapError SRCLOC . f -- 64 and here is the relevant part of the output (using -DPLAIN): -- firstLetters2 Prelude.head: empty list ("stacktraces.hs",59) ("stacktraces.hs",64) ("stacktraces.hs",64) ("stacktraces.hs",63) Neither 58 nor 62 appear in the trace (there is nothing wrong with 'map_'). The appearance of 63 and 64 in the trace gives one simple example of how information can be added without prematurely forcing evaluation (eg, 'head firstLetters2' gives no trace at all). Claus From heringtonlacey at mindspring.com Mon May 25 13:26:46 2009 From: heringtonlacey at mindspring.com (Dean Herington) Date: Mon May 25 13:11:28 2009 Subject: [grapefruit] can't run Grapefruit In-Reply-To: References: Message-ID: I decided to try on Max OS X (10.5). It seemed to get a bit further, but still no joy. Anyone have a suggestion? bash-3.2$ ghci GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package QuickCheck-2.1.0.1 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package process-1.0.1.1 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package gtk-0.10.0 ... linking ... done. Loading package TypeCompose-0.6.4 ... linking ... done. Loading package lazysmallcheck-0.3 ... linking ... done. Loading package Stream-0.3.1 ... linking ... done. Loading package arrows-0.4.1.1 ... linking ... done. Loading package grapefruit-frp-0.0.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package type-level-0.2.2 ... linking ... done. Loading package type-equality-check-0.0.0.0 ... linking ... done. Loading package grapefruit-records-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-0.0.0.0 ... linking ... done. Loading package grapefruit-examples-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-gtk-0.0.0.0 ... linking ... done. *** Exception: Cannot initialize GUI. At 3:58 PM -0400 5/23/09, Dean Herington wrote: >I'm trying to give Grapefruit a try. I installed it as described in >section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I >tried to run the Simple.hs example, I got the problem shown below. >Any ideas? > >My machine is running Windows XP Pro 2002 SP3. > >TIA >Dean > > >GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help >Loading package ghc-prim ... linking ... done. >Loading package integer ... linking ... done. >Loading package base ... linking ... done. >Prelude> :m + Graphics.UI.Grapefruit.Circuit >Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK >Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m >+ Examples.Grapefruit.Simple >Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK >Examples.Grapefruit.Simple> run GTK mainCircuit >Loading package syb ... linking ... done. >Loading package base-3.0.3.0 ... linking ... done. >Loading package array-0.2.0.0 ... linking ... done. >Loading package containers-0.2.0.0 ... linking ... done. >Loading package bytestring-0.9.1.4 ... linking ... done. >Loading package old-locale-1.0.0.1 ... linking ... done. >Loading package old-time-1.0.0.1 ... linking ... done. >Loading package random-1.0.0.1 ... linking ... done. >Loading package Win32-2.2.0.0 ... linking ... done. >Loading package filepath-1.1.0.1 ... linking ... done. >Loading package directory-1.0.0.2 ... linking ... done. >Loading package process-1.0.1.0 ... linking ... done. >Loading package haskell98 ... linking ... done. >Loading package mtl-1.1.0.2 ... linking ... done. >Loading package glib-0.10.0 ... can't load .so/.DLL for: intl >(addDLL: could not load DLL) From Axel.Simon at ens.fr Mon May 25 13:29:18 2009 From: Axel.Simon at ens.fr (Axel Simon) Date: Mon May 25 13:13:59 2009 Subject: [grapefruit] can't run Grapefruit In-Reply-To: References: Message-ID: <41AC9CBE-8C78-4EE1-A322-78931E27B963@di.ens.fr> On May 25, 2009, at 19:26, Dean Herington wrote: > I decided to try on Max OS X (10.5). It seemed to get a bit > further, but still no joy. Anyone have a suggestion? > > bash-3.2$ ghci > GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Graphics.UI.Grapefruit.Circuit > Prelude Graphics.UI.Grapefruit.Circuit> :m + > Graphics.UI.Grapefruit.GTK > Prelude Graphics.UI.Grapefruit.Circuit > Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK > Examples.Grapefruit.Simple> run GTK mainCircuit > Loading package syb ... linking ... done. > Loading package base-3.0.3.1 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.2 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package QuickCheck-2.1.0.1 ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package filepath-1.1.0.2 ... linking ... done. > Loading package unix-2.3.2.0 ... linking ... done. > Loading package directory-1.0.0.3 ... linking ... done. > Loading package process-1.0.1.1 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package glib-0.10.0 ... linking ... done. > Loading package cairo-0.10.0 ... linking ... done. > Loading package gtk-0.10.0 ... linking ... done. > Loading package TypeCompose-0.6.4 ... linking ... done. > Loading package lazysmallcheck-0.3 ... linking ... done. > Loading package Stream-0.3.1 ... linking ... done. > Loading package arrows-0.4.1.1 ... linking ... done. > Loading package grapefruit-frp-0.0.0.0 ... linking ... done. > Loading package packedstring-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.1.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package type-level-0.2.2 ... linking ... done. > Loading package type-equality-check-0.0.0.0 ... linking ... done. > Loading package grapefruit-records-0.0.0.0 ... linking ... done. > Loading package grapefruit-ui-0.0.0.0 ... linking ... done. > Loading package grapefruit-examples-0.0.0.0 ... linking ... done. > Loading package grapefruit-ui-gtk-0.0.0.0 ... linking ... done. > *** Exception: Cannot initialize GUI. > Of course! You need to run your program in X11, not in the Terminal. I can't comment on the windows problem since I think ghci not being able to load the .dll file is a ghci problem, unless I'm mistaken and it's a naming issue. Cheers, Axel. From phercek at gmail.com Mon May 25 13:55:17 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon May 25 13:39:48 2009 Subject: can't run Grapefruit In-Reply-To: References: Message-ID: <4A1ADB85.50604@gmail.com> Dean Herington wrote: > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ... cut ... > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: > could not load DLL) Ok, I do not use windows more than a year now exactly because of problems like these, but this bug was often because of incorrect or missing value in extra-ghci-libraries attribute. Run this: ghc-pkg describe glib and then check whether attribute extra-ghci-libraries contains something sensible. Now, I do not know what it needs to be exactly now (do not use windows any more so I cannot look it up) but I recall that I was adding value libcairo-2 to extra-ghci-libraries for the cairo package. The point is that the dll name containing the C implementation of the given package must correspond to the string in extra-ghci-libraries. IIRC, sometimes, I was also adding the path to the library (something like -L) in ld-option attribute. But that was probably for compiling and not for ghci. Hope it helps, Peter. From simonpj at microsoft.com Tue May 26 09:58:31 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 26 09:42:55 2009 Subject: error stack traces/source locations (was: Should exhaustiveness testing be on by default?) In-Reply-To: <49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt><20090523000511.GA3344@sliver.repetae.net> <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> <49B74AD4A37F49EAB8C51D4031F4716D@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC6675DE@EA-EXMSG-C334.europe.corp.microsoft.com> | I'd be happy to be proven wrong in this, of course!-) I had the feeling | that there'd been some recent work on all this and, indeed, reddit has: | | http://www.reddit.com/r/haskell/comments/8mbar/finding_the_needle_stack_traces_for_g | hc_pdf/ Sorry I've been very buried recently. Some brief rejoinders to this thread. - Yes, Tristan's paper "Finding the needle" http://research.microsoft.com/~simonpj/papers/stack-trace/DebugTraces.pdf describes his intern work, and represents a good stab at the problem. I think he'd be very interested in feedback. Is this the best way to tackle the problem? Are there better alternatives? - It's not in GHC HEAD, because of the unresolved issues that are discussed towards the end of the paper. - Template Haskell does let you find the current source location, thus: loc :: Q Exp loc = do { l <- location ; lift (loc_module l ++ ":" ++ show (loc_start l)) } Now you can say (error $(loc)), and you'll get the source location of the call to $loc. So that's pretty close to what was originally asked for. Simon From ndmitchell at gmail.com Tue May 26 21:33:45 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 26 21:18:04 2009 Subject: mtl and network packages in GHC 6.10.3.* Message-ID: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil From dons at galois.com Wed May 27 02:44:13 2009 From: dons at galois.com (Don Stewart) Date: Wed May 27 02:30:10 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> Message-ID: <20090527064413.GD2895@whirlpool.galois.com> Not part of the core libs, so these are slowly disappearing from the extralibs bundled shipped with GHC (in favour of the platform bundle). The 6.10.3 windows installer is due out June 1. -- Don ndmitchell: > Hi, > > I just downloaded the Windows snapshot of 6.10.3.20090526, and found > that mtl and network don't seem to be included. > > $ ghc-pkg list > c:/ghc/ghc-6.10.3.20090526\package.conf: > Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, > base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, > directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, > (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, > haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, > old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, > pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, > syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 > > In addition, I can't install network under Cygwin, Mingw, or the > Windows command line. Here are the errors from Cygwin: > > Preprocessing library network-2.2.1.2... > In file included from Network\BSD.hsc:17: > include/HsNet.h:78:22: sys/uio.h: No such file or directory > include/HsNet.h:81:25: sys/socket.h: No such file or directory > include/HsNet.h:84:26: netinet/tcp.h: No such file or directory > include/HsNet.h:87:25: netinet/in.h: No such file or directory > include/HsNet.h:90:21: sys/un.h: No such file or directory > include/HsNet.h:93:24: arpa/inet.h: No such file or directory > include/HsNet.h:96:19: netdb.h: No such file or directory > In file included from Network\BSD.hsc:17: > include/HsNet.h:138: error: syntax error before "addr" > include/HsNet.h: In function `my_inet_ntoa': > include/HsNet.h:146: error: storage size of 'a' isn't known > include/HsNet.h:147: error: `addr' undeclared (first use in this function) > include/HsNet.h:147: error: (Each undeclared identifier is reported only once > include/HsNet.h:147: error: for each function it appears in.) > include/HsNet.h:148: warning: return makes pointer from integer without a cast > Network\BSD.hsc: In function `main': > Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` > servent' > > And Mingw: > > * Missing header file: HsNet.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal.exe: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > exit: ExitFailure 1 > > And Windows command line: > > Resolving dependencies... > Configuring network-2.2.1.2... > cabal: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > sh: runProcess: does not exist (No such file or directory) > > Was removal of these packages on the stable branch was an oversight? > Could network at the very least be reinstated soon? I'd love to report > back whether the GHC 6.10.4 fixes work or not in practice. > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From johan.tibell at gmail.com Wed May 27 03:57:22 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed May 27 03:41:41 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <90889fe70905270056n1190ce5dpd26afd8f1776c5f5@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <90889fe70905270056n1190ce5dpd26afd8f1776c5f5@mail.gmail.com> Message-ID: <90889fe70905270057p3459ea52pc40811d1b484342f@mail.gmail.com> I'll look into it later today when I have access to a Windows install. On May 27, 2009 3:33 AM, "Neil Mitchell" wrote: Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil _______________________________________________ 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/20090527/a95be4f0/attachment.html From ndmitchell at gmail.com Wed May 27 04:36:26 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 27 04:20:46 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <90889fe70905270057p3459ea52pc40811d1b484342f@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <90889fe70905270056n1190ce5dpd26afd8f1776c5f5@mail.gmail.com> <90889fe70905270057p3459ea52pc40811d1b484342f@mail.gmail.com> Message-ID: <404396ef0905270136o5b43cbfoadc86c364a2dcaf0@mail.gmail.com> Hi The GHC 6.10.3 installer is 100% useless to me (and my colleagues) - GHC 6.10.4 has two critical fixes in, for fatal problems which we're hitting on an at least an hourly basis. The Haskell platform can be a convenient way to get a standardised set of packages, but if cabal install doesn't work for Core libraries I'm in deep trouble. > I'll look into it later today when I have access to a Windows install. Thanks Johan. My personal feeling is if Core packages can't be installed with "cabal install foo" on the standard command line with a standard Windows+GHC install then they MUST be shipped in with GHC. If the platform effort wants to fix up the packages then that's great, but if the platform becomes the only way to get critical libraries with a massive lag, then I'm in serious trouble. Given this is a minor bug fix release, and that removing time in a minor bug fix release seems like it was a massive mistake, shouldn't these packages be reinstated at least until GHC 6.12? Thanks Neil On Wed, May 27, 2009 at 8:57 AM, Johan Tibell wrote: > > On May 27, 2009 3:33 AM, "Neil Mitchell" wrote: > > Hi, > > I just downloaded the Windows snapshot of 6.10.3.20090526, and found > that mtl and network don't seem to be included. > > $ ghc-pkg list > c:/ghc/ghc-6.10.3.20090526\package.conf: > ? ?Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, > ? ?base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, > ? ?directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, > ? ?(ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, > ? ?haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, > ? ?old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, > ? ?pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, > ? ?syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 > > In addition, I can't install network under Cygwin, Mingw, or the > Windows command line. Here are the errors from Cygwin: > > Preprocessing library network-2.2.1.2... > In file included from Network\BSD.hsc:17: > include/HsNet.h:78:22: sys/uio.h: No such file or directory > include/HsNet.h:81:25: sys/socket.h: No such file or directory > include/HsNet.h:84:26: netinet/tcp.h: No such file or directory > include/HsNet.h:87:25: netinet/in.h: No such file or directory > include/HsNet.h:90:21: sys/un.h: No such file or directory > include/HsNet.h:93:24: arpa/inet.h: No such file or directory > include/HsNet.h:96:19: netdb.h: No such file or directory > In file included from Network\BSD.hsc:17: > include/HsNet.h:138: error: syntax error before "addr" > include/HsNet.h: In function `my_inet_ntoa': > include/HsNet.h:146: error: storage size of 'a' isn't known > include/HsNet.h:147: error: `addr' undeclared (first use in this function) > include/HsNet.h:147: error: (Each undeclared identifier is reported only > once > include/HsNet.h:147: error: for each function it appears in.) > include/HsNet.h:148: warning: return makes pointer from integer without a > cast > Network\BSD.hsc: In function `main': > Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete > type ` > servent' > > And Mingw: > > * Missing header file: HsNet.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal.exe: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > exit: ExitFailure 1 > > And Windows command line: > > Resolving dependencies... > Configuring network-2.2.1.2... > cabal: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > sh: runProcess: does not exist (No such file or directory) > > Was removal of these packages on the stable branch was an oversight? > Could network at the very least be reinstated soon? I'd love to report > back whether the GHC 6.10.4 fixes ?work or not in practice. > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From claus.reinke at talk21.com Wed May 27 05:21:23 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 27 05:05:48 2009 Subject: reallocating buildbots? (Re: mtl and network packages in GHC 6.10.3.*) References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <20090527064413.GD2895@whirlpool.galois.com> Message-ID: <90B9C05240BF4BB08980CC55E252D43E@cr3lt> > Not part of the core libs, so these are slowly disappearing from the > extralibs bundled shipped with GHC (in favour of the platform bundle). As the stable/head buildbots (as opposed to stable fast/head fast) are becoming less and less useful and cared for in the context of GHC, could they perhaps be reallocated to the Haskell Platform effort? It seems a shame to see these formerly useful donated build slots lie unused when the HP has no equivalent. > The 6.10.3 windows installer is due out June 1. Given that fact, I'm surprised about the lack of activity on the HP list. But automated nightly snapshots from the buildbots would take some pressure off platform packagers, would get bugfixes out as they are done (which was why the buildbots started uploading them when GHC still came with libraries), and would allow for HP releases to use tested snapshots (as well as seeing immediately if GHC patches are going to affect their release process, allowing them to react early). Claus From lennart at augustsson.net Wed May 27 05:23:52 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed May 27 05:08:11 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <20090527064413.GD2895@whirlpool.galois.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <20090527064413.GD2895@whirlpool.galois.com> Message-ID: 6.10.4 is a bug fix release. A bug fix release cannot remove packages no matter what state the platform is in, that's just seriously broken. On Wed, May 27, 2009 at 7:44 AM, Don Stewart wrote: > Not part of the core libs, so these are slowly disappearing from the > extralibs bundled shipped with GHC (in favour of the platform bundle). > > The 6.10.3 windows installer is due out June 1. > > -- Don > > ndmitchell: >> Hi, >> >> I just downloaded the Windows snapshot of 6.10.3.20090526, and found >> that mtl and network don't seem to be included. >> >> $ ghc-pkg list >> c:/ghc/ghc-6.10.3.20090526\package.conf: >> ? ? Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, >> ? ? base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, >> ? ? directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, >> ? ? (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, >> ? ? haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, >> ? ? old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, >> ? ? pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, >> ? ? syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 >> >> In addition, I can't install network under Cygwin, Mingw, or the >> Windows command line. Here are the errors from Cygwin: >> >> Preprocessing library network-2.2.1.2... >> In file included from Network\BSD.hsc:17: >> include/HsNet.h:78:22: sys/uio.h: No such file or directory >> include/HsNet.h:81:25: sys/socket.h: No such file or directory >> include/HsNet.h:84:26: netinet/tcp.h: No such file or directory >> include/HsNet.h:87:25: netinet/in.h: No such file or directory >> include/HsNet.h:90:21: sys/un.h: No such file or directory >> include/HsNet.h:93:24: arpa/inet.h: No such file or directory >> include/HsNet.h:96:19: netdb.h: No such file or directory >> In file included from Network\BSD.hsc:17: >> include/HsNet.h:138: error: syntax error before "addr" >> include/HsNet.h: In function `my_inet_ntoa': >> include/HsNet.h:146: error: storage size of 'a' isn't known >> include/HsNet.h:147: error: `addr' undeclared (first use in this function) >> include/HsNet.h:147: error: (Each undeclared identifier is reported only once >> include/HsNet.h:147: error: for each function it appears in.) >> include/HsNet.h:148: warning: return makes pointer from integer without a cast >> Network\BSD.hsc: In function `main': >> Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` >> servent' >> >> And Mingw: >> >> * Missing header file: HsNet.h >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> cabal.exe: Error: some packages failed to install: >> network-2.2.1.2 failed during the configure step. The exception was: >> exit: ExitFailure 1 >> >> And Windows command line: >> >> Resolving dependencies... >> Configuring network-2.2.1.2... >> cabal: Error: some packages failed to install: >> network-2.2.1.2 failed during the configure step. The exception was: >> sh: runProcess: does not exist (No such file or directory) >> >> Was removal of these packages on the stable branch was an oversight? >> Could network at the very least be reinstated soon? I'd love to report >> back whether the GHC 6.10.4 fixes ?work or not in practice. >> >> Thanks >> >> Neil >> _______________________________________________ >> 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 Wed May 27 07:39:42 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed May 27 07:24:00 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> Message-ID: <20090527113942.GA712@matrix.chaos.earth.li> On Wed, May 27, 2009 at 02:33:45AM +0100, Neil Mitchell wrote: > > I just downloaded the Windows snapshot of 6.10.3.20090526, and found > that mtl and network don't seem to be included. Ooops, the extralibs were accidentally not being built by the buildbots. Should be fixed now. Thanks for pointing it out. Thanks Ian From duncan.coutts at worc.ox.ac.uk Wed May 27 12:24:10 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 27 12:08:49 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> Message-ID: <1243441450.20357.18.camel@localhost> On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote: > Andrea, > > 2009/3/19 Andrea Vezzosi : > > It turns out that those variables are there to allow relocation, in > > fact $topdir is expanded by > > Distribution.Simple.GHC.getInstalledPackages, it seems that > > $httptopdir has been overlooked. > > I'd be tempted to say that it's ghc-pkg dump/describe responsibility > > to expand those vars instead, like it does for ghc-pkg field. > > Do you (or anyone else) intend to work on this? If not, I'd like to > fix it, but I'll need some guidance. Like, is > Distribution.Simple.GHC.getInstalledPackages where the variable > expansion code should go, or should it be somewhere else? I don't think we should be hacking around this in Cabal without any discussion with the ghc folks on what is supposed to be there, what variables are allowed. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. The output of ghc-pkg describe/dump is not just for ghc to define and play around with. It's supposed to be defined by the Cabal spec. Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. Then perhaps as a compat hack we should get Cabal to handle older ghc versions that do use these funny vars. Duncan From claus.reinke at talk21.com Wed May 27 14:47:48 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 27 14:32:13 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com><1233959225.26754.713.camel@localhost><8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com><79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com><1236032892.22402.33.camel@localhost><79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com><8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com><79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com><8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com><8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com><79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> Message-ID: <85817A862E784C0BB8C730346B8A47DD@cr3lt> >> > It turns out that those variables are there to allow relocation, in >> > fact $topdir is expanded by >> > Distribution.Simple.GHC.getInstalledPackages, it seems that >> > $httptopdir has been overlooked. >> > I'd be tempted to say that it's ghc-pkg dump/describe responsibility >> > to expand those vars instead, like it does for ghc-pkg field. Agreed on ghc-pkg doing the translation. Via commandline options, or via environment vars (one might be tempted to manage the bindings in ghc-pkg's database itself, even). The lack of support for this hampers the useability of ghc-pkg and the database it is responsible for. > We need a clear spec on what variables tools are expected to handle and > how they are to be interpreted. Currently, there seem to be $topdir and $httptopdir. Given the split between GHC and HP, it might be useful to have an additional $hptopdir, or just a general mechanism for variables in ghc-pkg's database (I recall being disappointed when what looked like environment variables were unaffected by environment settings..). The info is somewhat distributed: http://darcs.haskell.org/ghc/utils/ghc-pkg/Main.hs http://darcs.haskell.org/ghc/compiler/main/Packages.lhs http://darcs.haskell.org/ghc/compiler/main/SysTools.lhs [Note topdir] > Supporting relocatable sets of packages is a good idea. We should aim to > have something that is usable by each compiler, not just ghc, so > interpreting paths relative to ghc's libdir doesn't seem ideal. GHC makes no reference to libdir, it simply talks about a $topdir (where it would like to store things it needs) and $httptopdir (where haddocks might be found). > How > about this: a way to specify paths in the package registration info that > are relative to the location of the package db they are in. ahem. That sounds like a backwards step, being dependent on two locations instead of one. Before the HP, windows GHCs could be relocated without needing to update the ghc-pkg database, even if some packages were installed outside GHCs $topdir. With your variant, just about any change would need updating. Assuming that the parts are independently located by whatever the OS packaging conventions say, and can be independently relocated otherwise, it seems simpler to continue with the variable scheme, but with improved support and documentation for it. Claus From simonpj at microsoft.com Wed May 27 15:38:34 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 27 15:22:54 2009 Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types In-Reply-To: <4377284F-6AAD-4603-9B4F-059C18AC150B@z.odi.ac> References: <4377284F-6AAD-4603-9B4F-059C18AC150B@z.odi.ac> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC712F8E@EA-EXMSG-C334.europe.corp.microsoft.com> Folks Quite a few people have asked for splices in Template Haskell *types*, and I have finally gotten around to implementing them. So now you can write things like instance Binary $(blah blah) where ... or f :: $(wubble bubble) -> Int as requested, for example, in the message below. Give it a whirl. You need the HEAD; in a day or two you should find binary snapshots if you don't want to build from source. Simon PS: Note that you (still) cannot write a splice in a *binding* position. Thus you can't write f $(blah blah) = e or data T $(blah blah) = MkT Int I don't intend to change this; see the commentary at http://hackage.haskell.org/trac/ghc/ticket/1476 | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On | Behalf Of Ross Mellgren | Sent: 25 January 2009 19:55 | To: Haskell Cafe | Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types | | Hi all, | | I'm writing a small module that exposes a template haskell splice that | takes a (very simplified) C struct definition and builds: | | - A data type definition, | - an instance for Data.Binary.Binary, | - and optionally a pretty print function for it | | However, it seems to do this I have to write a bunch of really ugly | code that builds up the TH data structures "by hand" because quoting | only works with splices for expressions, or so it seems. | | For example, to generate the binary instance I have this code: | | import qualified Language.Haskell.TH as TH | | -- tyname is the name of the data type I've already created, as a | TH.Name | -- tempnames is a list of temporary variable names that are used in | lambda patterns | -- fields is a list of tuples describing each field | -- makeGetExp recursively builds a monadic computation consisting | mostly of Binary.getWord32be >>= \ tempvar -> ... | | binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ | TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) | [d| get = $(makeGetExp (reverse $ zip | fields tempnames) returnExp) | put = undefined |] | | I'd really rather write: | | binaryInstDec <- [d| | instance Binary.Binary $(tyname) where | get = $(makeGetExp (reverse $ zip fields tempnames) | returnExp) | put = undefined |] | | But GHC gives me a syntax error on the tyname splice. The docs seem to | indicate this is the way it is -- that splices in type locations is | plain not implemented. | | My question is whether or not this is just the way it is, and people | writing TH declaration splices tend to have to start manually | assembling a bunch of it, or is there some trick I've missed? Perhaps | even better are there some tricks that people tend to use to make this | less painful? | | I did try using some of the lowercased monadic constructors in | Language.Haskell.TH.Lib but I didn't seem to get anything more succint | out of it. From johan.tibell at gmail.com Wed May 27 15:53:31 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed May 27 15:38:09 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> Message-ID: <90889fe70905271253k3c431a1x91efc50968822405@mail.gmail.com> On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell wrote: > In addition, I can't install network under Cygwin, Mingw, or the > Windows command line. Here are the errors from Cygwin: > I've filed a bug: http://trac.haskell.org/network/ticket/14 In the meantime try 2.2.1.1 Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090527/8eba3008/attachment-0001.html From duncan.coutts at worc.ox.ac.uk Wed May 27 16:17:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 27 16:05:17 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <85817A862E784C0BB8C730346B8A47DD@cr3lt> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> <85817A862E784C0BB8C730346B8A47DD@cr3lt> Message-ID: <1243455473.20357.37.camel@localhost> On Wed, 2009-05-27 at 19:47 +0100, Claus Reinke wrote: > > We need a clear spec on what variables tools are expected to handle and > > how they are to be interpreted. > > Currently, there seem to be $topdir and $httptopdir. And I can't see a justification for there being two. > Given the split between GHC and HP, it might be useful to have an > additional $hptopdir, or just a general mechanism for variables in > ghc-pkg's database (I recall being disappointed when what looked like > environment variables were unaffected by environment settings..). I'd rather not create ad-hoc vars which everyone needs to know about for things like the platform. > > Supporting relocatable sets of packages is a good idea. We should aim to > > have something that is usable by each compiler, not just ghc, so > > interpreting paths relative to ghc's libdir doesn't seem ideal. > > GHC makes no reference to libdir, it simply talks about a $topdir > (where it would like to store things it needs) and $httptopdir (where > haddocks might be found). Yes ok, on windows the topdir is the parent of dir containing ghc.exe. > > How about this: a way to specify paths in the package registration info that > > are relative to the location of the package db they are in. > > ahem. That sounds like a backwards step, being dependent on two > locations instead of one. I don't follow this. Which two? > Before the HP, windows GHCs could be relocated without needing to > update the ghc-pkg database, even if some packages were installed > outside GHCs $topdir. I don't see how this is related to what the Windows installer for the HP is doing. Sure, since it's installing packages relative to ghc and we'd like the whole thing to be relocatable then it should use relative paths. I don't think anyone disputes that, the question is how to implement relative paths. > With your variant, just about any change would need updating. I must be missing something. If you move package.conf and the packages in one go, then nothing needs changing as far as I can see. > Assuming that the parts are independently located by whatever the OS > packaging conventions say, and can be independently relocated > otherwise, it seems simpler to continue with the variable scheme, but > with improved support and documentation for it. My suggestion seems very simple! I'm clearly missing some problem which you can see. To be clear, here's what I'm imagining: blah/package.conf blah/lib/foo-1.0/libfoo-1.0.a and package.conf would contain foo-1.0 with paths looking like "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name we agree on) as being "blah/" because that's the dir containing the db. So crucially, it doesn't really matter where ghc.exe is. Assuming ghc can find the package conf then it can find all the files. So it'd let you create multiple relocatable package collections. If the primary package db is kept relative to ghc (eg in ghc's topdir) then the whole ghc installation including libs is relocatable Duncan From johan.tibell at gmail.com Wed May 27 16:50:26 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed May 27 16:40:17 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <90889fe70905271253k3c431a1x91efc50968822405@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <90889fe70905271253k3c431a1x91efc50968822405@mail.gmail.com> Message-ID: <90889fe70905271350u732261b4u9f2be37c08e23dd1@mail.gmail.com> On Wed, May 27, 2009 at 9:53 PM, Johan Tibell wrote: > On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell wrote: > >> In addition, I can't install network under Cygwin, Mingw, or the >> Windows command line. Here are the errors from Cygwin: >> > > I've filed a bug: http://trac.haskell.org/network/ticket/14 > > In the meantime try 2.2.1.1 > The latest HEAD from darcs works fine for me on Windows XP. Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090527/cb666fca/attachment.html From twhitehead at gmail.com Wed May 27 19:07:53 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed May 27 18:52:15 2009 Subject: Lazy computation being repeated? Message-ID: <200905271907.54164.twhitehead@gmail.com> I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. The program in question goes like so. The results from the expensive calculation are stored in this structure data Cache = Cache { cacheBits0 :: UArr Float, cacheBits1 :: UArr Float } and computed by this function (which takes several gigs of RAM) cacheIndex :: ... -> Cache cacheIndex ... = ... The main program is main = catch prog error where prog = do ... let !cache = cacheIndex ... ... run cache ... ... The run function reads an input line from stdin and calls effectChange to performs the indicated calculation run cache ... = loop where loop = do ... case effectChange ... cache of ... ... loop The effectChange function is calculates the change in an auto correlation. It is made much cheaper (order too fast to notice) through the use of a the one time computations stored in cacheBits0 and cacheBits1 (order several seconds). Whether cacheBits1 is used or not depends on the input, while cacheBits0 is always used because I used lengthU cacheBits0 [the fast one from UArr] to get the length of both of them. The first line of input causes a several second delay and lots of memory to be allocated (the cacheBits are being computed). Repeated lines of input respond very quickly and the memory stays mostly constant, unless cacheBits1 is used, in which case there is always a delay of several seconds and big jumps in memory allocation. The only thing I can think of that each time effectsChange is being run and it is uses cacheBits1, it causes it value to be recomputed. Indeed, the delay and big memory jumps go away if I change all references of cacheBits1 to cacheBits0 in effectsChange or make the data fields strict like so data Cache = Cache { cacheBits0 :: !(UArr Float), cacheBits1 :: !(UArr Float) } Does this make sense? Am I missing some reason why this should be the expected behaviour for this program? Thanks! -Tyson From jules at jellybean.co.uk Thu May 28 02:04:23 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Thu May 28 01:48:39 2009 Subject: Lazy computation being repeated? In-Reply-To: <200905271907.54164.twhitehead@gmail.com> References: <200905271907.54164.twhitehead@gmail.com> Message-ID: <4A1E2967.6000009@jellybean.co.uk> Tyson Whitehead wrote: > I have a program that seems to me to be exhibiting strange behaviour. > Basically, it looks like something somewhere is not being updated, and this is > resulting in (very expensive) computation being repeated. Just a hunch - try recompiling your modules with -fno-state-hack. q.v. http://hackage.haskell.org/trac/ghc/ticket/2284 From simonpj at microsoft.com Thu May 28 03:04:44 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 28 02:49:03 2009 Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types In-Reply-To: <1bc51a990905271607l2985daafv38925a2dd76aea6e@mail.gmail.com> References: <4377284F-6AAD-4603-9B4F-059C18AC150B@z.odi.ac> <638ABD0A29C8884A91BC5FB5C349B1C337FC712F8E@EA-EXMSG-C334.europe.corp.microsoft.com> <1bc51a990905271607l2985daafv38925a2dd76aea6e@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC71303E@EA-EXMSG-C334.europe.corp.microsoft.com> You already have splicing for top level decls. Splicing for local decls is a whole different ball game because it brings new *binders* into scope. For example f = ...g... g = let $(foo) in ...f... Is the 'f' inside 'g' the same 'f' as the one bound at top level? Not necessarily, because $(foo) might bind f. So I can't even do dependency analysis to figure out whether f and g are mutually recursive! It gets harder if $(foo) mentions 'f'; and if the definition of 'f' has a declaration splice too. So splicing local decls introduces a new raft of questions whose answers are not obvious, and that might require some substantial structural rearrangement of GHC. In particular to the "rename and then typecheck" strategy. It's very similar to reason that we don't allow splices in patterns. Bottom line: my nose tells me this is a swamp and I'm steering clear of it for now. Simon From: Matt Morrow [mailto:moonpatio@gmail.com] Sent: 28 May 2009 00:08 To: Simon Peyton-Jones Cc: Ross Mellgren; Haskell Cafe; GHC users Subject: Re: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types Spectacular! How difficult would it be to implement splicing in decls? I'm interested in having a go at it, and it seems like a perfect time since I can cheat off the fresh diff. In particular I'd love to be able to do stuff like this (without the current vicious hackery i'm using) (and granted, where i'm splicing is somewhat willy-nilly, but some approximation of this): ----------------------------------------------------------------------------- {-# LANGUAGE TemplateHaskell, QuasiQuotes #-} module DecTest where import HsDec import Data.List import DecTestBoot import Language.Haskell.TH.Lib import Language.Haskell.TH.Syntax import Language.Haskell.Meta.Utils bootQ :: Q [Dec] bootQ = bootQFunct primQStruct primQStruct = (''[] ,(conT ''[] `appT`) ,[|[]|] ,[|null|] ,[|undefined|] ,[|union|] ,[|undefined|] ,[|undefined|]) bootQFunct (primN :: Name ,primQ :: TypeQ -> TypeQ -- exists q. forall a. a -> q a ,emptyQ :: ExpQ -- Q a ,isEmptyQ :: ExpQ -- q a -> Bool ,insertQ :: ExpQ -- Int -> a -> q a -> q a ,mergeQ :: ExpQ -- q a -> q a -> q a ,findMinQ :: ExpQ -- q a -> Maybe (Int, a) ,deleteMinQ :: ExpQ) -- q a -> q a = do n <- newName "a" let primT = varT primN a = varT n [$dec| data BootQ $(a) = Nil | Node {-# UNPACK #-} !Int $(a) ($(primT) (BootQ $(a))) deriving(Eq,Ord) empty :: BootQ $(a) isEmpty :: BootQ $(a) -> Bool insert :: Int -> $(a) -> BootQ $(a) -> BootQ $(a) merge :: BootQ $(a) -> BootQ $(a) -> BootQ $(a) findMin :: BootQ $(a) -> Maybe (Int, $(a)) deleteMin :: BootQ $(a) -> BootQ $(a) empty = Nil isEmpty Nil = True isEmpty _ = False findMin Nil = Nothing findMin (Node n x _) = Just (n, x) insert n x q = merge (Node n x $(emptyQ)) q merge (Node n1 x1 q1) (Node n2 x2 q2) | n1 <= n2 = Node n1 x1 ($(insertQ) n2 (Node n2 x2 q2) q1) | otherwise = Node n2 x2 ($(insertQ) n1 (Node n1 x1 q1) q2) merge Nil q = q merge q Nil = q deleteMin Nil = Nil deleteMin (Node _ _ q) = case $(findMinQ) q of Nothing -> Nil Just (_, Node m y q1) -> let q2 = $(deleteMinQ) q in Node m y ($(mergeQ) q1 q2) |] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090528/4d96f78f/attachment-0001.html From simonpj at microsoft.com Thu May 28 03:08:31 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 28 02:52:48 2009 Subject: Lazy computation being repeated? In-Reply-To: <200905271907.54164.twhitehead@gmail.com> References: <200905271907.54164.twhitehead@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC713043@EA-EXMSG-C334.europe.corp.microsoft.com> That certainly sounds odd to me. As Jules says, try -fno-state-hack (a bit of a shot in the dark, because we don't have the full context). I hope someone can help you characterise it a bit more accurately, so you can report it as a Trac bug. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Tyson Whitehead | Sent: 28 May 2009 00:08 | To: glasgow-haskell-users@haskell.org | Subject: Lazy computation being repeated? | | I have a program that seems to me to be exhibiting strange behaviour. | Basically, it looks like something somewhere is not being updated, and this is | resulting in (very expensive) computation being repeated. | | The program in question goes like so. The results from the expensive | calculation are stored in this structure | | data Cache = Cache { cacheBits0 :: UArr Float, | cacheBits1 :: UArr Float } | | and computed by this function (which takes several gigs of RAM) | | cacheIndex :: ... -> Cache | cacheIndex ... = ... | | The main program is | | main = catch prog error | where prog = do ... | let !cache = cacheIndex ... | ... | run cache ... | ... | | The run function reads an input line from stdin and calls effectChange to | performs the indicated calculation | | run cache ... = loop | where loop = do ... | case effectChange ... cache of | ... | ... | loop | | The effectChange function is calculates the change in an auto correlation. It | is made much cheaper (order too fast to notice) through the use of a the one | time computations stored in cacheBits0 and cacheBits1 (order several seconds). | | Whether cacheBits1 is used or not depends on the input, while cacheBits0 is | always used because I used lengthU cacheBits0 [the fast one from UArr] to get | the length of both of them. The first line of input causes a several second | delay and lots of memory to be allocated (the cacheBits are being computed). | | Repeated lines of input respond very quickly and the memory stays mostly | constant, unless cacheBits1 is used, in which case there is always a delay of | several seconds and big jumps in memory allocation. | | The only thing I can think of that each time effectsChange is being run and it | is uses cacheBits1, it causes it value to be recomputed. Indeed, the delay | and big memory jumps go away if I change all references of cacheBits1 to | cacheBits0 in effectsChange or make the data fields strict like so | | data Cache = Cache { cacheBits0 :: !(UArr Float), | cacheBits1 :: !(UArr Float) } | | Does this make sense? Am I missing some reason why this should be the | expected behaviour for this program? | | Thanks! -Tyson | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From claus.reinke at talk21.com Thu May 28 06:16:17 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 28 06:00:40 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com><1233959225.26754.713.camel@localhost><8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com><79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com><1236032892.22402.33.camel@localhost><79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com><8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com><79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com><8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com><8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com><79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com><1243441450.20357.18.camel@localhost><85817A862E784C0BB8C730346B8A47DD@cr3lt> <1243455473.20357.37.camel@localhost> Message-ID: >> Currently, there seem to be $topdir and $httptopdir. > And I can't see a justification for there being two. Each variable provides an indirection that decouples the installation from one source of _independent_ relocations (btw, I've always imagined that it is called 'http' instead of 'html' to allow for references to haskell.org when no local docs are installed, but it doesn't seem to work that way). >> > How about this: a way to specify paths in the package registration info that >> > are relative to the location of the package db they are in. >> ahem. That sounds like a backwards step, being dependent on two >> locations instead of one. > I don't follow this. Which two? package db + package path: in the current system, you only have to update the package db if you move a package that isn't installed under the GHC tree; in your suggestion, you also have to update it if you move the package db/GHC itself while having non-core packages installed outside the GHC tree. >> Before the HP, windows GHCs could be relocated without needing to >> update the ghc-pkg database, even if some packages were installed >> outside GHCs $topdir. > > I don't see how this is related to what the Windows installer for the HP > is doing. Sure, since it's installing packages relative to ghc and we'd > like the whole thing to be relocatable then it should use relative > paths. I don't think anyone disputes that, the question is how to > implement relative paths. I was just disambiguating which GHC installers I was referring to, since there are now two possibilities, with different properties. >> With your variant, just about any change would need updating. > I must be missing something. If you move package.conf and the packages > in one go, then nothing needs changing as far as I can see. You seem to be assuming that everything is under a common root? That isn't the case for most unixes (different locations for bin/ doc/ lib/ .., docs installed or not), and even on windows, it stopped being the case with cabal insisting on 'Program Files/Haskell/...' as the default install. Since ghc traditionally installs into 'c:/ghc/ghc-' (on my system, at least, but I think that no-spaces-location was suggested by one of the GHC installers originally, and spaces in tool paths still confuse the GHC build system), I have two locations. If I move GHC, nothing needs changing. If I move packages that didn't come with GHC, package.db needs updating. If the packages had been registered wrt to a $cabaltopdir, no changes would be needed in either case. In your suggestion, if I move GHC but not the packages, package.db needs updating, if I move the packages but not GHC, package.dg needs updating, only if I move both, and by the same relative path, no update is needed. >> Assuming that the parts are independently located by whatever the OS >> packaging conventions say, and can be independently relocated >> otherwise, it seems simpler to continue with the variable scheme, but >> with improved support and documentation for it. > > My suggestion seems very simple! I'm clearly missing some problem which > you can see. > > To be clear, here's what I'm imagining: > > blah/package.conf > blah/lib/foo-1.0/libfoo-1.0.a That is everything under one tree, right? And since package.conf is GHC's register, GHC would have to be in that tree as well. > and package.conf would contain foo-1.0 with paths looking like > "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name > we agree on) as being "blah/" because that's the dir containing the db. > > So crucially, it doesn't really matter where ghc.exe is. Assuming ghc > can find the package conf then it can find all the files. So it'd let > you create multiple relocatable package collections. If the primary > package db is kept relative to ghc (eg in ghc's topdir) then the whole > ghc installation including libs is relocatable That is what GHC did on windows before cabal changed the package locations away to a path that neither GHC nor its build tools can use. Is that even possible on unix systems, with their various packaging and location traditions? And if Simon ever makes that breakthrough of binary compatibility at least between minor GHC versions, we can't have the libraries in the GHC directories, as they'd be shared between several GHCs. Claus From marlowsd at gmail.com Thu May 28 07:07:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 28 06:51:41 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net> <2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> Message-ID: <4A1E7069.7010500@gmail.com> On 23/05/2009 14:53, Claus Reinke wrote: >> JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'. >> It is actually mentioned on this page: >> http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack > > Yes, I know, but the discussion on that page wanted to go beyond this > (possibly triggered by your demonstration that one can go beyond plain > SRCLOC;-), which is why GHC still has neither of SRCLOC or > SRCLOC_ANNOTATE (apart from the various SRCLOC hacks). > > What is really frustrating is that GHC has the machinery to do this > trivially (RULES, soon core2core phase plugins as well), only that this > machinery gets applied when source location information is no longer > available, so it is useless for this problem:-( > > One thing that wasn't available when this discussion was last active > is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions' > would be useful). For instance, appended below is the example from that > wiki page, with entirely local transformations to add source locations > and to use that info to augment 'ErrorCall' exceptions (we should really > augment 'PatternMatchFail' exception messages as well..). > > $ ghc -e main callstack.hs > : hd: empty list > ("callstack.hs",25) > ("callstack.hs",21) > ("callstack.hs",16) > ("callstack.hs",13) Your example is giving you the dynamic call stack. Is that really what you want? The dynamic call stack will often be quite different from the structure of your program, may well be surprising, and may even differ depending on compiler flags. My personal preference would be to fix cost center stacks to do the right thing here. Currently we have +RTS -xc which shows the call stack when an exception is raised, available when your program is profiled. Sometimes it gives odd results because it has bugs, but the idea is that it gives you a *lexical* call stack, which corresponds exactly to the code that you wrote, not the unpredictable evaluation strategy of the compiler. Obviously the down side of CCSs is that you have to compile your code and libraries for profiling, but OTOH you don't have to add any mapExceptions, pragmas, or other explicit annotation stuff. And it could be added to GHCi by default, so when working in GHCi you could have full lexical call stacks for all interpreted code. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu May 28 07:32:45 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 28 07:17:29 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> <85817A862E784C0BB8C730346B8A47DD@cr3lt> <1243455473.20357.37.camel@localhost> Message-ID: <1243510365.20357.83.camel@localhost> On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote: > >> > How about this: a way to specify paths in the package registration info that > >> > are relative to the location of the package db they are in. > >> ahem. That sounds like a backwards step, being dependent on two > >> locations instead of one. > > I don't follow this. Which two? > > package db + package path: in the current system, you only have to > update the package db if you move a package that isn't installed under > the GHC tree; in your suggestion, you also have to update it if you move > the package db/GHC itself while having non-core packages installed > outside the GHC tree. But if you're registering global packages that are installed outside of the GHC tree then you wouldn't register them using relative paths. I'm not saying everything must use relative paths. > >> With your variant, just about any change would need updating. > > I must be missing something. If you move package.conf and the packages > > in one go, then nothing needs changing as far as I can see. > > You seem to be assuming that everything is under a common root? Well it is on Windows which is the main case where people want relocatable installations. If we wanted relocatable installations on Unix then it'd all have to be under one root too, eg /opt/whatever. > That isn't the case for most unixes (different locations for bin/ doc/ > lib/ .., docs installed or not), and even on windows, it stopped being > the case with cabal insisting on 'Program Files/Haskell/...' as the > default install. Sure, extra packages should not be installed in the ghc tree and so those should not use paths relative to the ghc location. > Since ghc traditionally installs into 'c:/ghc/ghc-' > (on my system, at least, but I think that no-spaces-location was > suggested by one of the GHC installers originally, and spaces in > tool paths still confuse the GHC build system), I have two locations. > > If I move GHC, nothing needs changing. If I move packages that > didn't come with GHC, package.db needs updating. If the packages > had been registered wrt to a $cabaltopdir, no changes would be > needed in either case. For some reason I really dislike the idea that we make up specific vars like $cabaltopdir for specific purposes. Perhaps that's just me. I want a general solution, not something that forces everyone to adopt conventions like installing everything in ~/.cabal/. That's just a sensible default, but the user rightly has full control over --prefix, --libdir etc etc. > In your suggestion, if I move GHC but not the packages, package.db > needs updating, No it does not. That would only be the case if you always registered things relative to ghc, but that'd be silly for things not actually installed in the ghc install tree. > if I move the packages but not GHC, package.dg needs updating, only if > I move both, and by the same relative path, no update is needed. Are you suggesting that we need to be able to move core libs that are distributed with ghc, independently of where the ghc binary is? > >> Assuming that the parts are independently located by whatever the OS > >> packaging conventions say, and can be independently relocated > >> otherwise, it seems simpler to continue with the variable scheme, but > >> with improved support and documentation for it. > > > > My suggestion seems very simple! I'm clearly missing some problem which > > you can see. > > > > To be clear, here's what I'm imagining: > > > > blah/package.conf > > blah/lib/foo-1.0/libfoo-1.0.a > > That is everything under one tree, right? Not necessarily. For the things in the same tree it'd be sensible to use relative paths. For things not in the same tree it'd be sensible to use absolute paths. This scheme also allows other sets of relocatable packages, so long as ghc gets told where to find the package.conf. > And since package.conf is GHC's register, GHC would have to be in that > tree as well. For core packages shipped with ghc/hp, yes. > > and package.conf would contain foo-1.0 with paths looking like > > "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name > > we agree on) as being "blah/" because that's the dir containing the db. > > > > So crucially, it doesn't really matter where ghc.exe is. Assuming ghc > > can find the package conf then it can find all the files. So it'd let > > you create multiple relocatable package collections. If the primary > > package db is kept relative to ghc (eg in ghc's topdir) then the whole > > ghc installation including libs is relocatable > > That is what GHC did on windows before cabal changed the package > locations away to a path that neither GHC nor its build tools can use. Do you mean installing binaries in C:\Program Files\Haskell\bin by default? That decision was made by the Windows users. It's true that the GHC build system cannot work in a directory containing spaces, and that's probably too hard to fix. However using tools (eg happy, alex) that are in a dir containing spaces should not be nearly so hard to fix. > Is that even possible on unix systems, with their various packaging and > location traditions? I'm not sure what you're referring to. > And if Simon ever makes that breakthrough of binary compatibility > at least between minor GHC versions, we can't have the libraries in > the GHC directories, as they'd be shared between several GHCs. I've never suggested they should be. Only things distributed with ghc/hp should be together in one relocatable tree. Everything else the user installs should go in the appropriate locations. Duncan From claus.reinke at talk21.com Thu May 28 09:12:36 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 28 08:57:01 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com><1233959225.26754.713.camel@localhost><8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com><79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com><1236032892.22402.33.camel@localhost><79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com><8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com><79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com><8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com><8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com><79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com><1243441450.20357.18.camel@localhost><85817A862E784C0BB8C730346B8A47DD@cr3lt><1243455473.20357.37.camel@localhost> <1243510365.20357.83.camel@localhost> Message-ID: <83E7EBA60C2B4C55964981982C3F6A64@cr3lt> > But if you're registering global packages that are installed outside of > the GHC tree then you wouldn't register them using relative paths. I'm > not saying everything must use relative paths. Please don't move your windmills while I'm fighting them!-) If you don't want to move from absolute paths for non-core packages, the current system should just work, right? I thought we were talking about (a) making ghc-pkg (optionally) instantiate any variables in its database in (all of) its command-line output and (b) allowing non-core packages to be relocated without having to update ghc-pkg's database. > For some reason I really dislike the idea that we make up specific vars > like $cabaltopdir for specific purposes. Perhaps that's just me. I want > a general solution, not something that forces everyone to adopt > conventions like installing everything in ~/.cabal/. That's just a > sensible default, but the user rightly has full control over --prefix, > --libdir etc etc. Personally, I only dislike the idea of hardcoding specific variable names in ghc-pkg, which is why I suggested a name-independent approach (I also dislike the current duplication of code in ghc-pkg/ghc api/..). $cabaltopdir would just improve the handling of the default cabal install locations, without dictating where users say those default locations should be - and if users move specific packages/package parts to different absolute locations, those absolute locations would still have to appear in the package database, but I'd expect that to be an exception. If common prefixes are abstracted out via variables, it would simply be easier to see that the majority of package parts are not randomly distributed over the available file systems, but related to the chosen default settings of the tool that installed them (that might involve communication between GHC and Cabal: GHC knows about its own dir, but would have to ask Cabal about its locations - or, better, Cabal could tell GHC about its locations once, when the user changes them). I'm mostly seeing the windows perspective at the moment, btw, but even on unix, one might want to abstract out common prefixes, in case one decides to move packages from $HOME/ to system-wide prefixes, or from one system-wide prefix to another. Perhaps the difference doesn't matter much, apart from readability: Let's say I wanted to move a GHC/Cabal/HP installation to a USB drive: moving GHC/corelibs is straightforward (it doesn't care under what drive name the USB drive gets mounted on the lecture theatre computer), but how would I move Cabal-installed non-core packages (not to mention Cabal itself?)? Is that use case documented in some faq? If the extra package paths are absolute, it would involve something like search&replace on the concrete representation of the supposedly abstract package database, but as long as that representation is a simple text file, that might not be too troublesome; if the extra package paths are relative to a $cabaltopdir, it would involve telling GHC about the new location prefix whenever calling it directly (or telling Cabal about its new location, and Cabal passing that on when calling GHC). >> That is what GHC did on windows before cabal changed the package >> locations away to a path that neither GHC nor its build tools can use. > Do you mean installing binaries in C:\Program Files\Haskell\bin by > default? That decision was made by the Windows users. s/the/some/ ;-) It is a reasonable default to expect, but if Cabal had ever asked me before starting to install things there, I'd have changed that default immediately. I was thinking more about things that would appear in package.conf: C:\Program Files\Haskell\\ C:\Program Files\Haskell\doc\ but it is the same difference: there are now two locations to consider even on windows (GHC/corelibs + Cabal/other packages), and that is probably how it should be. > It's true that the GHC build system cannot work in a directory > containing spaces, and that's probably too hard to fix. However using > tools (eg happy, alex) that are in a dir containing spaces should not be > nearly so hard to fix. Maybe so, but last time (end of January) I asked about the GHC build (in a space-free path) using tools where cabal installs them by default (with spaces in path), Simon M answered: "It's not practical in general to cope with spaces in paths in the build system. IIRC we tried to get this right once and gave up.". So if there is a tool path specific subset of the problem that could be solved more easily, it doesn't seem to help. >> Is that even possible on unix systems, with their various packaging and >> location traditions? > I'm not sure what you're referring to. Some unix branches seem to distinguish themselves merely by different package management/location. But apart from Mac frameworks, I'm not aware of any unix that would not expect libraries/binaries/docs to be installed in different locations (instead of common, language-specific roots, the common roots are purpose-specific). Relocation might not be as typical there, though (don't know how mounting external drives affects paths there, or whether users might want to relocate packages between different prefixes like /opt, /etc, /usr, .., or just from user-local to system-wide locations). >> And if Simon ever makes that breakthrough of binary compatibility >> at least between minor GHC versions, we can't have the libraries in >> the GHC directories, as they'd be shared between several GHCs. > > I've never suggested they should be. Only things distributed with ghc/hp > should be together in one relocatable tree. Everything else the user > installs should go in the appropriate locations. Ok, then the question is just how to communicate those locations to GHC: monolithically, as absolute paths, or separated into common prefixes and relative paths (usually, only the prefixes would change on relocations). My preference would be separated, with ghc-pkg filling in the prefix variables' current values when asked to do so. Claus From duncan.coutts at worc.ox.ac.uk Thu May 28 09:48:43 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 28 09:33:10 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <1243455473.20357.37.camel@localhost> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> <85817A862E784C0BB8C730346B8A47DD@cr3lt> <1243455473.20357.37.camel@localhost> Message-ID: <1243518523.20357.144.camel@localhost> On Wed, 2009-05-27 at 21:17 +0100, Duncan Coutts wrote: > To be clear, here's what I'm imagining: > > blah/package.conf > blah/lib/foo-1.0/libfoo-1.0.a > > and package.conf would contain foo-1.0 with paths looking like > "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name > we agree on) as being "blah/" because that's the dir containing the db. Ian has convinced me that we do actually need two vars. We need one for file paths and one for urls. For example, consider haddock-html: $pkgroot/doc/ghc-6.10.1/libraries/base This is supposed to expand to a URL like file:///usr/share/doc/ghc-6.10.1/libraries/base or something similar on Windows. It's especially important that it is a file:// url on windows because normal windows paths are not absolute urls like unix ones are. Now if we've only got one var like $pkgroot then we cannot encode file:///usr/share/doc/ghc-6.10.1/libraries/base and also be able to interpret it relative for tools that grok the var. You could say: haddock-html: file://$pkgroot/doc/ghc-6.10.1/libraries/base but then tools that want to construct relative paths have to disentangle the file:// prefix. So, we suggest that we have two vars, $pkgroot and $pkgrooturl. These are to be interpreted as the directory containing the package registration information, eg the package.conf file in the case of ghc. Hugs and nhc do not use package databases but they do use individual files for each package's registration info. So again $pkgroot(url) is just the dir containing the file. Now tools may well be expected to understand these vars. We cannot always have hc-pkg expand it, because for hugs and nhc there is no hc-pkg, it's just the simple text files. A tool using the Cabal lib to read the set of installed packages could benefit from the var expansion but not one reading the files directly. As a convenience ghc-pkg field does do variable expansion, and that's probably the right tradeoff. Tools that parse the output of ghc-pkg dump/describe can be expected to do the var expansion (and of course they may want to see and construct relative paths). The only thing is that tools then need to know the path to use for the $pkgroot. In particular for the --global and --user packages which are not specified to hc-pkg by their path. Why not continue to use $topdir and $httptopdir? Because these things are not guaranteed to exist. They only make sense for a relocatable compiler installation. Users (especially distro packagers) may choose to do non-relocatable installations following the FSH spec. However the package file/db itself always exists. Also it's more general, it allows multiple relocatable sets of packages, each with their own package file/db, where as $topdir is tied to the installation of the compiler itself. Duncan From claus.reinke at talk21.com Thu May 28 10:09:03 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 28 09:53:24 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> <4A1E7069.7010500@gmail.com> Message-ID: <162772D134DA46E586DAB142369ECFE5@cr3lt> >> One thing that wasn't available when this discussion was last active >> is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions' >> would be useful). For instance, appended below is the example from that >> wiki page, with entirely local transformations to add source locations >> and to use that info to augment 'ErrorCall' exceptions (we should really >> augment 'PatternMatchFail' exception messages as well..). >> >> $ ghc -e main callstack.hs >> : hd: empty list >> ("callstack.hs",25) >> ("callstack.hs",21) >> ("callstack.hs",16) >> ("callstack.hs",13) > > Your example is giving you the dynamic call stack. Is that really what you want? The dynamic > call stack will often be quite different from the structure of your program, may well be > surprising, and may even differ depending on compiler flags. Given the source locations, the lexical _position_ is obvious, so for mere traces, dynamic seems to be the choice (with an option of pseudo-cbv or the real dynamic stack). What is neither obvious nor provided (dynamic or static, in any of the proposed stack traces) are the parameters for the stack. If those are available, as in a debugger, the balance might shift to favour lexical stack, especially if I'm investigating "what is there?", rather than "who asked for this, and why?", "where am I?" or "how did I get there?". Both static and dynamic stack can be useful - different queries, different answers. And without automated annotation support, it is difficult to test how useful either stack traces are (apart from: better than nothing;-). I have the feeling that dynamic stack trace is the right _initial_ answer: if that induces a need to know about the construction environment, one can annotate construction Hood-style (preferred), without changing strictness, or make it strict (not useful if there are many constructions and only one failing access), so that construction and first observation coincide, or pretend to have made it strict while evaluating non-strictly (the pseudo-cbv stack traces). Or one could switch tools, from dynamic to a lexical stack, and from mere stack trace to debugger (where I would like good lexical and dynamic stacks with parameters:-). > My personal preference would be to fix cost center stacks to do the right thing here. Currently > we have +RTS -xc which shows the call stack when an exception is raised, available when your > program is profiled. Sometimes it gives odd results because it has bugs, but the idea is that it > gives you a *lexical* call stack, which corresponds exactly to the code that you wrote, not the > unpredictable evaluation strategy of the compiler. The more information one can get, the more queries about one's program one can answer, the more puzzles/bugs one can solve. So, by all means, lets have lexical stack, pseudo-call-by-value stack, and dynamic stack choices available. And lexical stack with parameters in the debugger. Here are the +RTS -xc and mapException outputs together (when I remove the mapError annotations, only the first <..> is printed, so that is the part to focus on, the rest is confusion) - they seem to complement each other (-xc has no locations, but names for the lexical stack; mapError has no names, but locations for the dynamic stack; we're still missing the parameters for either stack): $ ghc --make -prof -auto-all stacktraces.hs [1 of 1] Compiling Main ( stacktraces.hs, stacktraces.o ) Linking stacktraces.exe ... $ ./stacktraces.exe +RTS -xc -- fib 5 fib with non-positive number: 0 ("stacktraces.hs",46) ... ("stacktraces.hs",45) ("stacktraces.hs",36) -- odd_ 5 odd_: no match ("stacktraces.hs",51) ... ("stacktraces.hs",54) ("stacktraces.hs",50) ("stacktraces.hs",38) -- firstLetters2 Prelude.head: empty list ("stacktraces.hs",59) ... ("stacktraces.hs",64) ("stacktraces.hs",63) > Obviously the down side of CCSs is that you have to compile your code and libraries for profiling, > but OTOH you don't have to add any mapExceptions, pragmas, or other explicit annotation stuff. > And it could be added to GHCi by default, so when working in GHCi you could have full lexical call > stacks for all interpreted code. If RULES right hand sides could be given access to the source locations of the code that their left hand sides have matched, the annotation could be automated, and would seem to be less intrusive than the finding-the- needle transformation. Also, this seems to be the smallest possible change to GHC (I just don't know whether it is possible, or how to do it). But, as I said, the more info, the better. And getting some info without annotations would be great (currently, +RTC -sc is no use with GHCi, and even with printE replaced with print, -fbreak-on-error, and :trace main, the GHCi debugger doesn't seem to offer much help for this example). Claus From duncan.coutts at worc.ox.ac.uk Thu May 28 10:16:33 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 28 10:01:01 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <83E7EBA60C2B4C55964981982C3F6A64@cr3lt> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> <85817A862E784C0BB8C730346B8A47DD@cr3lt> <1243455473.20357.37.camel@localhost> <1243510365.20357.83.camel@localhost> <83E7EBA60C2B4C55964981982C3F6A64@cr3lt> Message-ID: <1243520193.20357.199.camel@localhost> On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote: > > But if you're registering global packages that are installed outside of > > the GHC tree then you wouldn't register them using relative paths. I'm > > not saying everything must use relative paths. > > Please don't move your windmills while I'm fighting them!-) > > If you don't want to move from absolute paths for non-core packages, > the current system should just work, right? Yes. Though it also allows for the possibility of relocatable sets of packages that are not installed relative to the compiler. But more importantly it's more general and simpler than the current '$topdir' that ghc uses. > I thought we were talking about > (a) making ghc-pkg (optionally) instantiate any variables in its > database in (all of) its command-line output and Yes, though I'm only asking for two vars (previously one), not an ad-hoc set of vars. > (b) allowing non-core packages to be relocated without having to > update ghc-pkg's database. In my suggested system this is possible if that set of packages use their own package db (containing relative paths). In your system it's possible by updating some var in a central registry and having that set of packages use paths relative to that var. > > For some reason I really dislike the idea that we make up specific vars > > like $cabaltopdir for specific purposes. Perhaps that's just me. I want > > a general solution, not something that forces everyone to adopt > > conventions like installing everything in ~/.cabal/. That's just a > > sensible default, but the user rightly has full control over --prefix, > > --libdir etc etc. > > Personally, I only dislike the idea of hardcoding specific variable names > in ghc-pkg, which is why I suggested a name-independent approach > (I also dislike the current duplication of code in ghc-pkg/ghc api/..). > > $cabaltopdir would just improve the handling of the default cabal > install locations, without dictating where users say those default locations > should be - and if users move specific packages/package parts to > different absolute locations, those absolute locations would still have > to appear in the package database, but I'd expect that to be an > exception. So ghc's current system uses two vars, $topdir and $httptopdir. I'm proposing to replace those with a standardised ${pkgroot} and ${pkgrooturl} vars which are usable by all compilers and in more situations. You're proposing a central registry of vars and to have ghc-pkg (optionally) expand these vars which could be used anywhere in the installed package descriptions. Presumably you're also suggesting some mechanism to query and update this registry of variables. Is that a fair summary? > Let's say I wanted to move a GHC/Cabal/HP installation to a > USB drive: moving GHC/corelibs is straightforward (it doesn't > care under what drive name the USB drive gets mounted on the > lecture theatre computer), but how would I move Cabal-installed > non-core packages (not to mention Cabal itself?)? Is that use case > documented in some faq? Ok, so you want to construct a set of relocatable packages. This needs to be decided from the beginning when you compile said packages because otherwise packages can have paths baked into them. There are some restrictions on making relocatable packages, eg you can't set --libdir to an absolute path, it has to be relative to the --prefix. In addition to making the package relocatable, we would have to register the package into a package db that lives relative to the packages in question. This db would contain relative paths (using ${pkgroot}). Once this is done then the whole lot would be relocatable onto a USB drive or whatever. To use this set of packages you would need to specify --package-conf= to ghc, or --package-db= to cabal. > If the extra package paths are absolute, it would involve something > like search&replace on the concrete representation of the supposedly > abstract package database, but as long as that representation is a > simple text file, that might not be too troublesome; Aye, so if you want to be able to move then then it's better if they're relative. > if the extra package paths are relative to a $cabaltopdir, it would > involve telling GHC about the new location prefix whenever calling > it directly (or telling Cabal about its new location, and Cabal passing > that on when calling GHC). So that's the bit in your suggestion that corresponds to using --package-conf= in my suggestion. And it assumes that you don't need to set $cabaltopdir to two values simultaniously, eg if the machine you've moved it to on the USB stick also has cabal packages that it needs to use. > > It's true that the GHC build system cannot work in a directory > > containing spaces, and that's probably too hard to fix. However using > > tools (eg happy, alex) that are in a dir containing spaces should not be > > nearly so hard to fix. > > Maybe so, but last time (end of January) I asked about the GHC build > (in a space-free path) using tools where cabal installs them by default > (with spaces in path), Simon M answered: "It's not practical in general > to cope with spaces in paths in the build system. IIRC we tried to get > this right once and gave up.". So if there is a tool path specific subset > of the problem that could be solved more easily, it doesn't seem to help. Spaces in paths in general is indeed hard. The case where the build tree is in a path with no spaces but some of the external tools are is much easier. Simon was talking about the more general, harder case. > >> Is that even possible on unix systems, with their various packaging and > >> location traditions? > > I'm not sure what you're referring to. > > Some unix branches seem to distinguish themselves merely by different > package management/location. But apart from Mac frameworks, I'm > not aware of any unix that would not expect libraries/binaries/docs to > be installed in different locations (instead of common, language-specific > roots, the common roots are purpose-specific). > > Relocation might not be as typical there, though (don't know how > mounting external drives affects paths there, or whether users might > want to relocate packages between different prefixes like /opt, /etc, > /usr, .., or just from user-local to system-wide locations). It's not especially common after installation. The advantage of a prefix-independent binary install is that it makes installation easy, just a copy. Duncan From claus.reinke at talk21.com Thu May 28 14:05:37 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 28 13:49:59 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt><4A1E7069.7010500@gmail.com> <162772D134DA46E586DAB142369ECFE5@cr3lt> Message-ID: <213F0D3580274166AAC651722FD923C8@cr3lt> > Here are the +RTS -xc and mapException outputs together (when I > remove the mapError annotations, only the first <..> is printed, so > that is the part to focus on, the rest is confusion) Actually, it looks as if the implementation of mapException modifies the stack that +RTS -xc prints. Not entirely surprising, perhaps. We can use that to illustrate the RULES for call site annotation suggestion, by rewriting call sites of functions to be traced to prefix 'mapException id' (see attached source). That won't change the error message, because the RULES don't have the source location we'd need there, but it will put a stack frame with lexical stack info onto the stack. On error, +RTS -xc prints the stack frames, corresponding to a dynamic stack trace, each stack frame giving a lexical stack for an annotated call site. 1) no annotations, no +RTS -xc: $ ghc -e main stacktracesXcHack.hs -- fib 5 fib with non-positive number: 0 -- odd_ 5 odd_: no match -- firstLetters2 Prelude.head: empty list 2) no annotations, +RTS -xc only: $ ghc --make -prof -auto-all stacktracesXcHack.hs -DHACK [1 of 1] Compiling Main ( stacktracesXcHack.hs, stacktracesXcHack.o ) Linking stacktracesXcHack.exe ... $ ./stacktracesXcHack.exe +RTS -xc -- fib 5 fib with non-positive number: 0 -- odd_ 5 odd_: no match -- firstLetters2 Prelude.head: empty list 3) RULES-based call site annotations, +RTS -xc (reformatted for readability): $ ghc --make -prof -auto-all stacktracesXcHack.hs -DHACK -fenable-rewrite-rules [1 of 1] Compiling Main ( stacktracesXcHack.hs, stacktracesXcHack.o ) Linking stacktracesXcHack.exe ... $ ./stacktracesXcHack.exe +RTS -xc -- fib 5 fib with non-positive number: 0 -- odd_ 5 odd_: no match -- firstLetters2 Prelude.head: empty list Would be much better if RULES could provide source location info from their application sites, or if at least +RTS -xc would contain source locations (shouldn't the parameters belonging to each stack frame be accessible, too?-). And is there an easier way to specify apply-once RULES than this double naming business? But perhaps it help to illustrate the potential, both for combining dynamic and lexical stack, and for using RULES for call site annotations.. Claus -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktracesXcHack.hs Type: application/octet-stream Size: 1379 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090528/609489a3/stacktracesXcHack-0001.obj From pgavin at gmail.com Thu May 28 15:38:26 2009 From: pgavin at gmail.com (Peter Gavin) Date: Thu May 28 15:28:19 2009 Subject: can't run Grapefruit In-Reply-To: References: Message-ID: <37df87420905281238p451b472bxf272715701e77ae2@mail.gmail.com> On Sat, May 23, 2009 at 3:58 PM, Dean Herington wrote: > GHCi, version 6.10.1: http://www.haskell.org/ghc/ ?:? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Graphics.UI.Grapefruit.Circuit > Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + > Examples.Grapefruit.Simple > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK > Examples.Grapefruit.Simple> run GTK mainCircuit > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.0 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.1 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package Win32-2.2.0.0 ... linking ... done. > Loading package filepath-1.1.0.1 ... linking ... done. > Loading package directory-1.0.0.2 ... linking ... done. > Loading package process-1.0.1.0 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could > not load DLL) Hi Dean, First, you should try using the newest version of the installer (0.10.1, it requires GHC 6.10.3). Second, you should check whether intl.dll exists in c:\gtk2hs\0.10.x\bin, and that c:\gtk2hs\0.10.x\bin is also in your PATH. If you're still having problems, please paste the contents of c:\gtk2hs\0.10.x\lib\gtk2hs\{gtk,glib}.package.conf. Please also make sure the libraries listed in the extra-libraries field and extra-ghci-libraries field exist in c:\gtk2hs\0.10.x\lib and c:\gtk2hs\0.10.x\bin respectively. Pete From claus.reinke at talk21.com Thu May 28 18:40:52 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 28 18:25:13 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com><1233959225.26754.713.camel@localhost><8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com><79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com><1236032892.22402.33.camel@localhost><79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com><8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com><79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com><8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com><8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com><79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com><1243441450.20357.18.camel@localhost><85817A862E784C0BB8C730346B8A47DD@cr3lt><1243455473.20357.37.camel@localhost><1243510365.20357.83.camel@localhost><83E7EBA60C2B4C55964981982C3F6A64@cr3lt> <1243520193.20357.199.camel@localhost> Message-ID: >> If you don't want to move from absolute paths for non-core packages, >> the current system should just work, right? > > Yes. The current system being the $topdir one. > Though it also allows for the possibility of relocatable sets of > packages that are not installed relative to the compiler. But more > importantly it's more general and simpler than the current '$topdir' > that ghc uses. 'it' now being the new system evolving in this thread, or have I missed anything? >> (a) making ghc-pkg (optionally) instantiate any variables in its >> database in (all of) its command-line output and > > Yes, though I'm only asking for two vars (previously one), not an ad-hoc > set of vars. > >> (b) allowing non-core packages to be relocated without having to >> update ghc-pkg's database. > > In my suggested system this is possible if that set of packages use > their own package db (containing relative paths). That is news to me - was that specified before this thread moved to ghc-users? > In your system it's possible by updating some var in a central registry > and having that set of packages use paths relative to that var. So, essentially, your system would have to keep a file listing the various package.conf locations (currently, GHC only knows about two: system/user, everything else would have to be passed on the commandline..). While my system would have to keep a file listing the variable bindings, so that tools processing the package db can instantiate the variables. I could see both approaches being useful, even together. > So ghc's current system uses two vars, $topdir and $httptopdir. This is GHC's view of its database. It should be useable independently, via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) - all of which should be able to resolve the variable bindings, in the same way. Btw, it would really be nice if the package handling code was shared rather than duplicated. > I'm proposing to replace those with a standardised ${pkgroot} and > ${pkgrooturl} vars which are usable by all compilers and in more > situations. Now you are talking about Cabal's view of its database. It doesn't have to expose the underlying implementation's view, especially since the other implementations organise their package handling differently. And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll files, or about include files, or haddock indices, or ..? In windows, these tend to end in a common sub-hierarchy, but you're aiming for something general, right? > You're proposing a central registry of vars and to have ghc-pkg > (optionally) expand these vars which could be used anywhere in the > installed package descriptions. Presumably you're also suggesting some > mechanism to query and update this registry of variables. > > Is that a fair summary? I think so. And you're proposing several separate registries (hasn't that been a Cabal problem in the past, even with just user and system to choose from?). Presumably you're also suggesting some mechanism to query and update the meta-registry of package database locations. Claus From simonpj at microsoft.com Fri May 29 03:07:02 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 29 02:51:20 2009 Subject: Unqualified names for -ddump-splices? In-Reply-To: <200905161711.19350.anotheraddress@gmx.de> References: <200905161711.19350.anotheraddress@gmx.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC713734@EA-EXMSG-C334.europe.corp.microsoft.com> Good idea. I've substantially improved this. In HEAD. Thanks for the suggestion. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Daniel Sch?ssler | Sent: 16 May 2009 16:11 | To: glasgow-haskell-users@haskell.org | Subject: Unqualified names for -ddump-splices? | | Hi! | | is it possible to look at spliced code without fully qualified names? (And | maybe with simple integer indices for newNames). Currently it can be pretty | hard to decipher sometimes :) | | | Greetings, | Daniel | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Fri May 29 05:59:24 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 29 05:43:50 2009 Subject: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> <79d7c4980902120121k24dea5aav20d71cee3f6fb61e@mail.gmail.com> <1236032892.22402.33.camel@localhost> <79d7c4980903181454v7566708dkc8b930934f5fe753@mail.gmail.com> <8625cd9c0903190310h341a18edm251695bc148f3ac@mail.gmail.com> <79d7c4980903190401i2fc41c59mdd3cd444ab6732f@mail.gmail.com> <8625cd9c0903190457x38017963vb93c385274b91c08@mail.gmail.com> <8625cd9c0903190528k7c254bd0g3556bdcde740a7cc@mail.gmail.com> <79d7c4980905270710l1035d7b8h48a58281a48170ea@mail.gmail.com> <1243441450.20357.18.camel@localhost> <85817A862E784C0BB8C730346B8A47DD@cr3lt> <1243455473.20357.37.camel@localhost> <1243510365.20357.83.camel@localhost> <83E7EBA60C2B4C55964981982C3F6A64@cr3lt> <1243520193.20357.199.camel@localhost> Message-ID: <1243591164.20357.1463.camel@localhost> On Thu, 2009-05-28 at 23:40 +0100, Claus Reinke wrote: > >> If you don't want to move from absolute paths for non-core packages, > >> the current system should just work, right? > > > > Yes. > > The current system being the $topdir one. Yep. It works, it's just not nice, it's ghc-specific and only make sense when ghc is installed in a prefix-independent way. > > Though it also allows for the possibility of relocatable sets of > > packages that are not installed relative to the compiler. But more > > importantly it's more general and simpler than the current '$topdir' > > that ghc uses. > > 'it' now being the new system evolving in this thread, or have I missed > anything? The new system I've been proposing. > >> (a) making ghc-pkg (optionally) instantiate any variables in its > >> database in (all of) its command-line output and > > > > Yes, though I'm only asking for two vars (previously one), not an ad-hoc > > set of vars. > > > >> (b) allowing non-core packages to be relocated without having to > >> update ghc-pkg's database. > > > > In my suggested system this is possible if that set of packages use > > their own package db (containing relative paths). > > That is news to me - was that specified before this thread moved > to ghc-users? It was in the first email that was cc'ed to ghc-users: How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. > > In your system it's possible by updating some var in a central registry > > and having that set of packages use paths relative to that var. > > So, essentially, your system would have to keep a file listing the > various package.conf locations (currently, GHC only knows about > two: system/user, everything else would have to be passed on the > commandline..). While my system would have to keep a file listing > the variable bindings, so that tools processing the package db can > instantiate the variables. If you want multiple relocatable sets of packages that are immediately "available" in the environment. > I could see both approaches being useful, even together. > > > So ghc's current system uses two vars, $topdir and $httptopdir. > > This is GHC's view of its database. It should be useable independently, > via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) - > all of which should be able to resolve the variable bindings, in the > same way. It's not usable independently, ghc does not always have a topdir. This makes life hard for tools. It's also not clear what topdir would mean in the context of other compilers. > Btw, it would really be nice if the package handling code > was shared rather than duplicated. It would be nice, yes. > > I'm proposing to replace those with a standardised ${pkgroot} and > > ${pkgrooturl} vars which are usable by all compilers and in more > > situations. > > Now you are talking about Cabal's view of its database. Cabal does not own the package databases, however it does expect that they are in the format describe by the Cabal spec, which places obligations on Haskell implementations to be somewhat package-aware. > It doesn't have to expose the underlying implementation's view, > especially since the other implementations organise their package > handling differently. All compilers use the same information (it's in the Cabal spec). They do store it differently but they all identify the location of the information using a file path. That seems pretty universal, compared to $topdir. > And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll > files, or about include files, or haddock indices, or ..? You only need one variable to identify the location of the installed package description. All relative paths can be constructed from that. The second variable is to allow for two representations of the same location, one as a native system path, the other as a URL. We do not need different variables for different kinds of files (except in as much as some fields use paths and some urls). > In windows, these tend to end in a common sub-hierarchy, but you're > aiming for something general, right? If you're making a relocatable package then these files will be in a common sub-hierarchy and you would use relative paths. If you're not making a relocatable package (eg following the Linux FSH) then you would not use relative paths. So that should be general. It does not remove any existing capability and it adds the ability to have relative paths for relocatable packages. Perhaps what you're saying is that we should be able to take any package whether it lives in a common sub-hierarchy or not and relocate it. In general this is problematic since packages can embed paths and if those paths are not relative to a common root then you have to specify them all (Cabal enables this by setting environment variables). Assuming that's ok, then even this rare use case is still possible, just by editing the package registration information. It doesn't need to be "simplified" by having one var per package entry. > > You're proposing a central registry of vars and to have ghc-pkg > > (optionally) expand these vars which could be used anywhere in the > > installed package descriptions. Presumably you're also suggesting some > > mechanism to query and update this registry of variables. > > > > Is that a fair summary? > > I think so. And you're proposing several separate registries (hasn't > that been a Cabal problem in the past, even with just user and system > to choose from?). Cabal can be instructed to use a specific package db, not just global and user. > Presumably you're also suggesting some mechanism > to query and update the meta-registry of package database locations. I wasn't actually proposing a meta-registry (ghc already supports this via an environment variable) but it is a possible extension which brings it closer to the capabilities of your proposal. My proposal is just to replace the use of $topdir with something that every compiler can implement and which tools can understand. The fact that it could be extended without having to modify the installed package description format or the tools which understand that format is a bonus. I would not argue particularly for or against such an extension, my main concern is for a simple clear spec and the sanity of tool authors. Duncan From duncan.coutts at worc.ox.ac.uk Fri May 29 06:23:28 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 29 08:31:56 2009 Subject: draft proposal for relative paths in installed package descriptions Message-ID: <1243592608.20357.1476.camel@localhost> All, This is a draft proposal for a common mechanism for implementing relative paths in installed package descriptions. Comments and feedback are welcome. I'm cc'ing this to the cabal and ghc-users lists but let's keep the discussion on the libraries list. There has been some discussion of this issue on the cabal and ghc-users list, but it's a relatively long thread and the idea has evolved somewhat so this is an attempt to present the proposal clearly. Proposal ======== This proposal is an extension to the Cabal spec section 3 http://haskell.org/cabal/proposal/x272.html Motivation ---------- Being able to have relative paths in the installed package description is useful as it makes it possible to construct relocatable (prefix-independent) package installations. This is useful when distributing compilers along with packages and there may be other uses. This proposal does not require that all paths are relative. It is still perfectly ok to use absolute paths where appropriate. It just adds an option to use relative paths. The aim is for a single simple specification that any compiler can implement and have the tools work uniformly, rather than ad-hoc implementations for each compiler. Details ------- In the installed package description, we will allow paths that begin with the variables ${pkgroot} or ${pkgrooturl}. For example: library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 They may only appear at the beginning of the paths and must be followed by a directory separator (platform-dependent '/' or '\'). This is because the vars refer to a directory so it does not make sense to construct extensions like ${pkgroot}blah. The use of '{}' is required and is to avoid any ambiguity (especially since the string "$pkgrooturl" is otherwise an extension of "$pkgroot"). Directly relative file paths like "blah" or "./blah" are not allowed. Fields containing paths must be absolute or begin with ${pkgroot}. Field containing urls must be absolute or begin with ${pkgrooturl}. The var ${pkgroot} is to be interpreted as the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is the usual system-dependent filepath syntax, e.g. windows: c:\ghc\ghc-6.12.1 unix: /opt/ghc-6.12.1 The var ${pkgrooturl} is to be interpreted as a url representation of the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is as a valid file url including the file:// prefix e.g. windows: file:///c:/ghc/ghc-6.12.1 unix: file:///opt/ghc-6.12.1 This is similar to how relative paths in .cabal files are interpreted relative to the directory containing the .cabal file, however in this case we mark relative paths more explicitly using a variable. So in the original example library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 If we assume this installed package description is at c:\ghc\ghc-6.12.1 \package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then the compiler and other tools would interpret these as library-dirs: c:\ghc\ghc-6.12.1/foo-1.0 haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0 or on unix: library-dirs: /opt/ghc-6.12.1/foo-1.0 haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0 Tools ----- Tools which process the installed package description format will be expected to interpret these relative paths. This requires that they can discover the path for the ${pkgroot}. How they discover this is dependent on the Haskell implementation. Some implementations use separate files for each installed package description, some embed them in library package files, some use databases of installed package descriptions. Haskell implementations should provide a mechanism to discover the path for an installed package description. Duncan From jvlask at hotmail.com Fri May 29 10:19:27 2009 From: jvlask at hotmail.com (John Lask) Date: Fri May 29 10:05:59 2009 Subject: ghc - force library search order Message-ID: ----- Original Message ----- From: "Duncan Coutts" To: "John Lask" Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order > On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >> I need to force a library to be searched for unresolved symbols after all >> other libraries have been searched, and I would rather not resort to >> constructing the linker command line directly. Is there a way to do this? >> >> i.e. I want for example -lfoo to appear after all other haskell libraries >> and before system libraries (for example -lmsvcrt) once ghc has >> constructed >> the link command. i.e. how is it possible to coerce ghc into respecting >> dependencies between the libraries. GHC does a good job in general with >> native libraries, but there are allways corner cases. >> >> I have a feeling this is not possible, but it dosn't hurt to ask. > > If you don't get a reply then ask on the ghc users mailing list. > > Duncan > > From ndmitchell at gmail.com Sat May 30 07:50:44 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 30 07:34:53 2009 Subject: mtl and network packages in GHC 6.10.3.* In-Reply-To: <90889fe70905271350u732261b4u9f2be37c08e23dd1@mail.gmail.com> References: <404396ef0905261833v6c42d5b8p9c72fffb275ae37f@mail.gmail.com> <90889fe70905271253k3c431a1x91efc50968822405@mail.gmail.com> <90889fe70905271350u732261b4u9f2be37c08e23dd1@mail.gmail.com> Message-ID: <404396ef0905300450s485e25b8h5716a0d08242be6b@mail.gmail.com> Works perfectly, thanks a lot Johan! Neil On Wed, May 27, 2009 at 9:50 PM, Johan Tibell wrote: > On Wed, May 27, 2009 at 9:53 PM, Johan Tibell > wrote: >> >> On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell >> wrote: >>> >>> In addition, I can't install network under Cygwin, Mingw, or the >>> Windows command line. Here are the errors from Cygwin: >> >> I've filed a bug: http://trac.haskell.org/network/ticket/14 >> >> In the meantime try 2.2.1.1 > > The latest HEAD from darcs works fine for me on Windows XP. > > Cheers, > > Johan > > > From marcot at holoscopio.com Sun May 31 15:20:57 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sun May 31 15:06:00 2009 Subject: Problem with profiling Message-ID: <1243797657.27787.36.camel@zezinho> Hello, recently there was a thread about a problem in profiling in gtk2hs-users, and it was menitoned that this could be a GHC6 bug. The problem is described in http://sourceforge.net/mailarchive/forum.php?thread_name=1242762143.18742.277.camel%40zezinho&forum_name=gtk2hs-users . Do you think this is a gtk2hs specific problem, or is it something about GHC? Greetings. -- marcot http://marcot.iaaeee.org/