From donn at avvanta.com Sun Jun 1 04:24:12 2008 From: donn at avvanta.com (Donn Cave) Date: Sun Jun 1 04:16:24 2008 Subject: *BSD support in 6.8.3 In-Reply-To: References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> Message-ID: <20080601012412.96f63620.donn@avvanta.com> On Fri, 30 May 2008 10:43:22 -0400 Gregory Wright wrote: > > http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch > > > > *BSD folks please test. > > > > I built the 20080529 snapshot with this patch and my light testing of > ghci > showed no problems (FreeBSD 7.0/x86_64). 20080531 and NetBSD-amd64 4.0, not so good: GHCi, version 6.8.2.20080531: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Bad system call (core dumped) SIGSYS appears to happen in select(), is all I could get out of gdb. Prior to the patch, it was the usual error. Otherwise, 20080531 seems to work as well as 6.8.2 release on NetBSD-amd64. NetBSD defines ELF64_ST_TYPE and ELF64_ST_BIND. Unfortunately, it won't build with the GNU "ar" that's standard on this platform. It can't index archives as big as libHSbase.a: apparently, it allocates too many moderately large hash tables for the many small modules in that archive, and runs out of memory. I worked around this by reducing the default hash table size in libbfd.so. I'm not saying any of this makes sense, it's just what I eventually managed to get working. Otherwise, it builds smoothly. -- Donn Cave From igloo at earth.li Sun Jun 1 06:52:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 1 06:45:23 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080529180852.GA22228@gmx.de> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080529180852.GA22228@gmx.de> Message-ID: <20080601105236.GA18410@matrix.chaos.earth.li> On Thu, May 29, 2008 at 08:08:52PM +0200, Marc Weber wrote: > > Please test as much as possible; bugs are much cheaper if we find them > > before the release! > Hi Ian, > > I haven't done extensive testing, but at least you can start ghci and > compile simple hello world apps on nixos 64 bit without trouble. Great, thanks Marc! > I've noted that I had to use a more recent ghc for bootstrapping than > ghc-6.4. Thanks for the report; building with GHC 6.4 should work now. Thanks Ian From mechvel at botik.ru Sun Jun 1 09:39:49 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jun 1 09:32:28 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601001306.GA11868@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> Message-ID: <20080601133949.GA1135@scico.botik.ru> On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote: > > Hi Serge, > > On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: > > This is a bug report for the ghc candidate of May 27, 2008 > > for ghc-6.8.3. > > A short program example for this bug candidate is on > > > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip > > Thanks, I've finally tracked this down. The problem is that when you > evaluate something like > f ^ 10 > in 6.8.2 the result was > res > while in 6.8.3 it is > 1 * res > > I think this is actually a bug in your class instances, but I will try > to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 > which should, as a side-effect, make it work again. ?? Probably, 6.8.3 is wrong. Because when res :: Num a => a, 1*res means ((fromInteger 1) :: a) * res in Haskell-98. Right? And (fromInteger n) :: a can be defined arbitrarily by the programmer. For example, DoCon has the instance instance CommutativeRing a => Num (Pol a) where ... fromInteger _ = error "No (fromInteger n) :: Pol _ !\ \Apply instead fromi n." -- something of this kind. This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a. Am I missing something? ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Sun Jun 1 10:34:00 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 1 10:26:46 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601133949.GA1135@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> Message-ID: <20080601143400.GA8637@matrix.chaos.earth.li> On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: > > This is why res and 1*res are not equivalent in Haskell-98 for > res :: Num a => a. > > Am I missing something? The library functions assume that class instances obey some unwritten laws; it's all a bit vague, but if your instances don't obey them then you might find that things go wrong when using library functions. For example, if your (*) isn't associative then (^) is going to give odd results, and if the type of the second argument to (^) doesn't do arithmetic in the normal way then very strange things could happen. Anyway, I've just tweaked the (^) definition again, so your code should work in 6.8.3. Thanks Ian From mechvel at botik.ru Sun Jun 1 13:34:06 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jun 1 13:26:48 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601143400.GA8637@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> <20080601143400.GA8637@matrix.chaos.earth.li> Message-ID: <20080601173406.GA1297@scico.botik.ru> On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote: > On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: > > > > This is why res and 1*res are not equivalent in Haskell-98 for > > res :: Num a => a. > > > > Am I missing something? > > The library functions assume that class instances obey some unwritten > laws; it's all a bit vague, but if your instances don't obey them then > you might find that things go wrong when using library functions. For > example, if your (*) isn't associative then (^) is going to give odd > results, and if the type of the second argument to (^) doesn't do > arithmetic in the normal way then very strange things could happen. > > Anyway, I've just tweaked the (^) definition again, so your code should > work in 6.8.3. Thank you. This helps -- in that the public DoCon-2.11 test will run (I hope). But I think that you have found a bug in the DoCon test program. Thank you. More precisely, here are my indeas. 1. Generally, for t = Num a => a, the expessions res :: t and ((fromInteger 1) :: t) * res are not equivalent in Haskell-98, and the compiler has not rigth to replace the former with the latter. Right? 2. But I guess, our current questions are different: (2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t right to base on certain natural properties of the operation fromInteger :: Integer -> t ? (2.2) Has a reliable mathematical application right to base on that for n > 0 the expression (f^n) :: Polynomial Integer does not imply computing fromInteger 1 :: Polynomial Integer ? Concerning (2.1): I do not know whether Haskell-98 allows to rely on that f^3 is equivalent to (fromInteger 1)*(f^3). But concerning (2.2), I think that (independently of the question (2.1)) a reliable mathematical application must not presume the above properties of (^) and fromInteger. Concerning f^3 :: UPol Integer in my test for DoCon: 1) fromInteger _ :: UPol _ is defined as error "... use fromi instead". 2) (*) is defined via polMul ... 3) The expression f ^ 3 relies on the Haskell-98 library for (^). The Haskell library defines (^) via (*) -- all right. 4) DoCon has the function `power' to use instead of (^), and its library avoids (^). But for n > 0, I considered f^n :: UPol _ as also correct. Because the Haskell library performs this via repeated application of (*). And I thought that if n > 0, then (fromInteger _ :: UPol _) will not appear. Maybe it does not appear in old GHC-s and does appear 6.8.3 ? I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] in my _test programs_ for DoCon. But this relies on a particular property of the Haskell library definition for (f^n) :: a -- on that if n > 0 then (fromInteger _ :: a) does not appear in this computation. Now, I think, either I need to hide the standard (^) and overload it or to replace (^) with `power' in my examples too. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Sun Jun 1 14:05:11 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jun 1 13:57:47 2008 Subject: test for 6.8.3-may27 Message-ID: <20080601180511.GA1338@scico.botik.ru> About the 6.8.3 candidate of May 27, there remains the question: why it builds DoCon-2.11 considerably slower than ghc-6.8.2 (3 times, as I recall) and needs larger -M memory to build this DoCon ? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From lennart at augustsson.net Sun Jun 1 14:50:22 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jun 1 14:43:07 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601173406.GA1297@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> <20080601143400.GA8637@matrix.chaos.earth.li> <20080601173406.GA1297@scico.botik.ru> Message-ID: There are no rules written down. But the fast exponentiation algorithm used by (^) assumes that (*) is associative. I also don't think that fast exponentiation should ever multiply by 1. -- Lennart On Sun, Jun 1, 2008 at 6:34 PM, Serge D. Mechveliani wrote: > On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote: >> On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: >> > >> > This is why res and 1*res are not equivalent in Haskell-98 for >> > res :: Num a => a. >> > >> > Am I missing something? >> >> The library functions assume that class instances obey some unwritten >> laws; it's all a bit vague, but if your instances don't obey them then >> you might find that things go wrong when using library functions. For >> example, if your (*) isn't associative then (^) is going to give odd >> results, and if the type of the second argument to (^) doesn't do >> arithmetic in the normal way then very strange things could happen. >> >> Anyway, I've just tweaked the (^) definition again, so your code should >> work in 6.8.3. > > > Thank you. > This helps -- in that the public DoCon-2.11 test will run (I hope). > > But I think that you have found a bug in the DoCon test program. > Thank you. > More precisely, here are my indeas. > > > 1. Generally, for t = Num a => a, the expessions res :: t and > ((fromInteger 1) :: t) * res > are not equivalent in Haskell-98, > and the compiler has not rigth to replace the former with the latter. > Right? > > 2. But I guess, our current questions are different: > > (2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t > right to base on certain natural properties of the operation > fromInteger :: Integer -> t ? > (2.2) Has a reliable mathematical application right to base on that > for n > 0 the expression (f^n) :: Polynomial Integer > does not imply computing fromInteger 1 :: Polynomial Integer > ? > > Concerning (2.1): I do not know whether Haskell-98 allows to rely on > that f^3 is equivalent to (fromInteger 1)*(f^3). > > But concerning (2.2), I think that (independently of the question (2.1)) > a reliable mathematical application must not presume the above properties > of (^) and fromInteger. > > Concerning f^3 :: UPol Integer in my test for DoCon: > > 1) fromInteger _ :: UPol _ is defined as > error "... use fromi instead". > 2) (*) is defined via polMul ... > 3) The expression f ^ 3 relies on the Haskell-98 library for (^). > The Haskell library defines (^) via (*) -- all right. > > 4) DoCon has the function `power' to use instead of (^), > and its library avoids (^). > But for n > 0, I considered f^n :: UPol _ > as also correct. Because the Haskell library performs this via repeated > application of (*). > And I thought that if n > 0, then (fromInteger _ :: UPol _) will not > appear. > Maybe it does not appear in old GHC-s and does appear 6.8.3 ? > > I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] > in my _test programs_ for DoCon. > But this relies on a particular property of the Haskell library definition > for (f^n) :: a > -- on that if n > 0 then (fromInteger _ :: a) does not appear in this > computation. > > Now, I think, either I need to hide the standard (^) and overload it > or to replace (^) with `power' in my examples too. > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From christian.hoener at uni-bielefeld.de Sun Jun 1 15:55:06 2008 From: christian.hoener at uni-bielefeld.de (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Sun Jun 1 15:47:52 2008 Subject: GHC 6.8.2 and large source files Message-ID: <20080601195506.GB8274@workstation> Dear Haskell users, we have an automated system that generates executable haskell source files. These files have a line count from 1,000 lines up to 28,000 lines. There is only 1 type definition and 5 functions in total in the file. We now can compile into executable code some of these programs but the compiler requires an incredible amount of memory: the 15,000 line programs easily require 2 GByte of RAM and then the compiler dies. Are there hints on how to compile large source files? Would it help, for example to compile each function on its own? On the following webpage you can find a handcrafted program, albeit with very few lines, that shows how one of our source files would look like: http://bibiserv.techfak.uni-bielefeld.de/cgi-bin/adp_MatrixMult We automatically generate type, algebras and the grammar for our application. Thanks, Christian H?ner zu Siederdissen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080601/7e7f4a7a/attachment.bin From dons at galois.com Sun Jun 1 16:46:43 2008 From: dons at galois.com (Don Stewart) Date: Sun Jun 1 16:39:53 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601133949.GA1135@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> Message-ID: <20080601204643.GC4759@scytale.galois.com> Hello Serge, I was looking at the cabal file used to build docon, I note the current flags are: ghc-options: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -O +RTS -M400m -RTS Do you gain any performance benefit using: -O2 -fvia-C -optc-O2 I'm wondering. Also, would you be interested in releasing the cabal bundle for docon on hackage.haskell.org , so it can be easily installed by others? -- Don mechvel: > On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote: > > > > Hi Serge, > > > > On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: > > > This is a bug report for the ghc candidate of May 27, 2008 > > > for ghc-6.8.3. > > > A short program example for this bug candidate is on > > > > > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip > > > > Thanks, I've finally tracked this down. The problem is that when you > > evaluate something like > > f ^ 10 > > in 6.8.2 the result was > > res > > while in 6.8.3 it is > > 1 * res > > > > I think this is actually a bug in your class instances, but I will try > > to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 > > which should, as a side-effect, make it work again. > > ?? > Probably, 6.8.3 is wrong. > Because when res :: Num a => a, 1*res means > ((fromInteger 1) :: a) * res > in Haskell-98. Right? > And (fromInteger n) :: a can be defined arbitrarily by the programmer. > For example, DoCon has the instance > instance CommutativeRing a => Num (Pol a) > where > ... > fromInteger _ = error "No (fromInteger n) :: Pol _ !\ > \Apply instead fromi n." > -- something of this kind. > This is why res and 1*res are not equivalent in Haskell-98 for > res :: Num a => a. > > Am I missing something? > > ----------------- > Serge Mechveliani > mechvel@botik.ru > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From gwright at comcast.net Sun Jun 1 22:08:03 2008 From: gwright at comcast.net (Gregory Wright) Date: Sun Jun 1 22:01:05 2008 Subject: *BSD support in 6.8.3 In-Reply-To: References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> Message-ID: <70023940-7722-4955-8E6F-C63848E44960@comcast.net> Hi, > On May 29, 2008, at 11:19 AM, Simon Marlow wrote: > >> Ok, I've now modified the patch and attached a new version to the >> ticket: >> >> http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch >> >> *BSD folks please test. >> > > I built the 20080529 snapshot with this patch and my light testing > of ghci > showed no problems (FreeBSD 7.0/x86_64). > > I will built it again tonight in a darcs checkout and run the test > suite. I should > be able to send back any tweaks to the patch in the next two days. > > -Greg I've built ghc 6.8.x from the darcs repository (checked out on 30 May) with the 2013.patch on FreeBSD 7.0/x86_64. As far as ghci is concerned, it seems to work and passes almost all of the tests. However, there are many unexpected failures in the testsuite, almost all apparently coming from failures to find mkstemp, mknod and S_IFDIR in header files. Either some conditional includes are broken in ghc or FreeBSD 7.0 moved some things. I'll have a look tomorrow. -Greg From mechvel at botik.ru Mon Jun 2 02:59:45 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Jun 2 02:52:30 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601204643.GC4759@scytale.galois.com> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> <20080601204643.GC4759@scytale.galois.com> Message-ID: <20080602065945.GA2641@scico.botik.ru> On Sun, Jun 01, 2008 at 01:46:43PM -0700, Don Stewart wrote: > Hello Serge, > > I was looking at the cabal file used to build docon, > I note the current flags are: > > ghc-options: > -fglasgow-exts -fallow-overlapping-instances > -fallow-undecidable-instances > -fno-warn-overlapping-patterns -fwarn-unused-binds > -fwarn-unused-matches -fwarn-unused-imports > -O > +RTS -M400m -RTS > > Do you gain any performance benefit using: > > -O2 -fvia-C -optc-O2 > > I'm wondering. I tried -O2 -fvia-C -optc-O2, together with making the very test (demotest/Main) under -O. In ghc-6.8.2 this does not gain anything in DoCon in comparison to -O, it makes things worse: * the speed of running the test preserves, * making the DoCon library becomes 4 times slower, * the library code becomes 10% larger, * making the test module becomes ? times slower, Concerning the speed of running the test, maybe -O2 does not help because DoCon uses Integer everywhere instead of Int, I do not know. I do not apply -O2 in making the test because this takes too much of time (hours, more than 50 times more than -Onot), and also because this would not increase perforamance, because all the time consuming inner loops are in the library, not in the test. > Also, would you be interested in releasing the cabal bundle for docon on > hackage.haskell.org , so it can be easily installed by others? Could you explain me, why currently DoCon is not easy to install? I thought, install.txt provides a short instruction which is easy to follow. What is difficult there, what could be improved? What is a cabal bundle? DoCon has the file docon.cabal. Is not this a cabal bundle? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From simonpj at microsoft.com Mon Jun 2 03:50:18 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 2 03:43:02 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080601173406.GA1297@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> <20080601001306.GA11868@matrix.chaos.earth.li> <20080601133949.GA1135@scico.botik.ru> <20080601143400.GA8637@matrix.chaos.earth.li> <20080601173406.GA1297@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE58CEF93@EA-EXMSG-C334.europe.corp.microsoft.com> Interesting * I think it is a Bad Idea for an application to assume that the implementation of (f^n) will not multiply by 1. Implementations of numeric algorithms probably make all sorts of ill-documented assumptions about the algebraic properties of numeric operations * On the other hand, it's a bit stupid for the implementation of (f^n) to multiply by 1, and Ian has, I think, already fixed this. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 01 June 2008 18:34 | To: Ian Lynagh | Cc: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 6.8.3 Release Candidate | | On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote: | > On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: | > > | > > This is why res and 1*res are not equivalent in Haskell-98 for | > > res :: Num a => a. | > > | > > Am I missing something? | > | > The library functions assume that class instances obey some unwritten | > laws; it's all a bit vague, but if your instances don't obey them then | > you might find that things go wrong when using library functions. For | > example, if your (*) isn't associative then (^) is going to give odd | > results, and if the type of the second argument to (^) doesn't do | > arithmetic in the normal way then very strange things could happen. | > | > Anyway, I've just tweaked the (^) definition again, so your code should | > work in 6.8.3. | | | Thank you. | This helps -- in that the public DoCon-2.11 test will run (I hope). | | But I think that you have found a bug in the DoCon test program. | Thank you. | More precisely, here are my indeas. | | | 1. Generally, for t = Num a => a, the expessions res :: t and | ((fromInteger 1) :: t) * res | are not equivalent in Haskell-98, | and the compiler has not rigth to replace the former with the latter. | Right? | | 2. But I guess, our current questions are different: | | (2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t | right to base on certain natural properties of the operation | fromInteger :: Integer -> t ? | (2.2) Has a reliable mathematical application right to base on that | for n > 0 the expression (f^n) :: Polynomial Integer | does not imply computing fromInteger 1 :: Polynomial Integer | ? | | Concerning (2.1): I do not know whether Haskell-98 allows to rely on | that f^3 is equivalent to (fromInteger 1)*(f^3). | | But concerning (2.2), I think that (independently of the question (2.1)) | a reliable mathematical application must not presume the above properties | of (^) and fromInteger. | | Concerning f^3 :: UPol Integer in my test for DoCon: | | 1) fromInteger _ :: UPol _ is defined as | error "... use fromi instead". | 2) (*) is defined via polMul ... | 3) The expression f ^ 3 relies on the Haskell-98 library for (^). | The Haskell library defines (^) via (*) -- all right. | | 4) DoCon has the function `power' to use instead of (^), | and its library avoids (^). | But for n > 0, I considered f^n :: UPol _ | as also correct. Because the Haskell library performs this via repeated | application of (*). | And I thought that if n > 0, then (fromInteger _ :: UPol _) will not | appear. | Maybe it does not appear in old GHC-s and does appear 6.8.3 ? | | I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] | in my _test programs_ for DoCon. | But this relies on a particular property of the Haskell library definition | for (f^n) :: a | -- on that if n > 0 then (fromInteger _ :: a) does not appear in this | computation. | | Now, I think, either I need to hide the standard (^) and overload it | or to replace (^) with `power' in my examples too. | | Regards, | | ----------------- | Serge Mechveliani | mechvel@botik.ru | | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Mon Jun 2 04:36:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 2 04:29:28 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <20080601012412.96f63620.donn@avvanta.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> Message-ID: <4843B119.50704@gmail.com> Donn Cave wrote: > On Fri, 30 May 2008 10:43:22 -0400 > Gregory Wright wrote: > >>> http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch >>> >>> *BSD folks please test. >>> >> I built the 20080529 snapshot with this patch and my light testing of >> ghci >> showed no problems (FreeBSD 7.0/x86_64). > > 20080531 and NetBSD-amd64 4.0, not so good: > > GHCi, version 6.8.2.20080531: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Bad system call (core dumped) > > SIGSYS appears to happen in select(), is all I could get out of gdb. Prior > to the patch, it was the usual error. I guess the error in the linker was masking the SIGSYS in select(), because it occurred first. So now we need to figure out what is causing this SIGSYS. > Otherwise, 20080531 seems to work as well as 6.8.2 release on NetBSD-amd64. > NetBSD defines ELF64_ST_TYPE and ELF64_ST_BIND. > > Unfortunately, it won't build with the GNU "ar" that's standard on this > platform. It can't index archives as big as libHSbase.a: apparently, it > allocates too many moderately large hash tables for the many small modules > in that archive, and runs out of memory. I worked around this by reducing > the default hash table size in libbfd.so. I'm not saying any of this makes > sense, it's just what I eventually managed to get working. Otherwise, it > builds smoothly. Perhaps turning off -split-objs would also work around this problem? Cheers, Simon From marlowsd at gmail.com Mon Jun 2 04:37:33 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 2 04:30:19 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <70023940-7722-4955-8E6F-C63848E44960@comcast.net> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <70023940-7722-4955-8E6F-C63848E44960@comcast.net> Message-ID: <4843B14D.6010504@gmail.com> Gregory Wright wrote: > Hi, >> On May 29, 2008, at 11:19 AM, Simon Marlow wrote: >> >>> Ok, I've now modified the patch and attached a new version to the >>> ticket: >>> >>> http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch >>> >>> *BSD folks please test. >>> >> >> I built the 20080529 snapshot with this patch and my light testing of >> ghci >> showed no problems (FreeBSD 7.0/x86_64). >> >> I will built it again tonight in a darcs checkout and run the test >> suite. I should >> be able to send back any tweaks to the patch in the next two days. >> >> -Greg > > > I've built ghc 6.8.x from the darcs repository (checked out on 30 May) > with the > 2013.patch on FreeBSD 7.0/x86_64. As far as ghci is concerned, it seems > to work and passes almost all of the tests. However, there are many > unexpected > failures in the testsuite, almost all apparently coming from failures to > find mkstemp, mknod > and S_IFDIR in header files. Either some conditional includes are > broken in ghc or FreeBSD 7.0 moved some things. I'll have a look tomorrow. Great, thanks for the feedback Greg. I'll push this patch. Cheers, Simon From isaacdupree at charter.net Mon Jun 2 10:37:54 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 2 10:30:34 2008 Subject: impredicative polymorphism: seen on HCAR Message-ID: <484405C2.8020901@charter.net> The May 2008 Haskell Communities and Activities Report, GHC : > Impredicative polymorphism. We are not happy with GHC?s current > implementation of impredicative polymorphism, which is rather > complicated and ad hoc. Dimitrios (with Simon and Stephanie) > wrote a paper about a new and better approach: > http://research.microsoft.com/~simonpj/papers/boxy > . At the same time, Daan Leijen has been working on his > closely-related design: > http://research.microsoft.com/users/daan/pubs.html > . Daan?s design has a much simpler implementation, in exchange > for an (arguably) less-predictable specification. Which of these > two should we implement? Let us know! I read the papers... Dimitrios's *paper* is easier for me to understand than Daan's. In fact they seem quite similar. I have no idea of any examples where they would behave differently. I don't use impredicative polymorphism much (but maybe because of my perception that the existing implementations are poorly designed, and that it can usually be avoided by an amount of abstraction that's useful anyway). So I'd say, implement the easier solution. Is there a paper or documentation somewhere, presenting a practical argument for why impredicative polymorphism is important in real programs (beyond runST $) -- for example, a real program that uses it and has clearer code because of it? I don't really mind writing let/function type-signatures that have weird types (unless they're long and repeat information that doesn't need to be, which is a different problem). I wonder how often these proposals require type-signatures on lambdas passed to higher-order functions, though... A side-effect is for those of us who want to have any concern for future compatibility with non-GHC type systems (or the long future of GHC's, even), whether one of the proposals would be likely to be easier for someone else to implement in a different compiler. -Isaac From isaacdupree at charter.net Mon Jun 2 10:42:41 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 2 10:35:22 2008 Subject: impredicative polymorphism: seen on HCAR In-Reply-To: <484405C2.8020901@charter.net> References: <484405C2.8020901@charter.net> Message-ID: <484406E1.10204@charter.net> I wrote: > A side-effect is for those of us who want to have any concern for future > compatibility with non-GHC type systems (or the long future of GHC's, > even), whether one of the proposals would be likely to be easier for > someone else to implement in a different compiler. actually, just as important is the ability of the GHC implementation to turn on and off (-XImpredicativeTypes?) so that we can use GHC to make sure our programs don't go beyond, e.g., Rank2Types if we don't want them to. -Isaac From isaacdupree at charter.net Mon Jun 2 10:45:31 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 2 10:38:11 2008 Subject: [Haskell-cafe] Default definitions for associated type synonyms In-Reply-To: <52f14b210805300710k366731d6w340231d6eef3ef19@mail.gmail.com> References: <52f14b210805300710k366731d6w340231d6eef3ef19@mail.gmail.com> Message-ID: <4844078B.1010201@charter.net> Dreixel wrote: > Hello, > > Does anyone know if it is possible to specify a default definition for an > associated type synonym? When I tried: > > class A a where >> type B a = a >> > > GHC (version 6.9.20080309) told me: "Type declaration in a class must be a > kind signature or synonym default". However, when I look at the parser I see > no way to specify such synonym default. Is this possible? I'm curious... so, cc'ing glasgow-haskell-users mailinglist because the question is more likely to be noticed by relevant people there. > Thanks, > Z? Pedro From stefan at cs.uu.nl Mon Jun 2 10:50:00 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Mon Jun 2 10:42:47 2008 Subject: [Haskell-cafe] Default definitions for associated type synonyms In-Reply-To: <4844078B.1010201@charter.net> References: <52f14b210805300710k366731d6w340231d6eef3ef19@mail.gmail.com> <4844078B.1010201@charter.net> Message-ID: <9AAEC7D1-A1C3-4124-B2B0-E1F9F3E4675D@cs.uu.nl> Isaac, >> Does anyone know if it is possible to specify a default definition >> for an >> associated type synonym? According to http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus defaults for associated types is still a TODO. Cheers, Stefan From igloo at earth.li Mon Jun 2 10:52:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 2 10:45:19 2008 Subject: GHC 6.8.2 and large source files In-Reply-To: <20080601195506.GB8274@workstation> References: <20080601195506.GB8274@workstation> Message-ID: <20080602145236.GA6418@matrix.chaos.earth.li> Hi Christian, On Sun, Jun 01, 2008 at 09:55:06PM +0200, Christian H?ner zu Siederdissen wrote: > > We now can compile into executable code some of these programs but the > compiler requires an incredible amount of memory: the 15,000 line > programs easily require 2 GByte of RAM and then the compiler dies. We've been looking into similar problems recently, and hopefully GHC 6.10 will do better. > Are there hints on how to compile large source files? Would it help, for > example to compile each function on its own? Yes, I expect so, although the sweet spot probably has several functions per module. Thanks Ian From donn at avvanta.com Mon Jun 2 11:31:14 2008 From: donn at avvanta.com (Donn Cave) Date: Mon Jun 2 11:23:18 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <4843B119.50704@gmail.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> Message-ID: <20080602083114.e9fbfada.donn@avvanta.com> On Mon, 02 Jun 2008 09:36:41 +0100 Simon Marlow wrote: > > Unfortunately, it won't build with the GNU "ar" that's standard on this > > platform. It can't index archives as big as libHSbase.a: apparently, it > > allocates too many moderately large hash tables for the many small modules > > in that archive, and runs out of memory. I worked around this by reducing > > the default hash table size in libbfd.so. I'm not saying any of this makes > > sense, it's just what I eventually managed to get working. Otherwise, it > > builds smoothly. > > Perhaps turning off -split-objs would also work around this problem? Yes, so the NetBSD package maintainer suggested, after I wrote to him about this. He expressed some interest in getting the amd64 build into the package system, as there have been requests (currently supports only the i386 platform), so I'm going to pursue that. -- Donn Cave From donn at avvanta.com Tue Jun 3 16:31:16 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Jun 3 16:23:09 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <4843B119.50704@gmail.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> Message-ID: <20080603133116.ed212f2e.donn@avvanta.com> On Mon, 02 Jun 2008 09:36:41 +0100 Simon Marlow wrote: > Donn Cave wrote: ... > > 20080531 and NetBSD-amd64 4.0, not so good: > > > > GHCi, version 6.8.2.20080531: http://www.haskell.org/ghc/ :? for help > > Loading package base ... linking ... done. > > Bad system call (core dumped) > > > > SIGSYS appears to happen in select(), is all I could get out of gdb. Prior > > to the patch, it was the usual error. > > I guess the error in the linker was masking the SIGSYS in select(), because > it occurred first. So now we need to figure out what is causing this SIGSYS. Well, good news and bad news. The patch works - this was indeed a different problem, and with that out of the way ghci comes up and works well enough to pass some randomly selected tests from a testsuite - ghci, rts. This is 20080531 plus patch 2013. The SIGSYS problem is an awkward issue between GHC and NetBSD, which I see has already been reported, #2305. C code compiled from /usr/include/signal.h links to __sigprocmask14, but libraries/base/System/Posix/Internals.hs links to sigprocmask because it misses out on the __RENAME magic in signal.h. That's a compatibility function that doesn't work out so well for ghci. I will take this up with the NetBSD ghc package maintainer. At worst, we can just hard-code the (incompatibility?) function names. thanks, -- Donn Cave From chak at cse.unsw.edu.au Wed Jun 4 00:52:41 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jun 4 00:45:21 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate - MacOS X (Intel/Leopard) installer, updated! In-Reply-To: <0238D121-16AB-4009-B426-A53A81B12484@cse.unsw.edu.au> References: <20080528152033.GA6188@matrix.chaos.earth.li> <0238D121-16AB-4009-B426-A53A81B12484@cse.unsw.edu.au> Message-ID: <051A8819-DC11-432E-AB88-279494477AF0@cse.unsw.edu.au> Here is an updated release candidate for the MacOS X installer for Intel/Leopard: http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080604-i386.pkg It includes readline support statically linked. Unless we receive any bug reports, these are basically the bits you'll get for the 6.8.3 release. So, please test it thoroughly. Manuel PS: I am not very hopeful about having a 10.4 (Tiger) version of the installer for 6.8.3. I am currently missing a method to identify the symbols in an executable that lead to the "bus error" (invariably at _calloc_initialize) that signals an attempt to execute a Leopard binary on Tiger. If any Mac guru here knows how to identify these symbols, let me know. (I know about DYLD_PRINT_BINDINGS and friends, but that didn't help me so far.) Alternatively, grab -my currently best effort at cross-compiling for 10.4- and tell me why it won't run on Tiger. Manuel M T Chakravarty: > A Mac installer version of the release candidate for Intel/Leopard > Macs is at > > http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg > > This version of GHC includes neither editline nor readline at the > moment (this will be fixed for the final release). It also only > works for Leopard (MacOS X 10.5) as I haven't managed to get cross > compiling for older OS versions fully functional yet. > > In any case, please test this if you have an Intel/Leopard Mac and > are interested in a one-click installer with no dependencies other > than a recent version of Xcode. > > The packages comes with an uninstall script located at > > /Library/Frameworks/GHC.framework/Tools/Uninstaller > > It will overwrite other 6.8.x versions of GHC installed from an > installer package, but peacefully coexist with other distributions > of 6.8 and with GHC versions other than 6.8 independent of how they > were installed. > > Manuel > >> >> We are pleased to announce the Release Candidate phase for GHC 6.8.3. >> >> Snapshots beginning with 6.8.2.20080527 are release candidates >> for 6.8.3 >> >> You can download snapshots from here: >> >> http://www.haskell.org/ghc/dist/stable/dist/ >> >> Right now we have the source bundles: >> >> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 >> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2 >> >> >> Only the first of these is necessary. The "extralibs" package >> contains >> various extra packages that are often supplied with GHC - unpack the >> extralibs tarball on top of the source tree to add them, and they >> will >> be included in the build automatically. >> >> There is also currently an installer for i386/Windows and binary >> distributions for x86_64/Linux and i386/Linux. More may appear later. >> >> Please test as much as possible; bugs are much cheaper if we find >> them >> before the release! >> >> We expect to release in a few days, assuming no major issues are >> discovered. >> >> >> Thanks >> Ian, on behalf of the GHC team >> >> _______________________________________________ >> 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 bos at serpentine.com Wed Jun 4 16:29:27 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Jun 4 16:22:38 2008 Subject: Having trouble with parallel Haskell Message-ID: <4846FB27.1010105@serpentine.com> I intended to write a half chapter or so about parallel programming in Haskell for the book I'm working on, but I've been coming to the conclusion that the time is not yet ripe for this. I hope it will be helpful if I share my experiences here. Specifically, I was planning to write about parallel programming in pure code: use of "par" and programming with strategies. The most substantial problem is that the threaded RTS in GHC 6.8.2 is very crashy in the face of "par": about 90% of my runs fail with a segfault or an assertion failure. Simon Marlow mentioned that this bug is fixed, but I've been unsuccessful in building a GHC 6.8.3 release candidate snapshot so far, so I can't verify this. When a run does go through, I have found it surprisingly difficult to actually get both cores of a dual-core system to show activity. As there are no tools I can use to see what is happening, I am stumped. It is of course quite likely that I am doing something wrong that results in unexpected dependencies, but I cannot find a means to gaining insight into the problem. As an example, I have a simple parallel quicksort that is very conservative in its sparking, and I get no joy out of it on a dual-core machine: it mostly sticks to a single core. This wouldn't be a problem if I had some way to spot the presumed data dependency that is serialising the code, but no joy. [a] -> [a] sort (x:xs) = lesser ++ x:greater where lesser = sort [y | y <- xs, y < x] greater = sort [y | y <- xs, y >= x] sort _ = [] parSort :: (NFData a, Ord a) => Int -> [a] -> [a] parSort d list@(x:xs) | d <= 0 = sort list | otherwise = rnf lesser `par` (rnf greater `pseq` lesser ++ x:greater) where lesser = parSort d' [y | y <- xs, y < x] greater = parSort d' [y | y <- xs, y >= x] d' = d - 1 parSort _ _ = [] main = do args <- getArgs let count | null args = 8192 | otherwise = read (head args) input :: [Int] <- (take count . randoms) `fmap` getStdGen putStrLn $ "We have " ++ show (length input) ++ " elements to sort." start <- getCurrentTime let sorted = parSort 2 input putStrLn $ "Sorted all " ++ show (length sorted) ++ " elements." end <- getCurrentTime putStrLn $ show (end `diffUTCTime` start) ++ " elapsed." From isaacdupree at charter.net Wed Jun 4 18:06:25 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jun 4 17:58:59 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <4846FB27.1010105@serpentine.com> References: <4846FB27.1010105@serpentine.com> Message-ID: <484711E1.2060800@charter.net> Bryan O'Sullivan wrote: > | otherwise = rnf lesser `par` (rnf greater `pseq` > lesser ++ x:greater) It seems that `pseq` doesn't have a defined precedence, so it's infixl 9, unlike `seq` and `par` which are infixr 0. Therefore the above is equivalent to | otherwise = rnf lesser `par` ((rnf greater `pseq` lesser) ++ x:greater) (no idea if that's relevant, though) -Isaac From trebla at vex.net Wed Jun 4 18:08:04 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed Jun 4 18:00:39 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <4846FB27.1010105@serpentine.com> References: <4846FB27.1010105@serpentine.com> Message-ID: <48471244.8040204@vex.net> I do not have a platform to try it on; the following is pure speculation. In main, the builder of input is highly lazy, since randoms is. To be sure, the spine of the list is presently forced by printing its length, but the numbers inside the list... It is very bleak because randoms ensures that input!!(n+1) is patently dependent on input!!n, ad infinitum; this should defy all attempts at parallelism... Forcing the numbers themselves before sorting will give a much more conclusive result, success or failure. From dons at galois.com Wed Jun 4 18:22:38 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 4 18:15:16 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <48471244.8040204@vex.net> References: <4846FB27.1010105@serpentine.com> <48471244.8040204@vex.net> Message-ID: <20080604222238.GA20092@scytale.galois.com> trebla: > I do not have a platform to try it on; the following is pure speculation. > > In main, the builder of input is highly lazy, since randoms is. To be > sure, the spine of the list is presently forced by printing its length, > but the numbers inside the list... It is very bleak because randoms > ensures that input!!(n+1) is patently dependent on input!!n, ad > infinitum; this should defy all attempts at parallelism... > > Forcing the numbers themselves before sorting will give a much more > conclusive result, success or failure. I wonder if a fast, strict randoms generator (like mersenne-pure64) would help then. -- Don From bos at serpentine.com Wed Jun 4 20:51:51 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Jun 4 20:45:01 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <484711E1.2060800@charter.net> References: <4846FB27.1010105@serpentine.com> <484711E1.2060800@charter.net> Message-ID: <484738A7.2010705@serpentine.com> Isaac Dupree wrote: > (no idea if that's relevant, though) I can't tell either. It doesn't seem to make a difference, at any rate. By the way, I notice that the threaded RTS blocks signals for long periods of time when I run this program. If I hit control-C, it takes several seconds for the program to notice. References: <4846FB27.1010105@serpentine.com> <48471244.8040204@vex.net> Message-ID: <48473AEE.4090403@serpentine.com> Albert Y. C. Lai wrote: > In main, the builder of input is highly lazy, since randoms is. To be > sure, the spine of the list is presently forced by printing its length, > but the numbers inside the list... It is very bleak because randoms > ensures that input!!(n+1) is patently dependent on input!!n, ad > infinitum; this should defy all attempts at parallelism... Hmm. I forced the elements of the list with rnf, and it didn't really make a difference. I now get perhaps 115% CPU usage during a sort. That is a small improvement in parallelism, but it also causes the program to take about 15% longer to run :-) References: <20080601195506.GB8274@workstation> Message-ID: <20080605010659.GA9207@workstation> Dear Haskell users, please see ticket 2346 for example code. Note that two of the files will likely require all available memory upon compilation. Christian H?ner zu Siederdissen * Christian H?ner zu Siederdissen [01.01.1970 00:59]: > Dear Haskell users, > > we have an automated system that generates executable haskell source > files. These files have a line count from 1,000 lines up to 28,000 > lines. There is only 1 type definition and 5 functions in total in the > file. > > We now can compile into executable code some of these programs but the > compiler requires an incredible amount of memory: the 15,000 line > programs easily require 2 GByte of RAM and then the compiler dies. > > Are there hints on how to compile large source files? Would it help, for > example to compile each function on its own? > > On the following webpage you can find a handcrafted program, albeit with > very few lines, that shows how one of our source files would look like: > http://bibiserv.techfak.uni-bielefeld.de/cgi-bin/adp_MatrixMult > > We automatically generate type, algebras and the grammar for our > application. > > Thanks, > Christian H?ner zu Siederdissen > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080605/7e0f3f5c/attachment.bin From donn at avvanta.com Wed Jun 4 21:10:55 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Jun 4 21:02:43 2008 Subject: -fvia-C for libHSbase, etc.? Message-ID: <20080604181055.d84dcfb1.donn@avvanta.com> I'm building GHC on NetBSD-amd64, and among other things need to deal with the problem described in #2305 - native code misses the __RENAME (__asm) directive in NetBSD include files, and ends up linking to the wrong externals. The author of #2305 reports that -fvia-C avoids this problem, so I built the ghc 5/31 distribution I've been working on, with GhcLibHcOpts=-O -Rghc-timing -fgenerics -fvia-C (i.e., add -fvia-C compile option for library build.) Does that seem like a reasonable solution? It does seem to work, but I'm wondering if there are issues we can expect with performance etc.? thanks, -- Donn Cave From marlowsd at gmail.com Thu Jun 5 04:49:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 5 04:42:03 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <20080603133116.ed212f2e.donn@avvanta.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> <20080603133116.ed212f2e.donn@avvanta.com> Message-ID: <4847A892.3040203@gmail.com> Donn Cave wrote: > On Mon, 02 Jun 2008 09:36:41 +0100 > Simon Marlow wrote: > >> Donn Cave wrote: > ... >>> 20080531 and NetBSD-amd64 4.0, not so good: >>> >>> GHCi, version 6.8.2.20080531: http://www.haskell.org/ghc/ :? for help >>> Loading package base ... linking ... done. >>> Bad system call (core dumped) >>> >>> SIGSYS appears to happen in select(), is all I could get out of gdb. Prior >>> to the patch, it was the usual error. >> I guess the error in the linker was masking the SIGSYS in select(), because >> it occurred first. So now we need to figure out what is causing this SIGSYS. > > Well, good news and bad news. The patch works - this was indeed > a different problem, and with that out of the way ghci comes up > and works well enough to pass some randomly selected tests from a > testsuite - ghci, rts. This is 20080531 plus patch 2013. > > The SIGSYS problem is an awkward issue between GHC and NetBSD, > which I see has already been reported, #2305. C code compiled > from /usr/include/signal.h links to __sigprocmask14, but > libraries/base/System/Posix/Internals.hs links to sigprocmask > because it misses out on the __RENAME magic in signal.h. That's > a compatibility function that doesn't work out so well for ghci. > I will take this up with the NetBSD ghc package maintainer. At > worst, we can just hard-code the (incompatibility?) function names. See my update to #2305 - it looks like we need a C wrapper for sigprocmask() in the base package. Would you like to make a ticket for this, or better still a patch (it's not too hard, there are plenty of other examples of this in base already)? Cheers, Simon From marlowsd at gmail.com Thu Jun 5 05:44:15 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 5 05:36:56 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <4846FB27.1010105@serpentine.com> References: <4846FB27.1010105@serpentine.com> Message-ID: <4847B56F.3010606@gmail.com> Bryan O'Sullivan wrote: > I intended to write a half chapter or so about parallel programming in > Haskell for the book I'm working on, but I've been coming to the > conclusion that the time is not yet ripe for this. I hope it will be > helpful if I share my experiences here. > > Specifically, I was planning to write about parallel programming in pure > code: use of "par" and programming with strategies. > > The most substantial problem is that the threaded RTS in GHC 6.8.2 is > very crashy in the face of "par": about 90% of my runs fail with a > segfault or an assertion failure. Simon Marlow mentioned that this bug > is fixed, but I've been unsuccessful in building a GHC 6.8.3 release > candidate snapshot so far, so I can't verify this. > > When a run does go through, I have found it surprisingly difficult to > actually get both cores of a dual-core system to show activity. As > there are no tools I can use to see what is happening, I am stumped. It > is of course quite likely that I am doing something wrong that results > in unexpected dependencies, but I cannot find a means to gaining insight > into the problem. > > As an example, I have a simple parallel quicksort that is very > conservative in its sparking, and I get no joy out of it on a dual-core > machine: it mostly sticks to a single core. This wouldn't be a problem > if I had some way to spot the presumed data dependency that is > serialising the code, but no joy. I don't have a great deal of time to look at this right now, but I had a bit more luck with this version: parSort :: (NFData a, Ord a) => Int -> [a] -> [a] parSort d list@(x:xs) | d <= 0 = sort list | otherwise = rnf below `pseq` ( rnf above `pseq` ( rnf lesser `par` ( rnf greater `pseq` ( (lesser ++ x:greater))))) where below = [y | y <- xs, y < x] above = [y | y <- xs, y >= x] lesser = parSort d' below greater = parSort d' above d' = d - 1 parSort _ _ = [] I imagine the problem is mainly to do with nested pars: in the original code, the left-hand par evaluates immediately into another par, and so on: there's no actual *work* being done in each spark. Which is why I tried to do some evaluation before each par above. It still doesn't achieve much speedup though. Incedentally, this kind of recursive parallelism is typically much harder to get any benefit from than, for example, a simple top-level parMap. If you're just trying to introduce parallelism, it might be worthwhile sticking to the easy cases: simple strategies, and speeding up concurrent programs. Also you might notice that the GC is doing a lot of work in this example (first port of call is always +RTS -sstderr). I tried the parallel GC, but it didn't help at all, I guess because the heap is full of lists and the parallel GC likes trees. The biggest problem, as you note, is the lack of tools for investigating parallel performance. This is high on our priority list, we have a couple of projects planned over the summer to improve the situation. Cheers, Simon From marlowsd at gmail.com Thu Jun 5 05:47:45 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 5 05:40:23 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <484738A7.2010705@serpentine.com> References: <4846FB27.1010105@serpentine.com> <484711E1.2060800@charter.net> <484738A7.2010705@serpentine.com> Message-ID: <4847B641.9090509@gmail.com> Bryan O'Sullivan wrote: > Isaac Dupree wrote: > >> (no idea if that's relevant, though) > > I can't tell either. It doesn't seem to make a difference, at any rate. > > By the way, I notice that the threaded RTS blocks signals for long > periods of time when I run this program. If I hit control-C, it takes > several seconds for the program to notice. This is usually a symptom of a program that does a lot of allocation-less computation (or also, long GCs). When the program isn't allocating, the scheduler never runs, and ^C doesn't get serviced. Allocation-less computation will also hurt parallelism, because the load-balancing only happens when the scheduler runs. This often crops up when people try to parallelism small benchmarks (e.g. fib). It's certainly a problem, and we don't have a good solution yet. Cheers, Simon From marlowsd at gmail.com Thu Jun 5 05:50:42 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 5 05:43:19 2008 Subject: -fvia-C for libHSbase, etc.? In-Reply-To: <20080604181055.d84dcfb1.donn@avvanta.com> References: <20080604181055.d84dcfb1.donn@avvanta.com> Message-ID: <4847B6F2.3010607@gmail.com> Donn Cave wrote: > I'm building GHC on NetBSD-amd64, and among other things > need to deal with the problem described in #2305 - native > code misses the __RENAME (__asm) directive in NetBSD include > files, and ends up linking to the wrong externals. The > author of #2305 reports that -fvia-C avoids this problem, so > I built the ghc 5/31 distribution I've been working on, with > > GhcLibHcOpts=-O -Rghc-timing -fgenerics -fvia-C > > (i.e., add -fvia-C compile option for library build.) > > Does that seem like a reasonable solution? It does seem to > work, but I'm wondering if there are issues we can expect > with performance etc.? The right fix is to add a C wrapper for the offending function (see my other message, and reply to #2305). Cheers, Simon From waldmann at imn.htwk-leipzig.de Thu Jun 5 05:56:02 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Jun 5 05:48:32 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <4847B56F.3010606@gmail.com> References: <4846FB27.1010105@serpentine.com> <4847B56F.3010606@gmail.com> Message-ID: <4847B832.80309@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a "metoo": a nicely working "Parallel Haskell" would be a very strong selling point, and I'm especially thinking of education here. If I could show to my students that just by inserting a few 'par' (or similar) annotations in the source they can easily and fully exploit multi-core hardware, then they sure would take that course on Declarative Programming... Best regards, Johannes Waldmann. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhHuDIACgkQDqiTJ5Q4dm+mzACgxO7eYQf5ejogjJGv9Qp7oAlL eykAoLRa81xVju2rx5Q0bCu8L95pQiMD =cWEA -----END PGP SIGNATURE----- From simonpj at microsoft.com Thu Jun 5 06:56:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 5 06:48:38 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <4847B56F.3010606@gmail.com> References: <4846FB27.1010105@serpentine.com> <4847B56F.3010606@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA014@EA-EXMSG-C334.europe.corp.microsoft.com> | > The most substantial problem is that the threaded RTS in GHC 6.8.2 is | > very crashy in the face of "par": about 90% of my runs fail with a | > segfault or an assertion failure. Simon Marlow mentioned that this bug | > is fixed, but I've been unsuccessful in building a GHC 6.8.3 release | > candidate snapshot so far, so I can't verify this. There's a 6.8.3 release candidate you might be able to try. GHC shouldn't crash, ever. So everyone, do please file bug reports with test cases for parallel programs that crash. (But probably not for 6.8.2!) Simon From Christian.Maeder at dfki.de Thu Jun 5 09:13:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jun 5 09:06:25 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate - MacOS X (Intel/Leopard) distribution In-Reply-To: <051A8819-DC11-432E-AB88-279494477AF0@cse.unsw.edu.au> References: <20080528152033.GA6188@matrix.chaos.earth.li> <0238D121-16AB-4009-B426-A53A81B12484@cse.unsw.edu.au> <051A8819-DC11-432E-AB88-279494477AF0@cse.unsw.edu.au> Message-ID: <4847E68F.7060309@dfki.de> For those without root rights I've made a plain distribution that relies on gmp and readline under /opt/local/ (for 9.3.0 Darwin Kernel) http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-6.8.2.20080603-i386-apple-darwin.tar.bz2 Christian Manuel M T Chakravarty wrote: > Here is an updated release candidate for the MacOS X installer for > Intel/Leopard: > > http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080604-i386.pkg > > It includes readline support statically linked. Unless we receive any > bug reports, these are basically the bits you'll get for the 6.8.3 > release. So, please test it thoroughly. > > Manuel From donnie at darthik.com Wed Jun 4 22:57:47 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Jun 5 10:52:42 2008 Subject: Having trouble with parallel Haskell In-Reply-To: References: <4846FB27.1010105@serpentine.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: ParSort-post.parprof.ps Type: application/postscript Size: 2613617 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080604/265aecbf/ParSort-post.parprof-0001.ps From bos at serpentine.com Thu Jun 5 11:44:14 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jun 5 11:37:24 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA014@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4846FB27.1010105@serpentine.com> <4847B56F.3010606@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA014@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <484809CE.5090802@serpentine.com> Simon Peyton-Jones wrote: > There's a 6.8.3 release candidate you might be able to try. Yes, I reported a bug and Simon mentioned that it ought to be fixed already. I've been trying to build snapshots for about a week :-) References: <4846FB27.1010105@serpentine.com> <4847B56F.3010606@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA014@EA-EXMSG-C334.europe.corp.microsoft.com> <484809CE.5090802@serpentine.com> Message-ID: <48480AD8.5090005@gmail.com> Bryan O'Sullivan wrote: > Simon Peyton-Jones wrote: > >> There's a 6.8.3 release candidate you might be able to try. > > Yes, I reported a bug and Simon mentioned that it ought to be fixed > already. I've been trying to build snapshots for about a week :-) And we appreciate the bug reports. Is it just the Haddock 2 problem you're having now? Cheers, Simon From bos at serpentine.com Thu Jun 5 11:55:53 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jun 5 11:49:03 2008 Subject: Having trouble with parallel Haskell In-Reply-To: <48480AD8.5090005@gmail.com> References: <4846FB27.1010105@serpentine.com> <4847B56F.3010606@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA014@EA-EXMSG-C334.europe.corp.microsoft.com> <484809CE.5090802@serpentine.com> <48480AD8.5090005@gmail.com> Message-ID: <48480C89.4070400@serpentine.com> Simon Marlow wrote: > Is it just the Haddock 2 problem > you're having now? I switched back to Haddock 0.8, and found a new problem at installation time: http://hackage.haskell.org/trac/ghc/ticket/2343 This is a change in behaviour from 6.8.2, and I'm not really sure what to do about it. I've attached a log of the 'make install' on advice from Igloo. I get the following when trying to building from source with the documentation install enabled: #Hacks: /usr/bin/install -c -m 644 base/dist/doc/html/*/*.css /usr/local/share/doc/ghc/libraries /usr/bin/install: cannot stat `base/dist/doc/html/*/*.css': No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/cody/Desktop/ghc-6.9.20080603/libraries' make: *** [install] Error 2 However, if I comment out lines 386 -394 in the libraries makefile, it all installs perfectly. But then I get this runtime error every time I use any GHC file: ghc-6.9.20080603: panic! (the 'impossible' happened) (GHC version 6.9.20080603 for i386-unknown-linux): interactiveUI:setBuffering2 _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080605/142bfe0a/attachment.htm From donn at avvanta.com Thu Jun 5 12:23:36 2008 From: donn at avvanta.com (Donn Cave) Date: Thu Jun 5 12:15:19 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <4847A892.3040203@gmail.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> <20080603133116.ed212f2e.donn@avvanta.com> <4847A892.3040203@gmail.com> Message-ID: <20080605092336.e389dca3.donn@avvanta.com> On Thu, 05 Jun 2008 09:49:22 +0100 Simon Marlow wrote: > See my update to #2305 - it looks like we need a C wrapper for > sigprocmask() in the base package. Would you like to make a ticket for > this, or better still a patch (it's not too hard, there are plenty of other > examples of this in base already)? OK. I can find 7 of these renamed externals, in base, network and unix, out of 88 in NetBSD 4.0. This will obviously need to be revisited occasionally, but I will be happy to make a patch. Unified context diff OK? It looks like, in base anyway, this actually goes in a .h file, to a pattern like INLINE int __hscore_xyz( ... ) { return xyz( ... ); } thanks, -- Donn Cave From bulat.ziganshin at gmail.com Thu Jun 5 13:24:29 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jun 5 13:23:18 2008 Subject: automatically deriving Functor Re[2]: [Haskell-cafe] automatically deriving Map and Filter on datatypes etc. In-Reply-To: <404396ef0806050954i5a9d6b1cw2cde7d6091650048@mail.gmail.com> References: <1ff5dedc0806050103h1639d907r7ac731de016787bc@mail.gmail.com> <0D31F43A-4404-40EA-8628-45A033FB6493@yandex.ru> <2638D507-4427-4A04-96E5-C8208F3F0D2F@gmail.com> <28B5EEBB-7843-436D-9CFC-A01EEFDF1E9A@fastmail.fm> <404396ef0806050954i5a9d6b1cw2cde7d6091650048@mail.gmail.com> Message-ID: <1099732191.20080605212429@gmail.com> Hello Neil, Thursday, June 5, 2008, 8:54:51 PM, you wrote: >> PS Why isn't Functor derivable? > Derive can do it: http://www.cs.york.ac.uk/~ndm/derive > I believe that Twan (the author of Functor deriving in Derive) is > trying to get this suggested for Haskell' as a proper deriving. dear GHC developers, may be it's a good idea to add such facility to ghc? [as one more H98 extension] -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From donn at avvanta.com Thu Jun 5 13:55:42 2008 From: donn at avvanta.com (Donn Cave) Date: Thu Jun 5 13:47:26 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <20080605092336.e389dca3.donn@avvanta.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> <20080603133116.ed212f2e.donn@avvanta.com> <4847A892.3040203@gmail.com> <20080605092336.e389dca3.donn@avvanta.com> Message-ID: <20080605105542.8f22174b.donn@avvanta.com> On Thu, 5 Jun 2008 09:23:36 -0700 Donn Cave wrote: > ... It looks like, in base anyway, this actually goes in a .h file, > to a pattern like ... ah, never mind that, I see those wrappers are not the sort I need. -- Donn Cave From richardg at richardg.name Thu Jun 5 17:46:22 2008 From: richardg at richardg.name (Richard Giraud) Date: Thu Jun 5 17:38:56 2008 Subject: Mutually recursive modules Message-ID: <48485EAE.2030307@richardg.name> Hello I've been doing some work with mutually recursive modules (MRMs). I'm familiar with the section in the User's Guide on how to do this and have successfully worked with MRMs with simple dependencies. However, I have created a set of MRMs that I can't seem to get to compile because of type issues. I can get the code to compile by combining all of the modules into a single, monolithic module; however, this breaks the conceptual design that I'm going for. I may also be able to break the modules into smaller pieces that will compile, though I'm not sure about this and it, too, would break the conceptual design. Does the current {-# SOURCE #-}/.hs-boot scheme allow for compilation of arbitrary MRMs? Or are there known cases where it doesn't work? If there are cases where it doesn't work, are there other options? Someone in Haskell Cafe mentioned that GHC 6.2 used a different scheme for MRMs (.hi-boot). Is it still possible to use this? Would it allow for compilation of arbitrary MRMs? I can create a minimal case as an example, if it would be useful. Thanks, Richard From aslatter at gmail.com Thu Jun 5 17:56:39 2008 From: aslatter at gmail.com (Antoine Latter) Date: Thu Jun 5 17:49:11 2008 Subject: Mutually recursive modules In-Reply-To: <48485EAE.2030307@richardg.name> References: <48485EAE.2030307@richardg.name> Message-ID: <694519c50806051456v721103gddf66d5c78f988fb@mail.gmail.com> On Thu, Jun 5, 2008 at 4:46 PM, Richard Giraud wrote: > > Does the current {-# SOURCE #-}/.hs-boot scheme allow for compilation of > arbitrary MRMs? Or are there known cases where it doesn't work? If there > are cases where it doesn't work, are there other options? > I don't think the .hs-boot method can deal with having a set of mutually recursive types split by module boundaries. If all you want to do is keep your API clean, you can stick all of your types in one monolithic module that isn't exposed by the package, and then re-export them in public modules. -Antoine From isaacdupree at charter.net Thu Jun 5 19:15:29 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jun 5 19:08:06 2008 Subject: Mutually recursive modules In-Reply-To: <694519c50806051456v721103gddf66d5c78f988fb@mail.gmail.com> References: <48485EAE.2030307@richardg.name> <694519c50806051456v721103gddf66d5c78f988fb@mail.gmail.com> Message-ID: <48487391.1020506@charter.net> Antoine Latter wrote: > On Thu, Jun 5, 2008 at 4:46 PM, Richard Giraud wrote: >> Does the current {-# SOURCE #-}/.hs-boot scheme allow for compilation of >> arbitrary MRMs? Or are there known cases where it doesn't work? If there >> are cases where it doesn't work, are there other options? >> > > I don't think the .hs-boot method can deal with having a set of > mutually recursive types split by module boundaries. sometimes it can, I think > If all you want to do is keep your API clean, you can stick all of > your types in one monolithic module that isn't exposed by the package, > and then re-export them in public modules. Yeah, remember that you only have to put (some of) your types together -- you can spread out your functions in your modules any way you want. -Isaac From simonpj at microsoft.com Fri Jun 6 03:49:39 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 6 03:42:11 2008 Subject: Mutually recursive modules In-Reply-To: <48485EAE.2030307@richardg.name> References: <48485EAE.2030307@richardg.name> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE59BA4BD@EA-EXMSG-C334.europe.corp.microsoft.com> Richard I'm assuming you have ready the GHC manual? http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion Yes, mutually recursive modules are fine (in GHC anyway), and should work as advertised there. Please do produce a test case if not. Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Richard Giraud | Sent: 05 June 2008 22:46 | To: GHC Users Mailing List | Subject: Mutually recursive modules | | Hello | | I've been doing some work with mutually recursive modules (MRMs). I'm | familiar with the section in the User's Guide on how to do this and have | successfully worked with MRMs with simple dependencies. However, I have | created a set of MRMs that I can't seem to get to compile because of | type issues. | | I can get the code to compile by combining all of the modules into a | single, monolithic module; however, this breaks the conceptual design | that I'm going for. I may also be able to break the modules into | smaller pieces that will compile, though I'm not sure about this and it, | too, would break the conceptual design. | | Does the current {-# SOURCE #-}/.hs-boot scheme allow for compilation of | arbitrary MRMs? Or are there known cases where it doesn't work? If | there are cases where it doesn't work, are there other options? | | Someone in Haskell Cafe mentioned that GHC 6.2 used a different scheme | for MRMs (.hi-boot). Is it still possible to use this? Would it allow | for compilation of arbitrary MRMs? | | I can create a minimal case as an example, if it would be useful. | | Thanks, | | Richard | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From conal at conal.net Fri Jun 6 20:08:40 2008 From: conal at conal.net (Conal Elliott) Date: Fri Jun 6 20:01:11 2008 Subject: desperately seeking RULES help Message-ID: I'm trying to do some fusion in ghc, and I'd greatly appreciate help with the code below (which is simplified from fusion on linear maps). I've tried every variation I can think of, and always something prevents the fusion. Help, please! Thanks, - Conal {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-} -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} module F where -- | Domain of a linear map. class AsInt a where toInt :: a -> Int fromInt :: Int -> a {-# RULES "toInt/fromInt" forall m. toInt (fromInt m) = m #-} {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f = fromInt . f . toInt test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g -- The desired result: -- -- test h g -- == onInt h . onInt g -- == (fromInt . h . toInt) . (fromInt . g . toInt) -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) -- == \ a -> fromInt (h (g (toInt a))) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080606/17501eb9/attachment.htm From dominic.steinitz at blueyonder.co.uk Sat Jun 7 04:04:57 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jun 7 03:56:34 2008 Subject: Building ndp Problem In-Reply-To: <066B8FEE-5784-42B4-98AC-225F2852D812@cse.unsw.edu.au> References: <48393583.2070201@blueyonder.co.uk> <066B8FEE-5784-42B4-98AC-225F2852D812@cse.unsw.edu.au> Message-ID: <484A4129.9050902@blueyonder.co.uk> Manuel M T Chakravarty wrote: > Dominic Steinitz: >> I wanted to try out data parallel haskell. I followed the instructions >> on http://haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP but I >> get the following error: >> >>> dom@lagrange:~/ghc/libraries> make make.library.ndp >>> make: *** No rule to make target `build.library.ndp', needed by >>> `make.library.ndp'. Stop. > > The ndp libraries are currently undergoing a fundamental restructure. > We'll update the instructions once matters settle down. Sorry for the > inconvenience. > > Manuel > > > Manuel, I think I have things working now but the "make" system seems to have problems. I followed the instructions here: http://www.haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP but got the messages below. On the other hand this worked: ghc --make -o dotp dotp.hs -package ndp -i../lib -threaded and then running dom@lagrange:~/ghc/libraries/ndp/examples/dotp> ./dotp 100000 --threads=1 --runs=10 +RTS -N1 N = 100000: 125/124 126/126 129/132 dom@lagrange:~/ghc/libraries/ndp/examples/dotp> ./dotp 100000 --threads=2 --runs=10 +RTS -N2 N = 100000: 80/116 86/142 96/156 which seemed to indicate I was getting a performance improvement on my dual core machine. Would you like me to raise a ticket? Dominic. dom@lagrange:~/ghc/libraries/ndp/examples> make Makefile:14: warning: overriding commands for target `bench' mk/test.mk:28: warning: ignoring old commands for target `bench' Makefile:17: warning: overriding commands for target `clean' mk/test.mk:10: warning: ignoring old commands for target `clean' make -C lib make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' for i in concomp dotp primes smvm qsort barneshut primespj ; do \ make -C $i ; \ done make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/concomp' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: *** No rule to make target `Graph.hi', needed by `mkg.o'. Stop. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/concomp' make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/dotp' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/dotp' make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/primes' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: *** No rule to make target `H98.hi', needed by `primes.o'. Stop. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/primes' make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/smvm' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: *** No rule to make target `SMVMPar.hi', needed by `smvm.o'. Stop. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/smvm' make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/qsort' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: *** No rule to make target `QSortPar.hi', needed by `QSort.o'. Stop. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/qsort' make: *** barneshut: No such file or directory. Stop. make[1]: Entering directory `/home/dom/ghc/libraries/ndp/examples/primespj' cd ../lib && make make[2]: Entering directory `/home/dom/ghc/libraries/ndp/examples/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/lib' make[1]: *** No rule to make target `PrimesVect.hi', needed by `PrimesPJ.o'. Stop. make[1]: Leaving directory `/home/dom/ghc/libraries/ndp/examples/primespj' make: *** [all] Error 2 From johan.tibell at gmail.com Sat Jun 7 06:37:17 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Jun 7 06:29:49 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: <90889fe70806070337i38040937i62fae42409f80a4b@mail.gmail.com> 2008/6/7 Conal Elliott : > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > the code below (which is simplified from fusion on linear maps). I've tried > every variation I can think of, and always something prevents the fusion. > > [snip] > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f = fromInt . f . toInt I don't know if this will help but add this to prevent GHC from inlining the definition of fromInt (or toInt) in the first phase: {-# NOINLINE [1] fromInt #-} {-# INLINE [2] fromInt #-} It might be possible to combine the both into one pragma but I don't know how. -- Johan From lennart at augustsson.net Sat Jun 7 07:10:44 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Jun 7 07:03:15 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: Interesting. The problem seems to be that GHC always inlines toInt and fromInt early, but this means that the rewrite rule no longer applies. And, of course, it doesn't inline toInt and fromInt in the rewrite rule. I have no idea if you can write a rule that will actually work, because after toInt and fromInt have been inlined you can no longer write rules that apply, since the types involve dictionaries and the terms pattern match on dictionaries. -- Lennart 2008/6/7 Conal Elliott : > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > the code below (which is simplified from fusion on linear maps). I've tried > every variation I can think of, and always something prevents the fusion. > > Help, please! Thanks, - Conal > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-} > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt :: a -> Int > fromInt :: Int -> a > > {-# RULES > "toInt/fromInt" forall m. toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f = fromInt . f . toInt > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > -- The desired result: > -- > -- test h g > -- == onInt h . onInt g > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > -- == \ a -> fromInt (h (g (toInt a))) > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From lennart at augustsson.net Sat Jun 7 08:07:29 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Jun 7 07:59:59 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: Here's something that actually works. You need to pass -fno-method-sharing on the command line. Instead of using rules on methods it uses rules on global functions, and these global functions don't get inlined until late (after the rule has fired). -- Lennart module F where -- | Domain of a linear map. class AsInt a where toInt' :: a -> Int fromInt' :: Int -> a {-# INLINE[1] toInt #-} toInt :: (AsInt a) => a -> Int toInt = toInt' {-# INLINE[1] fromInt #-} fromInt :: (AsInt a) => Int -> a fromInt = fromInt' {-# RULES "toInt/fromInt" forall m . toInt (fromInt m) = m #-} {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f x = fromInt (f (toInt x)) test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g 2008/6/7 Conal Elliott : > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > the code below (which is simplified from fusion on linear maps). I've tried > every variation I can think of, and always something prevents the fusion. > > Help, please! Thanks, - Conal > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-} > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt :: a -> Int > fromInt :: Int -> a > > {-# RULES > "toInt/fromInt" forall m. toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f = fromInt . f . toInt > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > -- The desired result: > -- > -- test h g > -- == onInt h . onInt g > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > -- == \ a -> fromInt (h (g (toInt a))) > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From marlowsd at gmail.com Sat Jun 7 00:14:02 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Jun 7 08:06:33 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <20080605105542.8f22174b.donn@avvanta.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> <20080603133116.ed212f2e.donn@avvanta.com> <4847A892.3040203@gmail.com> <20080605092336.e389dca3.donn@avvanta.com> <20080605105542.8f22174b.donn@avvanta.com> Message-ID: <484A0B0A.7050401@gmail.com> Donn Cave wrote: > On Thu, 5 Jun 2008 09:23:36 -0700 > Donn Cave wrote: > >> ... It looks like, in base anyway, this actually goes in a .h file, >> to a pattern like > > ... ah, never mind that, I see those wrappers are not the sort I need. Yes, those are the kind of wrappers I mean. For example, base has a wrapper for lseek() (__hsccore_lseek()) for exactly the same reason. Cheers, Simon From conal at conal.net Sat Jun 7 12:23:48 2008 From: conal at conal.net (Conal Elliott) Date: Sat Jun 7 12:16:15 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: Thanks a million, Lennart! -fno-method-sharing was the missing piece. - Conal On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson wrote: > Here's something that actually works. You need to pass > -fno-method-sharing on the command line. > Instead of using rules on methods it uses rules on global functions, > and these global functions don't get inlined until late (after the > rule has fired). > > -- Lennart > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt' :: a -> Int > fromInt' :: Int -> a > > {-# INLINE[1] toInt #-} > toInt :: (AsInt a) => a -> Int > toInt = toInt' > > {-# INLINE[1] fromInt #-} > fromInt :: (AsInt a) => Int -> a > fromInt = fromInt' > > {-# RULES > "toInt/fromInt" forall m . toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f x = fromInt (f (toInt x)) > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > > > 2008/6/7 Conal Elliott : > > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > > the code below (which is simplified from fusion on linear maps). I've > tried > > every variation I can think of, and always something prevents the fusion. > > > > Help, please! Thanks, - Conal > > > > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats > #-} > > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > > > module F where > > > > -- | Domain of a linear map. > > class AsInt a where > > toInt :: a -> Int > > fromInt :: Int -> a > > > > {-# RULES > > "toInt/fromInt" forall m. toInt (fromInt m) = m > > #-} > > > > {-# INLINE onInt #-} > > onInt :: AsInt a => (Int -> Int) -> (a -> a) > > onInt f = fromInt . f . toInt > > > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > > test h g = onInt h . onInt g > > > > -- The desired result: > > -- > > -- test h g > > -- == onInt h . onInt g > > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > > -- == \ a -> fromInt (h (g (toInt a))) > > > > > > > > _______________________________________________ > > 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/20080607/88dfae2e/attachment.htm From conal at conal.net Sat Jun 7 12:25:34 2008 From: conal at conal.net (Conal Elliott) Date: Sat Jun 7 12:18:01 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: Is it by intention that -fno-method-sharing works only from the command line, not in an OPTIONS_GHC pragma? On Sat, Jun 7, 2008 at 9:23 AM, Conal Elliott wrote: > Thanks a million, Lennart! -fno-method-sharing was the missing piece. - > Conal > > > On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson > wrote: > >> Here's something that actually works. You need to pass >> -fno-method-sharing on the command line. >> Instead of using rules on methods it uses rules on global functions, >> and these global functions don't get inlined until late (after the >> rule has fired). >> >> -- Lennart >> >> module F where >> >> -- | Domain of a linear map. >> class AsInt a where >> toInt' :: a -> Int >> fromInt' :: Int -> a >> >> {-# INLINE[1] toInt #-} >> toInt :: (AsInt a) => a -> Int >> toInt = toInt' >> >> {-# INLINE[1] fromInt #-} >> fromInt :: (AsInt a) => Int -> a >> fromInt = fromInt' >> >> {-# RULES >> "toInt/fromInt" forall m . toInt (fromInt m) = m >> #-} >> >> {-# INLINE onInt #-} >> onInt :: AsInt a => (Int -> Int) -> (a -> a) >> onInt f x = fromInt (f (toInt x)) >> >> test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >> test h g = onInt h . onInt g >> >> >> >> 2008/6/7 Conal Elliott : >> > I'm trying to do some fusion in ghc, and I'd greatly appreciate help >> with >> > the code below (which is simplified from fusion on linear maps). I've >> tried >> > every variation I can think of, and always something prevents the >> fusion. >> > >> > Help, please! Thanks, - Conal >> > >> > >> > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats >> #-} >> > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} >> > >> > module F where >> > >> > -- | Domain of a linear map. >> > class AsInt a where >> > toInt :: a -> Int >> > fromInt :: Int -> a >> > >> > {-# RULES >> > "toInt/fromInt" forall m. toInt (fromInt m) = m >> > #-} >> > >> > {-# INLINE onInt #-} >> > onInt :: AsInt a => (Int -> Int) -> (a -> a) >> > onInt f = fromInt . f . toInt >> > >> > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >> > test h g = onInt h . onInt g >> > >> > -- The desired result: >> > -- >> > -- test h g >> > -- == onInt h . onInt g >> > -- == (fromInt . h . toInt) . (fromInt . g . toInt) >> > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) >> > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) >> > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) >> > -- == \ a -> fromInt (h (g (toInt a))) >> > >> > >> > >> > _______________________________________________ >> > 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/20080607/a57a86f7/attachment.htm From donn at avvanta.com Sat Jun 7 13:09:57 2008 From: donn at avvanta.com (Donn Cave) Date: Sat Jun 7 13:01:28 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <484A0B0A.7050401@gmail.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> <20080601012412.96f63620.donn@avvanta.com> <4843B119.50704@gmail.com> <20080603133116.ed212f2e.donn@avvanta.com> <4847A892.3040203@gmail.com> <20080605092336.e389dca3.donn@avvanta.com> <20080605105542.8f22174b.donn@avvanta.com> <484A0B0A.7050401@gmail.com> Message-ID: <20080607100957.53652dce.donn@avvanta.com> On Sat, 07 Jun 2008 05:14:02 +0100 Simon Marlow wrote: > Donn Cave wrote: > > On Thu, 5 Jun 2008 09:23:36 -0700 > > Donn Cave wrote: > > > >> ... It looks like, in base anyway, this actually goes in a .h file, > >> to a pattern like > > > > ... ah, never mind that, I see those wrappers are not the sort I need. > > Yes, those are the kind of wrappers I mean. For example, base has a > wrapper for lseek() (__hsccore_lseek()) for exactly the same reason. Thanks, I submitted one of those yesterday (unsetenv, where the type of the function has changed in POSIX.1 from the older spec that GHC follows.) I've done the rest of them too, but since this is a general platform issue, I wanted to get some input from the NetBSD package maintainer, who is interested in the issue but I believe is off at some conference. Other renamed functions, in NetBSD 4.0, are sigprocmask, opendir, socket, times, sigpending, and sigsuspend. -- Donn Cave From simonpj at microsoft.com Mon Jun 9 05:38:50 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 9 05:31:14 2008 Subject: desperately seeking RULES help In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> The -fno-method-sharing flag was supposed to be a bit experimental, which is why it takes the cheap-and-cheerful route of being a static flag. (Only dynamic flags can go in OPTIONS_GHC.) What it does is this. When you call an overloaded function f :: C a => a -> a, in a function g = ...f...f... you normally get something like this fint :: Int -> Int fint = f Int dCInt g = ...fint...fint... That is, 'fint' extracts the 'f' method from dCInt::C Int, and it's then used repeatedly. With -fno-method-sharing you get g = ...(f Int dCInt) ... (f Int dCInt)... So the record selection is duplicated. It shouldn't make much difference, but of course it *does* when rules are involved, because there are no rules for fint (it's a fresh, local function). Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 07 June 2008 17:26 To: glasgow-haskell-users@haskell.org Subject: Re: desperately seeking RULES help Is it by intention that -fno-method-sharing works only from the command line, not in an OPTIONS_GHC pragma? On Sat, Jun 7, 2008 at 9:23 AM, Conal Elliott > wrote: Thanks a million, Lennart! -fno-method-sharing was the missing piece. - Conal On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson > wrote: Here's something that actually works. You need to pass -fno-method-sharing on the command line. Instead of using rules on methods it uses rules on global functions, and these global functions don't get inlined until late (after the rule has fired). -- Lennart module F where -- | Domain of a linear map. class AsInt a where toInt' :: a -> Int fromInt' :: Int -> a {-# INLINE[1] toInt #-} toInt :: (AsInt a) => a -> Int toInt = toInt' {-# INLINE[1] fromInt #-} fromInt :: (AsInt a) => Int -> a fromInt = fromInt' {-# RULES "toInt/fromInt" forall m . toInt (fromInt m) = m #-} {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f x = fromInt (f (toInt x)) test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g 2008/6/7 Conal Elliott >: > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > the code below (which is simplified from fusion on linear maps). I've tried > every variation I can think of, and always something prevents the fusion. > > Help, please! Thanks, - Conal > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-} > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt :: a -> Int > fromInt :: Int -> a > > {-# RULES > "toInt/fromInt" forall m. toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f = fromInt . f . toInt > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > -- The desired result: > -- > -- test h g > -- == onInt h . onInt g > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > -- == \ a -> fromInt (h (g (toInt a))) > > > > _______________________________________________ > 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/20080609/7d357cf9/attachment-0001.htm From rl at cse.unsw.edu.au Mon Jun 9 05:54:26 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Jun 9 05:46:52 2008 Subject: desperately seeking RULES help In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <484CFDD2.3000603@cse.unsw.edu.au> Simon Peyton-Jones wrote: > The -fno-method-sharing flag was supposed to be a bit experimental, > which is why it takes the cheap-and-cheerful route of being a static > flag. (Only dynamic flags can go in OPTIONS_GHC.) It's dynamic in the HEAD, see Mon May 19 19:59:56 PDT 2008 Roman Leshchinskiy * Make -f[no-]method-sharing a dynamic flag Roman From rl at cse.unsw.edu.au Mon Jun 9 06:00:27 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Jun 9 05:52:54 2008 Subject: Building ndp Problem In-Reply-To: <484A4129.9050902@blueyonder.co.uk> References: <48393583.2070201@blueyonder.co.uk> <066B8FEE-5784-42B4-98AC-225F2852D812@cse.unsw.edu.au> <484A4129.9050902@blueyonder.co.uk> Message-ID: <484CFF3B.8020506@cse.unsw.edu.au> Dominic Steinitz wrote: > > I think I have things working now but the "make" system seems to have > problems. I followed the instructions here: > > http://www.haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP > > but got the messages below. Sorry, I haven't checked whether doing "make" works in the examples subdirectory for a while. However, "make " ought to work, where is dotp, smvm and so on. In any case, the code and the build system are undergoing extensive refactoring at the moment. I hope this will work better once that's done. > On the other hand this worked: > > ghc --make -o dotp dotp.hs -package ndp -i../lib -threaded I would recommend using -Odph with the HEAD or the flags from ndp.mk if you want to actually run the programs; it's going to be really slow otherwise. > Would you like me to raise a ticket? For the moment, please just email or cc me about any NDP problems. Roman From claus.reinke at talk21.com Mon Jun 9 06:00:26 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Jun 9 05:54:05 2008 Subject: desperately seeking RULES help References: Message-ID: <012001c8ca17$d07c6150$fc148351@cr3lt> could you please send the complete options/commandline and the expect final form of 'test'? i did play with Conal's example as well, but couldn't find a combination to make it work. perhaps i'm looking at the wrong output, but it seems i either get non-inlined 'onInt's in various forms or multiple matches out of the same dictionary, but with generic method names rather than the original 'fromInt'/'toInt'. claus > Thanks a million, Lennart! -fno-method-sharing was the missing piece. - > Conal > > On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson > wrote: > >> Here's something that actually works. You need to pass >> -fno-method-sharing on the command line. >> Instead of using rules on methods it uses rules on global functions, >> and these global functions don't get inlined until late (after the >> rule has fired). >> >> -- Lennart >> >> module F where >> >> -- | Domain of a linear map. >> class AsInt a where >> toInt' :: a -> Int >> fromInt' :: Int -> a >> >> {-# INLINE[1] toInt #-} >> toInt :: (AsInt a) => a -> Int >> toInt = toInt' >> >> {-# INLINE[1] fromInt #-} >> fromInt :: (AsInt a) => Int -> a >> fromInt = fromInt' >> >> {-# RULES >> "toInt/fromInt" forall m . toInt (fromInt m) = m >> #-} >> >> {-# INLINE onInt #-} >> onInt :: AsInt a => (Int -> Int) -> (a -> a) >> onInt f x = fromInt (f (toInt x)) >> >> test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >> test h g = onInt h . onInt g >> >> >> >> 2008/6/7 Conal Elliott : >> > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with >> > the code below (which is simplified from fusion on linear maps). I've >> tried >> > every variation I can think of, and always something prevents the fusion. >> > >> > Help, please! Thanks, - Conal >> > >> > >> > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats >> #-} >> > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} >> > >> > module F where >> > >> > -- | Domain of a linear map. >> > class AsInt a where >> > toInt :: a -> Int >> > fromInt :: Int -> a >> > >> > {-# RULES >> > "toInt/fromInt" forall m. toInt (fromInt m) = m >> > #-} >> > >> > {-# INLINE onInt #-} >> > onInt :: AsInt a => (Int -> Int) -> (a -> a) >> > onInt f = fromInt . f . toInt >> > >> > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >> > test h g = onInt h . onInt g >> > >> > -- The desired result: >> > -- >> > -- test h g >> > -- == onInt h . onInt g >> > -- == (fromInt . h . toInt) . (fromInt . g . toInt) >> > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) >> > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) >> > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) >> > -- == \ a -> fromInt (h (g (toInt a))) >> > >> > >> > >> > _______________________________________________ >> > 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 conal at conal.net Mon Jun 9 11:27:53 2008 From: conal at conal.net (Conal Elliott) Date: Mon Jun 9 11:20:12 2008 Subject: desperately seeking RULES help In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: How does method sharing interact with the ability of the rules engine to "look through" lets? Wouldn't an f rule kick in when fint is seen, by looking through the fint binding? I've been wondering: will pattern matching look through a let even when the let-bound variable is used more than once? I chose "yes" in Pan, though somewhat nervously, since all but one of the uses are free anyway. Cheers, - Conal On Mon, Jun 9, 2008 at 2:38 AM, Simon Peyton-Jones wrote: > The -fno-method-sharing flag was supposed to be a bit experimental, which > is why it takes the cheap-and-cheerful route of being a static flag. (Only > dynamic flags can go in OPTIONS_GHC.) > > > > What it does is this. When you call an overloaded function f :: C a => a -> > a, in a function > > g = ...f...f... > > > > you normally get something like this > > > > fint :: Int -> Int > > fint = f Int dCInt > > > > g = ...fint...fint... > > > > That is, 'fint' extracts the 'f' method from dCInt::C Int, and it's then > used repeatedly. > > > > With -fno-method-sharing you get > > > > g = ...(f Int dCInt) ... (f Int dCInt)... > > > > So the record selection is duplicated. It shouldn't make much difference, > but of course it **does** when rules are involved, because there are no > rules for fint (it's a fresh, local function). > > > > Simon > > > > *From:* glasgow-haskell-users-bounces@haskell.org [mailto: > glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 07 June 2008 17:26 > *To:* glasgow-haskell-users@haskell.org > *Subject:* Re: desperately seeking RULES help > > > > Is it by intention that -fno-method-sharing works only from the command > line, not in an OPTIONS_GHC pragma? > > On Sat, Jun 7, 2008 at 9:23 AM, Conal Elliott wrote: > > Thanks a million, Lennart! -fno-method-sharing was the missing piece. - > Conal > > > > On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson > wrote: > > Here's something that actually works. You need to pass > -fno-method-sharing on the command line. > Instead of using rules on methods it uses rules on global functions, > and these global functions don't get inlined until late (after the > rule has fired). > > -- Lennart > > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt' :: a -> Int > fromInt' :: Int -> a > > {-# INLINE[1] toInt #-} > toInt :: (AsInt a) => a -> Int > toInt = toInt' > > {-# INLINE[1] fromInt #-} > fromInt :: (AsInt a) => Int -> a > fromInt = fromInt' > > > {-# RULES > "toInt/fromInt" forall m . toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > > onInt f x = fromInt (f (toInt x)) > > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > > 2008/6/7 Conal Elliott : > > > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > > the code below (which is simplified from fusion on linear maps). I've > tried > > every variation I can think of, and always something prevents the fusion. > > > > Help, please! Thanks, - Conal > > > > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats > #-} > > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > > > module F where > > > > -- | Domain of a linear map. > > class AsInt a where > > toInt :: a -> Int > > fromInt :: Int -> a > > > > {-# RULES > > "toInt/fromInt" forall m. toInt (fromInt m) = m > > #-} > > > > {-# INLINE onInt #-} > > onInt :: AsInt a => (Int -> Int) -> (a -> a) > > onInt f = fromInt . f . toInt > > > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > > test h g = onInt h . onInt g > > > > -- The desired result: > > -- > > -- test h g > > -- == onInt h . onInt g > > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > > -- == \ a -> fromInt (h (g (toInt a))) > > > > > > > > > _______________________________________________ > > 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/20080609/a7a0aebf/attachment.htm From simonpj at microsoft.com Mon Jun 9 11:53:16 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 9 11:45:40 2008 Subject: desperately seeking RULES help In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FA92@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5A3FEF1@EA-EXMSG-C334.europe.corp.microsoft.com> GHC only "looks through" *value* bindings, because (as you note) you can get arbitrary loss of sharing otherwise. And fint isn't a value binding, since it has work to do. (Not much, I grant you -- maybe we could take account of that.) Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 09 June 2008 16:28 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: desperately seeking RULES help How does method sharing interact with the ability of the rules engine to "look through" lets? Wouldn't an f rule kick in when fint is seen, by looking through the fint binding? I've been wondering: will pattern matching look through a let even when the let-bound variable is used more than once? I chose "yes" in Pan, though somewhat nervously, since all but one of the uses are free anyway. Cheers, - Conal On Mon, Jun 9, 2008 at 2:38 AM, Simon Peyton-Jones > wrote: The -fno-method-sharing flag was supposed to be a bit experimental, which is why it takes the cheap-and-cheerful route of being a static flag. (Only dynamic flags can go in OPTIONS_GHC.) What it does is this. When you call an overloaded function f :: C a => a -> a, in a function g = ...f...f... you normally get something like this fint :: Int -> Int fint = f Int dCInt g = ...fint...fint... That is, 'fint' extracts the 'f' method from dCInt::C Int, and it's then used repeatedly. With -fno-method-sharing you get g = ...(f Int dCInt) ... (f Int dCInt)... So the record selection is duplicated. It shouldn't make much difference, but of course it *does* when rules are involved, because there are no rules for fint (it's a fresh, local function). Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 07 June 2008 17:26 To: glasgow-haskell-users@haskell.org Subject: Re: desperately seeking RULES help Is it by intention that -fno-method-sharing works only from the command line, not in an OPTIONS_GHC pragma? On Sat, Jun 7, 2008 at 9:23 AM, Conal Elliott > wrote: Thanks a million, Lennart! -fno-method-sharing was the missing piece. - Conal On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson > wrote: Here's something that actually works. You need to pass -fno-method-sharing on the command line. Instead of using rules on methods it uses rules on global functions, and these global functions don't get inlined until late (after the rule has fired). -- Lennart module F where -- | Domain of a linear map. class AsInt a where toInt' :: a -> Int fromInt' :: Int -> a {-# INLINE[1] toInt #-} toInt :: (AsInt a) => a -> Int toInt = toInt' {-# INLINE[1] fromInt #-} fromInt :: (AsInt a) => Int -> a fromInt = fromInt' {-# RULES "toInt/fromInt" forall m . toInt (fromInt m) = m #-} {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f x = fromInt (f (toInt x)) test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g 2008/6/7 Conal Elliott >: > I'm trying to do some fusion in ghc, and I'd greatly appreciate help with > the code below (which is simplified from fusion on linear maps). I've tried > every variation I can think of, and always something prevents the fusion. > > Help, please! Thanks, - Conal > > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-} > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} > > module F where > > -- | Domain of a linear map. > class AsInt a where > toInt :: a -> Int > fromInt :: Int -> a > > {-# RULES > "toInt/fromInt" forall m. toInt (fromInt m) = m > #-} > > {-# INLINE onInt #-} > onInt :: AsInt a => (Int -> Int) -> (a -> a) > onInt f = fromInt . f . toInt > > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) > test h g = onInt h . onInt g > > -- The desired result: > -- > -- test h g > -- == onInt h . onInt g > -- == (fromInt . h . toInt) . (fromInt . g . toInt) > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) > -- == \ a -> fromInt (h (g (toInt a))) > > > > _______________________________________________ > 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/20080609/e0f34fd7/attachment-0001.htm From lennart at augustsson.net Mon Jun 9 15:06:59 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Jun 9 14:59:19 2008 Subject: desperately seeking RULES help In-Reply-To: <012001c8ca17$d07c6150$fc148351@cr3lt> References: <012001c8ca17$d07c6150$fc148351@cr3lt> Message-ID: Here it is: {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl #-} -- compile with: ghc -fno-method-sharing -c F.hs module F(test) where -- | Domain of a linear map. class AsInt a where toInt' :: a -> Int fromInt' :: Int -> a {-# INLINE[1] toInt #-} toInt :: (AsInt a) => a -> Int toInt = toInt' {-# INLINE[1] fromInt #-} fromInt :: (AsInt a) => Int -> a fromInt = fromInt' {-# RULES "toInt/fromInt" forall m . toInt (fromInt m) = m #-} {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f x = fromInt (f (toInt x)) test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g {- Glasgow Haskell Compiler, Version 6.8.2.20080211, for Haskell 98, stage 2 booted by GHC version 6.6.1 F.test = \ (@ a_a6C) ($dAsInt_a6M :: F.AsInt a_a6C) (h_a67 :: GHC.Base.Int -> GHC.Base.Int) (g_a68 :: GHC.Base.Int -> GHC.Base.Int) (eta_s77 :: a_a6C) -> case $dAsInt_a6M of tpl_B1 { F.:DAsInt tpl1_B2 tpl2_B3 -> tpl2_B3 (h_a67 (g_a68 (tpl1_B2 eta_s77))) } -} On Mon, Jun 9, 2008 at 11:00 AM, Claus Reinke wrote: > could you please send the complete options/commandline and > the expect final form of 'test'? i did play with Conal's example > as well, but couldn't find a combination to make it work. > > perhaps i'm looking at the wrong output, but it seems i either get > non-inlined 'onInt's in various forms or multiple matches out of the same > dictionary, but with generic method names rather than the original > 'fromInt'/'toInt'. > > claus > >> Thanks a million, Lennart! -fno-method-sharing was the missing piece. - >> Conal >> >> On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson >> >> wrote: >> >>> Here's something that actually works. You need to pass >>> -fno-method-sharing on the command line. >>> Instead of using rules on methods it uses rules on global functions, >>> and these global functions don't get inlined until late (after the >>> rule has fired). >>> >>> -- Lennart >>> >>> module F where >>> >>> -- | Domain of a linear map. >>> class AsInt a where >>> toInt' :: a -> Int >>> fromInt' :: Int -> a >>> >>> {-# INLINE[1] toInt #-} >>> toInt :: (AsInt a) => a -> Int >>> toInt = toInt' >>> >>> {-# INLINE[1] fromInt #-} >>> fromInt :: (AsInt a) => Int -> a >>> fromInt = fromInt' >>> >>> {-# RULES >>> "toInt/fromInt" forall m . toInt (fromInt m) = m >>> #-} >>> >>> {-# INLINE onInt #-} >>> onInt :: AsInt a => (Int -> Int) -> (a -> a) >>> onInt f x = fromInt (f (toInt x)) >>> >>> test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >>> test h g = onInt h . onInt g >>> >>> >>> >>> 2008/6/7 Conal Elliott : >>> > I'm trying to do some fusion in ghc, and I'd greatly appreciate help >>> > with >>> > the code below (which is simplified from fusion on linear maps). I've >>> tried >>> > every variation I can think of, and always something prevents the >>> > fusion. >>> > >>> > Help, please! Thanks, - Conal >>> > >>> > >>> > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl >>> > -ddump-simpl-stats >>> #-} >>> > -- {-# OPTIONS_GHC -ddump-simpl-iterations #-} >>> > >>> > module F where >>> > >>> > -- | Domain of a linear map. >>> > class AsInt a where >>> > toInt :: a -> Int >>> > fromInt :: Int -> a >>> > >>> > {-# RULES >>> > "toInt/fromInt" forall m. toInt (fromInt m) = m >>> > #-} >>> > >>> > {-# INLINE onInt #-} >>> > onInt :: AsInt a => (Int -> Int) -> (a -> a) >>> > onInt f = fromInt . f . toInt >>> > >>> > test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) >>> > test h g = onInt h . onInt g >>> > >>> > -- The desired result: >>> > -- >>> > -- test h g >>> > -- == onInt h . onInt g >>> > -- == (fromInt . h . toInt) . (fromInt . g . toInt) >>> > -- == \ a -> (fromInt . h . toInt) ((fromInt . g . toInt) a) >>> > -- == \ a -> (fromInt . h . toInt) (fromInt (g (toInt a))) >>> > -- == \ a -> fromInt (h (toInt (fromInt (g (toInt a))))) >>> > -- == \ a -> fromInt (h (g (toInt a))) >>> > >>> > >>> > >>> > _______________________________________________ >>> > Glasgow-haskell-users mailing list >>> > Glasgow-haskell-users@haskell.org >>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> > >>> > >>> >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From judah.jacobson at gmail.com Mon Jun 9 15:09:31 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jun 9 15:01:51 2008 Subject: Problems interrupting IO with -threaded Message-ID: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> Hi all, I'm writing a program that reads input from the user but should also handle a ctrl-c. My attempt is below; the program forks a thread to read one character of input, and kills that thread upon receiving a sigINT. It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. I know that in general, foreign calls are not interruptible; but the documentation for Control.Concurrent and System.Timeout suggests that I/O operations are a special case. In particular, the documentation for System.Timeout.timeout says: "Standard I/O functions like hGetBuf, hPutBuf, Network.Socket.accept, or hWaitForInput appear to be blocking, but they really don't because the runtime system uses scheduling mechanisms like select(2) to perform asynchronous I/O, so it is possible to interrupt standard socket I/O or file I/O using this combinator." So is the behavior that I'm seeing correct? If so, it seems odd to get better concurrency without the threaded runtime. If not, I can file a bug for this. I used ghc-6.8.2 and HEAD on OS X 10.5 (x86). Thanks, -Judah -------------- module Main where import Control.Monad import System.Posix.Signals import Control.Concurrent import Control.Concurrent.MVar import System.IO main = do hSetBuffering stdin NoBuffering hSetEcho stdin False mv <- newEmptyMVar let handler = putMVar mv Nothing installHandler sigINT (CatchOnce handler) Nothing tid <- forkIO (myGetChar mv) c <- takeMVar mv when (c==Nothing) $ do killThread tid putStrLn ("Result: " ++ show c) myGetChar mv = do c <- getChar putMVar mv (Just c) From thomas.krauss at gmail.com Mon Jun 9 15:42:40 2008 From: thomas.krauss at gmail.com (Thomas Krauss) Date: Mon Jun 9 15:34:58 2008 Subject: Missing Data.Map library? GHC 6.8.2 under OS X Message-ID: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> I seem to be having trouble using GHC 6.8.2 and OS X (10.5). It seems that any use of anything from Data.Map results in a link error like Undefined symbols: "___stginit_containerszm0zi1zi0zi1_DataziMap_", referenced from: ___stginit_Main_ in tst_parse.o ld: symbol(s) not found Has anyone else seen this? I tried reinstalling the package from haskell.org, but no luck. From waldmann at imn.htwk-leipzig.de Mon Jun 9 16:03:59 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Jun 9 15:56:18 2008 Subject: Missing Data.Map library? GHC 6.8.2 under OS X In-Reply-To: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> References: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> Message-ID: <484D8CAF.1080807@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 what is the exact source file, what is the compile/link command that causes the error? if you use "ghc --make Foo" then all dependencies should be handled correctly. what is the output of "ghc-pkg list containers"? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITYyeDqiTJ5Q4dm8RAkBRAJ9hmHelQxWpWWbQf+pVRHTsm2mkTwCgssQb XT6Wk/kbWLlzml6sD8V2fCY= =RqQn -----END PGP SIGNATURE----- From bulat.ziganshin at gmail.com Mon Jun 9 15:58:30 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jun 9 15:58:43 2008 Subject: Missing Data.Map library? GHC 6.8.2 under OS X In-Reply-To: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> References: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> Message-ID: <1854917270.20080609235830@gmail.com> Hello Thomas, Monday, June 9, 2008, 11:42:40 PM, you wrote: > Undefined symbols: > "___stginit_containerszm0zi1zi0zi1_DataziMap_", referenced from: > ___stginit_Main_ in tst_parse.o > ld: symbol(s) not found add --make to cmdline -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeremy at n-heptane.com Mon Jun 9 16:21:09 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Mon Jun 9 16:11:54 2008 Subject: Missing Data.Map library? GHC 6.8.2 under OS X In-Reply-To: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> References: <7fe2d560806091242k494144bby2384be2dca6cbba2@mail.gmail.com> Message-ID: <87k5gygy16.wl%jeremy@n-heptane.com> At Mon, 9 Jun 2008 15:42:40 -0400, Thomas Krauss wrote: > > I seem to be having trouble using GHC 6.8.2 and OS X (10.5). It seems > that any use of anything from Data.Map results in a link error like > > Undefined symbols: > "___stginit_containerszm0zi1zi0zi1_DataziMap_", referenced from: > ___stginit_Main_ in tst_parse.o > ld: symbol(s) not found In my experience, you will get this error if you have some libraries which were built against an older version of Data.Map and then you upgraded to the new Data.Map without rebuilding those libraries. Or, if you just have some .o/.hi files in your local directory that were built against the old Data.Map. Have you tried creating a very simple new project like: > module Main where > > import Data.Map > > main = print (empty :: Map Int Int) $ ghc --make Main.hs -o test If that fails, then the problem is likely with your GHC 6 installation itself, not some stale third party library. Have you previously installed GHC 6 on this machine? If so, perhaps the old version was not completely removed and the compiler is getting mixed up. Alternatively, perhaps the new version requires you to install some extra package to get all the libraries, instead of just the core libraries ? Looking at the binary distribution page, that does not appear to be the case. j. From claus.reinke at talk21.com Mon Jun 9 18:08:10 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Jun 9 18:00:34 2008 Subject: desperately seeking RULES help References: <012001c8ca17$d07c6150$fc148351@cr3lt> Message-ID: <021b01c8ca7d$4eea2670$fc148351@cr3lt> > Here it is: > > {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl #-} > -- compile with: ghc -fno-method-sharing -c F.hs thanks! it seems i misread the users guide (or is this a bug?). i used -frewrite-rules ("Switch on all rewrite rules"), which does not(!) work, instead of -fglasgow-exts, which does work (ghc-6.9.20080514, booted from 6.6.1). i learned something new,-) claus From dons at galois.com Mon Jun 9 18:10:44 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 9 18:03:20 2008 Subject: desperately seeking RULES help In-Reply-To: <021b01c8ca7d$4eea2670$fc148351@cr3lt> References: <012001c8ca17$d07c6150$fc148351@cr3lt> <021b01c8ca7d$4eea2670$fc148351@cr3lt> Message-ID: <20080609221044.GC25378@scytale.galois.com> claus.reinke: > >Here it is: > > > >{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl #-} > >-- compile with: ghc -fno-method-sharing -c F.hs > > thanks! it seems i misread the users guide (or is this a bug?). > i used -frewrite-rules ("Switch on all rewrite rules"), which > does not(!) work, instead of -fglasgow-exts, which does > work (ghc-6.9.20080514, booted from 6.6.1). > > i learned something new,-) Right. There are two things here: 1) -frewrite-rules enables rules to fire. 2) -fglasgow-exts enables parsing of RULES pragmas, and their interpretation. You need both if you wish to both write your own rules, and have them fire. -- Don From claus.reinke at talk21.com Mon Jun 9 18:29:12 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Jun 9 18:21:39 2008 Subject: desperately seeking RULES help References: <012001c8ca17$d07c6150$fc148351@cr3lt><021b01c8ca7d$4eea2670$fc148351@cr3lt> <20080609221044.GC25378@scytale.galois.com> Message-ID: <027c01c8ca80$3f88e560$fc148351@cr3lt> > Right. There are two things here: > > 1) -frewrite-rules > > enables rules to fire. > > 2) -fglasgow-exts > > enables parsing of RULES pragmas, and their interpretation. > > You need both if you wish to both write your own rules, and have them > fire. nope!-) -fglasgow-exts is sufficient for the RULE to be parsed and applied in Lennart's code, -frewrite-rules doesn't seem to serve any noticable purpose. but i see now this is under re-evaluation, aptly titled: "Confusing flags for rewrite rules" http://hackage.haskell.org/trac/ghc/ticket/2213 (see simonpj's comment at the end) claus $ head -1 Rules.hs {-# OPTIONS_GHC -O2 -Wall -fglasgow-exts #-} $ /cygdrive/c/fptools/ghc/ghc-6.9.20080514/bin/ghc -fno-method-sharing -ddump-simpl-stats -c Rules. hs ==================== FloatOut stats: ==================== 0 Lets floated to top level; 0 Lets floated elsewhere; from 3 Lambda groups ==================== FloatOut stats: ==================== 0 Lets floated to top level; 0 Lets floated elsewhere; from 3 Lambda groups ==================== Grand total simplifier statistics ==================== Total ticks: 60 18 PreInlineUnconditionally 11 PostInlineUnconditionally 5 UnfoldingDone 1 RuleFired 1 toInt/fromInt 2 EtaReduction 22 BetaReduction 1 KnownBranch 11 SimplifierDone From dons at galois.com Mon Jun 9 18:31:40 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 9 18:24:14 2008 Subject: desperately seeking RULES help In-Reply-To: <027c01c8ca80$3f88e560$fc148351@cr3lt> References: <20080609221044.GC25378@scytale.galois.com> <027c01c8ca80$3f88e560$fc148351@cr3lt> Message-ID: <20080609223140.GE25378@scytale.galois.com> claus.reinke: > >Right. There are two things here: > > > > 1) -frewrite-rules > > > >enables rules to fire. > > > > 2) -fglasgow-exts > > > >enables parsing of RULES pragmas, and their interpretation. > > > >You need both if you wish to both write your own rules, and have them > >fire. > > nope!-) -fglasgow-exts is sufficient for the RULE to be parsed > and applied in Lennart's code, -frewrite-rules doesn't seem to > serve any noticable purpose. Well, if -O is on, -frewrite-rules is already on by default. Try -fno-rewrite-rules with -O to turn them off specifically, or in ghci, -frewrite-rules can be used to help them fire even on bytecode. > but i see now this is under re-evaluation, aptly titled: > > "Confusing flags for rewrite rules" > http://hackage.haskell.org/trac/ghc/ticket/2213 > (see simonpj's comment at the end) Right. -- Don From claus.reinke at talk21.com Mon Jun 9 18:43:50 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Jun 9 18:36:17 2008 Subject: desperately seeking RULES help References: <20080609221044.GC25378@scytale.galois.com><027c01c8ca80$3f88e560$fc148351@cr3lt> <20080609223140.GE25378@scytale.galois.com> Message-ID: <028a01c8ca82$4aeb6840$fc148351@cr3lt> >> nope!-) -fglasgow-exts is sufficient for the RULE to be parsed >> and applied in Lennart's code, -frewrite-rules doesn't seem to >> serve any noticable purpose. > > Well, if -O is on, -frewrite-rules is already on by default. > Try -fno-rewrite-rules with -O to turn them off specifically, yep, see my note in the ticket about this confusion. > or in ghci, -frewrite-rules can be used to help them fire even on > bytecode. when i tried this earlier, the hpc ticks seemed to get in the way? claus From dons at galois.com Mon Jun 9 18:47:02 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 9 18:39:23 2008 Subject: desperately seeking RULES help In-Reply-To: <028a01c8ca82$4aeb6840$fc148351@cr3lt> References: <20080609223140.GE25378@scytale.galois.com> <028a01c8ca82$4aeb6840$fc148351@cr3lt> Message-ID: <20080609224702.GF25378@scytale.galois.com> claus.reinke: > >>nope!-) -fglasgow-exts is sufficient for the RULE to be parsed > >>and applied in Lennart's code, -frewrite-rules doesn't seem to > >>serve any noticable purpose. > > > >Well, if -O is on, -frewrite-rules is already on by default. > >Try -fno-rewrite-rules with -O to turn them off specifically, > > yep, see my note in the ticket about this confusion. > > >or in ghci, -frewrite-rules can be used to help them fire even on > >bytecode. > > when i tried this earlier, the hpc ticks seemed to get in the way? HPC will break rules, yes. See: "-fhpc inteferes/prevents rewrite rules from firing" http://hackage.haskell.org/trac/ghc/ticket/2224 -- Don From dominic.steinitz at blueyonder.co.uk Tue Jun 10 16:39:30 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Jun 10 16:30:57 2008 Subject: Rebuilding ghc Message-ID: <484EE682.1070801@blueyonder.co.uk> I've built ghc previously and I assumed to keep it up to date I just did darcs pull followed by make but I got errors and according to the rebuilding instructions http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't have done that. I therefore followed the instructions but got the following error. By the way darcs-pull all seemed to require a lot of manual intervention. Is there a way of getting the latest patches automatically and building overnight without intervention? Thanks, Dominic. > if ifBuildable/ifBuildable /home/dom/ghc/libraries/boot-packages editline; then \ > cd editline && \ > cmp -s /home/dom/ghc/libraries/Makefile.local Makefile.local || cp /home/dom/ghc/libraries/Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ > make -wr && \ > setup/Setup register --inplace; \ > fi > mv: cannot stat `GNUmakefile': No such file or directory > Preprocessing library editline-0.2... > In file included from Editline.hsc:52: > include/HsEditline.h:11: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?v? > compiling dist/build/System/Console/Editline_hsc_make.c failed > command was: gcc -c -D__GLASGOW_HASKELL__=609 -I/home/dom/ghc/includes -I/home/dom/ghc/gmp/gmpbuild -D__GLASGOW_HASKELL__=609 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o > make[2]: Entering directory `/home/dom/ghc/libraries/editline' > make[2]: *** No targets specified and no makefile found. Stop. > make[2]: Leaving directory `/home/dom/ghc/libraries/editline' > make[1]: *** [make.library.editline] Error 2 > make[1]: Leaving directory `/home/dom/ghc/libraries' > make: *** [stage1] Error 2 From catamorphism at gmail.com Tue Jun 10 17:57:27 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Jun 10 17:49:43 2008 Subject: Rebuilding ghc In-Reply-To: <484EE682.1070801@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> Message-ID: <4683d9370806101457r3b5d5e37r3aaadbbab1242900@mail.gmail.com> On 6/10/08, Dominic Steinitz wrote: > I've built ghc previously and I assumed to keep it up to date I just did > > darcs pull > > followed by > > make > > but I got errors and according to the rebuilding instructions > http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't > have done that. > > I therefore followed the instructions but got the following error. It's probably best to do a "make distclean" at this point, then follow the building instructions. > By > the way darcs-pull all seemed to require a lot of manual intervention. > Is there a way of getting the latest patches automatically and building > overnight without intervention? > ./darcs-all pull -a will pull all patches without prompting you to ask whether you want to pull each patch, if that's what you mean. The following should pull patches and rebuild everything without manual intervention: ./darcs-all pull -a; sh boot; ./configure; make but YMMV. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Aristotle maintained that women have fewer teeth than men; although he was twice married, it never occurred to him to verify this statement by examining his wives' mouths." -- Bertrand Russell From judah.jacobson at gmail.com Tue Jun 10 20:00:50 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jun 10 19:53:05 2008 Subject: Rebuilding ghc In-Reply-To: <484EE682.1070801@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> Message-ID: <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> On Tue, Jun 10, 2008 at 1:39 PM, Dominic Steinitz wrote: > I've built ghc previously and I assumed to keep it up to date I just did > > darcs pull > > followed by > > make > > but I got errors and according to the rebuilding instructions > http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't > have done that. > > I therefore followed the instructions but got the following error. By > the way darcs-pull all seemed to require a lot of manual intervention. > Is there a way of getting the latest patches automatically and building > overnight without intervention? > > Thanks, Dominic. > >> if ifBuildable/ifBuildable /home/dom/ghc/libraries/boot-packages editline; then \ >> cd editline && \ >> cmp -s /home/dom/ghc/libraries/Makefile.local Makefile.local || cp /home/dom/ghc/libraries/Makefile.local .; \ >> mv GNUmakefile GNUmakefile.tmp; \ >> setup/Setup makefile -f GNUmakefile; \ >> cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ >> make -wr && \ >> setup/Setup register --inplace; \ >> fi >> mv: cannot stat `GNUmakefile': No such file or directory >> Preprocessing library editline-0.2... >> In file included from Editline.hsc:52: >> include/HsEditline.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'v' >> compiling dist/build/System/Console/Editline_hsc_make.c failed >> command was: gcc -c -D__GLASGOW_HASKELL__=609 -I/home/dom/ghc/includes -I/home/dom/ghc/gmp/gmpbuild -D__GLASGOW_HASKELL__=609 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o >> make[2]: Entering directory `/home/dom/ghc/libraries/editline' >> make[2]: *** No targets specified and no makefile found. Stop. >> make[2]: Leaving directory `/home/dom/ghc/libraries/editline' >> make[1]: *** [make.library.editline] Error 2 >> make[1]: Leaving directory `/home/dom/ghc/libraries' >> make: *** [stage1] Error 2 > >From that error, I suspect you have a conflict in the editline package, and the compiler is barfing on the marker "vvvvvv" which is inserted by darcs. Strange... If you weren't planning on hacking editline, it's probably easiest to just rm -rf the libraries/editline directory and do another "darcs-all get" to replace it with a consistent version. Otherwise, send me the darcs --changes of that repo and I can take a look at it. Hope that helps, -Judah From marlowsd at gmail.com Wed Jun 11 00:43:33 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 11 08:35:58 2008 Subject: Problems interrupting IO with -threaded In-Reply-To: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> References: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> Message-ID: <484F57F5.6000800@gmail.com> Judah Jacobson wrote: > Hi all, > > I'm writing a program that reads input from the user but should also > handle a ctrl-c. My attempt is below; the program forks a thread to > read one character of input, and kills that thread upon receiving a > sigINT. It works fine compiled without -threaded, but with -threaded > it blocks forever after a ctrl-c. > > I know that in general, foreign calls are not interruptible; but the > documentation for Control.Concurrent and System.Timeout suggests that > I/O operations are a special case. In particular, the documentation > for System.Timeout.timeout says: > > "Standard I/O functions like hGetBuf, hPutBuf, Network.Socket.accept, > or hWaitForInput appear to be blocking, but they really don't because > the runtime system uses scheduling mechanisms like select(2) to > perform asynchronous I/O, so it is possible to interrupt standard > socket I/O or file I/O using this combinator." > > So is the behavior that I'm seeing correct? If so, it seems odd to > get better concurrency without the threaded runtime. If not, I can > file a bug for this. I used ghc-6.8.2 and HEAD on OS X 10.5 (x86). Ah, this is a consequence of the change we made to stdin/stdout/stderr so that they no longer use O_NONBLOCK, but with -threaded they use blocking foreign calls instead. In your example, getChar is stuck in a blocking foreign call and can't be interrupted. I don't see a good workaround. One way is to add another thread: run the getChar in a subthread and the parent will be able to receive the signal. Or perhaps you could cause the read() that getChar has called to return EINTR, but that might not be enough because the I/O library executes mostly inside Control.Exception.block. Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. Cheers, Simon From allbery at ece.cmu.edu Wed Jun 11 09:05:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jun 11 08:57:52 2008 Subject: Problems interrupting IO with -threaded In-Reply-To: <484F57F5.6000800@gmail.com> References: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> <484F57F5.6000800@gmail.com> Message-ID: On 2008 Jun 11, at 0:43, Simon Marlow wrote: > Unix semantics just isn't the right thing when it comes to non- > blocking I/O. If only there were non-blocking read()/write() system > calls, we'd be fine. Have you considered using aio_read() and company? -- 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 From marlowsd at gmail.com Wed Jun 11 03:02:55 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 11 10:55:15 2008 Subject: Problems interrupting IO with -threaded In-Reply-To: References: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> <484F57F5.6000800@gmail.com> Message-ID: <484F789F.7090609@gmail.com> Brandon S. Allbery KF8NH wrote: > > On 2008 Jun 11, at 0:43, Simon Marlow wrote: > >> Unix semantics just isn't the right thing when it comes to >> non-blocking I/O. If only there were non-blocking read()/write() >> system calls, we'd be fine. > > > Have you considered using aio_read() and company? aio is not exactly the right API either. The IO manager would have to call aio_suspend(), and then in order to receive events from the RTS over the special pipe we have set up, the IO manager would have to issue its own aio_read() on this FD. And I'm not sure whether you can use aio_suspend() to wait for network accept(), but I suspect not. There ought to be a single way to wait for various different types of event on Unix. Cheers, Simon From gale at sefer.org Wed Jun 11 14:25:26 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jun 11 14:17:38 2008 Subject: Problems interrupting IO with -threaded In-Reply-To: <484F57F5.6000800@gmail.com> References: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> <484F57F5.6000800@gmail.com> Message-ID: <2608b8a80806111125r245078e5qe96cc95feaacadb4@mail.gmail.com> Judah Jacobson wrote: >> I'm writing a program that reads input from the user but should also >> handle a ctrl-c... >> It works fine compiled without -threaded, but with -threaded >> it blocks forever after a ctrl-c. Simon Marlow wrote: > Ah, this is a consequence of the change we made to stdin/stdout/stderr so > that they no longer use O_NONBLOCK, but with -threaded they use blocking > foreign calls instead... > I don't see a good workaround... > Unix semantics just isn't the right thing when it comes to non-blocking I/O. > If only there were non-blocking read()/write() system calls, we'd be fine. I believe you that the Unix semantics may not be very pretty. But all modern high-level programming languages have a getChar that can be interrupted by ^C. Can't we just do what they all do? This is basic, essential functionality that we use every day. In my opinion, Judah should file a bug, and it should be marked high priority. Thanks, Yitz From dominic.steinitz at blueyonder.co.uk Thu Jun 12 16:15:43 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Thu Jun 12 16:07:02 2008 Subject: Rebuilding ghc In-Reply-To: <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> Message-ID: <485183EF.7020403@blueyonder.co.uk> Judah Jacobson wrote: > On Tue, Jun 10, 2008 at 1:39 PM, Dominic Steinitz > wrote: >> I've built ghc previously and I assumed to keep it up to date I just did > > From that error, I suspect you have a conflict in the editline > package, and the compiler is barfing on the marker "vvvvvv" which is > inserted by darcs. Strange... > > If you weren't planning on hacking editline, it's probably easiest to > just rm -rf the libraries/editline directory and do another "darcs-all > get" to replace it with a consistent version. Otherwise, send me the > darcs --changes of that repo and I can take a look at it. > > Hope that helps, > -Judah > > Judah, Thanks for your help but now I'm getting a mismatch between ghc and ghc-pkg. I'm not sure how to fix this. Dominic. > Preprocessing library template-haskell-2.2... > Generating Makefile template-haskell-2.2... > make[2]: Entering directory `/home/dom/ghc/libraries/template-haskell' > make[2]: Leaving directory `/home/dom/ghc/libraries/template-haskell' > Registering template-haskell-2.2... > Reading package info from "dist/inplace-pkg-config" ... done. > Saving old package config file... done. > Writing new package config file... done. > rm -f -f stamp/configure.library.*.editline editline/unbuildable > ../utils/mkdirhier/mkdirhier `dirname stamp/configure.library.build.editline` > ( cd editline && setup/Setup configure --prefix=/NONEXISTENT --bindir=/NONEXIST > ENT --libdir=/NONEXISTENT --libsubdir='$pkgid' --libexecdir=/NONEXISTENT --datad > ir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEX > ISTENT --with-compiler=/home/dom/ghc/compiler/stage1/ghc-inplace --with-hc-pkg=/ > home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace --with-hsc2hs=/home/dom/ghc/utils/hsc > 2hs/hsc2hs-inplace --with-ld=/usr/bin/ld --haddock-options="--use-contents=../in > dex.html --use-index=../doc-index.html" --configure-option=--with-cc=gcc ) \ > && touch stamp/configure.library.build.editline || touch editline/ > unbuildable > Warning: defaultUserHooks in Setup script is deprecated. > Configuring editline-0.2... > Setup: Version mismatch between ghc and ghc-pkg: > /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606 > /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612 > if ifBuildable/ifBuildable /home/dom/ghc/libraries/boot-packages editline; then > \ > cd editline && \ > cmp -s /home/dom/ghc/libraries/Makefile.local Makefile.local || cp /ho > me/dom/ghc/libraries/Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; > \ > make -wr && \ > setup/Setup register --inplace; \ > fi > Warning: Package is unbuildable > rm -f -f stamp/configure.library.*.Cabal Cabal/unbuildable > ../utils/mkdirhier/mkdirhier `dirname stamp/configure.library.build.Cabal` > ( cd Cabal && setup/Setup configure --prefix=/NONEXISTENT --bindir=/NONEXISTENT > --libdir=/NONEXISTENT --libsubdir='$pkgid' --libexecdir=/NONEXISTENT --datadir= > /NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXIST > ENT --with-compiler=/home/dom/ghc/compiler/stage1/ghc-inplace --with-hc-pkg=/hom > e/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace --with-hsc2hs=/home/dom/ghc/utils/hsc2hs > /hsc2hs-inplace --with-ld=/usr/bin/ld --haddock-options="--use-contents=../index > .html --use-index=../doc-index.html" --configure-option=--with-cc=gcc ) \ > && touch stamp/configure.library.build.Cabal || touch Cabal/unbuil > dable > Configuring Cabal-1.5.1... > Setup: Version mismatch between ghc and ghc-pkg: > /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606 > /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612 > if ifBuildable/ifBuildable /home/dom/ghc/libraries/boot-packages Cabal; then \ > cd Cabal && \ > cmp -s /home/dom/ghc/libraries/Makefile.local Makefile.local || cp /ho > me/dom/ghc/libraries/Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ > make -wr && \ > setup/Setup register --inplace; \ > fi > mv: cannot stat `GNUmakefile': No such file or directory > Setup: Run the 'configure' command first. > make[2]: Entering directory `/home/dom/ghc/libraries/Cabal' > ./setup configure --with-compiler=ghc --prefix=/usr/local > make[2]: execvp: ./setup: Permission denied > make[2]: *** [dist/setup-config] Error 127 > make[2]: Leaving directory `/home/dom/ghc/libraries/Cabal' > make[1]: *** [make.library.Cabal] Error 2 > make[1]: Leaving directory `/home/dom/ghc/libraries' > make: *** [stage1] Error 2 From judah.jacobson at gmail.com Thu Jun 12 16:39:31 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jun 12 16:31:42 2008 Subject: Rebuilding ghc In-Reply-To: <485183EF.7020403@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> Message-ID: <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> On Thu, Jun 12, 2008 at 1:15 PM, Dominic Steinitz wrote: > Judah Jacobson wrote: >> >> If you weren't planning on hacking editline, it's probably easiest to >> just rm -rf the libraries/editline directory and do another "darcs-all >> get" to replace it with a consistent version. Otherwise, send me the >> darcs --changes of that repo and I can take a look at it. >> > Thanks for your help but now I'm getting a mismatch between ghc and > ghc-pkg. I'm not sure how to fix this. > > Dominic. > >> Preprocessing library template-haskell-2.2... >> Generating Makefile template-haskell-2.2... >> make[2]: Entering directory `/home/dom/ghc/libraries/template-haskell' >> make[2]: Leaving directory `/home/dom/ghc/libraries/template-haskell' >> Registering template-haskell-2.2... >> Reading package info from "dist/inplace-pkg-config" ... done. >> Saving old package config file... done. >> Writing new package config file... done. >> rm -f -f stamp/configure.library.*.editline editline/unbuildable >> ../utils/mkdirhier/mkdirhier `dirname stamp/configure.library.build.editline` >> ( cd editline && setup/Setup configure --prefix=/NONEXISTENT --bindir=/NONEXIST >> ENT --libdir=/NONEXISTENT --libsubdir='$pkgid' --libexecdir=/NONEXISTENT --datad >> ir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEX >> ISTENT --with-compiler=/home/dom/ghc/compiler/stage1/ghc-inplace --with-hc-pkg=/ >> home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace --with-hsc2hs=/home/dom/ghc/utils/hsc >> 2hs/hsc2hs-inplace --with-ld=/usr/bin/ld --haddock-options="--use-contents=../in >> dex.html --use-index=../doc-index.html" --configure-option=--with-cc=gcc ) \ >> && touch stamp/configure.library.build.editline || touch editline/ >> unbuildable >> Warning: defaultUserHooks in Setup script is deprecated. >> Configuring editline-0.2... >> Setup: Version mismatch between ghc and ghc-pkg: >> /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606 >> /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612 >From the above error, I suspect that you need to run "make distclean" in the root of the source tree, then try building again. (I usually run that command every time before/after pulling from darcs.) Let me know if that helps, -Judah From dominic.steinitz at blueyonder.co.uk Thu Jun 12 16:58:34 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Thu Jun 12 16:49:50 2008 Subject: Rebuilding ghc In-Reply-To: <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> Message-ID: <48518DFA.9030605@blueyonder.co.uk> >>> Configuring editline-0.2... >>> Setup: Version mismatch between ghc and ghc-pkg: >>> /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606 >>> /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612 > > From the above error, I suspect that you need to run "make distclean" > in the root of the source tree, then try building again. (I usually > run that command every time before/after pulling from darcs.) > > Let me know if that helps, > -Judah > > Ok but doesn't that rebuild everything not just the bits that have changed? BTW it's still running. Dominic. From dominic.steinitz at blueyonder.co.uk Thu Jun 12 17:04:36 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Thu Jun 12 16:55:53 2008 Subject: Rebuilding ghc In-Reply-To: <48518DFA.9030605@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> Message-ID: <48518F64.90000@blueyonder.co.uk> This is becoming a bit of an odyssey ("a series of vicissitudes"). I now get a bug in ghc. Should I report it? Dominic. > /home/dom/ghc/compiler/stage1/ghc-inplace -package-name ndp-0.2 -hide-all-packag > es -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -odir dist/bu > ild -hidir dist/build -stubdir dist/build -package array-0.1 -package base-3.0 - > package ghc-prim-0.1 -package random-1.0 -O -O2 -funbox-strict-fields -fdicts-ch > eap -fno-method-sharing -fno-spec-constr-threshold -fmax-simplifier-iterations10 > -haddock -fcpr-off -package-name ndp -XTypeFamilies -XGADTs -XRankNTypes -XBang > Patterns -XMagicHash -XUnboxedTuples -XTypeOperators -idist/build -H32m -O2 -fa > sm -Rghc-timing -O -fgenerics -c Data/Array/Parallel/Base/Rebox.hs -o dist/buil > d/Data/Array/Parallel/Base/Rebox.o -ohi dist/build/Data/Array/Parallel/Base/Reb > ox.hi > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file coreSyn/CoreSubst.lhs line 182 > CoreSubst.lookupIdSubst dseq{v sk4} [lid] > WARNING: file coreSyn/CoreSubst.lhs line 182 > CoreSubst.lookupIdSubst rebox{v sk5} [lid] > WARNING: file coreSyn/CoreSubst.lhs line 182 > CoreSubst.lookupIdSubst dseq{v sjY} [lid] > WARNING: file coreSyn/CoreSubst.lhs line 182 > CoreSubst.lookupIdSubst rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] > WARNING: file stgSyn/CoreToStg.lhs line 217 > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] > ghc-6.9.20080612: panic! (the 'impossible' happened) > (GHC version 6.9.20080612 for i386-unknown-linux): > ASSERT failed! file stgSyn/CoreToStg.lhs line 184 > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] > \ (@ a{tv ae0} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) -> > ndp:Data.Array.Parallel.Base.Rebox.:DRebox{v rf4} [gid] > @ (ndp:Data.Array.Parallel.Base.Rebox.Box{tc rdA} > a{tv ae0} [sk]) > (rebox{v sjZ} [lid] @ a{tv ae0} [sk]) > (dseq{v sjY} [lid] @ a{tv ae0} [sk]) > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] = > NO_CCS ndp:Data.Array.Parallel.Base.Rebox.:DRebox{d reZ}! [rebox{v sjZ} [lid ] > dseq{v sjY} [lid] ]; > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > <> > make[2]: *** [dist/build/Data/Array/Parallel/Base/Rebox.o] Error 1 > make[2]: Leaving directory `/home/dom/ghc/libraries/ndp' > make[1]: *** [make.library.ndp] Error 2 > make[1]: Leaving directory `/home/dom/ghc/libraries' > make: *** [stage1] Error 2 From judah.jacobson at gmail.com Thu Jun 12 17:37:02 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jun 12 17:29:11 2008 Subject: Rebuilding ghc In-Reply-To: <48518DFA.9030605@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> Message-ID: <6d74b0d20806121437o609c48c4pd8dfa83641802822@mail.gmail.com> On Thu, Jun 12, 2008 at 1:58 PM, Dominic Steinitz wrote: >>>> Configuring editline-0.2... >>>> Setup: Version mismatch between ghc and ghc-pkg: >>>> /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606 >>>> /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612 >> >> From the above error, I suspect that you need to run "make distclean" >> in the root of the source tree, then try building again. (I usually >> run that command every time before/after pulling from darcs.) >> >> Let me know if that helps, >> -Judah >> >> > > Ok but doesn't that rebuild everything not just the bits that have changed? Correct. Ideally, the makefiles would be able to detect any changes after a pull, but in practice I've found that they get easily confused. Incidentally, if you haven't already, you can make each build much faster by adding a mk/build.mk file as in: http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking -Judah From allbery at ece.cmu.edu Thu Jun 12 17:42:07 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jun 12 17:34:30 2008 Subject: Rebuilding ghc In-Reply-To: <48518DFA.9030605@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> Message-ID: <8BD0035C-B093-4802-B173-168EE304B990@ece.cmu.edu> On 2008 Jun 12, at 16:58, Dominic Steinitz wrote: > Ok but doesn't that rebuild everything not just the bits that have > changed? Enough stuff usually changes that it's necessary (and for whatever reason dependencies don't catch enough of it). -- 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 From judah.jacobson at gmail.com Thu Jun 12 17:56:54 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jun 12 17:49:04 2008 Subject: Rebuilding ghc In-Reply-To: <48518F64.90000@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> Message-ID: <6d74b0d20806121456j2fce69b9ra7cf616ed0d71618@mail.gmail.com> On Thu, Jun 12, 2008 at 2:04 PM, Dominic Steinitz wrote: > This is becoming a bit of an odyssey ("a series of vicissitudes"). I now > get a bug in ghc. Should I report it? > > [snip error building ndp] This does seem worth reporting. There seem to be other outstanding bugs when building ndp, such as: http://hackage.haskell.org/trac/ghc/ticket/2355 I would suggest just renaming libraries/ndp to libraries/ndp-1 for now (to hide it from the build system). That library is pretty cutting-edge and isn't critical to a build. (But I eagerly await its completion; data parallel Haskell is great stuff!) -Judah From simonpj at microsoft.com Thu Jun 12 23:46:46 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 12 23:38:53 2008 Subject: Rebuilding ghc In-Reply-To: <48518F64.90000@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> Sorry about this -- it's my fault. I did validate a fix to the desugarer, but ndp isn't part of 'validate'. Turns out that the change to the desugarer provoked quite subtle and longstanding bug in the simplifier. To get rolling again, use -fno-ds-multi-tyvar. Or just don't compile NDP. I'll commit a patch shortly. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Dominic Steinitz | Sent: 12 June 2008 22:05 | To: Judah Jacobson | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Rebuilding ghc | | This is becoming a bit of an odyssey ("a series of vicissitudes"). I now | get a bug in ghc. Should I report it? | | Dominic. | | > /home/dom/ghc/compiler/stage1/ghc-inplace -package-name ndp-0.2 -hide-all- | packag | > es -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -odir | dist/bu | > ild -hidir dist/build -stubdir dist/build -package array-0.1 -package base- | 3.0 - | > package ghc-prim-0.1 -package random-1.0 -O -O2 -funbox-strict-fields - | fdicts-ch | > eap -fno-method-sharing -fno-spec-constr-threshold -fmax-simplifier- | iterations10 | > -haddock -fcpr-off -package-name ndp -XTypeFamilies -XGADTs -XRankNTypes - | XBang | > Patterns -XMagicHash -XUnboxedTuples -XTypeOperators -idist/build -H32m - | O2 -fa | > sm -Rghc-timing -O -fgenerics -c Data/Array/Parallel/Base/Rebox.hs -o | dist/buil | > d/Data/Array/Parallel/Base/Rebox.o -ohi | dist/build/Data/Array/Parallel/Base/Reb | > ox.hi | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file coreSyn/CoreSubst.lhs line 182 | > CoreSubst.lookupIdSubst dseq{v sk4} [lid] | > WARNING: file coreSyn/CoreSubst.lhs line 182 | > CoreSubst.lookupIdSubst rebox{v sk5} [lid] | > WARNING: file coreSyn/CoreSubst.lhs line 182 | > CoreSubst.lookupIdSubst dseq{v sjY} [lid] | > WARNING: file coreSyn/CoreSubst.lhs line 182 | > CoreSubst.lookupIdSubst rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sjZ} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sjY} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 rebox{v sk5} [lid] | > WARNING: file simplCore/SimplEnv.lhs line 470 dseq{v sk4} [lid] | > WARNING: file stgSyn/CoreToStg.lhs line 217 | > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] | > ghc-6.9.20080612: panic! (the 'impossible' happened) | > (GHC version 6.9.20080612 for i386-unknown-linux): | > ASSERT failed! file stgSyn/CoreToStg.lhs line 184 | > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] | > \ (@ a{tv ae0} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) -> | > ndp:Data.Array.Parallel.Base.Rebox.:DRebox{v rf4} [gid] | > @ (ndp:Data.Array.Parallel.Base.Rebox.Box{tc rdA} | > a{tv ae0} [sk]) | > (rebox{v sjZ} [lid] @ a{tv ae0} [sk]) | > (dseq{v sjY} [lid] @ a{tv ae0} [sk]) | > ndp:Data.Array.Parallel.Base.Rebox.$f2{v rfZ} [gid] = | > NO_CCS ndp:Data.Array.Parallel.Base.Rebox.:DRebox{d reZ}! [rebox{v sjZ} | [lid ] | > dseq{v sjY} | [lid] ]; | > | > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | > | > <> | > make[2]: *** [dist/build/Data/Array/Parallel/Base/Rebox.o] Error 1 | > make[2]: Leaving directory `/home/dom/ghc/libraries/ndp' | > make[1]: *** [make.library.ndp] Error 2 | > make[1]: Leaving directory `/home/dom/ghc/libraries' | > make: *** [stage1] Error 2 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bos at serpentine.com Fri Jun 13 01:37:33 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Jun 13 01:29:46 2008 Subject: Record syntax and INLINE annotations Message-ID: I have a curious situation. I've defined a data type using record syntax, and my module exports one of the accessor functions. I notice that GHC is not inlining any of the others, even though they are not exported. Furthermore, while poking around to see if I could bend it to my will, I found that I couldn't figure out where to place an INLINE annotation for an accessor function defined via record syntax such that the compiler would accept it. For now, I've dropped back to non-record syntax, my hand-crafted accessors are being inlined as I'd expect, and I win a few percent in performance. If anyone could shed a wee bit of light, I'd be most grateful. From simonpj at microsoft.com Fri Jun 13 07:48:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 13 07:40:04 2008 Subject: Record syntax and INLINE annotations In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> can you give an example? GHC should inline selectors, whether exported or not, whenever it'd help. They are implicitly defined as INLINE. Since this obviously isn?t working right, I'd like to see the code. Perhaps you can boil it down a little, and submit a ticket? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Bryan O'Sullivan | Sent: 13 June 2008 06:38 | To: glasgow-haskell-users@haskell.org | Subject: Record syntax and INLINE annotations | | I have a curious situation. I've defined a data type using record | syntax, and my module exports one of the accessor functions. I notice | that GHC is not inlining any of the others, even though they are not | exported. | | Furthermore, while poking around to see if I could bend it to my will, | I found that I couldn't figure out where to place an INLINE annotation | for an accessor function defined via record syntax such that the | compiler would accept it. | | For now, I've dropped back to non-record syntax, my hand-crafted | accessors are being inlined as I'd expect, and I win a few percent in | performance. If anyone could shed a wee bit of light, I'd be most | grateful. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From isaacdupree at charter.net Fri Jun 13 07:53:12 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jun 13 07:45:20 2008 Subject: Record syntax and INLINE annotations In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48525FA8.8030705@charter.net> is it trac bug #2070, http://hackage.haskell.org/trac/ghc/ticket/2070 (fixed in 6.9?) -Isaac Simon Peyton-Jones wrote: > can you give an example? GHC should inline selectors, whether exported or not, whenever it'd help. They are implicitly defined as INLINE. Since this obviously isn?t working right, I'd like to see the code. Perhaps you can boil it down a little, and submit a ticket? > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- > | users-bounces@haskell.org] On Behalf Of Bryan O'Sullivan > | Sent: 13 June 2008 06:38 > | To: glasgow-haskell-users@haskell.org > | Subject: Record syntax and INLINE annotations > | > | I have a curious situation. I've defined a data type using record > | syntax, and my module exports one of the accessor functions. I notice > | that GHC is not inlining any of the others, even though they are not > | exported. > | > | Furthermore, while poking around to see if I could bend it to my will, > | I found that I couldn't figure out where to place an INLINE annotation > | for an accessor function defined via record syntax such that the > | compiler would accept it. > | > | For now, I've dropped back to non-record syntax, my hand-crafted > | accessors are being inlined as I'd expect, and I win a few percent in > | performance. If anyone could shed a wee bit of light, I'd be most > | grateful. > | _______________________________________________ > | 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 simonpj at microsoft.com Fri Jun 13 07:59:39 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 13 07:59:30 2008 Subject: Record syntax and INLINE annotations In-Reply-To: <48525FA8.8030705@charter.net> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> <48525FA8.8030705@charter.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB378E@EA-EXMSG-C334.europe.corp.microsoft.com> Might be, but Bryan said that his selectors weren't getting inlined at all, which is a bit different perhaps S | -----Original Message----- | From: Isaac Dupree [mailto:isaacdupree@charter.net] | Sent: 13 June 2008 12:53 | To: Bryan O'Sullivan | Cc: Simon Peyton-Jones; glasgow-haskell-users@haskell.org | Subject: Re: Record syntax and INLINE annotations | | is it trac bug #2070, http://hackage.haskell.org/trac/ghc/ticket/2070 | (fixed in 6.9?) | | -Isaac | | | | Simon Peyton-Jones wrote: | > can you give an example? GHC should inline selectors, whether exported or | not, whenever it'd help. They are implicitly defined as INLINE. Since this | obviously isn?t working right, I'd like to see the code. Perhaps you can | boil it down a little, and submit a ticket? | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | > | users-bounces@haskell.org] On Behalf Of Bryan O'Sullivan | > | Sent: 13 June 2008 06:38 | > | To: glasgow-haskell-users@haskell.org | > | Subject: Record syntax and INLINE annotations | > | | > | I have a curious situation. I've defined a data type using record | > | syntax, and my module exports one of the accessor functions. I notice | > | that GHC is not inlining any of the others, even though they are not | > | exported. | > | | > | Furthermore, while poking around to see if I could bend it to my will, | > | I found that I couldn't figure out where to place an INLINE annotation | > | for an accessor function defined via record syntax such that the | > | compiler would accept it. | > | | > | For now, I've dropped back to non-record syntax, my hand-crafted | > | accessors are being inlined as I'd expect, and I win a few percent in | > | performance. If anyone could shed a wee bit of light, I'd be most | > | grateful. | > | _______________________________________________ | > | 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 bos at serpentine.com Fri Jun 13 12:32:37 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Jun 13 12:25:47 2008 Subject: Record syntax and INLINE annotations In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB377B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4852A125.80209@serpentine.com> Simon Peyton-Jones wrote: > can you give an example? Certainly. This comes from the bloomfilter package on Hackage. type Hash = Word32 data MBloom s a = MB { hashMB :: {-# UNPACK #-} !(a -> [Hash]) , shiftMB :: {-# UNPACK #-} !Int , maskMB :: {-# UNPACK #-} !Int , bitArrayMB :: {-# UNPACK #-} !(STUArray s Int Hash) } insertMB :: MBloom s a -> a -> ST s () {-# SPECIALIZE insertMB :: MBloom s SB.ByteString -> SB.ByteString -> ST s () #-} insertMB mb elt = do let mu = bitArrayMB mb forM_ (hashesM mb elt) $ \(word :* bit) -> do old <- unsafeRead mu word unsafeWrite mu word (old .|. (1 `shiftL` bit)) If I look at the Core generated for any version of insertMB, specialised or not, I see the following. Note the non-inlined uses of maskMB and bitArrayMB. (I export bitArrayMB from the module, but not maskMB.) Data.BloomFilter.insertMB = \ (@ s_a2ta) (@ a_a2tb) (mb_X2n2 :: Data.BloomFilter.MBloom s_a2ta a_a2tb) (elt_X2n4 :: a_a2tb) -> __letrec { a2_s3g9 :: [Word32] -> State# s_a2ta -> (# State# s_a2ta, () #) [Arity 2 a2_s3g9 = \ (ds_a2S9 :: [Word32]) (eta_s37Y :: State# s_a2ta) -> case ds_a2S9 of wild_a2Sa { [] -> (# eta_s37Y, () #); : y_a2Se ys_a2Sf -> case y_a2Se of wild1_a2Io { W32# x#_a2Iq -> case Data.BloomFilter.maskMB @ s_a2ta @ a_a2tb mb_X2n2 of wild11_a2T0 { I# y#_a2T2 -> case Data.BloomFilter.bitArrayMB @ s_a2ta @ a_a2tb mb_X2n2 of wild2_a2P0 { Data.Array.Base.STUArray ds2_a2P2 ds3_a2P3 ds4_a2P4 marr#_a2P5 -> [......] If I switch to non-record syntax, the inliner does the right thing. <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <8BD0035C-B093-4802-B173-168EE304B990@ece.cmu.edu> Message-ID: Brandon S. Allbery KF8NH wrote: > On 2008 Jun 12, at 16:58, Dominic Steinitz wrote: >> Ok but doesn't that rebuild everything not just the bits that have >> changed? > > Enough stuff usually changes that it's necessary (and for whatever > reason dependencies don't catch enough of it). Recursive Make Considered Harmful: http://miller.emu.id.au/pmiller/books/rmch/ I won't say more. Cheers Ben From dominic.steinitz at blueyonder.co.uk Sat Jun 14 02:42:52 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jun 14 02:34:03 2008 Subject: Rebuilding ghc In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4853686C.10505@blueyonder.co.uk> Simon Peyton-Jones wrote: > Sorry about this -- it's my fault. I did validate a fix to the > desugarer, but ndp isn't part of 'validate'. Turns out that the > change to the desugarer provoked quite subtle and longstanding bug in > the simplifier. > > To get rolling again, use -fno-ds-multi-tyvar. Or just don't compile > NDP. I'll commit a patch shortly. > The reason I'm compiling rather than installing is because I want to use NDP. Where do I put -fno-ds-multi-tyvar so that the build system knows to use it? I'm going to try build.mk. Ok that didn't work and I couldn't find anything about -fno-ds-multi-tyvar in the documentation. Thanks, Dominic. > ../utils/mkdependC/mkdependC -f .depend -I. -Iinclude -I../includes -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=20080517 -I../libraries/base/cbits -I../libraries/base/include -- cbits/directory.c cbits/rawSystem.c cbits/unicode.c > /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H32m -O2 -fasm -Rghc-timing -fno-ds-multi-tyvar -w -I. -Iinclude -Rghc-timing -O0 -W -package directory -package pretty -I../libraries -fglasgow-exts -no-recomp Compat/Unicode.hs Distribution/Compat/Exception.hs Distribution/Compat/ReadP.hs Distribution/Compat/TempFile.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/ReadE.hs Distribution/Simple/Program.hs Distribution/Simple/Utils.hs Distribution/System.hs Distribution/Text.hs Distribution/Verbosity.hs Distribution/Version.hs Language/Haskell/Extension.hs System/FilePath.hs System/FilePath/Posix.hs System/FilePath/Windows.hs Trace/Hpc/Mix.hs Trace/Hpc/Tix.hs Trace/Hpc/Util.hs > ghc-6.9.20080517: unrecognised flags: -fno-ds-multi-tyvar > Usage: For basic information, try the `--help' option. > <> > make[1]: *** [depend] Error 1 > make: *** [stage1] Error 1 From batterseapower at hotmail.com Sat Jun 14 21:15:44 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Jun 14 21:07:46 2008 Subject: Generalized phase control for GHC Message-ID: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> Hi, As some of you may know, I'm working on adding support for dynamically loaded plugins to GHC this summer. As part of this we need a way to specify ordering on the compiler phases installed, so e.g. you can say that a phase you install should run after strictness analysis does. This problem begs for a more modular and principled solution than just reusing the current system where we use the natural numbers to impose an ordering on INLINE/RULE activations. I have proposed a system at http://hackage.haskell.org/trac/ghc/wiki/Plugins/Phases that replaces this with one of named compiler phases not only for plugins but for all activation control in the compiler. The proposal mostly remains backwards compatible with the most common uses of the numeric format, with an exception noted on the page and below. I would be interested in feedback on the design before the implementation is complete and in the wild. I'm especially interested in hearing if you believe that loss of support for numeric phase numbers > 2 is a problem, as this is the only breaking change that I'm proposing. Cheers, Max From richardg at richardg.name Sun Jun 15 00:20:01 2008 From: richardg at richardg.name (Richard Giraud) Date: Sun Jun 15 00:12:05 2008 Subject: Haddock, .lhs, and GHC Message-ID: <48549871.1070006@richardg.name> Hello I did a little digging on this issue and didn't find a definitive answer. According to the Haddock page in the wiki, Haddock is the de facto way of documenting files [http://haskell.org/haskellwiki/Haddock]. Does this mean that literate source files should be discouraged? They seem to be fairly common, especially in conjunction with Cabal (i.e., Setup.lhs). They also appear in quite a few beginner tutorials, which can send new users down the wrong path (e.g., http://haskell.org/haskellwiki/How_to_write_a_Haskell_program). Is there an effort and/or intent to move the GHC sources away from .lhs entirely? --- The reason I ask is: I'm looking at the Test.HUnit modules and there are no Haddock annotations. I thought I'd help document the modules but, when I had a look at the source files, I found they were .lhs instead of .hs. There is already some documentation in the files but it's not visible to Haddock. What's the best way to proceed in a case like this? 1. Shoe-horn in the Haddock annotations by putting them in the code sections (e.g., > -- | Document comment...) but this seems a little cumbersome, especially if these comments show up in the published form of the .lhs file. 2. Rename to the files to .hs and touch up the files so they compile, then add the Haddock annotations. 3. Another option? --- I get the feeling that HUnit isn't getting much attention. Is that because it's "done" or because it's obsolete and will soon be removed? Thanks, Richard G. From dgoldsmith at mac.com Sun Jun 15 02:38:25 2008 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Sun Jun 15 02:30:28 2008 Subject: 6.8.3: make framework-pkg doesn't work Message-ID: I tried building 6.8.3, and just "make" worked, but when I tried "make framework-pkg" I got stuff like this: > "/Users/chak/Code/ghc/ > distrib/MacOS/Info copy.plist" -expandbuildsettings -o /Users/debbie/ > Work/source/ghc-6.8.3/distrib/MacOS/build/Release/GHC.framework/ > Versions/608/Resources/Info.plist I don't have a user named "chak" on my system, so it looks like there are some hardwired paths in the Xcode project for this target. I'm trying "make framework-binary-dist" and that appears to be working better. Deborah From duncan.coutts at worc.ox.ac.uk Sun Jun 15 16:04:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 15 15:51:51 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <48549871.1070006@richardg.name> References: <48549871.1070006@richardg.name> Message-ID: <1213560247.15010.591.camel@localhost> On Sat, 2008-06-14 at 22:20 -0600, Richard Giraud wrote: > I'm looking at the Test.HUnit modules and there are no Haddock > annotations. I thought I'd help document the modules but, when I had a > look at the source files, I found they were .lhs instead of .hs. There > is already some documentation in the files but it's not visible to Haddock. > > What's the best way to proceed in a case like this? > 1. Shoe-horn in the Haddock annotations by putting them in the code > sections (e.g., > -- | Document comment...) but this seems a little > cumbersome, especially if these comments show up in the published form > of the .lhs file. > > 2. Rename to the files to .hs and touch up the files so they compile, > then add the Haddock annotations. > > 3. Another option? You can use: | blah blah > ordinary code And if you're using Cabal then it uses an extended 'unlit' function which generates sensible input for haddock. In fact this only works at the moment with haddock-0.x (ie 0.8, 0.9) because haddock-2.x does it's own unliting. For an example of this lhs/haddock style, see takusen. Duncan From simonpj at microsoft.com Sun Jun 15 23:44:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sun Jun 15 23:36:31 2008 Subject: Rebuilding ghc In-Reply-To: <4853686C.10505@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> <4853686C.10505@blueyonder.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5B36A94@EA-EXMSG-C334.europe.corp.microsoft.com> | Where do I put -fno-ds-multi-tyvar so that the build system knows to use | it? I'm going to try build.mk. | | Ok that didn't work and I couldn't find anything about | -fno-ds-multi-tyvar in the documentation. Yes, in GhcLibHcOpts in build.mk is a good place. The flag isn't documented because it's a debug-only flag that I threw in so that I can measure the effect of this particular desugaring change. It's not really intended for users -- hard to explain just what it does. In any case I'm just about to push a patch which fixes the original problem and makes the flag unnecessary for your purposes. | The reason I'm compiling rather than installing is because I want to use | NDP. Great! I'm copying Roman, Gabi, and Manuel so they know you're doing this. Much of GHC is very stable but NDP emphatically isn't. We're working hard on it, the code is changing a lot, so you may well get short-lived build difficulties. So do have a go, but show us your code, and keep us in touch with what happens. Simon From waldmann at imn.htwk-leipzig.de Mon Jun 16 01:38:09 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Jun 16 01:30:09 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <48549871.1070006@richardg.name> References: <48549871.1070006@richardg.name> Message-ID: <4855FC41.8010806@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Does this mean that literate source files should be discouraged? They > seem to be fairly common, especially in conjunction with Cabal (i.e., > Setup.lhs). I think the reason for having Setup.lhs instead of Setup.hs is that you can put #!/usr/local/bin/runhaskell in their first line. Then chmod +x Setup.lhs and you can do ./Setup.lhs configure etc. So, this has nothing to do with literate programming. Best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVfxBDqiTJ5Q4dm8RAtZkAJ4r0qWQiUmQvsPhJMAFiccMvmJTQgCcCSH9 Y3Wph09j9/j2yJ2bsYYMXfQ= =NIax -----END PGP SIGNATURE----- From dominic.steinitz at blueyonder.co.uk Mon Jun 16 03:12:49 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon Jun 16 03:03:56 2008 Subject: Rebuilding ghc In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5B36A94@EA-EXMSG-C334.europe.corp.microsoft.com> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> <4853686C.10505@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5B36A94@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48561271.9030300@blueyonder.co.uk> Simon Peyton-Jones wrote: > | Where do I put -fno-ds-multi-tyvar so that the build system knows > to use | it? I'm going to try build.mk. | | Ok that didn't work and I > couldn't find anything about | -fno-ds-multi-tyvar in the > documentation. > > Yes, in GhcLibHcOpts in build.mk is a good place. The flag isn't > documented because it's a debug-only flag that I threw in so that I > can measure the effect of this particular desugaring change. It's > not really intended for users -- hard to explain just what it does. > > In any case I'm just about to push a patch which fixes the original > problem and makes the flag unnecessary for your purposes. > Thanks. I put the flag in the right place and got further but see below. Dominic. PS I appreciate all the help I'm getting. > ../compiler/ghc-inplace -H32m -O2 -fasm -Rghc-timing -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -static -I../gmp/gmp uild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o > PrimOps.cmm:945:0: unknown macro: RET_NNNN > <> > make[1]: *** [PrimOps.o] Error 1 > make: *** [stage1] Error 1 From duncan.coutts at worc.ox.ac.uk Mon Jun 16 04:57:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 16 04:45:36 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <4855FC41.8010806@imn.htwk-leipzig.de> References: <48549871.1070006@richardg.name> <4855FC41.8010806@imn.htwk-leipzig.de> Message-ID: <1213606663.15010.618.camel@localhost> On Mon, 2008-06-16 at 07:38 +0200, Johannes Waldmann wrote: > > Does this mean that literate source files should be discouraged? They > > seem to be fairly common, especially in conjunction with Cabal (i.e., > > Setup.lhs). > > I think the reason for having Setup.lhs instead of Setup.hs > is that you can put #!/usr/local/bin/runhaskell > in their first line. Then chmod +x Setup.lhs > and you can do ./Setup.lhs configure etc. > So, this has nothing to do with literate programming. And it's really more trouble than it's worth, IMHO. runghc Setup is the better recommendation I think because it works for .hs or .lhs and it works on operating systems with no concept of #! or chmod. So with that the recommendation then the simplest possible Setup script is: Setup.hs: import Distribution.Simple main = defaultMain Duncan From marlowsd at gmail.com Mon Jun 16 08:52:19 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 16 08:44:19 2008 Subject: Problems interrupting IO with -threaded In-Reply-To: <2608b8a80806111125r245078e5qe96cc95feaacadb4@mail.gmail.com> References: <6d74b0d20806091209k17a08976m940388ec3fce205a@mail.gmail.com> <484F57F5.6000800@gmail.com> <2608b8a80806111125r245078e5qe96cc95feaacadb4@mail.gmail.com> Message-ID: <48566203.9070809@gmail.com> Yitzchak Gale wrote: > Judah Jacobson wrote: >>> I'm writing a program that reads input from the user but should also >>> handle a ctrl-c... >>> It works fine compiled without -threaded, but with -threaded >>> it blocks forever after a ctrl-c. > > Simon Marlow wrote: >> Ah, this is a consequence of the change we made to stdin/stdout/stderr so >> that they no longer use O_NONBLOCK, but with -threaded they use blocking >> foreign calls instead... >> I don't see a good workaround... >> Unix semantics just isn't the right thing when it comes to non-blocking I/O. >> If only there were non-blocking read()/write() system calls, we'd be fine. > > I believe you that the Unix semantics may not be very pretty. But all modern > high-level programming languages have a getChar that can be > interrupted by ^C. Can't we just do what they all do? This is basic, > essential functionality that we use every day. > > In my opinion, Judah should file a bug, and it should be marked > high priority. You're right. I've created a ticket: http://hackage.haskell.org/trac/ghc/ticket/2363 Cheers, Simon From richardg at richardg.name Mon Jun 16 10:14:39 2008 From: richardg at richardg.name (Richard Giraud) Date: Mon Jun 16 10:06:38 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <4855FC41.8010806@imn.htwk-leipzig.de> References: <48549871.1070006@richardg.name> <4855FC41.8010806@imn.htwk-leipzig.de> Message-ID: <4856754F.3080705@richardg.name> I never thought about that. I've been using Setup.hs with "#!/usr/bin/env runhaskell" and never had any problems. I guess the only thing that would be gained by using Setup.lhs is the ability to compile the setup program. Is that something that's commonly done? Richard G. Johannes Waldmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> Does this mean that literate source files should be discouraged? They >> seem to be fairly common, especially in conjunction with Cabal (i.e., >> Setup.lhs). > > I think the reason for having Setup.lhs instead of Setup.hs > is that you can put #!/usr/local/bin/runhaskell > in their first line. Then chmod +x Setup.lhs > and you can do ./Setup.lhs configure etc. > So, this has nothing to do with literate programming. > > Best regards, J.W. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIVfxBDqiTJ5Q4dm8RAtZkAJ4r0qWQiUmQvsPhJMAFiccMvmJTQgCcCSH9 > Y3Wph09j9/j2yJ2bsYYMXfQ= > =NIax > -----END PGP SIGNATURE----- > From alistair at abayley.org Mon Jun 16 10:39:22 2008 From: alistair at abayley.org (Alistair Bayley) Date: Mon Jun 16 10:31:19 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <4856754F.3080705@richardg.name> References: <48549871.1070006@richardg.name> <4855FC41.8010806@imn.htwk-leipzig.de> <4856754F.3080705@richardg.name> Message-ID: <79d7c4980806160739y5764fcccpadb211ea6a1723d2@mail.gmail.com> > I never thought about that. I've been using Setup.hs with "#!/usr/bin/env > runhaskell" and never had any problems. > > I guess the only thing that would be gained by using Setup.lhs is the > ability to compile the setup program. Is that something that's commonly > done? That's what I do. My normal install procedure is: ghc --make setup setup configure setup build setup install If only takes a couple of seconds for ghc to compile setup, and then it runs instantly. If I was to use runghc then it would recompile (in ghci) for each invocation. I use #! in Setup.hs (non-lit) and it compiles fine, so no worries there either. Alistair From duncan.coutts at worc.ox.ac.uk Mon Jun 16 15:06:22 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 16 15:06:04 2008 Subject: Haddock, .lhs, and GHC In-Reply-To: <79d7c4980806160739y5764fcccpadb211ea6a1723d2@mail.gmail.com> References: <48549871.1070006@richardg.name> <4855FC41.8010806@imn.htwk-leipzig.de> <4856754F.3080705@richardg.name> <79d7c4980806160739y5764fcccpadb211ea6a1723d2@mail.gmail.com> Message-ID: <1213643182.15010.654.camel@localhost> On Mon, 2008-06-16 at 15:39 +0100, Alistair Bayley wrote: > > I never thought about that. I've been using Setup.hs with "#!/usr/bin/env > > runhaskell" and never had any problems. > > > > I guess the only thing that would be gained by using Setup.lhs is the > > ability to compile the setup program. Is that something that's commonly > > done? > > That's what I do. My normal install procedure is: > ghc --make setup > setup configure > setup build > setup install Though of course these days we can just: cabal install It compiles Setup.(l)hs if necessary or for build types other than Custom it can just do it directly without going via the Setup script. Duncan From dan.doel at gmail.com Mon Jun 16 15:51:31 2008 From: dan.doel at gmail.com (Dan Doel) Date: Mon Jun 16 15:43:47 2008 Subject: Low-level array performance Message-ID: <200806161551.31696.dan.doel@gmail.com> Greetings, Recently, due to scattered complaints I'd seen on the internet, I set about to rewrite the fannkuch [1] benchmark on the Great Computer Language Shootout. The current entry uses Ptr/Addr#, malloc, etc. so it's not particularly representative of code one would actually write in Haskell these days. Over the past few days, I've written several versions of the benchmark, and collaborated a bit with local speed guru Don Stewart, but an entry that bests the current entry does not seem to be in the cards currently. So, I thought I'd write about some of the issues, and hopefully get some encouraging news about the situation. Issue 1: STUArrays aren't optimized as fully as one might ideally expect. This isn't so much of an issue, I suppose, except possibly for an environment like the shootout. I wrote versions of the benchmark (and particular pieces of the overall benchmark, as well) for both STUArrays, and MUArrays from dons' new uvector [2] library. The STUArray versions are consistently slower, and a look at the core reveals that STUArray code contains significantly more boxing than uvector. This isn't a big deal, as there's no reason not to use uvector, aside from it not being blessed by being in the GHC distribution. However, I thought I'd bring it up in case anyone hasn't heard of the library yet. Issue 2: Reading from/writing to a MutableByteArray# is slower than an Addr# This is, I think, the crux of the issue. The main content of the benchmark is reversing/shifting items in an array. To get a somewhat easier look at the core, I boiled things down to a benchmark that just reverses a small array many times. In the interest of further reducing things, I wrote a version of the benchmark that uses raw Addr#s, and a version that uses raw MutableByteArray#s. I've attached both versions. The fannkuch benchmark (input 11) with byte arrays runs in around 12 seconds on my machine. To get the reversal benchmark to around that time, I can tell it to, for instance, reverse a 10-element array 250 million times. Those same inputs to the Addr# version of the reverse benchmark result in a runtime of 7 to 8 seconds, so there's a significant discrepancy at the level the benchmark actually runs at (the current fannkuch entry that uses Addr#/Ptr takes around 9 seconds, so there's other stuff going on in the benchmark evening them out, but this is likely the source of the difference between the two). uvector performance on the reversal benchmark is comparable with MutableByteArray#, so the practical slowdown using a library for actual public consumption seems to be in the fact that it's based on byte arrays (STUArray again falls further behind by retaining too many boxes). So, to wrap things up: dons and I were rather curious about the performance differences between MutableByteArray# and Addr#, as one might expect them to be comparable, both being low-level, raw pointer type structures; the code for using the two is nearly identical. (If one were to raise an Issue 3, it'd likely be that, even with Addr# and malloc, which is currently the fastest Haskell solution, we're not that fast. A glance at that shootout list reveals that we're beat by a myriad of Java-based languages, Python (Psyco), Ada, Ocaml, Eiffel, Lisp (SBCL), Clean, and of course C++, C, Fortran, etc. Is there any hope of getting performance improvements that will push us up in that list? I've heard that people are working on improved code generation, but I don't know if that can help with this sort of thing (or if it's more of a runtime system area). While writing this mail, it came to mind that this is also a potential source of slowness in the sorting 'library' I've been writing for uvector. I already have some routines that are competitive with/beat qsort from glibc, but GNU's C++ STL introsort implementation has remained untouched. However, if reads/writes simply take twice as much time in Haskell as they do in C++, my results aren't as surprising.) Anyhow, thanks for any light that can be shed on the subject. 1: http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch 2: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector -------------- next part -------------- A non-text attachment was scrubbed... Name: ByteArr.hs Type: text/x-hssrc Size: 1413 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080616/4aea9bc1/ByteArr.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Ptr.hs Type: text/x-hssrc Size: 867 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080616/4aea9bc1/Ptr.bin From igloo at earth.li Mon Jun 16 17:05:58 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 16 16:57:58 2008 Subject: Rebuilding ghc In-Reply-To: <48561271.9030300@blueyonder.co.uk> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> <4853686C.10505@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5B36A94@EA-EXMSG-C334.europe.corp.microsoft.com> <48561271.9030300@blueyonder.co.uk> Message-ID: <20080616210558.GA6029@matrix.chaos.earth.li> On Mon, Jun 16, 2008 at 08:12:49AM +0100, Dominic Steinitz wrote: > > Thanks. I put the flag in the right place and got further but see below. > > > ../compiler/ghc-inplace -H32m -O2 -fasm -Rghc-timing -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -static -I../gmp/gmp uild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o > > PrimOps.cmm:945:0: unknown macro: RET_NNNN RET_NNNN is a relatively recent addition to compiler/cmm/CmmParse.y by the patch [Fix conversions between Double/Float and simple-integer Ian Lynagh **20080614152337] { I suspect that for some reason something didn't rebuild properly after you pulled that patch. Thanks Ian From simonpj at microsoft.com Tue Jun 17 00:36:20 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 17 00:28:07 2008 Subject: Low-level array performance In-Reply-To: <200806161551.31696.dan.doel@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5B3719C@EA-EXMSG-C334.europe.corp.microsoft.com> Dan John Dias is indeed spending 6 months at Microsoft to work on GHC's back end. He's doing a pretty wholesale re-architecting job, so it will be a couple of months before we have the new setup glued together, but once we do I hope that we'll have a much more friendly framework in place for doing good optimizations. Meanwhile, concrete examples like yours are very useful. It would be still more useful if you and Don could pinpoint more accurately just what the difference (say) between Addr# and MutableByteArray# is. Is it array bounds checking, for example? Looking first at the Core that is generated and then (if it looks the same on both cases) at the C--, is often illuminating. If you can say "for this little loop, GHC generates this stupid code sequence" that's particularly helpful. (Don often does this.) Even if you don't, we'll still take a look in due course, but the more you can pin it down the more motivating it is for us to fix it! Do start a Trac ticket so your thoughts and code examples are not lost in the welter of email. Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Dan Doel | Sent: 16 June 2008 20:52 | To: glasgow-haskell-users@haskell.org | Subject: Low-level array performance | | Greetings, | | Recently, due to scattered complaints I'd seen on the internet, I set about | to | rewrite the fannkuch [1] benchmark on the Great Computer Language Shootout. | The current entry uses Ptr/Addr#, malloc, etc. so it's not particularly | representative of code one would actually write in Haskell these days. Over | the past few days, I've written several versions of the benchmark, and | collaborated a bit with local speed guru Don Stewart, but an entry that bests | the current entry does not seem to be in the cards currently. So, I thought | I'd write about some of the issues, and hopefully get some encouraging news | about the situation. | | Issue 1: STUArrays aren't optimized as fully as one might ideally expect. | | This isn't so much of an issue, I suppose, except possibly for an environment | like the shootout. I wrote versions of the benchmark (and particular pieces | of the overall benchmark, as well) for both STUArrays, and MUArrays from | dons' new uvector [2] library. The STUArray versions are consistently slower, | and a look at the core reveals that STUArray code contains significantly more | boxing than uvector. This isn't a big deal, as there's no reason not to use | uvector, aside from it not being blessed by being in the GHC distribution. | However, I thought I'd bring it up in case anyone hasn't heard of the library | yet. | | Issue 2: Reading from/writing to a MutableByteArray# is slower than an Addr# | | This is, I think, the crux of the issue. The main content of the benchmark is | reversing/shifting items in an array. To get a somewhat easier look at the | core, I boiled things down to a benchmark that just reverses a small array | many times. In the interest of further reducing things, I wrote a version of | the benchmark that uses raw Addr#s, and a version that uses raw | MutableByteArray#s. I've attached both versions. | | The fannkuch benchmark (input 11) with byte arrays runs in around 12 seconds | on my machine. To get the reversal benchmark to around that time, I can tell | it to, for instance, reverse a 10-element array 250 million times. Those same | inputs to the Addr# version of the reverse benchmark result in a runtime of 7 | to 8 seconds, so there's a significant discrepancy at the level the benchmark | actually runs at (the current fannkuch entry that uses Addr#/Ptr takes around | 9 seconds, so there's other stuff going on in the benchmark evening them out, | but this is likely the source of the difference between the two). | | uvector performance on the reversal benchmark is comparable with | MutableByteArray#, so the practical slowdown using a library for actual | public consumption seems to be in the fact that it's based on byte arrays | (STUArray again falls further behind by retaining too many boxes). | | So, to wrap things up: dons and I were rather curious about the performance | differences between MutableByteArray# and Addr#, as one might expect them to | be comparable, both being low-level, raw pointer type structures; the code | for | using the two is nearly identical. | | (If one were to raise an Issue 3, it'd likely be that, even with Addr# and | malloc, which is currently the fastest Haskell solution, we're not that fast. | A glance at that shootout list reveals that we're beat by a myriad of | Java-based languages, Python (Psyco), Ada, Ocaml, Eiffel, Lisp (SBCL), Clean, | and of course C++, C, Fortran, etc. Is there any hope of getting performance | improvements that will push us up in that list? I've heard that people are | working on improved code generation, but I don't know if that can help with | this sort of thing (or if it's more of a runtime system area). | | While writing this mail, it came to mind that this is also a potential source | of slowness in the sorting 'library' I've been writing for uvector. I already | have some routines that are competitive with/beat qsort from glibc, but GNU's | C++ STL introsort implementation has remained untouched. However, if | reads/writes simply take twice as much time in Haskell as they do in C++, my | results aren't as surprising.) | | Anyhow, thanks for any light that can be shed on the subject. | | 1: http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch | 2: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector From dominic.steinitz at blueyonder.co.uk Tue Jun 17 01:23:43 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Jun 17 01:14:53 2008 Subject: Rebuilding ghc In-Reply-To: <20080616210558.GA6029@matrix.chaos.earth.li> References: <484EE682.1070801@blueyonder.co.uk> <6d74b0d20806101700qecea33qf420ba7b433f59ef@mail.gmail.com> <485183EF.7020403@blueyonder.co.uk> <6d74b0d20806121339r5c1d0dd0nfa8945582de4261@mail.gmail.com> <48518DFA.9030605@blueyonder.co.uk> <48518F64.90000@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5AB352A@EA-EXMSG-C334.europe.corp.microsoft.com> <4853686C.10505@blueyonder.co.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE5B36A94@EA-EXMSG-C334.europe.corp.microsoft.com> <48561271.9030300@blueyonder.co.uk> <20080616210558.GA6029@matrix.chaos.earth.li> Message-ID: <48574A5F.6030303@blueyonder.co.uk> Ian Lynagh wrote: > On Mon, Jun 16, 2008 at 08:12:49AM +0100, Dominic Steinitz wrote: >> Thanks. I put the flag in the right place and got further but see below. >> >>> ../compiler/ghc-inplace -H32m -O2 -fasm -Rghc-timing -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -static -I../gmp/gmp uild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o >>> PrimOps.cmm:945:0: unknown macro: RET_NNNN > > RET_NNNN is a relatively recent addition to compiler/cmm/CmmParse.y by > the patch > [Fix conversions between Double/Float and simple-integer > Ian Lynagh **20080614152337] { > I suspect that for some reason something didn't rebuild properly after > you pulled that patch. > > > Thanks > Ian > > Success! > dom@lagrange:~/ghc> ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.9.20080616 Thanks, Dominic. From marlowsd at gmail.com Tue Jun 17 06:48:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 17 06:40:58 2008 Subject: Low-level array performance In-Reply-To: <200806161551.31696.dan.doel@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> Message-ID: <4857969B.4040009@gmail.com> Dan Doel wrote: > Issue 2: Reading from/writing to a MutableByteArray# is slower than an Addr# > > This is, I think, the crux of the issue. The main content of the benchmark is > reversing/shifting items in an array. To get a somewhat easier look at the > core, I boiled things down to a benchmark that just reverses a small array > many times. In the interest of further reducing things, I wrote a version of > the benchmark that uses raw Addr#s, and a version that uses raw > MutableByteArray#s. I've attached both versions. So I tried your examples and the Addr# version looks slower than the MBA# version: $ ./Ptr 100 1000000 +RTS -sstderr Done. 48,196,560 bytes allocated in the heap 27,381,764 bytes copied during GC (scavenged) 18,260,784 bytes copied during GC (not scavenged) 14,389,248 bytes maximum residency (5 sample(s)) 92 collections in generation 0 ( 0.09s) 5 collections in generation 1 ( 0.13s) 28 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.68s ( 0.69s elapsed) GC time 0.22s ( 0.28s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.90s ( 0.97s elapsed) $ ./ByteArr 100 1000000 +RTS -sstderr Done. 4,042,700 bytes allocated in the heap 1,272 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 16,384 bytes maximum residency (1 sample(s)) 2 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 5 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.53s ( 0.54s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.53s ( 0.54s elapsed) I tried with 6.8.2 and 6.8.3, using -O2 in both cases. I tried the Ptr version with and without -fvia-C -optc-O2, no difference. Are these exactly the same programs you measured? What parameters did you use? Cheers, Simon From dan.doel at gmail.com Tue Jun 17 12:32:20 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Jun 17 12:24:23 2008 Subject: Low-level array performance In-Reply-To: <4857969B.4040009@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> <4857969B.4040009@gmail.com> Message-ID: <200806171232.20666.dan.doel@gmail.com> On Tuesday 17 June 2008, Simon Marlow wrote: > So I tried your examples and the Addr# version looks slower than the MBA# > version: Hmm... > I tried with 6.8.2 and 6.8.3, using -O2 in both cases. I tried the Ptr > version with and without -fvia-C -optc-O2, no difference. I had forgotten about the via-c in the pragma when I sent it, but I've tested it both via-c and with the new backend (and triple checked since your message), and I always come away with the Ptr version being faster. -fvia-c doesn't seem to affect the speed of the Addr# version much, while it improves the speed of the MBA# version. However, even with the improved speed, Addr# seems to edge it out here. With the new backend, I get the results I sent in my initial mail. The ByteArray version takes 11 - 12 seconds to reverse a size 10 array 250 million times, whereas the Addr# version takes around 7 seconds. (I also noticed a bug I'd missed before sending the ByteArray version. It should allocate based on w, but I left it hard coded to 4# when I was experimenting. This was causing segmentation faults on large arrays on my machine, since I'm running in 64-bit mode, and 8# is the correct value here. Are you running in 32-bit, and if so, could that be the source of our discrepancy?) > Are these exactly the same programs you measured? What parameters did you > use? Aside from the couple oversights above, yes. The actual fannkuch benchmark doesn't use very large arrays. The current test input is n = 11, and all the arrays it uses are length n. It gets its work from copying, reversing and shifting (portions of) those arrays n! or more times. So, I thought it'd be truer to the benchmark to reverse a small array many times. I've been running with command lines like './ByteArr 250000000 10', which says to reverse a size-10 array 250 million times. I tested with other sizes, and things seem to stay about the same increasing the array size and decreasing the iterations by the same factor, until I got to an array size of around 100,000, at which point there's a drop off for both (Addr# still being faster). I assume that's due to cache effects. Here's some example runs, using '--make -O2' for both (OPTIONS pragma changed to only have -fglasgow-exts for both, and the w bug fixed). ./ByteArr 250000000 10 +RTS -sstderr Done. 56,824 bytes allocated in the heap 552 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 45,056 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 1 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 10.35s ( 11.15s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 10.36s ( 11.15s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 5,486 bytes per MUT second Productivity 100.0% of total user, 92.9% of total elapsed ./Ptr 250000000 10 +RTS -sstderr Done. 57,840 bytes allocated in the heap 552 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 45,056 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 1 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 6.53s ( 7.05s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 6.53s ( 7.05s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 8,854 bytes per MUT second Productivity 100.0% of total user, 92.7% of total elapsed As I mentioned before, using -fvia-c -optc-O2 leaves Ptr unchanged, and speeds up ByteArr, but not enough to catch up with Ptr (here, at least). Anyhow, my apologies for the mistakes above, and thanks for your time and assistance. I'll try puzzling over the C-- some and probably open a trac ticket a bit later as the other Simon suggested (if that's still appropriate). Thanks again, -- Dan From daniel.is.fischer at web.de Tue Jun 17 13:10:45 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Jun 17 13:00:44 2008 Subject: Low-level array performance In-Reply-To: <200806171232.20666.dan.doel@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> <4857969B.4040009@gmail.com> <200806171232.20666.dan.doel@gmail.com> Message-ID: <200806171910.45771.daniel.is.fischer@web.de> Am Dienstag, 17. Juni 2008 18:32 schrieb Dan Doel: > On Tuesday 17 June 2008, Simon Marlow wrote: > > So I tried your examples and the Addr# version looks slower than the MBA# > > version: > > Hmm... > > > I tried with 6.8.2 and 6.8.3, using -O2 in both cases. I tried the Ptr > > version with and without -fvia-C -optc-O2, no difference. > > I had forgotten about the via-c in the pragma when I sent it, but I've > tested it both via-c and with the new backend (and triple checked since > your message), and I always come away with the Ptr version being faster. > -fvia-c doesn't seem to affect the speed of the Addr# version much, while > it improves the speed of the MBA# version. However, even with the improved > speed, Addr# seems to edge it out here. > > With the new backend, I get the results I sent in my initial mail. The > ByteArray version takes 11 - 12 seconds to reverse a size 10 array 250 > million times, whereas the Addr# version takes around 7 seconds. > I've experimented a bit and found that Ptr is faster for small arrays (only very slightly so if compiled with -fvia-C -optc-O3), but ByteArr performs much better for larger arrays dafis@linux:~/Documents/haskell/move> ./PtrC +RTS -sstderr -RTS 20 10000000 ./PtrC 20 10000000 +RTS -sstderr Done. 481,596,836 bytes allocated in the heap 257,665,360 bytes copied during GC (scavenged) 171,919,440 bytes copied during GC (not scavenged) 117,149,696 bytes maximum residency (8 sample(s)) 919 collections in generation 0 ( 3.44s) 8 collections in generation 1 ( 24.99s) 226 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 8.16s ( 9.06s elapsed) GC time 28.43s ( 30.11s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 36.59s ( 39.16s elapsed) %GC time 77.7% (76.9% elapsed) Alloc rate 59,019,220 bytes per MUT second Productivity 22.3% of total user, 20.8% of total elapsed dafis@linux:~/Documents/haskell/move> ./ByteArrC +RTS -sstderr -RTS 20 10000000 ./ByteArrC 20 10000000 +RTS -sstderr Done. 40,041,976 bytes allocated in the heap 1,272 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 16,384 bytes maximum residency (1 sample(s)) 2 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 40 Mb total memory in use INIT time 0.00s ( 0.02s elapsed) MUT time 5.03s ( 5.32s elapsed) GC time 0.00s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 5.03s ( 5.35s elapsed) %GC time 0.0% (0.3% elapsed) Alloc rate 7,960,631 bytes per MUT second Productivity 100.0% of total user, 94.0% of total elapsed Using GHC 6.8.2 The GC time for the Addr# version is frightening From dan.doel at gmail.com Tue Jun 17 14:35:38 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Jun 17 14:27:37 2008 Subject: Low-level array performance In-Reply-To: <200806171910.45771.daniel.is.fischer@web.de> References: <200806161551.31696.dan.doel@gmail.com> <200806171232.20666.dan.doel@gmail.com> <200806171910.45771.daniel.is.fischer@web.de> Message-ID: <200806171435.39200.dan.doel@gmail.com> On Tuesday 17 June 2008, Daniel Fischer wrote: > I've experimented a bit and found that Ptr is faster for small arrays (only > very slightly so if compiled with -fvia-C -optc-O3), but ByteArr performs > much better for larger arrays > ... > The GC time for the Addr# version is frightening I had an entire e-mail written about what a bizarre and interesting result you'd just found, but unfortunately, I then remembered exactly how the array gets filled in the Ptr version. Namely: (Ptr a) <- newArray [0..n-1] Which, I assume does something terrible, like calling length to get the size needed for the array, while also needing the values after array creation to feed into it. For small arrays like the ones I'd been testing with, this doesn't matter, because the work done on the list is negligible. However, when you get to very large lists (100,000 elements and above, apparently) this starts causing massive space leaks, which explains the terrible GC behavior we were seeing. If you change the benchmark like so: bench :: Int -> Int -> IO () bench k n = do (Ptr a) <- mallocArray n :: IO (Ptr Int) fill a n replicateM_ k (reverse a 0 (n-1)) fill :: Addr# -> Int -> IO () fill a (I# n) = IO (go 0#) where go i s | i <# n = case writeIntOffAddr# a i i s of s -> go (i +# 1#) s | otherwise = (# s, () #) The space leak goes away, and the runtimes stay consistent. Up to around 10,000 elements, Ptr hovers around 6s, and ByteArray (-fasm) stays around 11. At 100,000, Ptr jumps to 12-13s, and ByteArray goes to 14-16 and stays there (again, I imagine due to running into bad cache effects at that level). This is all for size * iterations = 2.5 billion on my machine. A good catch anyhow, though. That could explain why Simon Marlow was seeing the Addr# version as slower, since he was using a large array, and thus work done on the list could have contributed significantly (although MUT time was higher with Ptr, so it would have had to contribute work there, not just GC thrashing). Thanks for the input, -- Dan From igloo at earth.li Tue Jun 17 14:59:45 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 17 14:51:43 2008 Subject: ANNOUNCE: GHC version 6.8.3 Message-ID: <20080617185945.GA2262@matrix.chaos.earth.li> ============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.2, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.3/html/users_guide/release-6-8-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 haskell at list.mightyreason.com Tue Jun 17 15:09:31 2008 From: haskell at list.mightyreason.com (haskell@list.mightyreason.com) Date: Tue Jun 17 15:01:33 2008 Subject: Low-level array performance In-Reply-To: <200806171910.45771.daniel.is.fischer@web.de> References: <200806161551.31696.dan.doel@gmail.com> <4857969B.4040009@gmail.com> <200806171232.20666.dan.doel@gmail.com> <200806171910.45771.daniel.is.fischer@web.de> Message-ID: <48580BEB.9090702@list.mightyreason.com> I see that Dan Doel's post favoring Ptr/Addr# has the same allocation amounts (from +RTS -sstderr) for Ptr/Addr# and the MutableByteArray# Everyone else sees more allocation for Ptr/Addr# than MBA# and see MBA# as faster in these cases. I myself (on G4) see more allocation [just like Simon Marlow] for Ptr/Addr# and find it slower. If I boost the initial memory with "-A 100m" then Ptr still allocated more, but the timing difference becomes quite small: The Ptr/Addr# code now runs in: pamac-cek10:tmp chrisk$ time ./addr 100 1000000 +RTS -sstderr -A100m ./a 100 1000000 +RTS -sstderr -A100m Done. 48,182,068 bytes allocated in the heap 276 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 20,480 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 97 Mb total memory in use INIT time 0.00s ( 0.01s elapsed) MUT time 1.54s ( 2.43s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.55s ( 2.44s elapsed) %GC time 0.2% (0.1% elapsed) Alloc rate 31,205,254 bytes per MUT second Productivity 99.6% of total user, 63.1% of total elapsed real 0m2.728s user 0m1.548s sys 0m0.207s And the MutableByteArray# code now runs in: pamac-cek10:tmp chrisk$ time ./mba 100 1000000 +RTS -sstderr -A100m ./m 100 1000000 +RTS -sstderr -A100m Done. 4,023,784 bytes allocated in the heap 276 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 20,480 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 101 Mb total memory in use INIT time 0.00s ( 0.01s elapsed) MUT time 1.50s ( 2.30s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.51s ( 2.32s elapsed) %GC time 0.3% (0.2% elapsed) Alloc rate 2,668,201 bytes per MUT second Productivity 99.6% of total user, 65.0% of total elapsed real 0m2.335s user 0m1.513s sys 0m0.049s From daniel.is.fischer at web.de Tue Jun 17 15:28:14 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Jun 17 15:18:09 2008 Subject: Low-level array performance In-Reply-To: <200806171435.39200.dan.doel@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> <200806171910.45771.daniel.is.fischer@web.de> <200806171435.39200.dan.doel@gmail.com> Message-ID: <200806172128.14360.daniel.is.fischer@web.de> Am Dienstag, 17. Juni 2008 20:35 schrieb Dan Doel: > On Tuesday 17 June 2008, Daniel Fischer wrote: > > I've experimented a bit and found that Ptr is faster for small arrays > > (only very slightly so if compiled with -fvia-C -optc-O3), but ByteArr > > performs much better for larger arrays > > ... > > The GC time for the Addr# version is frightening > > I had an entire e-mail written about what a bizarre and interesting result > you'd just found, but unfortunately, I then remembered exactly how the > array gets filled in the Ptr version. Namely: > > (Ptr a) <- newArray [0..n-1] Ouch. I should've looked at both sources, that would have been obvious then :) > > Which, I assume does something terrible, like calling length to get the > size needed for the array, while also needing the values after array > creation to feed into it. For small arrays like the ones I'd been testing > with, this doesn't matter, because the work done on the list is negligible. > However, when you get to very large lists (100,000 elements and above, > apparently) this starts causing massive space leaks, which explains the > terrible GC behavior we were seeing. > > If you change the benchmark like so: > > bench :: Int -> Int -> IO () > bench k n = do (Ptr a) <- mallocArray n :: IO (Ptr Int) > fill a n > replicateM_ k (reverse a 0 (n-1)) > > fill :: Addr# -> Int -> IO () > fill a (I# n) = IO (go 0#) > where > go i s > > | i <# n = case writeIntOffAddr# a i i s of s -> go (i +# 1#) s > | otherwise = (# s, () #) > > The space leak goes away, and the runtimes stay consistent. Up to around > 10,000 elements, Ptr hovers around 6s, and ByteArray (-fasm) stays around > 11. At 100,000, Ptr jumps to 12-13s, and ByteArray goes to 14-16 and stays > there (again, I imagine due to running into bad cache effects at that > level). This is all for size * iterations = 2.5 billion on my machine. Since my computer is slower, I confined my tests to size*iterations ~= 10^9. Mostly, I find no noticeable difference, between 0.2 and 0.5 %, sometimes one faster, sometimes the other. I have the impression that the Ptr version is the faster more often than the ByteArr version, but the tendency isn't very strong. That applies to both compiled with -O2 -fvia-C -optc-O3. Compiling with -O2 -fasm doesn't make a noticeable difference for Ptr, but is about 13% slower for ByteArr when the arrays are large (too large for the cache, I suppose) and about 50% slower for small arrays. So what I can read off that is that the native code generator still has to catch up for such code, not that either way of implementing arrays is inherently faster. > > A good catch anyhow, though. That could explain why Simon Marlow was seeing > the Addr# version as slower, since he was using a large array, and thus > work done on the list could have contributed significantly (although MUT > time was higher with Ptr, so it would have had to contribute work there, > not just GC thrashing). > > Thanks for the input, > -- Dan Cheers, Daniel From dan.doel at gmail.com Tue Jun 17 16:37:02 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Jun 17 16:29:12 2008 Subject: Low-level array performance In-Reply-To: <48580BEB.9090702@list.mightyreason.com> References: <200806161551.31696.dan.doel@gmail.com> <200806171910.45771.daniel.is.fischer@web.de> <48580BEB.9090702@list.mightyreason.com> Message-ID: <200806171637.02586.dan.doel@gmail.com> On Tuesday 17 June 2008, haskell@list.mightyreason.com wrote: > I see that Dan Doel's post favoring Ptr/Addr# > has the same allocation amounts (from +RTS -sstderr) for Ptr/Addr# and the > MutableByteArray# > > Everyone else sees more allocation for Ptr/Addr# than MBA# and see MBA# as > faster in these cases. > > I myself (on G4) see more allocation [just like Simon Marlow] for Ptr/Addr# > and find it slower. If I boost the initial memory with "-A 100m" then Ptr > still allocated more, but the timing difference becomes quite small: Pardon my noise, but is this still with the version of Ptr.hs that would (in your case) allocate a 1 million element list and traverse it twice, or the revision that fills the array in a loop with an Int#? If it's the former, and Addr# is tying MutableByteArray# even with operations on a 40-some megabyte list (if the allocation is any indication), then the actual Addr# operations are probably faster for you, too. :) I'll attach new, hopefully bug-free versions of the benchmark to this message. Of course, without the list overhead, the ByteArr appears to allocate much more than Ptr for large arrays, because the n*w byte array shows up in the heap allocation, whereas the malloced memory does not. None of this should be a factor in the actual fannkuch benchmark, of course, which only allocates 3 arrays of size 11. Cheers, -- Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: ByteArr.hs Type: text/x-hssrc Size: 1407 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080617/e506727d/ByteArr.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Ptr.hs Type: text/x-hssrc Size: 1079 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080617/e506727d/Ptr.bin From bos at serpentine.com Tue Jun 17 19:16:14 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Jun 17 19:08:12 2008 Subject: Symbols in built executables Message-ID: Here's something I just stumbled upon by accident: at least on Linux, GHC emits huge numbers of symbols into the binaries it generates. Here's Haddock, which I compiled without any funny debug options: $ du -h haddock-0.9 4.1M haddock-0.9 $ nm haddock-0.9 | wc -l 37938 $ strip haddock-0.9 $ du -h haddock-0.9 2.7M haddock-0.9 I happened upon this because I'm repackaging GHC 6.8.3 for Fedora, and rpmlint complained that haddock was not stripped. The RPM packager automatically strips binaries using "strip -g", but that wasn't stripping any of the abovementioned symbols. I don't know what the purpose of those symbols might be. Could someone fill me in, please? Can they actually be used for anything? From daniel.is.fischer at web.de Wed Jun 18 04:10:57 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Jun 18 04:00:54 2008 Subject: Low-level array performance In-Reply-To: <200806171637.02586.dan.doel@gmail.com> References: <200806161551.31696.dan.doel@gmail.com> <48580BEB.9090702@list.mightyreason.com> <200806171637.02586.dan.doel@gmail.com> Message-ID: <200806181010.57227.daniel.is.fischer@web.de> Am Dienstag, 17. Juni 2008 22:37 schrieb Dan Doel: > I'll attach new, hopefully bug-free versions of the benchmark to this > message. With -O2 -fvia-C -optc-O3, the difference is small (less than 1%), but today, ByteArr is faster more often. > > Of course, without the list overhead, the ByteArr appears to allocate much > more than Ptr for large arrays, because the n*w byte array shows up in the > heap allocation, whereas the malloced memory does not. None of this should > be a factor in the actual fannkuch benchmark, of course, which only > allocates 3 arrays of size 11. > > Cheers, > -- Dan Cheers, Daniel From marlowsd at gmail.com Wed Jun 18 05:09:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 18 05:01:55 2008 Subject: Symbols in built executables In-Reply-To: References: Message-ID: <4858D0E1.5000806@gmail.com> Bryan O'Sullivan wrote: > Here's something I just stumbled upon by accident: at least on Linux, > GHC emits huge numbers of symbols into the binaries it generates. > Here's Haddock, which I compiled without any funny debug options: > > $ du -h haddock-0.9 > 4.1M haddock-0.9 > $ nm haddock-0.9 | wc -l > 37938 > $ strip haddock-0.9 > $ du -h haddock-0.9 > 2.7M haddock-0.9 > > I happened upon this because I'm repackaging GHC 6.8.3 for Fedora, and > rpmlint complained that haddock was not stripped. The RPM packager > automatically strips binaries using "strip -g", but that wasn't > stripping any of the abovementioned symbols. > > I don't know what the purpose of those symbols might be. Could someone > fill me in, please? Can they actually be used for anything? We didn't put them there on purpose, if that's what you're asking :) These are just the symbols that get left in by the linker by default. gdb and things like valgrind can use them, but they're not a lot of use in general. There tend to be a lot of local symbols left around too, which are of even less use. At one time I used to strip these out when making libraries, but it was tricky and non-portable, so I think we stopped doing it. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Jun 18 06:53:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 18 06:41:08 2008 Subject: Symbols in built executables In-Reply-To: References: Message-ID: <1213786429.15010.798.camel@localhost> On Tue, 2008-06-17 at 16:16 -0700, Bryan O'Sullivan wrote: > Here's something I just stumbled upon by accident: at least on Linux, > GHC emits huge numbers of symbols into the binaries it generates. > Here's Haddock, which I compiled without any funny debug options: > > $ du -h haddock-0.9 > 4.1M haddock-0.9 > $ nm haddock-0.9 | wc -l > 37938 > $ strip haddock-0.9 > $ du -h haddock-0.9 > 2.7M haddock-0.9 > > I happened upon this because I'm repackaging GHC 6.8.3 for Fedora, and > rpmlint complained that haddock was not stripped. The RPM packager > automatically strips binaries using "strip -g", but that wasn't > stripping any of the abovementioned symbols. According to man strip, the -g flag means only strip debugging symbols. But ghc doesn't generate any debugging symbols (and ghc does not pass -g to gcc so nor does gcc). So it seems to me that it's not surprising that you still get all the symbols. What is a surprise is that rpm only uses strip -g when rpmlint seems to expect normal strip. > I don't know what the purpose of those symbols might be. Could someone > fill me in, please? Can they actually be used for anything? I don't think they're used for anything. Cabal-1.4 now strips executables by default upon installation (distros that want to do the strip themselves can disable this). Duncan From chak at cse.unsw.edu.au Wed Jun 18 08:22:39 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jun 18 08:14:45 2008 Subject: ANNOUNCE: GHC version 6.8.3 - Mac OS X, Intel/Leopard In-Reply-To: <20080617185945.GA2262@matrix.chaos.earth.li> References: <20080617185945.GA2262@matrix.chaos.earth.li> Message-ID: Ian Lynagh: > ============================================================= > The (Interactive) Glasgow Haskell Compiler -- version 6.8.3 > ============================================================= > > The GHC Team is pleased to announce a new patchlevel release of GHC. > This release contains a number of bugfixes relative to 6.8.2, so we > recommend upgrading. An installer package for Mac OS X, Intel/Leopard, is available at http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg The packages requires Xcode 3.0 to be already installed. You can find Xcode 3.0 on your Leopard installation DVD (or at .) IF you installed one of the pre-release packages AND the final release package doesn't install properly, just remove the pre-release first by executing sudo /Library/Frameworks/GHC.framework/Tools/Uninstaller (You can remove any other GHC installer package in the same way.) Manuel PS: I will post instructions on how to create a PPC/Leopard installer package in the next few days (unfortunately, the 6.8.3 release tar ball is not sufficient). Package creation does not currently work for Tiger. From mechvel at botik.ru Wed Jun 18 08:39:57 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Jun 18 08:31:59 2008 Subject: 6.8.3 against DoCon Message-ID: <20080618123956.GA3292@scico.botik.ru> Dear GHC developers, I wonder whether ghc-6.8.3 is better than 6.8.2. Because 6.8.2 makes DoCon-2.11 under -M400m. And 6.8.3 does not suffice -M500m. It breaks with the heap exhaustion at the module RsePol_. -------------------------------------------------- Moreover, repeated make docon again breaks with the heap exhaustion for -M500m. So this memory is spent to compile a single current module. -------------------------------------------------- The last (difficult) module is RsePol_. And `make' is slower than in 6.8.2, at least at this module. I do not believe that a reasonable compiler may need more than 500 Mb for compiling this poor RsePol_. Second, for the candidate version I reported to the e-mail lists the two problems. The second one was about this memory and time strangeness in compiling RsePol_. Now, you issue an official release, without even considering the second problem. I do not know, maybe this RsePol_ is somehow too irregular (with overlapping instance, etc.), maybe, DoCon is guilty. But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ? Actually, ghc-6.8.3 does not support DoCon. I wonder what to do. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Wed Jun 18 09:38:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 18 09:30:38 2008 Subject: 6.8.3 against DoCon In-Reply-To: <20080618123956.GA3292@scico.botik.ru> References: <20080618123956.GA3292@scico.botik.ru> Message-ID: <20080618133840.GA4052@matrix.chaos.earth.li> Hi Serge, On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote: > > But as ghc-6.8.2 handles DoCon all right, why do not you > investigate this difference in 6.8.3 ? We did investigate it - the details are in this trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2328 but the conclusion was that overall it was best to leave things as they are. Unfortunately, this means that performance with GHC 6.8.3 is worse for DoCon; hopefully things will be better with 6.10.1! Thanks Ian From sedillard at ucdavis.edu Wed Jun 18 11:33:25 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Wed Jun 18 11:25:18 2008 Subject: Fundeps, instances and inference Message-ID: Hi, I've been fidgeting with a fixed-length list library, for things like 3d vectors/points, rgba tuples, etc. The data type is data a :. b = (:.) a b deriving (everything reasonable) infixr :. Nothing in that type specifies that for the partially instantiated type t1:.t2:.t3, t1 and t2 should be equal. (Like Int:.Int:.() for a 2D integer point.) But t1 and t2 will always will be equal, at least I want them to always be equal, and everything useful I can think of needs them to be equal. (Note I won't actually store things in these data types. This is just a way of defining operations. Packed arrays and vectors will be converted to/from these types in a stream-fusioney kind of way. That's the plan, at least.) Anyway, I don't need to force them to be equal because all of the functions for these list-like things come in the form of classes, and those classes have fundeps, and the fundeps let me enforce type constraints. The problem I'm having is making these constraints work nicely with inference. I'm not sure exactly whats going on, which is why I'm asking the list. For an example, folding: -- the fold function/class class Fold a v | v -> a where fold :: (a -> a -> a) -> v -> a foldl :: (b -> a -> b) -> b -> v -> b foldr :: (a -> b -> b) -> b -> v -> b -- base case of the recursion, () is like [] instance Fold a (a:.()) where fold f (a:._) = a foldl f z (a:._) = f z a foldr f z (a:._) = f a z -- inductive case. Pick one of the "instance" declarations below... instance Fold a (a:.u) => Fold a (a:.a:.u) where -- I1 instance Fold a (a2:.u) => Fold a (a:.a2:.u) where -- I2 fold f (a:.v) = f a (fold f v) foldl f z (a:.v) = f (foldl f z v) a foldr f z (a:.v) = f a (foldr f z v) Now, both of those instance declarations work. The first one (I1) specifies that all of the list elements should be the same type, "a". The second (I2) doesn't say that right away, because one is 'a' and the other is 'a2.' However the fundep (v->a) will force a and a2 to match, so from orbit the two instances appear the same. In practice, I1 does not cause the type checker to infer the type of list elements, while I2 does. So, in ghci, if you do foldr (:) [] (1:.2:.3:.()) With I1 you'll get an error like "no instance for Fold a (t :. t1 :. t2 :. ()).." But with I2, it will infer 1 2 and 3 to all be of type "Num a => a" and will evaluate the expression to [1,2,3]. So the question is "Why?" For simple things like fold, map, etc., I can massage the instance declarations so that the type checker infers things for me, but for more complicated recursions, I'm having trouble. (For example, computing determinants by minor expansion. Not the most efficient way I know, but if I can't figure that out there's no hope for Gaussian elimination.) The functions work, its just the inference that isn't working. I'm forced to annotate things, or at least ensure that the types of the arguments can be inferred from someplace else. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080618/f21ff3a5/attachment.htm From mechvel at botik.ru Wed Jun 18 12:14:20 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Jun 18 12:06:25 2008 Subject: 6.8.3 against DoCon In-Reply-To: <20080618133840.GA4052@matrix.chaos.earth.li> References: <20080618123956.GA3292@scico.botik.ru> <20080618133840.GA4052@matrix.chaos.earth.li> Message-ID: <20080618161420.GA6104@scico.botik.ru> On Wed, Jun 18, 2008 at 02:38:40PM +0100, Ian Lynagh wrote: > > Hi Serge, > > On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote: > > > > But as ghc-6.8.2 handles DoCon all right, why do not you > > investigate this difference in 6.8.3 ? > > We did investigate it - the details are in this trac ticket: > http://hackage.haskell.org/trac/ghc/ticket/2328 > but the conclusion was that overall it was best to leave things as they > are. Unfortunately, this means that performance with GHC 6.8.3 is worse > for DoCon; hopefully things will be better with 6.10.1! Yes, I see. Thank you for paying attention to this problem. I would like to add the following notes about comparison of ghc-6.8.2 and ghc-6.8.3. 1. As you already knew, abot 3 times slow down is visible in making a certain part of DoCon-2.11 -- due to the module RsePol_. 2. RsePol_.hs is only about 400 lines, together with comments. ghc-6.8.2 suffices -M80m to compile RsePol_.hs. ghc-6.8.3 needs more than -M600m for this. > 7 times loss in space. There are many computers which have not 600 Mb RAM. So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. Hm ... a small module needs > 600 Mb instead of 80 Mb to compile, and the release is considered as a progress. All right, this may occur correct -- if the developers know what namely must be fixed, and also know how to fix it. If so, then I could believe. By the way, not only 6.8.3 looks strange: even 80 Mb looks like an un-naturally large minimum for compiling this small RsePol_.hs. In symbolic computation, in the DoCon test running, in my Dumatel prover test, most examples take less than 40 Mb to perform, while I write all this in Haskell and do not care much for the code optimization. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From sedillard at ucdavis.edu Wed Jun 18 12:42:44 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Wed Jun 18 12:34:38 2008 Subject: Default class method inlining bug (wasn't this fixed?) Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Vec.hs Type: text/x-haskell Size: 20806 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080618/72a6261b/Vec-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.hs Type: text/x-haskell Size: 1708 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080618/72a6261b/Test-0001.bin From sedillard at ucdavis.edu Wed Jun 18 12:46:23 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Wed Jun 18 12:38:15 2008 Subject: Default class method inlining bug (wasn't this fixed?) Message-ID: Something strange happened and the body of my previous email was lost. I've re-sent it here. The attachments are there. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-June/014973.html ===== Hi, I'm seeing the following bug revived in 6.8.2 and 6.8.3: http://hackage.haskell.org/trac/ghc/ticket/672 I use a default definition for class method, one that calls methods of dependent (super?) classes. Of course I'm embarrassed it took me so long to realize I didn't _need_ the class in the first place, I could just write a plain polymorphic function that calls those methods. Regardless, looks like a bug to me. Two files are attached, Test.hs and Vec.hs. Search for "BUG IS HERE" in Test.hs. There is a class and an instance declaration. Compile as-is to see the correct result. Comment out the method definition in the instance declaration to see the bug. If someone confirms, I'll open a ticket. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080618/eaf91585/attachment.htm From dan.doel at gmail.com Wed Jun 18 17:00:22 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Jun 18 16:52:34 2008 Subject: Low-level array performance In-Reply-To: <200806181010.57227.daniel.is.fischer@web.de> References: <200806161551.31696.dan.doel@gmail.com> <200806171637.02586.dan.doel@gmail.com> <200806181010.57227.daniel.is.fischer@web.de> Message-ID: <200806181700.22847.dan.doel@gmail.com> On Wednesday 18 June 2008, Daniel Fischer wrote: > Am Dienstag, 17. Juni 2008 22:37 schrieb Dan Doel: > > I'll attach new, hopefully bug-free versions of the benchmark to this > > message. > > With -O2 -fvia-C -optc-O3, the difference is small (less than 1%), but > today, ByteArr is faster more often. Hmm, well, I'm a bit flummoxed. I still get Addr# outperforming MBA# by perhaps 10% - 15%, even with -fvia-C -optc-O3 (and before the slight speedup below). Perhaps gcc's optimizer isn't doing as good a job for me for some reason. In any case, I've entered a bug for this on the GHC trac: http://hackage.haskell.org/trac/ghc/ticket/2374 It contains a Ptr benchmark that performs slightly faster on very small arrays (under, say, 40 elements; I noticed such runs were taking more time than those with larger arrays with correspondingly fewer iterations, so I eliminated the replicateM_ in favor of an explicit loop. It gains a little time on the small arrays, but not enough to match the performance on the larger arrays, so I guess there are yet more factors. :) In any case, it makes it closer to being the same code as ByteArr). The bug is filed against the native code generator, since it shows up more clearly there. I haven't gotten to looking at C-- or assembly yet, but hopefully I will in the near future. I'll try to do further followup on the bug report, since that's probably easier for the developers to keep track of. Cheers, -- Dan From richardg at richardg.name Thu Jun 19 01:04:01 2008 From: richardg at richardg.name (Richard Giraud) Date: Thu Jun 19 00:55:51 2008 Subject: HUnit Message-ID: <4859E8C1.4080601@richardg.name> I've converted the literate Haskell documentation and filled in the gaps for HUnit. I've posted the darcs repository with the changes and the new documentation at http://richardg.name/ Please email me with any feedback and/or patches that you might have. In a bit, I'll submit the patches for inclusion into the GHC repository. Richard G. From simonpj at microsoft.com Thu Jun 19 11:01:29 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 19 10:53:19 2008 Subject: 6.8.3 against DoCon In-Reply-To: <20080618161420.GA6104@scico.botik.ru> References: <20080618123956.GA3292@scico.botik.ru> <20080618133840.GA4052@matrix.chaos.earth.li> <20080618161420.GA6104@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38284@EA-EXMSG-C334.europe.corp.microsoft.com> | So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. | | Hm ... a small module needs > 600 Mb instead of 80 Mb to compile, | and the release is considered as a progress. | All right, this may occur correct -- if the developers know what | namely must be fixed, and also know how to fix it. If so, then I could | believe. I have looked into this a bit. It's because GHC currently inlines every instance declaration bodily, code and all. DoCon has a lot of instance declarations with a lot of code in them, so there's a tremendous amount of code duplication as a result of dictionary construction. I've been working on a fix for this -- it bites every program, but DoCon especially -- but I have not yet managed to complete it. I'm not quite sure why 6.8.3 is worse than 6.8.2, but both are bad. I'm hoping for a dramatic improvement once I've done my fix. Simon From dons at galois.com Thu Jun 19 13:39:50 2008 From: dons at galois.com (Don Stewart) Date: Thu Jun 19 13:31:42 2008 Subject: HUnit In-Reply-To: <4859E8C1.4080601@richardg.name> References: <4859E8C1.4080601@richardg.name> Message-ID: <20080619173950.GB27331@scytale.galois.com> richardg: > I've converted the literate Haskell documentation and filled in the gaps > for HUnit. I've posted the darcs repository with the changes and the > new documentation at http://richardg.name/ > > Please email me with any feedback and/or patches that you might have. > In a bit, I'll submit the patches for inclusion into the GHC repository. > > Richard G. Would you like to move your HUnit work into code.haskell.org/hunit? We need someone to take over maintainance of this public library, and centralised hosting will ensure it isn't lost to the ages. To register an hunit project and user account, visit community.haskell.org Thanks for contributing! -- Don From richardg at richardg.name Thu Jun 19 16:54:38 2008 From: richardg at richardg.name (Richard Giraud) Date: Thu Jun 19 16:46:28 2008 Subject: HUnit In-Reply-To: <20080619173950.GB27331@scytale.galois.com> References: <4859E8C1.4080601@richardg.name> <20080619173950.GB27331@scytale.galois.com> Message-ID: <485AC78E.6030507@richardg.name> Hi Don I've made the appropriate requests, I think, and I'll upload once they are processed. Richard G. Don Stewart wrote: > richardg: >> I've converted the literate Haskell documentation and filled in the gaps >> for HUnit. I've posted the darcs repository with the changes and the >> new documentation at http://richardg.name/ >> >> Please email me with any feedback and/or patches that you might have. >> In a bit, I'll submit the patches for inclusion into the GHC repository. >> >> Richard G. > > Would you like to move your HUnit work into code.haskell.org/hunit? > We need someone to take over maintainance of this public library, and > centralised hosting will ensure it isn't lost to the ages. > > To register an hunit project and user account, visit > > community.haskell.org > > Thanks for contributing! > > -- Don > From Christian.Maeder at dfki.de Fri Jun 20 05:13:54 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jun 20 05:05:41 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <20080617185945.GA2262@matrix.chaos.earth.li> References: <20080617185945.GA2262@matrix.chaos.earth.li> Message-ID: <485B74D2.8030703@dfki.de> Hi, I've created the following binary distributions, but -- like Serge Mechveliani -- I'm not very happy with the results, because the created binaries are much bigger. http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.tar.bz2 http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-tests.log.bz2 http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-tests.log.bz2 The log files contain the results of running "(g)make stage=2" in testsuite/tests/ghc-regress. The summaries are below. The Tiger Mac OS PPC (8.11.0 Darwin) distribution relies on libreadline.5.2.dylib and libncurses.5.dylib under /opt/local/lib/. libgmp.a is statically linked in. Due to the increased code sizes it is more likely to get "relocation overflow" (therefore this distribution does not work for our hets project). http://hackage.haskell.org/trac/ghc/ticket/2031 For i386 Solaris it would be good to have a GHC build slave to improve the testsuite results (below) and to avoid building problems (that Ian Lynagh helped to resolve before. Thanks!). The sizes of our compressed hets binaries increased as follows: ghc-6.8.2 ghc-6.8.3 i386-Solaris 10 Mb 16 Mb i386-Darwin 7 Mb 13 Mb i386-Linux 7.2 Mb 10 Mb (i.e. compare http://www.dfki.de/sks/hets/linux/daily/ with a recent http://www.dfki.de/sks/hets/linux/versions/) I gave up (I'm not through) with sparc Solaris as it takes too long and gcc-4.2.2 crashed for one large .hc file from our sources (with segmentation fault). An unofficial i386-Darwin (Leopard) distribution can be found at http://www.dfki.de/sks/hets/intel-mac/ghcs/ (needs libgmp.3.dylib), but use http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg if you can. Cheers Christian ppc-Darwin (Tiger): OVERALL SUMMARY for test run started at Thu Jun 19 12:42:52 CEST 2008 2148 total tests, which gave rise to 11032 test cases, of which 0 caused framework failures 2309 were skipped 8490 expected passes 195 expected failures 0 unexpected passes 38 unexpected failures Unexpected failures: conc049(threaded2) conc052(profc,profasm) conc053(threaded2) divbyzero(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) ffi009(ghci) galois_raytrace(optc,profc) ghci024(ghci) joao-circular(profc) net001(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) seward-space-leak(ghci) signals002(ghci) i386-Solaris: OVERALL SUMMARY for test run started at Wed Jun 18 17:09:48 CEST 2008 2148 total tests, which gave rise to 11032 test cases, of which 0 caused framework failures 2315 were skipped 8448 expected passes 199 expected failures 0 unexpected passes 70 unexpected failures Unexpected failures: 1861(optc,profc) barton-mangler-bug(optc) bug1465(normal) cabal01(normal) conc052(profc,profasm) concprog002(threaded2) conflicting_flags(normal) derefnull(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) driver063(normal) expfloat(optc,profc) fun_insts(optc,profc) hClose002(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) joao-circular(profc) num009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) openFile003(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) regex001(ghci) user001(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) From mechvel at botik.ru Fri Jun 20 10:14:33 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Jun 20 10:06:27 2008 Subject: -O in 6.8.3 Message-ID: <20080620141433.GA10589@scico.botik.ru> Hello, This is on the recent topic of very eager inlining in ghc-6.8.3. I wrote recently that (1) 6.8.3 takes 7 times more of heap than 6.8.2 to complile under -O a certain small-size module RsePol_ (let us call it M.hs), (2) even the needed ~70 Mb in 6.8.2 looks unnaturally large. After thinking a bit, I take back (2). For `making' M under -Onot -- all right, it must suffice about 20 Mb. But -O allows deeper optimization, this needs more inlining, inlining pieces between modules, inlining instances (to some extent). I expect that -O needs for compilation not more than about 5 times greater expence in memory and time than -Onot. ghc-6.8.2 satisfies this. And 6.8.3 does not, its ratio is about 35 on the example of RsePol_.hs What is the developer's idea abot -O/-Onot cost ratio for RAM and time? What is the difference between ghc-6.8.2 and ghc-6.8.3 ? The former does not inline instances under -O and the latter does inline? As to the 10-20 % of the result code increase, I am calm about this -- if something it bought by this. But I am not an expert and do not see in what point 6.8.3 is better, at least the DoCon performance is not greater. I do not know, maybe some bugs are fixed, and a bug fix often costs some code increase, and a bug fix is good. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From marlowsd at gmail.com Fri Jun 20 11:07:23 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jun 20 10:59:14 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <485B74D2.8030703@dfki.de> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> Message-ID: <485BC7AB.3080603@gmail.com> Christian Maeder wrote: > Hi, > > I've created the following binary distributions, but -- like Serge > Mechveliani -- I'm not very happy with the results, because the created > binaries are much bigger. > > http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.tar.bz2 > > http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-tests.log.bz2 > > http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 > http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-tests.log.bz2 > > The log files contain the results of running "(g)make stage=2" in > testsuite/tests/ghc-regress. The summaries are below. > > The Tiger Mac OS PPC (8.11.0 Darwin) distribution relies on > libreadline.5.2.dylib and libncurses.5.dylib under /opt/local/lib/. > libgmp.a is statically linked in. > > Due to the increased code sizes it is more likely to get "relocation > overflow" (therefore this distribution does not work for our hets > project). http://hackage.haskell.org/trac/ghc/ticket/2031 > > For i386 Solaris it would be good to have a GHC build slave to improve > the testsuite results (below) and to avoid building problems (that Ian > Lynagh helped to resolve before. Thanks!). > > The sizes of our compressed hets binaries increased as follows: > ghc-6.8.2 ghc-6.8.3 > i386-Solaris 10 Mb 16 Mb > i386-Darwin 7 Mb 13 Mb > i386-Linux 7.2 Mb 10 Mb > > (i.e. compare http://www.dfki.de/sks/hets/linux/daily/ with > a recent http://www.dfki.de/sks/hets/linux/versions/) That's odd - I measured binary sizes thoroughly before the release and didn't see any difference between 6.8.3 and 6.8.2. Perhaps -split-objs got lost somewhere? Or maybe you upgraded gcc at some point? Cheers, Simon From marlowsd at gmail.com Fri Jun 20 11:21:37 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jun 20 11:13:27 2008 Subject: -O in 6.8.3 In-Reply-To: <20080620141433.GA10589@scico.botik.ru> References: <20080620141433.GA10589@scico.botik.ru> Message-ID: <485BCB01.4040209@gmail.com> Serge D. Mechveliani wrote: > What is the difference between ghc-6.8.2 and ghc-6.8.3 ? Compile times were improved by 4.3% over the nofib suite between 6.8.2 and 6.8.3. Code size was unaffected (down 0.2%). Runtime and allocation were also about the same. That's not to say that we don't believe you - we know for sure that DoCon is experiencing a regression with 6.8.3. However, we looked into it and decided to release despite this regression for two reasons - it wasn't possible to fix it quickly, and we don't believe there's a widespread regression here. But any regression is bad, and we'll make it a high priority to fix this for 6.10.1. > But I am not an expert and do not > see in what point 6.8.3 is better, at least the DoCon performance is > not greater. I do not know, maybe some bugs are fixed, and a bug fix > often costs some code increase, and a bug fix is good. There are 112 ways in which 6.8.3 is better than 6.8.2 :-) http://hackage.haskell.org/trac/ghc/query?status=closed&milestone=6.8.3&order=priority Cheers, Simon From Christian.Maeder at dfki.de Fri Jun 20 11:37:16 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jun 20 11:29:01 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <485BC7AB.3080603@gmail.com> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> Message-ID: <485BCEAC.1000509@dfki.de> Simon Marlow wrote: > That's odd - I measured binary sizes thoroughly before the release and > didn't see any difference between 6.8.3 and 6.8.2. The size of ghc itself did not increase. > Perhaps -split-objs got lost somewhere? Or maybe you upgraded gcc at > some point? No (at least I don't think so). I suspect that we some "expensive" class instances (for our class Logic). Here is a list of our biggest object-files under linux: ghc-6.8.2: 2.0M CASL_DL/PredefinedCASLAxioms.o 1.2M HasCASL/ATC_HasCASL.o 984K Haskell/ATC_Haskell.o 896K Haskell/TiATC.o 888K VSE/ATC_VSE.o 832K CspCASL/ATC_CspCASL.o 832K ATC/Sml_cats.o 788K Modal/ATC_Modal.o 780K CASL/ATC_CASL.o 704K CASL_DL/ATC_CASL_DL.o 696K OMDoc/OMDocInput.o 564K CoCASL/ATC_CoCASL.o 544K SoftFOL/Sign.o 540K SoftFOL/ATC_SoftFOL.o 536K ATC/DevGraph.o 516K HasCASL/As.o 500K OMDoc/OMDocInterface.o 476K Haskell/TiPropATC.o 468K CASL/AS_Basic_CASL.o 460K OMDoc/HetsDefs.o 436K CASL_DL/PredefinedSign.o 420K Static/DevGraph.o 408K Haskell/HatAna.o 376K DL/ATC_DL.o 368K CASL/StaticAna.o 348K SoftFOL/MathServParsing.o 344K Static/AnalysisStructured.o 324K OMDoc/OMDocOutput.o 324K CASL/ColimSign.o 324K CASL/Amalgamability.o 324K CoCASL/Logic_CoCASL.o 320K Logic/Grothendieck.o 316K OWL/AS.o 316K ConstraintCASL/Logic_ConstraintCASL.o 316K OWL/ReadWrite.o 312K CASL/Logic_CASL.o ghc-6.8.3: 11M COL/Logic_COL.o 11M CASL/Logic_CASL.o 11M ConstraintCASL/Logic_ConstraintCASL.o 11M CoCASL/Logic_CoCASL.o 11M Modal/Logic_Modal.o 11M VSE/Logic_VSE.o 10M CASL_DL/Logic_CASL_DL.o 4,8M CoCASL/ATC_CoCASL.o 2,6M Modal/ATC_Modal.o 2,0M CASL_DL/PredefinedCASLAxioms.o 1,3M Haskell/ATC_Haskell.o 1,3M HasCASL/ATC_HasCASL.o 1,2M CspCASL/Logic_CspCASL.o 997K Haskell/TiPropATC.o 889K VSE/ATC_VSE.o 877K CspCASL/ATC_CspCASL.o 777K ATC/DevGraph.o 757K ATC/Sml_cats.o 737K SoftFOL/ATC_SoftFOL.o 729K Haskell/TiDecorateATC.o 717K CASL_DL/ATC_CASL_DL.o 697K OMDoc/OMDocInput.o P.S. The sources can be checked out (if you dare) from https://svn-agbkb.informatik.uni-bremen.de/Hets/trunk see more http://trac.informatik.uni-bremen.de:8080/hets/wiki/HetsForDevelopers From Christian.Maeder at dfki.de Fri Jun 20 12:15:31 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jun 20 12:07:15 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <485BCEAC.1000509@dfki.de> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> <485BCEAC.1000509@dfki.de> Message-ID: <485BD7A3.1070301@dfki.de> Hi Simon, maybe you can suggest a global flag setting that avoids too much inlining during optimization. Cheers Christian Christian Maeder wrote: > No (at least I don't think so). I suspect that we some "expensive" class > instances (for our class Logic). Here is a list of our biggest > object-files under linux: > > ghc-6.8.3: > 11M COL/Logic_COL.o > 11M CASL/Logic_CASL.o > 11M ConstraintCASL/Logic_ConstraintCASL.o > 11M CoCASL/Logic_CoCASL.o > 11M Modal/Logic_Modal.o > 11M VSE/Logic_VSE.o > 10M CASL_DL/Logic_CASL_DL.o > 4,8M CoCASL/ATC_CoCASL.o > 2,6M Modal/ATC_Modal.o > 2,0M CASL_DL/PredefinedCASLAxioms.o From dan.doel at gmail.com Fri Jun 20 17:04:46 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Jun 20 16:56:44 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <1212141413.15010.14.camel@localhost> References: <483F78FB.2080207@gmail.com> <1212141413.15010.14.camel@localhost> Message-ID: <200806201704.47243.dan.doel@gmail.com> On Friday 30 May 2008, Duncan Coutts wrote: > This is for two reasons. One is because your second foldl' is directly > recursive so does not get inlined. The static argument transformation it > what you're doing manually to turn the latter into the former. The SAT > is implemented in ghc 6.9 (though it seems to be having integration > problems). Apologies for replying to this thread after around a month, but I've been looking at performance of code with and without this transformation a bit lately, and I'm rather curious what is being planned to go on in GHC 6.10 with regard to it. Specifically, will GHC simply always perform the static argument transform, or will it have some kind of heuristic to decide when it's useful? It seems, according to some tests I've done, that it's not always a win, and is sometimes a loss (and not just with regard to code duplication). I've been hard pressed to come up with a definite rule for when it's a benefit, other than simply testing and seeing what works. For instance, consider some code from a recent benchmark I posted (I'm running this all under 6.8.2): bench :: Int -> Int -> ST s () bench (I# k) (I# n) = ST go where go s = case sizeOf (0 :: Int) of { I# w -> case newByteArray# (n *# w) s of { (# s, arr #) -> case fill arr n s of { s -> go' arr k s } } } go' arr 0# s = (# s, () #) go' arr k s = case reverse arr 0# (n -# 1#) s of { s -> go' arr (k -# 1#) s } reverse :: MutableByteArray# s -> Int# -> Int# -> State# s -> State# s reverse arr i j s | i <# j = case readIntArray# arr i s of { (# s, ei #) -> case readIntArray# arr j s of { (# s, ej #) -> case writeIntArray# arr j ei s of { s -> case writeIntArray# arr i ej s of { s -> reverse arr (i +# 1#) (j -# 1#) s } } } } | otherwise = s The above is without the SAT on 'arr', obviously. This code runs fast. Doing SAT on reverse, but not on go' causes lots of heap allocation (for high iteration counts), slowing things way down. Doing it on go' but not reverse yields results about the same as not doing it at all. Doing it on both go' *and* reverse eliminates the heap allocation of the first case, *but* it results in overall slower code (which may, in fact, invalidate my bug about MBA# performance; I'll have to check. Just goes to show, even the most straightforward benchmark may not be measuring what you intend to measure). Another example is this function from the MBA# version of the fannkuch benchmark: shift :: MutableByteArray# s -> Int# -> State# s -> State# s shift arr r s = case readIntArray# arr 0# s of { (# s, p0 #) -> case go arr 0# r s of { s -> writeIntArray# arr r p0 s } } where go arr i r s | i <# r = case readIntArray# arr (i +# 1#) s of { (# s, e #) -> case writeIntArray# arr i e s of { s -> go arr (i +# 1#) r s } } | otherwise = s {-# INLINE shift #-} Now, obviously, arr and r are static arguments for go (already in scope, no less), so one would likely write go without them (it's certainly what I did initially). However, eliminating either one of them causes heap allocation and, thus, slowdowns (eliminating both is even worse). So, I suppose my question is: will GHC be better at this than I am? :) Will it know that performing the transform on shift above would cause extra heap allocation/slowdowns? Will it know that transforming reverse (and go') is slower than not doing so (I suppose it may be suspicious that this is all low-level code, but I've tried fiddling with higher-level code that I know gets compiled to this sort of code, and the above results seemed to hold)? I'm also not yet skilled enough at reading assembly to figure out what exactly is causing all this. Are values getting kicked out of registers or some such? Cheers, -- Dan From batterseapower at hotmail.com Fri Jun 20 19:19:36 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Jun 20 19:11:21 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806201704.47243.dan.doel@gmail.com> References: <483F78FB.2080207@gmail.com> <1212141413.15010.14.camel@localhost> <200806201704.47243.dan.doel@gmail.com> Message-ID: <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> Hi Dan, I've only got time for a quick reply now, I'll see if I can take a more substantitative look at your examples next week. > Specifically, will GHC simply always perform the static argument transform, or > will it have some kind of heuristic to decide when it's useful? It seems, > according to some tests I've done, that it's not always a win, and is > sometimes a loss (and not just with regard to code duplication). I've been > hard pressed to come up with a definite rule for when it's a benefit, other > than simply testing and seeing what works. Yes. Basically the rule is that if the recursive function under consideration makes few dynamic iterations then the cost of closure allocation in the SATed version outweighs the benefits of reduced copying etc. Clearly it is quite difficult for the compiler to tell if this is likely to be the case! This has always been a well documented problem with SAT from Santos' thesis where it was introduced and is why it went unimplemented in GHC for so long. > (elided examples, no time to really get into them ATM but they seem to demonstrate this principle). > So, I suppose my question is: will GHC be better at this than I am? :) Will it > know that performing the transform on shift above would cause extra heap > allocation/slowdowns? Will it know that transforming reverse (and go') is > slower than not doing so (I suppose it may be suspicious that this is all > low-level code, but I've tried fiddling with higher-level code that I know > gets compiled to this sort of code, and the above results seemed to hold)? In short: no it will not be better at it than you! GHC performs the SAT iff the recursive call is direct (i.e. not on mutually recursive groups of functions) to reduce code expansion, and if the number of static arguments is at least 2. The reason for the last criterion is that moving a parameter to a closure implicitly adds an argument to all the functions that make reference to that variable, the implicit argument being the pointer to the closure. Eliminating an actual function argument just to add a layer of indirection via an allocated closure would be fairly pointless! There is no cleverer criterion involved, and this one was chosen just because it led to good results in the nofib benchmark suite that we consider to comprise "typical" Haskell programs for the purposes of evaluating optimisations. There will certainly be cases where it slows down the program under consideration, though the same can be said for almost any compiler optimisation ("no free lunch"). Of course, if you have any suggestions for good heuristics based on your benchmarking experience then we would like to hear them! There was some discussion of this in the original ticket, http://hackage.haskell.org/trac/ghc/ticket/888, but when implementing SAT I tried out the suggestions made there without good results (though to be perfectly honest I didn't really understand the motivations behind some of the suggestions made). Cheers, Max From dan.doel at gmail.com Fri Jun 20 21:34:14 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Jun 20 21:26:02 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> References: <483F78FB.2080207@gmail.com> <200806201704.47243.dan.doel@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> Message-ID: <200806202134.15111.dan.doel@gmail.com> On Friday 20 June 2008, Max Bolingbroke wrote: > Of course, if you have any suggestions for good heuristics based on > your benchmarking experience then we would like to hear them! There > was some discussion of this in the original ticket, > http://hackage.haskell.org/trac/ghc/ticket/888, but when implementing > SAT I tried out the suggestions made there without good results > (though to be perfectly honest I didn't really understand the > motivations behind some of the suggestions made). Well, as I said, I was apparently being over-aggressive in my manual application of the transform, so I'm not yet the best person to ask, I suppose. :) However, if I had to pick something out of the air, I'd say this: always do SAT when the argument in question is a function. This is actually the reason I started doing it in the first place. I was working on sorting uvectors, and had what I thought was pretty good performance, and then I did SAT on the comparison function, and suddenly my code was running in half the time. Going back to my sorting (testing on introsort), SAT for the array doesn't seem to do much, but undoing the SAT for the comparison function causes heap allocation to balloon, and everything gets at least a factor of 2 slower. This also seems to match the other manual uses of SAT I've seen in the past. For instance, in the GHC libraries you'll see: foldr f = go where go z (x:xs) = f x (go z xs) go z [ ] = z because it's significantly faster, while earlier in this thread, SPJ said that: xs ++ ys = let go [ ] = ys go (z:zs) = z : go zs in go xs isn't much of a win. I don't have much data currently, but the places I *know* it's been a win have been SAT on functions, while the places I *know* it's been a loss have been SAT on unboxed data. Whether this is because SAT allows more opportunity for inlining/specialization on functions, or because copying functions is inherently more expensive, though, I don't know. I'll keep an eye open from now on, though. (On an additional tentative note, undoing SAT in the first example of my last mail seemed to eliminate the difference between the native code generator and -fvia-c -optc-O3. So whatever SAT was doing to make the code slower (no extra heap allocation, just slower code), GCC may have been fixing. My off-the-top-of-the-head guess was that passing the arguments along kept them in registers, and maybe GCC was putting the SATed arguments back into registers, but as I said, I don't currently have the expertise to verify that.) Cheers, -- Dan From simonpj at microsoft.com Sat Jun 21 10:00:15 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Jun 21 09:51:58 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <485BD7A3.1070301@dfki.de> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> <485BCEAC.1000509@dfki.de> <485BD7A3.1070301@dfki.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> | maybe you can suggest a global flag setting that avoids too much | inlining during optimization. As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function instance C T where op = op_T op_T = .... But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned. Simon | Cheers Christian | | Christian Maeder wrote: | > No (at least I don't think so). I suspect that we some "expensive" class | > instances (for our class Logic). Here is a list of our biggest | > object-files under linux: | > From mechvel at botik.ru Sat Jun 21 11:05:20 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Jun 21 10:57:02 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> <485BCEAC.1000509@dfki.de> <485BD7A3.1070301@dfki.de> <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080621150520.GA28297@scico.botik.ru> Maybe, -O needs to denote for the compiler some reasonable degree of inlininig, both for functions and instances? ----------- Mechveliani On Sat, Jun 21, 2008 at 03:00:15PM +0100, Simon Peyton-Jones wrote: > > | maybe you can suggest a global flag setting that avoids too much > | inlining during optimization. > > As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function > instance C T where > op = op_T > > op_T = .... > > But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned. > > Simon > > | Cheers Christian > | > | Christian Maeder wrote: > | > No (at least I don't think so). I suspect that we some "expensive" class > | > instances (for our class Logic). Here is a list of our biggest > | > object-files under linux: > | > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From igloo at earth.li Sun Jun 22 10:06:08 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 22 09:57:49 2008 Subject: ANNOUNCE: GHC version 6.8.3 - Mac OS X, Intel/Leopard In-Reply-To: References: <20080617185945.GA2262@matrix.chaos.earth.li> Message-ID: <20080622140608.GA6260@matrix.chaos.earth.li> On Wed, Jun 18, 2008 at 10:22:39PM +1000, Manuel M T Chakravarty wrote: > > An installer package for Mac OS X, Intel/Leopard, is available at > > http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg Thanks Manuel; I've added this to the GHC download page. Thanks Ian From igloo at earth.li Sun Jun 22 10:07:04 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 22 09:58:43 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <485B74D2.8030703@dfki.de> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> Message-ID: <20080622140704.GB6260@matrix.chaos.earth.li> On Fri, Jun 20, 2008 at 11:13:54AM +0200, Christian Maeder wrote: > > I've created the following binary distributions > > http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.tar.bz2 > http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 > http://www.dfki.de/sks/hets/intel-mac/ghcs/ Thanks Christian; I've added these to the GHC download page. Thanks Ian From simonpj at microsoft.com Sun Jun 22 16:50:14 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sun Jun 22 16:43:50 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806202134.15111.dan.doel@gmail.com> References: <483F78FB.2080207@gmail.com> <200806201704.47243.dan.doel@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> <200806202134.15111.dan.doel@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38A5D@EA-EXMSG-C334.europe.corp.microsoft.com> | However, if I had to pick something out of the air, I'd say this: always do | SAT when the argument in question is a function. Yes, that might well be a good heuristic to try, if you are interested to pursue this, Max. Making the function static means that it may be inlined, and that can make a tremendous difference by specializing the loop for that particular function. But that in turn only tends to happen if the enclosing function is inlined. Consider foldr: the real payoff comes when foldr is inlined, so that the function at the call site becomes visible. Simon From twhitehead at gmail.com Mon Jun 23 10:31:13 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Jun 23 10:21:54 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806202134.15111.dan.doel@gmail.com> References: <483F78FB.2080207@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> <200806202134.15111.dan.doel@gmail.com> Message-ID: <200806231031.13505.twhitehead@gmail.com> On Friday 20 June 2008 21:34:14 Dan Doel wrote: > On Friday 20 June 2008, Max Bolingbroke wrote: > > Of course, if you have any suggestions for good heuristics based on > > your benchmarking experience then we would like to hear them! There > > was some discussion of this in the original ticket, > > http://hackage.haskell.org/trac/ghc/ticket/888, but when implementing > > SAT I tried out the suggestions made there without good results > > (though to be perfectly honest I didn't really understand the > > motivations behind some of the suggestions made). > > However, if I had to pick something out of the air, I'd say this: always do > SAT when the argument in question is a function. This is actually the > reason I started doing it in the first place. I was working on sorting > uvectors, and had what I thought was pretty good performance, and then I > did SAT on the comparison function, and suddenly my code was running in > half the time. Going back to my sorting (testing on introsort), SAT for the > array doesn't seem to do much, but undoing the SAT for the comparison > function causes heap allocation to balloon, and everything gets at least a > factor of 2 slower. I've been wondering if a nice option would be to be able to feed profiler information in at compile time and have it override the heuristics. That way, inlining, specialization, SAT, etc., decisions could be made based on how the code actually gets used during a typical run of the program. Cheers! -Tyson From batterseapower at hotmail.com Mon Jun 23 11:10:52 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jun 23 11:02:31 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806231029.58822.tyson@sharcnet.ca> References: <483F78FB.2080207@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> <200806202134.15111.dan.doel@gmail.com> <200806231029.58822.tyson@sharcnet.ca> Message-ID: <9d4d38820806230810t51ca05xc3cd32c8af4df6c1@mail.gmail.com> > I've been wondering if a nice option would be to be able to feed profiler > information in at compile time and have it override the heuristics. > > That way, inlining, specialization, SAT, etc., decisions could be made based > on how the code actually gets used during a typical run of the program. > > Cheers! -Tyson Yes, that is the ultimate solution to resolving those things that are traditionally unknown by a compiler, and profile directed optimization could certainly be exploited by GHC (imagine having the compiler automatically run Quickcheck/HUnit tests to exercise the code..). See http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx for details of a practical implementation of this strategy. I wouldn't be suprised if industrial virtual machine JIT compilers were making use of this sort of thing too. Another strategy is to having the runtime dynamically adjust how code is executed based on profiling information. See e.g. Adaptive Evalution of Non-Strict Programs by Robert Ennals (http://berkeley.intel-research.net/rennals/pubs/thesis.pdf). In the case of SAT this might involve the runtime switching to the non-SATed version of a function if it looks like most calls to it had a low iteration count. Cheers, Max From batterseapower at hotmail.com Mon Jun 23 12:17:54 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jun 23 12:09:30 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38A5D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <483F78FB.2080207@gmail.com> <200806201704.47243.dan.doel@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> <200806202134.15111.dan.doel@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38A5D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> 2008/6/22 Simon Peyton-Jones : > | However, if I had to pick something out of the air, I'd say this: always do > | SAT when the argument in question is a function. > > Yes, that might well be a good heuristic to try, if you are interested to pursue this, Max. Making the function static means that it may be inlined, and that can make a tremendous difference by specializing the loop for that particular function. But that in turn only tends to happen if the enclosing function is inlined. Consider foldr: the real payoff comes when foldr is inlined, so that the function at the call site becomes visible. I spent quite a bit of time today playing with various heuristics for the SAT including the one suggested above (which I agree sounded promising) but didn't make much progress. The best results were obtained by applying the SAT when: 1) At least two arguments are static, whatever their types 2) Or if at least one of the static arguments is a function type and the SATed functions right hand side is small enough to inline 3) As long as the function is not likely to be compiled as a tail call (because we effectively get staticness there by carrying arguments on the stack) If you just use criteria 2 then you get some bad worst cases in runtime (e.g. Para.dropTail and Constraints.initTree) because the additional inlining opportunity was not utilised enough to overcome the heap allocation cost. If you don't SAT functions that have only non-function static arguments then some other worst cases crop up (e.g. Rsa.power) where we actually quite want to do it. However this represents only a 0.3% decrease in allocations and runtime from the previous heuristic for nofib! Furthermore, it was necessary to run the SAT twice in the compiler pipeline to catch both those functions that only become tail calls after e.g. the let-to-case transform AND to identify the extra common subexpressions producted by SAT early enough that they could have good use made of them by later compiler passes. I'm not particularly happy with the tail call criterion because it's quite fragile to make inferences about how the function will be treated by codegen as early in the pipeline as SAT is running. So in summary I don't think this change is worth integrating. Cheers, Max From isaacdupree at charter.net Mon Jun 23 13:38:41 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 23 13:30:24 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> References: <483F78FB.2080207@gmail.com> <200806201704.47243.dan.doel@gmail.com> <9d4d38820806201619n5df28bd3x91b93fcb4a314abc@mail.gmail.com> <200806202134.15111.dan.doel@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38A5D@EA-EXMSG-C334.europe.corp.microsoft.com> <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> Message-ID: <485FDFA1.4080104@charter.net> there's no chance for the lower-level near code generation to reverse-SAT to eliminate the heap usage? (which would obviously be a different optimization that might be useful in other ways too, if it could be made to work) (did someone say that -fvia-C with gcc -O3 managed to do that sometimes?) just an underinformed thought, -Isaac From dan.doel at gmail.com Mon Jun 23 14:29:00 2008 From: dan.doel at gmail.com (Dan Doel) Date: Mon Jun 23 14:21:17 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <485FDFA1.4080104@charter.net> References: <483F78FB.2080207@gmail.com> <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> <485FDFA1.4080104@charter.net> Message-ID: <200806231429.01481.dan.doel@gmail.com> On Monday 23 June 2008, Isaac Dupree wrote: > there's no chance for the lower-level near code generation to > reverse-SAT to eliminate the heap usage? (which would obviously be a > different optimization that might be useful in other ways too, if it > could be made to work) (did someone say that -fvia-C with gcc -O3 > managed to do that sometimes?) I said something similar, but I don't actually know the details. What I have is a SAT and non-SAT version of a benchmark: ---- SAT ---- bench :: Int -> Int -> ST s () bench (I# k) (I# n) = ST go where go s = case sizeOf (0 :: Int) of { I# w -> case newByteArray# (n *# w) s of { (# s, arr #) -> case fill arr n s of { s -> go' arr k s } } } go' arr = go'' where go'' 0# s = (# s, () #) go'' k s = case reverse arr 0# (n -# 1#) s of { s -> go'' (k -# 1#) s } reverse :: MutableByteArray# s -> Int# -> Int# -> State# s -> State# s reverse arr = go where go i j s | i <# j = case readIntArray# arr i s of { (# s, ei #) -> case readIntArray# arr j s of { (# s, ej #) -> case writeIntArray# arr j ei s of { s -> case writeIntArray# arr i ej s of { s -> go (i +# 1#) (j -# 1#) s } } } } | otherwise = s ---- non-SAT ---- bench :: Int -> Int -> ST s () bench (I# k) (I# n) = ST go where go s = case sizeOf (0 :: Int) of { I# w -> case newByteArray# (n *# w) s of { (# s, arr #) -> case fill arr n s of { s -> go' arr k s } } } go' arr 0# s = (# s, () #) go' arr k s = case reverse arr 0# (n -# 1#) s of { s -> go' arr (k -# 1#) s } reverse :: MutableByteArray# s -> Int# -> Int# -> State# s -> State# s reverse arr i j s | i <# j = case readIntArray# arr i s of { (# s, ei #) -> case readIntArray# arr j s of { (# s, ej #) -> case writeIntArray# arr j ei s of { s -> case writeIntArray# arr i ej s of { s -> reverse arr (i +# 1#) (j -# 1#) s } } } } | otherwise = s In the SAT version, the native code generator is noticeably slower than -fvia-c -optc-O3, so the latter is doing something right. In the non-SAT version, -fvia-c is somewhat faster than the SAT version, but the NCG is just as fast. I don't know what's going on on the C end in the first case that makes it better, though (heap allocation is the same (low) in all cases; via-c doesn't fix large heap allocation when it happens in my experience). As an aside, I finally got around to compiling 6.9 from a day or so ago, and noticed that one of the functions I'd mentioned earlier does get SATed to the bad version (which causes lots of heap allocation in the program) because it has two static arguments. However, marking it NOINLINE seemed to keep it from having the negative effects. Does that pragma keep SAT from doing its thing, and if so, will that continue to be viable in cases where we decide we know better than GHC? Cheers, -- Dan From batterseapower at hotmail.com Mon Jun 23 19:11:04 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jun 23 19:02:38 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806231429.01481.dan.doel@gmail.com> References: <483F78FB.2080207@gmail.com> <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> <485FDFA1.4080104@charter.net> <200806231429.01481.dan.doel@gmail.com> Message-ID: <9d4d38820806231611l2ebca491q573d714dacfdfee4@mail.gmail.com> 2008/6/23 Dan Doel : > On Monday 23 June 2008, Isaac Dupree wrote: >> there's no chance for the lower-level near code generation to >> reverse-SAT to eliminate the heap usage? It might be possible to do this by utilising the rules system. It's something I had briefly considered but not really looked into. As there seems to be a lot of interest in this topic I'll probably devote some more time to the issue tomorrow and see if we can't get SAT working really well. >> (did someone say that -fvia-C with gcc -O3 >> managed to do that sometimes?) > > I said something similar, but I don't actually know the details. What I have > is a SAT and non-SAT version of a benchmark > > (snip) > > In the SAT version, the native code generator is noticeably slower > than -fvia-c -optc-O3, so the latter is doing something right. In the non-SAT > version, -fvia-c is somewhat faster than the SAT version, but the NCG is just > as fast. I don't know what's going on on the C end in the first case that > makes it better, though (heap allocation is the same (low) in all cases; > via-c doesn't fix large heap allocation when it happens in my experience). Having a compact benchmark is great, I'll take a look at what's going on tomorrow, though it will involve my plumbing the as-yet unknown depths of the code generation system :-) > As an aside, I finally got around to compiling 6.9 from a day or so ago, and > noticed that one of the functions I'd mentioned earlier does get SATed to the > bad version (which causes lots of heap allocation in the program) because it > has two static arguments. However, marking it NOINLINE seemed to keep it from > having the negative effects. Does that pragma keep SAT from doing its thing, > and if so, will that continue to be viable in cases where we decide we know > better than GHC? I assume you mean "shift" as all the others have only one static argument. Personally I find the behaviour of not SATing if something is NOINLINE surprising and I suspect something else is at work. Is is possible for you to send me a self-contained example of the problematic function that demonstrates this off-list that I can play with myself? It's worth noting that if you think SAT is a bad idea you can always resort to -fno-static-argument-transformation (IIRC) in an OPTIONS_GHC pragma. Incidentally I think the introduction of some sort of tail call detection in the SAT would resolve the problems with all the examples you've presented so far since they are all straight loops. Annoyingly this is not a clear win because I think doing this in general will impede loop invariant lifting e.g consider this tail recursive function: foo x y z = let invariant = x * y in foo x y (z + 1) This is static in x and y so we might like to SAT it: foo x y z = let foo' z = (let invariant = x * y in foo' (z + 1)) in foo' z This lets us take out the invariant in a later pass (CSE): foo x y z = let invariant = x * y in let foo' z = foo' (z + 1) in foo' z I don't >think< GHC is currently smart enough to detect this without SAT. A smart optimization might try and evaluate the relative cost of the SAT (heap allocation) and not doing the invariant lifting (redundant computation) and make some kind of decision about which is the lesser evil. There may even be a third option which may avoid closure creation: foo x y z = let foo' x y z invariant = (foo' x y (z + 1) invariant) in foo' x y z (x * y) (I think this is right). It corresponds operationally to computing the invariant once at the start of a loop and then carrying it on the stack rather than via the closure as with the option above, avoiding touching the heap. I'm uncertain about how different this really is though. Anyway, let's see what further investigations bring tomorrow, Cheers, Max From sedillard at ucdavis.edu Tue Jun 24 15:08:44 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Tue Jun 24 15:00:15 2008 Subject: Library-vs-local performance Message-ID: Hi, I've got a library that I'm in the process of uploading to hackage (waiting for account) but the darcs repo is here: http://graphics.cs.ucdavis.edu/~sdillard/Vec I notice a slight drop in performance when I install the library using cabal. Maybe 10-20%, on one particular function. This is in comparison to when the library is 'local', as in, the source files are in the same directory as the client application. What could be causing the performance drop? The function in question requires impractical amounts of inlining (This is something of an experiment), but I don't see how installing it as a library affects that. The functions to be inlined are small, surely available in the .hi files. Its only when they are applied do they agglomerate into a big mess - 80-200K lines of core. The function in question is invertMany in examples/Examples.hs. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080624/b9a5224a/attachment.htm From dons at galois.com Tue Jun 24 15:50:45 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 24 15:42:21 2008 Subject: Library-vs-local performance In-Reply-To: References: Message-ID: <20080624195045.GE17394@scytale.galois.com> sedillard: > Hi, > > I've got a library that I'm in the process of uploading to hackage > (waiting for account) but the darcs repo is here: > > [1]http://graphics.cs.ucdavis.edu/~sdillard/Vec > > I notice a slight drop in performance when I install the library using > cabal. Maybe 10-20%, on one particular function. This is in comparison to > when the library is 'local', as in, the source files are in the same > directory as the client application. Lack of unfolding and inlining when compiled in a package? Try compiling with -O2, for maximum unfolding. > What could be causing the performance drop? The function in question > requires impractical amounts of inlining (This is something of an > experiment), but I don't see how installing it as a library affects that. > The functions to be inlined are small, surely available in the .hi files. You can check this via -show-iface > Its only when they are applied do they agglomerate into a big mess - > 80-200K lines of core. > > The function in question is invertMany in examples/Examples.hs. -- Don From dons at galois.com Tue Jun 24 15:56:15 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 24 15:47:48 2008 Subject: Library-vs-local performance In-Reply-To: <20080624195045.GE17394@scytale.galois.com> References: <20080624195045.GE17394@scytale.galois.com> Message-ID: <20080624195615.GF17394@scytale.galois.com> dons: > sedillard: > > Hi, > > > > I've got a library that I'm in the process of uploading to hackage > > (waiting for account) but the darcs repo is here: > > > > [1]http://graphics.cs.ucdavis.edu/~sdillard/Vec > > > > I notice a slight drop in performance when I install the library using > > cabal. Maybe 10-20%, on one particular function. This is in comparison to > > when the library is 'local', as in, the source files are in the same > > directory as the client application. > > Lack of unfolding and inlining when compiled in a package? Try compiling > with -O2, for maximum unfolding. > > > What could be causing the performance drop? The function in question > > requires impractical amounts of inlining (This is something of an > > experiment), but I don't see how installing it as a library affects that. > > The functions to be inlined are small, surely available in the .hi files. > > You can check this via -show-iface > > > Its only when they are applied do they agglomerate into a big mess - > > 80-200K lines of core. > > > > The function in question is invertMany in examples/Examples.hs. Some general remarks, GHC isn't (yet) a whole program compiler by default. So it doesn't, by default, inling entire packages across package boundaries. So you can lose some specialisation/inlining, sometimes, by breaking things across module boundaries. That said, it's entirely possible to program libraries in a way to specifically allow full inlining of the libraries. The Data.Binary and Data.Array.Vector libraries are written in this style for example, which means lots of {-# INLINE #-} pragmas, maximum unfolding and high optimisation levels. -- Don From sedillard at ucdavis.edu Tue Jun 24 16:56:55 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Tue Jun 24 16:48:27 2008 Subject: Library-vs-local performance In-Reply-To: <20080624195615.GF17394@scytale.galois.com> References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> Message-ID: > > > That said, it's entirely possible to program libraries in a way to > specifically allow full inlining of the libraries. The Data.Binary and > Data.Array.Vector libraries are written in this style for example, > which means lots of {-# INLINE #-} pragmas, maximum unfolding and high > optimisation levels. > > -- Don > Every function has an inline pragma. Adding -O2 -funfolding-use-threshold999 -funfolding-creation-threshold999 does not significantly change the produced .hi files (--show-iface produces roughly the same files, just different headers) This makes sense to me because the library doesn't actually _do_ anything. There are no significant compiled functions, everything should be inlined. And since the .hi files are the same, I don't see why they wouldn't be. The two scenarios are these: 1) Library is installed via cabal. 2) Library source lives in the same directory as the application, so that ghc --make Examples.hs also builds the library. When compiling the application I set all knobs to 11. In case 1, ./Examples 3000000 runs in 6.9s, case 2 in 5.2s. The module structure is the same in both cases, so I don't know what inlining across module boundaries has to do with it. By the way, the library is now on hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Vec but the documentation does not show up. What do I have to do to make this happen? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080624/e60ed380/attachment.htm From dons at galois.com Tue Jun 24 17:01:58 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 24 16:53:32 2008 Subject: Library-vs-local performance In-Reply-To: References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> Message-ID: <20080624210158.GK17394@scytale.galois.com> sedillard: > That said, it's entirely possible to program libraries in a way to > specifically allow full inlining of the libraries. The Data.Binary and > Data.Array.Vector libraries are written in this style for example, > which means lots of {-# INLINE #-} pragmas, maximum unfolding and high > optimisation levels. > -- Don > > Every function has an inline pragma. Adding -O2 > -funfolding-use-threshold999 -funfolding-creation-threshold999 does not > significantly change the produced .hi files (--show-iface produces roughly > the same files, just different headers) This makes sense to me because > the library doesn't actually _do_ anything. There are no significant > compiled functions, everything should be inlined. And since the .hi files > are the same, I don't see why they wouldn't be. The two scenarios are > these: > > 1) Library is installed via cabal. > 2) Library source lives in the same directory as the application, so that > ghc --make Examples.hs also builds the library. That's compiling Examples with full access to the source though! So ghc has the entire source available. Once you've installed the library, however, only what is exposed via the .hi files can be used for optimisation purposes. So *something* is not being inlined fully (or some other optimisation is interferring) Boiling this down to the smallest test case you can would be *really* useful!! > > When compiling the application I set all knobs to 11. In case 1, > ./Examples 3000000 runs in 6.9s, case 2 in 5.2s. The module structure is > the same in both cases, so I don't know what inlining across module > boundaries has to do with it. > By the way, the library is now on hackage, > [1]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Vec > but the documentation does not show up. What do I have to do to make this > happen? Oh assuming haddock can process it, it'll appear in a few hours. Hadock is run periodically. From igloo at earth.li Tue Jun 24 17:16:42 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 24 17:08:22 2008 Subject: Library-vs-local performance In-Reply-To: <20080624210158.GK17394@scytale.galois.com> References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> Message-ID: <20080624211642.GA5823@matrix.chaos.earth.li> On Tue, Jun 24, 2008 at 02:01:58PM -0700, Donald Bruce Stewart wrote: > > > > 1) Library is installed via cabal. > > 2) Library source lives in the same directory as the application, so that > > ghc --make Examples.hs also builds the library. > > That's compiling Examples with full access to the source though! > So ghc has the entire source available. That shouldn't make any difference. I suspect a flag difference is to blame - giving cabal build the -v flag will show which flags it is using. Thanks Ian From sedillard at ucdavis.edu Tue Jun 24 17:45:00 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Tue Jun 24 17:36:32 2008 Subject: Library-vs-local performance In-Reply-To: <20080624211642.GA5823@matrix.chaos.earth.li> References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> <20080624211642.GA5823@matrix.chaos.earth.li> Message-ID: I can't reproduce the behavior on any of the less egregiously inlined functions. For everything else the running times are the same using either local packages or installed libraries. On Tue, Jun 24, 2008 at 3:16 PM, Ian Lynagh wrote: > On Tue, Jun 24, 2008 at 02:01:58PM -0700, Donald Bruce Stewart wrote: > > > > > > 1) Library is installed via cabal. > > > 2) Library source lives in the same directory as the application, so > that > > > ghc --make Examples.hs also builds the library. > > > > That's compiling Examples with full access to the source though! > > So ghc has the entire source available. > > That shouldn't make any difference. I suspect a flag difference is to > blame - giving cabal build the -v flag will show which flags it is > using. > I've taken all optimization flags out of the .cabal file. They don't have any effect. My understanding of things is this: (please correct if wrong) All functions have inline pragmas, and all are small (1 or 2 lines) so their definitions are all spewed into the .hi files. So in both scenarios (library vs local) GHC can "see" the whole library. Since every function is inlined, it doesn't matter what flags the library is compiled with. That compiled code will never be used so long as the application is compiled with optimization on. Now the particulars of the situation are this: the function in question is inlined very deeply, it has many instance constraints, and during simplification the core blows up to _ridiculous_ sizes. (Compilation with -ddump-simpl is taking about 5-10 min.) I think I'm pushing the compiler to unreasonable limits, and I think maybe something non-obvious is going on inside. On the otherhand, pushing the compiler in this way gets me a 3x speedup, which is nothing to sneeze at. In the meantime I'll see what I can do to make this function (gaussian elimination) more amenable to simplification. The rest of the library works great. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080624/df3cc857/attachment.htm From dons at galois.com Tue Jun 24 17:51:07 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 24 17:42:50 2008 Subject: Library-vs-local performance In-Reply-To: References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> <20080624211642.GA5823@matrix.chaos.earth.li> Message-ID: <20080624215107.GR17394@scytale.galois.com> sedillard: > I can't reproduce the behavior on any of the less egregiously inlined > functions. For everything else the running times are the same using either > local packages or installed libraries. > > On Tue, Jun 24, 2008 at 3:16 PM, Ian Lynagh <[1]igloo@earth.li> wrote: > > On Tue, Jun 24, 2008 at 02:01:58PM -0700, Donald Bruce Stewart wrote: > > > > > > 1) Library is installed via cabal. > > > 2) Library source lives in the same directory as the application, > so that > > > ghc --make Examples.hs also builds the library. > > > > That's compiling Examples with full access to the source though! > > So ghc has the entire source available. > > That shouldn't make any difference. I suspect a flag difference is to > blame - giving cabal build the -v flag will show which flags it is > using. > > I've taken all optimization flags out of the .cabal file. They don't have > any effect. My understanding of things is this: (please correct if wrong) > All functions have inline pragmas, and all are small (1 or 2 lines) so > their definitions are all spewed into the .hi files. So in both scenarios > (library vs local) GHC can "see" the whole library. Since every function > is inlined, it doesn't matter what flags the library is compiled with. > That compiled code will never be used so long as the application is > compiled with optimization on. > > Now the particulars of the situation are this: the function in question is > inlined very deeply, it has many instance constraints, and during > simplification the core blows up to _ridiculous_ sizes. (Compilation with > -ddump-simpl is taking about 5-10 min.) I think I'm pushing the compiler > to unreasonable limits, and I think maybe something non-obvious is going > on inside. > > On the otherhand, pushing the compiler in this way gets me a 3x speedup, > which is nothing to sneeze at. In the meantime I'll see what I can do to > make this function (gaussian elimination) more amenable to simplification. > The rest of the library works great. You might want to give the simplifier enough time to unwind things. I use, e.g. -O2 -fvia-C -optc-O2 -fdicts-cheap -fno-method-sharing -fmax-simplifier-iterations10 -fliberate-case-threshold100 in my ghc-options for 'whole program' libraries. Raise these limits if you find they're having an effect -- Don From sedillard at ucdavis.edu Tue Jun 24 18:05:46 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Tue Jun 24 17:57:18 2008 Subject: Library-vs-local performance In-Reply-To: <20080624215107.GR17394@scytale.galois.com> References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> <20080624211642.GA5823@matrix.chaos.earth.li> <20080624215107.GR17394@scytale.galois.com> Message-ID: On Tue, Jun 24, 2008 at 3:51 PM, Don Stewart wrote: > > > > I've taken all optimization flags out of the .cabal file. They don't > have > > any effect. My understanding of things is this: (please correct if > wrong) > > All functions have inline pragmas, and all are small (1 or 2 lines) so > > their definitions are all spewed into the .hi files. So in both > scenarios > > (library vs local) GHC can "see" the whole library. Since every > function > > is inlined, it doesn't matter what flags the library is compiled with. > > That compiled code will never be used so long as the application is > > compiled with optimization on. > > > You might want to give the simplifier enough time to unwind things. > I use, e.g. > > -O2 > -fvia-C -optc-O2 > -fdicts-cheap > -fno-method-sharing > -fmax-simplifier-iterations10 > -fliberate-case-threshold100 > > in my ghc-options for 'whole program' libraries. > > Raise these limits if you find they're having an effect > > -- Don Yeah I saw those in your uvector library and was going to ask: what do they do? Are they documented anywhere? I can't find any info on them. Speicifcally, what is the case liberation threshold? (Can't even find that on google.) That sounds germane because the function in question is one of the few with branches. And what effect does -fvia-C -optc-O2 have? Those refer to the generation of machine code, do they not? If the library is essentially a core-only library, why use them? As far as I can tell, even -O2 is ineffectual when compiling the library. 'Compiling' here is even a misnomer. We're just transliterating from haskell to core. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080624/43be2cea/attachment.htm From dons at galois.com Tue Jun 24 18:15:53 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 24 18:07:30 2008 Subject: Library-vs-local performance In-Reply-To: References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> <20080624211642.GA5823@matrix.chaos.earth.li> <20080624215107.GR17394@scytale.galois.com> Message-ID: <20080624221553.GS17394@scytale.galois.com> sedillard: > On Tue, Jun 24, 2008 at 3:51 PM, Don Stewart <[1]dons@galois.com> wrote: > > > > > I've taken all optimization flags out of the .cabal file. They > don't have > > any effect. My understanding of things is this: (please correct if > wrong) > > All functions have inline pragmas, and all are small (1 or 2 lines) > so > > their definitions are all spewed into the .hi files. So in both > scenarios > > (library vs local) GHC can "see" the whole library. Since every > function > > is inlined, it doesn't matter what flags the library is compiled > with. > > That compiled code will never be used so long as the application is > > compiled with optimization on. > > You might want to give the simplifier enough time to unwind things. > I use, e.g. > > -O2 > -fvia-C -optc-O2 > -fdicts-cheap > -fno-method-sharing > -fmax-simplifier-iterations10 > -fliberate-case-threshold100 > > in my ghc-options for 'whole program' libraries. > > Raise these limits if you find they're having an effect > -- Don > > Yeah I saw those in your uvector library and was going to ask: what do > they do? Are they documented anywhere? I can't find any info on them. > Speicifcally, what is the case liberation threshold? (Can't even find that > on google.) That sounds germane because the function in question is one of > the few with branches. > > And what effect does -fvia-C -optc-O2 have? Those refer to the generation > of machine code, do they not? If the library is essentially a core-only > library, why use them? As far as I can tell, even -O2 is ineffectual when > compiling the library. 'Compiling' here is even a misnomer. We're just > transliterating from haskell to core. Nope, there's a lot of optimisations taking place on the core-to-core phase, to ensure the core that gets unfolded into your .hi files is as nice as possible. And then still there's things that actually stay as calls into your compiled library -- for those, you'll want direct jumps and so forth, which you get with -fvia-C -optc-O2 and above. See my recent post on micro optimisations. -- Don From sedillard at ucdavis.edu Tue Jun 24 19:18:37 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Tue Jun 24 19:10:09 2008 Subject: Library-vs-local performance In-Reply-To: <20080624221553.GS17394@scytale.galois.com> References: <20080624195045.GE17394@scytale.galois.com> <20080624195615.GF17394@scytale.galois.com> <20080624210158.GK17394@scytale.galois.com> <20080624211642.GA5823@matrix.chaos.earth.li> <20080624215107.GR17394@scytale.galois.com> <20080624221553.GS17394@scytale.galois.com> Message-ID: On Tue, Jun 24, 2008 at 4:15 PM, Don Stewart wrote: > > Nope, there's a lot of optimisations taking place on the core-to-core > phase, to ensure the core that gets unfolded into your .hi files is as > nice as possible. And then still there's things that actually stay as > calls into your compiled library -- for those, you'll want direct jumps > and so forth, which you get with -fvia-C -optc-O2 and above. > > See my recent post on micro optimisations. > > -- Don Fair enough, but I don't think that's whats going on here specifically. I can't get ghc-options to effect any change, one way or the other. I guess its a mystery for now. Thanks for the replies. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080624/c5ecc40c/attachment-0001.htm From batterseapower at hotmail.com Wed Jun 25 04:48:36 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Jun 25 04:40:06 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <200806231429.01481.dan.doel@gmail.com> References: <483F78FB.2080207@gmail.com> <9d4d38820806230917k2552329dh507b113ef7e26b92@mail.gmail.com> <485FDFA1.4080104@charter.net> <200806231429.01481.dan.doel@gmail.com> Message-ID: <9d4d38820806250148q2f9b0b71k31094ca0bdd70334@mail.gmail.com> 2008/6/23 Dan Doel : > On Monday 23 June 2008, Isaac Dupree wrote: >> there's no chance for the lower-level near code generation to >> reverse-SAT to eliminate the heap usage? (which would obviously be a >> different optimization that might be useful in other ways too, if it >> could be made to work) (did someone say that -fvia-C with gcc -O3 >> managed to do that sometimes?) > > I said something similar, but I don't actually know the details. What I have > is a SAT and non-SAT version of a benchmark: > > In the SAT version, the native code generator is noticeably slower > than -fvia-c -optc-O3, so the latter is doing something right. In the non-SAT > version, -fvia-c is somewhat faster than the SAT version, but the NCG is just > as fast. I don't know what's going on on the C end in the first case that > makes it better, though (heap allocation is the same (low) in all cases; > via-c doesn't fix large heap allocation when it happens in my experience). I've tested this on my own machine (i386-apple-darwin) and I can't replicate it. For me (with 6.8.2), the SATed version is faster by almost 40%, and there is no essentially no difference between the NCG and GCC (GCC is maybe a fraction faster). In any event GHC will not automatically SAT this function because it has only one static argument. Indeed, I'm not quite sure why it should be faster with SAT at all, and my assembly-fu is still too weak to be able to work it out from the code generator output. > As an aside, I finally got around to compiling 6.9 from a day or so ago, and > noticed that one of the functions I'd mentioned earlier does get SATed to the > bad version (which causes lots of heap allocation in the program) because it > has two static arguments. I devoted yesterday entirely to SAT and came up with some refinements to my earlier heuristics which shave a couple of percent of allocations and runtime off of nofib compared with the existing ones, and also resolve this problem. I found that my tail call detection from the day before was a bit broken. Now that it is fixed I use it to avoid SATing functions which make tail calls, but with the important wrinkle that if the function has static function parameters we should SAT it anyway because this lets us do much more inlining and is a bigger win than avoiding allocation. This criterion avoids the heap allocation you are experiencing in your particular example. I've also added rule generation to rewrite instances of functions that are SATed purely because they have static function parameters back into the non-SATed versions if they do not experience inlinig. This prevents the worst cases that I got before when always SATing functions with static function parameters. What's more, I've found that most if not all SAT opportunities are found early in the pipeline by these new criteria, so we can get away with just one SAT pass instead of the two I reported earlier. All in all, these developments are pretty promising and I suspect I'll be able to integrate them into HEAD in time for 6.10, which will hopefully alleviate some of your worries about the efficacy of SAT. Cheers, Max From benjamin.franksen at bessy.de Thu Jun 26 08:51:05 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Thu Jun 26 09:41:28 2008 Subject: ghc-6.8.3 binary dist problem Message-ID: When I try to ./configure, I get this error: aragon: .../i386-unknown-linux/ghc-6.8.3 > ./configure --prefix=/projects/ctl/franksen/usr checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... configure: error: cannot determine current directory Looking into configure, I see that it calls 'utils/pwd/pwd forwardslash' which seems to be the culprit, since aragon: .../i386-unknown-linux/ghc-6.8.3 > utils/pwd/pwd forwardslash [1] 28489 floating point exception utils/pwd/pwd forwardslash Cheers Ben From igloo at earth.li Thu Jun 26 10:59:17 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 26 10:50:43 2008 Subject: ghc-6.8.3 binary dist problem In-Reply-To: References: Message-ID: <20080626145917.GA18419@matrix.chaos.earth.li> On Thu, Jun 26, 2008 at 02:51:05PM +0200, Benjamin Franksen wrote: > > aragon: .../i386-unknown-linux/ghc-6.8.3 > utils/pwd/pwd forwardslash > [1] 28489 floating point exception utils/pwd/pwd forwardslash This happens when your system (libc?) is too old to run the binaries in the bindist. If you want to use newer versions of GHC on this system then I'm afraid you'll have to compile them yourself. Thanks Ian From jim at sdf-eu.org Thu Jun 26 11:31:24 2008 From: jim at sdf-eu.org (Jim Burton) Date: Thu Jun 26 11:22:53 2008 Subject: error building HEAD Message-ID: <18136817.post@talk.nabble.com> I am trying to build ghc from the latest src from darcs (pulled today) on ubuntu hardy x86. configure and make *seem* to run fine (no errors reported) but make install gives a long stream of errors. Here's some of the output. What's wrong? Thanks! Jim --------------- (.text+0x435): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s7Un_info': (.text+0x7744): undefined reference to `base_TextziReadziLex_a119_info' Main.o: In function `s7VC_info': (.text+0x7de4): undefined reference to `base_TextziReadziLex_a119_info' Main.o: In function `s7WV_info': (.text+0x849c): undefined reference to `base_TextziReadziLex_a119_info' Main.o: In function `s7Ye_info': (.text+0x8b38): undefined reference to `base_TextziReadziLex_a119_info' Main.o: In function `s7Zx_info': (.text+0x91c0): undefined reference to `base_TextziReadziLex_a119_info' Main.o:(.text+0x982c): more undefined references to `base_TextziReadziLex_a119_info' follow Main.o: In function `r7rA_info': (.text+0xd59b): undefined reference to `base_GHCziHandle_checkWritableHandle_info' Main.o: In function `r7rC_info': (.text+0xd5cb): undefined reference to `base_GHCziHandle_checkWritableHandle_info' Main.o: In function `sdW4_info': (.text+0xd62e): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `s8bn_info': (.text+0xd66c): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `r7ug_info': (.text+0xf353): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `r7uq_info': (.text+0xf4fb): undefined reference to `base_GHCziHandle_checkWritableHandle_info' Main.o: In function `r7us_info': (.text+0xf52b): undefined reference to `base_GHCziHandle_checkWritableHandle_info' Main.o: In function `sewY_info': (.text+0xf5fd): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sewX_info': (.text+0xf63f): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `seRK_info': (.text+0x10658): undefined reference to `DistributionziPackage_zdwzsze_info' Main.o: In function `seZs_info': (.text+0x108ed): undefined reference to `base_DataziVersion_compare5_info' Main.o: In function `s8kb_info': (.text+0x10a94): undefined reference to `DistributionziPackage_go1_info' Main.o: In function `s8kq_info': (.text+0x10be4): undefined reference to `DistributionziPackage_go_info' Main.o: In function `r7xq_info': (.text+0x10cae): undefined reference to `DistributionziCompatziReadP_a13_info' Main.o: In function `r7xu_info': (.text+0x10d7f): undefined reference to `DistributionziCompatziReadP_mplus_info' Main.o: In function `r7xw_info': (.text+0x10fa8): undefined reference to `DistributionziCompatziReadP_run_info' Main.o: In function `s8nM_info': (.text+0x1166a): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `sfeV_info': (.text+0x11699): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s8oE_info': (.text+0x119b6): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `sfjk_info': (.text+0x119e5): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s8r2_info': (.text+0x125fe): undefined reference to `DistributionziPackage_showList_info' Main.o: In function `s8ta_info': (.text+0x14fef): undefined reference to `DistributionziLicense_showsPrec_info' Main.o: In function `sfqg_info': (.text+0x152d4): undefined reference to `DistributionziPackage_zdwshowsPrec_info' Main.o: In function `sgFo_info': (.text+0x15e1f): undefined reference to `DistributionziInstalledPackageInfo_showInstalledPackageInfoField_info' Main.o: In function `s8DS_info': (.text+0x16bfc): undefined reference to `SystemziFilePathziPosix_takeDirectory_info' Main.o: In function `sgY1_info': (.text+0x16dda): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sgXZ_info': (.text+0x16e05): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sgXV_info': (.text+0x16e50): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sgXU_info': (.text+0x16e9f): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sgXK_info': (.text+0x16f58): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a44_info' Main.o: In function `r7yG_info': (.text+0x16fa1): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8EY_info': (.text+0x16fd8): undefined reference to `base_GHCziIOBase_zddmshow6_info' Main.o: In function `sh1S_info': (.text+0x17052): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `s8EU_info': (.text+0x1709c): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sh3l_info': (.text+0x172bd): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sh3k_info': (.text+0x172ff): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8Fq_info': (.text+0x173e3): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a34_info' Main.o: In function `s8GG_info': (.text+0x1744d): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a26_info' Main.o: In function `sh3x_info': (.text+0x17472): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sh3v_info': (.text+0x1749d): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8GT_info': (.text+0x174d3): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a34_info' Main.o: In function `sh3D_info': (.text+0x17552): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8Hh_info': (.text+0x175e3): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sh3I_info': (.text+0x17625): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `s8Gu_info': (.text+0x17663): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8Hk_info': (.text+0x177a9): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8I1_info': (.text+0x17918): undefined reference to `base_GHCziIOBase_zddmshow9_info' Main.o: In function `r7yY_info': (.text+0x17cdb): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s8Jq_info': (.text+0x17e6e): undefined reference to `SystemziFilePathziPosix_combineAlways_info' Main.o: In function `s8Jw_info': (.text+0x17e89): undefined reference to `SystemziFilePathziPosix_combineAlways_info' Main.o: In function `shhH_info': (.text+0x17fea): undefined reference to `SystemziFilePathziPosix_combineAlways_info' Main.o: In function `s8JH_info': (.text+0x1801c): undefined reference to `SystemziFilePathziPosix_combineAlways_info' Main.o: In function `shhP_info': (.text+0x1839b): undefined reference to `base_GHCziList_polyzuinitzq_info' Main.o: In function `shhN_info': (.text+0x1843e): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `shhM_info': (.text+0x1849a): undefined reference to `SystemziFilePathziPosix_splitSearchPath_info' Main.o: In function `shhR_info': (.text+0x1854b): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `s8Ld_info': (.text+0x18739): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s8LA_info': (.text+0x18908): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `shi6_info': (.text+0x18fad): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a47_info' Main.o: In function `s8MR_info': (.text+0x19076): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `r7z6_info': (.text+0x19369): undefined reference to `DistributionziParseUtils_zdwlocatedErrorMsg_info' Main.o: In function `s8O1_info': (.text+0x19574): undefined reference to `DistributionziPackage_go1_info' Main.o: In function `s8PZ_info': (.text+0x19a24): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `shKV_info': (.text+0x19d8e): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s8R3_info': (.text+0x19e2a): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `shLE_info': (.text+0x19e59): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s8ST_info': (.text+0x1a025): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `s8SX_info': (.text+0x1a067): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `shO3_info': (.text+0x1ab09): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `shO0_info': (.text+0x1ab52): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shNZ_info': (.text+0x1aba2): undefined reference to `base_GHCziList_foldr21_info' Main.o: In function `shNS_info': (.text+0x1ad1d): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `shNO_info': (.text+0x1ad65): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `shNM_info': (.text+0x1ad91): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shNI_info': (.text+0x1add9): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `shNG_info': (.text+0x1ae05): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s8XF_info': (.text+0x1ae8f): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shNB_info': (.text+0x1af89): undefined reference to `processzm1zi0zi0zi0_SystemziCmd_a_info' Main.o: In function `shNA_info': (.text+0x1b027): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shNx_info': (.text+0x1b0e2): undefined reference to `base_GHCziList_foldr21_info' Main.o: In function `s8ZY_info': (.text+0x1b7dd): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `shOU_info': (.text+0x1b80d): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s90Q_info': (.text+0x1b961): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `shPo_info': (.text+0x1b991): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s91h_info': (.text+0x1bb55): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `shPt_info': (.text+0x1bb9f): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s920_info': (.text+0x1bec5): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `shPC_info': (.text+0x1bef5): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `shL9_info': (.text+0x1c28e): undefined reference to `DistributionziCompatziReadP_run_info' Main.o: In function `shL7_info': (.text+0x1c2cd): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `s92A_info': (.text+0x1c2fc): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shPO_info': (.text+0x1c3a9): undefined reference to `DistributionziInstalledPackageInfo_foldM1_info' Main.o: In function `shL6_info': (.text+0x1c3ca): undefined reference to `DistributionziParseUtils_readFields_info' Main.o: In function `s93n_info': (.text+0x1c5aa): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `shQ0_info': (.text+0x1c65b): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s98Z_info': (.text+0x1d065): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `siWl_info': (.text+0x1d095): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s99o_info': (.text+0x1d181): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `siWj_info': (.text+0x1d1b1): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s99J_info': (.text+0x1d319): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `siWg_info': (.text+0x1d349): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s9bf_info': (.text+0x1d492): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `s9aW_info': (.text+0x1d5d1): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_zdwmkNest_info' Main.o: In function `s9aU_info': (.text+0x1d5f2): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_reduceDoc_info' Main.o: In function `s9aS_info': (.text+0x1d619): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fill_info' Main.o: In function `s9aQ_info': (.text+0x1d641): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_punctuate_info' Main.o: In function `siWO_info': (.text+0x1d6fd): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `siWN_info': (.text+0x1d748): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `siWc_info': (.text+0x1d896): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `s9bF_info': (.text+0x1d8e6): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s98v_info': (.text+0x1da51): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s9bY_info': (.text+0x1ddd8): undefined reference to `DistributionziInstalledPackageInfo_showInstalledPackageInfo_info' Main.o: In function `sjbS_info': (.text+0x1de19): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sjbR_info': (.text+0x1de73): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sjdd_info': (.text+0x1df0a): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `s9cG_info': (.text+0x1df84): undefined reference to `SystemziFilePathziPosix_takeDirectory_info' Main.o: In function `sjdl_info': (.text+0x1e3bd): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sjdk_info': (.text+0x1e41d): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s9k6_info': (.text+0x1f306): undefined reference to `base_GHCziList_polyzuinitzq_info' Main.o: In function `s9ko_info': (.text+0x1f456): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s9ku_info': (.text+0x1f4aa): undefined reference to `base_GHCziList_polyzurev_info' Main.o: In function `s9kB_info': (.text+0x1f566): undefined reference to `base_GHCziList_polyzuinitzq_info' Main.o: In function `s9km_info': (.text+0x1f751): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `s9km_info': (.text+0x1f778): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `s9nh_info': (.text+0x20002): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `sjAB_info': (.text+0x20031): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s9nj_info': (.text+0x20099): undefined reference to `base_GHCziList_polyzulastzq_info' Main.o: In function `sjAC_info': (.text+0x200be): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sjAz_info': (.text+0x20118): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `s9rN_info': (.text+0x20d9a): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `s9qR_info': (.text+0x2102d): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_zdwmkNest_info' Main.o: In function `s9qP_info': (.text+0x2104e): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_reduceDoc_info' Main.o: In function `s9qN_info': (.text+0x21075): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fill_info' Main.o: In function `s9qL_info': (.text+0x2109d): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_punctuate_info' Main.o: In function `s9qp_info': (.text+0x21241): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `sjBy_info': (.text+0x21271): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `s9ru_info': (.text+0x21409): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fill_info' Main.o: In function `s9rs_info': (.text+0x21431): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_punctuate_info' Main.o: In function `s9rm_info': (.text+0x214c9): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_info' Main.o: In function `sjBv_info': (.text+0x214f9): undefined reference to `DistributionziPackage_zdwdisp1_info' Main.o: In function `sjBz_info': (.text+0x2161d): undefined reference to `base_GHCziIO_zdwa13_info' Main.o: In function `sjBr_info': (.text+0x2167d): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sjzI_info': (.text+0x21b5f): undefined reference to `unixzm2zi3zi0zi0_SystemziPosixziSignals_a38_info' Main.o: In function `sjzH_info': (.text+0x21bc7): undefined reference to `unixzm2zi3zi0zi0_SystemziPosixziSignals_a38_info' Main.o: In function `sjzE_info': (.text+0x21c2b): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sjzB_info': (.text+0x21d01): undefined reference to `base_GHCziIO_a25_info' Main.o: In function `sjzs_info': (.text+0x2209b): undefined reference to `base_GHCziTopHandler_a7_info' Main.o: In function `r7nA_srt': (.data+0x0): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7nC_srt': (.data+0xc): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7nE_srt': (.data+0x18): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7nI_srt': (.data+0x28): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7nK_srt': (.data+0x34): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7oI_srt': (.data+0x220): undefined reference to `base_TextziReadziLex_a119_closure' Main.o: In function `r7oI_srt': (.data+0x22c): undefined reference to `DistributionziPackage_a17_closure' Main.o: In function `r7oI_srt': (.data+0x230): undefined reference to `DistributionziPackage_a16_closure' Main.o: In function `r7oI_srt': (.data+0x23c): undefined reference to `DistributionziLicense_a20_closure' Main.o: In function `r7oS_srt': (.data+0x7a4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7pq_srt': (.data+0x8a4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7ps_srt': (.data+0x8b0): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7rA_srt': (.data+0xcb0): undefined reference to `base_GHCziHandle_checkWritableHandle_closure' Main.o: In function `r7rC_srt': (.data+0xcc0): undefined reference to `base_GHCziHandle_checkWritableHandle_closure' Main.o: In function `r7rE_srt': (.data+0xccc): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7rE_srt': (.data+0xcd4): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7rW_srt': (.data+0xd74): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl5_closure' Main.o: In function `r7rW_srt': (.data+0xd78): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a8_closure' Main.o: In function `r7uq_srt': (.data+0x12f4): undefined reference to `base_GHCziHandle_checkWritableHandle_closure' Main.o: In function `r7us_srt': (.data+0x1304): undefined reference to `base_GHCziHandle_checkWritableHandle_closure' Main.o: In function `r7uu_srt': (.data+0x1310): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7uu_srt': (.data+0x1318): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7uy_srt': (.data+0x1354): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl10_closure' Main.o: In function `r7uy_srt': (.data+0x1358): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a8_closure' Main.o: In function `r7xm_srt': (.data+0x18e0): undefined reference to `DistributionziPackage_lvl2_closure' Main.o: In function `r7xo_srt': (.data+0x18ec): undefined reference to `DistributionziPackage_ds_closure' Main.o: In function `r7xo_srt': (.data+0x18f0): undefined reference to `DistributionziPackage_lvl2_closure' Main.o: In function `r7xs_srt': (.data+0x1910): undefined reference to `DistributionziPackage_ds_closure' Main.o: In function `r7xu_srt': (.data+0x1928): undefined reference to `DistributionziCompatziReadP_mplus_closure' Main.o: In function `r7xC_closure': (.data+0x1990): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_Str_static_info' Main.o: In function `rXy_srt': (.data+0x19b8): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `rXu_srt': (.data+0x19c4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `rXu_srt': (.data+0x19c8): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7y2_srt': (.data+0x1a78): undefined reference to `DistributionziPackage_showList_closure' Main.o: In function `r7y2_srt': (.data+0x1a7c): undefined reference to `DistributionziInstalledPackageInfo_zddmshowList1_closure' Main.o: In function `r7y2_srt': (.data+0x1a84): undefined reference to `DistributionziPackage_zdwshowsPrec_closure' Main.o: In function `r7y2_srt': (.data+0x1a90): undefined reference to `DistributionziLicense_showsPrec_closure' Main.o: In function `r7yo_srt': (.data+0x1b18): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7ys_srt': (.data+0x1b34): undefined reference to `DistributionziInstalledPackageInfo_showInstalledPackageInfoField_closure' Main.o: In function `r7yy_srt': (.data+0x1c78): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7yA_srt': (.data+0x1c84): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7yG_srt': (.data+0x1cb0): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a44_closure' Main.o: In function `r7yG_srt': (.data+0x1cb8): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7yG_srt': (.data+0x1cc0): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7yI_srt': (.data+0x1cec): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7yI_srt': (.data+0x1cf4): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7yI_srt': (.data+0x1cf8): undefined reference to `base_GHCziIOBase_zddmshow6_closure' Main.o: In function `r7yK_srt': (.data+0x1d0c): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a34_closure' Main.o: In function `r7yK_srt': (.data+0x1d10): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a26_closure' Main.o: In function `r7yK_srt': (.data+0x1d14): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7yK_srt': (.data+0x1d1c): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7yO_closure': (.data+0x1d60): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a5_closure' Main.o: In function `r7yQ_closure': (.data+0x1d70): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl4_closure' Main.o: In function `r7yU_srt': (.data+0x1d94): undefined reference to `base_GHCziIOBase_zddmshow9_closure' Main.o: In function `r7z2_srt': (.data+0x1ddc): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl10_closure' Main.o: In function `r7z2_srt': (.data+0x1de0): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl5_closure' Main.o: In function `r7z2_srt': (.data+0x1de4): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a8_closure' Main.o: In function `r7z2_srt': (.data+0x1de8): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a3_closure' Main.o: In function `r7z2_srt': (.data+0x1dec): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a47_closure' Main.o: In function `r7z6_srt': (.data+0x1e84): undefined reference to `DistributionziParseUtils_zdwlocatedErrorMsg_closure' Main.o: In function `r7ze_srt': (.data+0x1ea4): undefined reference to `DistributionziPackage_lvl2_closure' Main.o: In function `r7zg_srt': (.data+0x1eb0): undefined reference to `DistributionziPackage_ds_closure' Main.o: In function `r7zg_srt': (.data+0x1eb4): undefined reference to `DistributionziPackage_lvl2_closure' Main.o: In function `r7zi_srt': (.data+0x1ecc): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7zi_srt': (.data+0x1ed0): undefined reference to `DistributionziInstalledPackageInfo_lvl85_closure' Main.o: In function `r7zi_srt': (.data+0x1ed4): undefined reference to `DistributionziParseUtils_readFields_closure' Main.o: In function `r7zi_srt': (.data+0x1ed8): undefined reference to `processzm1zi0zi0zi0_SystemziCmd_a_closure' Main.o: In function `r7zi_srt': (.data+0x1ef4): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7zi_srt': (.data+0x1efc): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7zi_srt': (.data+0x1f90): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7zw_srt': (.data+0x256c): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fill_closure' Main.o: In function `r7zw_srt': (.data+0x2570): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7zw_srt': (.data+0x2574): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7zw_srt': (.data+0x257c): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7zw_srt': (.data+0x2580): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7zw_srt': (.data+0x2584): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_reduceDoc_closure' Main.o: In function `r7zw_srt': (.data+0x2588): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7zy_srt': (.data+0x2598): undefined reference to `DistributionziInstalledPackageInfo_showInstalledPackageInfo_closure' Main.o: In function `r7zy_srt': (.data+0x259c): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7zy_srt': (.data+0x25a4): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7zA_srt': (.data+0x25b4): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7zA_srt': (.data+0x25bc): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7zE_closure': (.data+0x25f4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_Str_static_info' Main.o: In function `r7Am_closure': (.data+0x270c): undefined reference to `base_GHCziBase_Z0T_closure' Main.o: In function `r7Au_closure': (.data+0x2760): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fill_closure' Main.o: In function `r7Au_closure': (.data+0x2764): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7Au_closure': (.data+0x2768): undefined reference to `unixzm2zi3zi0zi0_SystemziPosixziSignals_a38_closure' Main.o: In function `r7Au_closure': (.data+0x2778): undefined reference to `base_GHCziIO_zdwa13_closure' Main.o: In function `r7Au_closure': (.data+0x2780): undefined reference to `base_GHCziIO_a25_closure' Main.o: In function `r7Au_closure': (.data+0x278c): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_reduceDoc_closure' Main.o: In function `r7Au_closure': (.data+0x2790): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `r7Au_closure': (.data+0x2794): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_fullRender_closure' Main.o: In function `ckw6_srtd': (.data+0x2c6c): undefined reference to `base_GHCziTopHandler_a7_closure' collect2: ld returned 1 exit status <> make[2]: *** [ghc-pkg.bin] Error 1 Failed making install in ghc-pkg: 1 make[1]: *** [install] Error 1 make: *** [install] Error 1 -- View this message in context: http://www.nabble.com/error-building-HEAD-tp18136817p18136817.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From igloo at earth.li Thu Jun 26 11:37:07 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 26 11:28:33 2008 Subject: Default class method inlining bug (wasn't this fixed?) In-Reply-To: References: Message-ID: <20080626153707.GB18419@matrix.chaos.earth.li> On Wed, Jun 18, 2008 at 10:42:44AM -0600, Scott Dillard wrote: > > If someone confirms, I'll open a ticket. The core is certainly different. It doesn't build in the HEAD, so I haven't looked to see what it looks like there. Please do file a ticket, although if you can cut the example down then that will make it easier to look at, and to convert into a testcase for the testsuite. Also, please include what flags you compile with in the ticket. Thanks Ian From igloo at earth.li Thu Jun 26 11:38:32 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 26 11:29:59 2008 Subject: error building HEAD In-Reply-To: <18136817.post@talk.nabble.com> References: <18136817.post@talk.nabble.com> Message-ID: <20080626153832.GC18419@matrix.chaos.earth.li> On Thu, Jun 26, 2008 at 08:31:24AM -0700, Jim Burton wrote: > > I am trying to build ghc from the latest src from darcs (pulled today) on > ubuntu hardy x86. configure and make *seem* to run fine (no errors reported) > but make install gives a long stream of errors. Here's some of the output. > What's wrong? Thanks! "make install" is probably broken at the moment. You should be able to use it in-place, though (run compiler/stage2/ghc-inplace). Thanks Ian From sedillard at ucdavis.edu Thu Jun 26 12:05:38 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Thu Jun 26 11:57:04 2008 Subject: Default class method inlining bug (wasn't this fixed?) In-Reply-To: <20080626153707.GB18419@matrix.chaos.earth.li> References: <20080626153707.GB18419@matrix.chaos.earth.li> Message-ID: Ticket and standalone program are here -> http://hackage.haskell.org/trac/ghc/ticket/2396 But I don't know anything about the test suite or how to make a test case. Scott On Thu, Jun 26, 2008 at 9:37 AM, Ian Lynagh wrote: > On Wed, Jun 18, 2008 at 10:42:44AM -0600, Scott Dillard wrote: > > > > If someone confirms, I'll open a ticket. > > The core is certainly different. It doesn't build in the HEAD, so I > haven't looked to see what it looks like there. > > Please do file a ticket, although if you can cut the example down then > that will make it easier to look at, and to convert into a testcase for > the testsuite. Also, please include what flags you compile with in the > ticket. > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080626/dd8d68fc/attachment.htm From igloo at earth.li Thu Jun 26 14:44:55 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 26 14:36:21 2008 Subject: Default class method inlining bug (wasn't this fixed?) In-Reply-To: References: <20080626153707.GB18419@matrix.chaos.earth.li> Message-ID: <20080626184455.GA22433@matrix.chaos.earth.li> On Thu, Jun 26, 2008 at 10:05:38AM -0600, Scott Dillard wrote: > Ticket and standalone program are here -> > http://hackage.haskell.org/trac/ghc/ticket/2396 Thanks! > But I don't know anything about the test suite or how to make a test case. I didn't mean that you should add it to the testsuite yourself, just that having a minimal example makes it easier for us to do so. Thanks Ian From jim at sdf-eu.org Thu Jun 26 15:32:40 2008 From: jim at sdf-eu.org (Jim Burton) Date: Thu Jun 26 15:24:10 2008 Subject: error building HEAD In-Reply-To: <20080626153832.GC18419@matrix.chaos.earth.li> References: <18136817.post@talk.nabble.com> <20080626153832.GC18419@matrix.chaos.earth.li> Message-ID: <87y74sxa93.wl%jim@sdf-eu.org> At Thu, 26 Jun 2008 16:38:32 +0100, Ian Lynagh wrote: > > On Thu, Jun 26, 2008 at 08:31:24AM -0700, Jim Burton wrote: > > > > I am trying to build ghc from the latest src from darcs (pulled today) on > > ubuntu hardy x86. configure and make *seem* to run fine (no errors reported) > > but make install gives a long stream of errors. Here's some of the output. > > What's wrong? Thanks! > > "make install" is probably broken at the moment. You should be able to > use it in-place, though (run compiler/stage2/ghc-inplace). > Thanks Ian. In fact, the stable branch will be suitable for my needs so I'll stick to that and I don't suppose I'll find this there? If I do I'll use your suggestion. Jim > > Thanks > Ian From igloo at earth.li Thu Jun 26 15:46:52 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 26 15:38:18 2008 Subject: error building HEAD In-Reply-To: <87y74sxa93.wl%jim@sdf-eu.org> References: <18136817.post@talk.nabble.com> <20080626153832.GC18419@matrix.chaos.earth.li> <87y74sxa93.wl%jim@sdf-eu.org> Message-ID: <20080626194652.GA2279@matrix.chaos.earth.li> On Thu, Jun 26, 2008 at 08:32:40PM +0100, Jim Burton wrote: > > > > "make install" is probably broken at the moment. You should be able to > > use it in-place, though (run compiler/stage2/ghc-inplace). > > > Thanks Ian. In fact, the stable branch will be suitable for my needs > so I'll stick to that I'm not sure what your needs are, but note that the stable branch is identical to 6.8.3 and no more releases will be made from it, so you might prefer to just use 6.8.3. > and I don't suppose I'll find this there The stable branch doesn't have the "make install" problems, no. Thanks Ian From jim at sdf-eu.org Fri Jun 27 05:26:01 2008 From: jim at sdf-eu.org (Jim Burton) Date: Fri Jun 27 05:17:26 2008 Subject: error building HEAD In-Reply-To: <20080626194652.GA2279@matrix.chaos.earth.li> References: <18136817.post@talk.nabble.com> <20080626153832.GC18419@matrix.chaos.earth.li> <87y74sxa93.wl%jim@sdf-eu.org> <20080626194652.GA2279@matrix.chaos.earth.li> Message-ID: <87d4m36xg6.wl%jim@sdf-eu.org> At Thu, 26 Jun 2008 20:46:52 +0100, Ian Lynagh wrote: > > On Thu, Jun 26, 2008 at 08:32:40PM +0100, Jim Burton wrote: > > > > > > "make install" is probably broken at the moment. You should be able to > > > use it in-place, though (run compiler/stage2/ghc-inplace). > > > > > Thanks Ian. In fact, the stable branch will be suitable for my needs > > so I'll stick to that > > I'm not sure what your needs are, Playing with type families, so it has to be 6.9. I will try with a 6.9 snapshot. Thanks, Jim > but note that the stable branch is > identical to 6.8.3 and no more releases will be made from it, so you > might prefer to just use 6.8.3. > > > and I don't suppose I'll find this there > > The stable branch doesn't have the "make install" problems, no. > > > Thanks > Ian From mechvel at botik.ru Fri Jun 27 06:55:45 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Jun 27 06:47:08 2008 Subject: possible OI extension Message-ID: <20080627105545.GA24702@scico.botik.ru> Hello, people, This is about possible extension in treating of overlapping instances. Here is a simple example. ------------------------------------------ import qualified Data.Set as Set (empty, member, insert) import List (nub) class Nub a where myNub :: a -> a instance Eq a => Nub [a] where myNub = nub instance Ord a => Nub [a] where myNub xs = nub' Set.empty xs where nub' _ [] = [] nub' set (x: xs) = if Set.member x set then nub' set xs else x: (nub' (Set.insert x set) xs) ------------------------------------------ The idea is that it is good to replace nub of the Haskell-98 library with myNub. Because: for Eq a, myNub costs O(n^2), for Ord a, myNub costs O(n*(log n)), and it is good to denote this operation with the same name. Compiling this by GHC under -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances yields the error report: Duplicate instance declarations: instance [overlap ok] (Eq a) => Nub [a] -- Defined at IOverlap2.hs:8:0-43 instance [overlap ok] (Ord a) => Nub [a] -- Defined at IOverlap2.hs:(9,0)-(15,71) Probably, as the context of Ord a is stronger than Eq a, then on the instance overlap, the compiler could choose the instance with the stronger context. Can there be a reasonably implemented extension of this kind? Thank you in advance for your comments, ----------------- Serge Mechveliani mechvel@botik.ru From claus.reinke at talk21.com Fri Jun 27 09:03:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Jun 27 08:55:17 2008 Subject: using GHC for dependency generation, a couple of questions Message-ID: <00d201c8d856$3ec64f30$4d268351@cr3lt> http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#makefile-dependencies Recently, I stumbled on -v2 in combination with --make or -M, which produces nice module-based output instead of the file-based makefile dependencies of -M, but have run into a couple of : 1. --make can't be used with -fno-code, and -M always generates a file, so is this the best one can do: ghc -M -v2 -optdep-f -optdep depend Main.hs ? It would be nice to have the dry-run option (isn't that -fno-code?) work with all commands that produce useful stdout information (including --make -v2). 2. I can't seem to figure out what --include-pkg-deps does? In a way, it seems to be always on, since package imports are always listed in the -v2 output. Claus From benjamin.franksen at bessy.de Fri Jun 27 09:22:35 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Fri Jun 27 09:14:06 2008 Subject: ghc-6.8.3 binary dist problem References: <20080626145917.GA18419@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > On Thu, Jun 26, 2008 at 02:51:05PM +0200, Benjamin Franksen wrote: >> aragon: .../i386-unknown-linux/ghc-6.8.3 > utils/pwd/pwd forwardslash >> [1] 28489 floating point exception utils/pwd/pwd forwardslash > > This happens when your system (libc?) is too old to run the binaries in > the bindist. If you want to use newer versions of GHC on this system > then I'm afraid you'll have to compile them yourself. Thanks. Indeed, we are on debian stable, here. At home I have the latest kubuntu and there the binary dist works just fine. Cheers Ben From simonpj at microsoft.com Fri Jun 27 10:01:00 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 27 09:52:24 2008 Subject: possible OI extension In-Reply-To: <20080627105545.GA24702@scico.botik.ru> References: <20080627105545.GA24702@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE71E19DD@EA-EXMSG-C334.europe.corp.microsoft.com> Yes, the idea of some kind of backtracking solution of class constraints (multiple instance declarations, choose the one whose context is indeed soluble) has often been suggested, and is quite attractive. But it raises a bunch of new complications. And your proposal does so even more, because it involves a notion of when one context is "stronger" than another. (What exactly does "stronger" mean.) Just for example, what's the inferred type of f x = nub (nub [x]) It could be f :: Eq a => a -> [a] or f :: Ord a => a -> [a] So far as the implementation is concerned, "improvement" currently happens by in-place unification, which is hard to undo when you need backtracking, so there's a practical problem there. That'll be ameliorated as we move towards type functions. So I can see the attraction, but I doubt I'll implement it anytime soon. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 27 June 2008 11:56 | To: glasgow-haskell-users@haskell.org | Subject: possible OI extension | | Hello, people, | | This is about possible extension in treating of overlapping instances. | Here is a simple example. | | ------------------------------------------ | import qualified Data.Set as Set (empty, member, insert) | import List (nub) | | class Nub a where myNub :: a -> a | | instance Eq a => Nub [a] where myNub = nub | | instance Ord a => Nub [a] | where | myNub xs = nub' Set.empty xs | where | nub' _ [] = [] | nub' set (x: xs) = if Set.member x set then nub' set xs | else x: (nub' (Set.insert x set) xs) | ------------------------------------------ | | The idea is that it is good to replace nub of the Haskell-98 library | with myNub. | Because: | for Eq a, myNub costs O(n^2), | for Ord a, myNub costs O(n*(log n)), | and it is good to denote this operation with the same name. | | Compiling this by GHC under | -fglasgow-exts -fallow-overlapping-instances | -fallow-undecidable-instances | | yields the error report: | | Duplicate instance declarations: | instance [overlap ok] (Eq a) => Nub [a] | -- Defined at IOverlap2.hs:8:0-43 | instance [overlap ok] (Ord a) => Nub [a] | -- Defined at IOverlap2.hs:(9,0)-(15,71) | | Probably, as the context of Ord a is stronger than Eq a, | then on the instance overlap, the compiler could choose the | instance with the stronger context. | | Can there be a reasonably implemented extension of this kind? | | Thank you in advance for your comments, | | ----------------- | Serge Mechveliani | mechvel@botik.ru | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From judah.jacobson at gmail.com Fri Jun 27 11:59:08 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jun 27 11:50:35 2008 Subject: Illegal instruction with ghc-6.8.3 distribution (OS X Tiger) Message-ID: <6d74b0d20806270859w11711916t1cd65f0445064867@mail.gmail.com> Hi, I recently installed ghc-6.8.3 on an iBook running OS X 10.4.11 (PowerPC G4), using the following distribution: http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 Running the following program, compiled with -O, causes an illegal instruction error: =========== module Main where main = print foo foo :: Integer foo = gcd 400 85 ================== Running through gdb produced the following output: Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x00046b50 in __gmpn_gcd_1 () (gdb) where #0 0x00046b50 in __gmpn_gcd_1 () #1 0x00028cb0 in gcdIntzh_fast () #2 0x0002be34 in scheduleWaitThread () #3 0x0001fdb8 in real_main () #4 0x0001fec0 in main () (gdb) quit Christian, did you compile this distribution on a G5 PowerPC? GMP is statically linked into this distribution, so if it's using any processor-specific instructions I could see that tripping up my G4. If you or someone else can confirm that this works on a G5, then we should probably just update the downloads page with that requirement. Thanks, -Judah From Christian.Maeder at dfki.de Fri Jun 27 12:34:35 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jun 27 12:25:58 2008 Subject: Illegal instruction with ghc-6.8.3 distribution (OS X Tiger) In-Reply-To: <6d74b0d20806270859w11711916t1cd65f0445064867@mail.gmail.com> References: <6d74b0d20806270859w11711916t1cd65f0445064867@mail.gmail.com> Message-ID: <4865169B.40400@dfki.de> Judah Jacobson wrote: > Christian, did you compile this distribution on a G5 PowerPC? Yes! > GMP is > statically linked into this distribution, so if it's using any > processor-specific instructions I could see that tripping up my G4. > If you or someone else can confirm that this works on a G5, then we > should probably just update the downloads page with that requirement. Your example works for me. Maybe my libgmp.a in /lib/ghc-6.8.3/ (that's used for linking) can be exchanged on a G4? My ghc-6.8.3 itself is linked against this very same libgmp.a (and seems to run). Cheers Christian From judah.jacobson at gmail.com Fri Jun 27 13:30:58 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jun 27 13:22:35 2008 Subject: Illegal instruction with ghc-6.8.3 distribution (OS X Tiger) In-Reply-To: <4865169B.40400@dfki.de> References: <6d74b0d20806270859w11711916t1cd65f0445064867@mail.gmail.com> <4865169B.40400@dfki.de> Message-ID: <6d74b0d20806271030k432c3b99jfca52e895d74130f@mail.gmail.com> On Fri, Jun 27, 2008 at 12:34 PM, Christian Maeder wrote: > Judah Jacobson wrote: >> >> Christian, did you compile this distribution on a G5 PowerPC? > > Yes! > >> GMP is >> statically linked into this distribution, so if it's using any >> processor-specific instructions I could see that tripping up my G4. >> If you or someone else can confirm that this works on a G5, then we >> should probably just update the downloads page with that requirement. > > Your example works for me. Maybe my libgmp.a in /lib/ghc-6.8.3/ > (that's used for linking) can be exchanged on a G4? My ghc-6.8.3 itself is > linked against this very same libgmp.a (and seems to run). OK, replacing that libgmp with a custom-built version fixed my standalone GCD.hs example. So that confirms the problem. Unfortunately, that doesn't fix it for me; my real issue is that ghc iself is getting the illegal instruction error, in the middle of compiling haddock-0.9. And since ghc is statically linked to libgmp, it can't use the replacement lib for itself. (Ironic, since statically linking gmp is supposed to make installation _easier_ :-) It's not a big problem for me, though; one of the ghc-6.8.2 distributions should work fine, and I can use them to build 6.8.3 myself. Now that we've confirmed it, can someone please update the 6.8.3 downloads page (Replacing "PowerPC" with "PowerPC G5", perhaps)? Thanks, -Judah From igloo at earth.li Fri Jun 27 13:46:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 27 13:38:19 2008 Subject: Illegal instruction with ghc-6.8.3 distribution (OS X Tiger) In-Reply-To: <6d74b0d20806271030k432c3b99jfca52e895d74130f@mail.gmail.com> References: <6d74b0d20806270859w11711916t1cd65f0445064867@mail.gmail.com> <4865169B.40400@dfki.de> <6d74b0d20806271030k432c3b99jfca52e895d74130f@mail.gmail.com> Message-ID: <20080627174654.GA23057@matrix.chaos.earth.li> On Fri, Jun 27, 2008 at 01:30:58PM -0400, Judah Jacobson wrote: > > Now that we've confirmed it, can someone please update the 6.8.3 > downloads page (Replacing "PowerPC" with "PowerPC G5", perhaps)? I've updated the blurb. Thanks Ian From twhitehead at gmail.com Sat Jun 28 12:32:30 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Sat Jun 28 12:22:54 2008 Subject: Implicit Function Arguments Message-ID: <200806281232.30989.twhitehead@gmail.com> What do people think about implicit function argument? That is, named function arguments, possibly tagged with something special like a tilde, whereby scoped variables of the same name are automatically passed. The idea is to avoid the pain of a lots of pass through parameters while make it easy to modify one or two of them. For example, in f1 :: ~state::State -> Input -> Output f1 input = f2 input f2 :: ~state::State -> Input -> Output f2 input = we don't have to specify ~state for f2 because it picks it up automatically from ~state being in scope from f1. To change it, however, we just do f1 :: ~state::State -> Input -> Output f1 input = f2 input where ~state = The advantage over wrapping it in a monad being: 1) it is evident what is being passed around behind the scenes from the type signatures, and 2) we avoiding the lifting issue (to compose multiple implicit arguments we just specifying them -- assuming their are no name clashes). Cheers! -Tyson From allbery at ece.cmu.edu Sat Jun 28 13:00:17 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Jun 28 12:51:36 2008 Subject: Implicit Function Arguments In-Reply-To: <200806281232.30989.twhitehead@gmail.com> References: <200806281232.30989.twhitehead@gmail.com> Message-ID: On 2008 Jun 28, at 12:32, Tyson Whitehead wrote: > What do people think about implicit function argument? http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#implicit-parameters It uses ? as the prefix instead of ~ (which already has a meaning in pattern matching). I am under the impression they are deprecated and slated for removal. -- 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 From philip.weaver at gmail.com Sun Jun 29 04:56:16 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Sun Jun 29 04:47:33 2008 Subject: Implicit Function Arguments In-Reply-To: References: <200806281232.30989.twhitehead@gmail.com> Message-ID: > I am under the impression they are deprecated and slated for removal. > This is the second time I have seen someone comment on implicit parameters being planned for removal, so now you have my attention :). I'd like to mention that a rather large project where I work (Galois, Inc.) uses implicit parameters a lot, so removing support for them would make me rather unhappy. - Phil From allbery at ece.cmu.edu Sun Jun 29 14:43:10 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Jun 29 14:34:25 2008 Subject: Implicit Function Arguments In-Reply-To: References: <200806281232.30989.twhitehead@gmail.com> Message-ID: <5EEE7E77-B986-43F2-B573-835529BCB7CC@ece.cmu.edu> On 2008 Jun 29, at 4:56, Philip Weaver wrote: >> I am under the impression they are deprecated and slated for removal. >> > This is the second time I have seen someone comment on implicit > parameters being planned for removal, so now you have my attention :). > I'd like to mention that a rather large project where I work (Galois, > Inc.) uses implicit parameters a lot, so removing support for them > would make me rather unhappy. Hm, looks like terminology confusion. Implicit parameters are staying. *Linear* implicit parameters were deprecated in 6.6 and seem to be gone now. -- 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 From marco-oweber at gmx.de Sun Jun 29 19:08:03 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jun 29 18:59:20 2008 Subject: Implicit Function Arguments In-Reply-To: References: <200806281232.30989.twhitehead@gmail.com> Message-ID: <20080629230803.GB5274@gmx.de> On Sat, Jun 28, 2008 at 01:00:17PM -0400, Brandon S. Allbery KF8NH wrote: > > On 2008 Jun 28, at 12:32, Tyson Whitehead wrote: > > > What do people think about implicit function argument? > > http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#implicit-parameters > It uses ? as the prefix instead of ~ (which already has a meaning in pattern > matching). The solution I might have tried is using StateT and and some kind of HList to pass state so that items can be appended and removed easily.. I didn't knew about this features which makes me aware again about how important it is to not stop learning new features.. I'll have a look at it now Marc From simonpj at microsoft.com Mon Jun 30 03:29:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 30 03:20:30 2008 Subject: Implicit Function Arguments In-Reply-To: <5EEE7E77-B986-43F2-B573-835529BCB7CC@ece.cmu.edu> References: <200806281232.30989.twhitehead@gmail.com> <5EEE7E77-B986-43F2-B573-835529BCB7CC@ece.cmu.edu> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE72D1B5C@EA-EXMSG-C334.europe.corp.microsoft.com> | > This is the second time I have seen someone comment on implicit | > parameters being planned for removal, so now you have my attention :). | > I'd like to mention that a rather large project where I work (Galois, | > Inc.) uses implicit parameters a lot, so removing support for them | > would make me rather unhappy. | | | Hm, looks like terminology confusion. Implicit parameters are | staying. *Linear* implicit parameters were deprecated in 6.6 and seem | to be gone now. Brandon's right. Linear implicit parameters are gone. Opinions differ about (ordinary) implicit parameters, but they are sometimes jolly useful, and don't seem to impose non-local complications on the type system. We have no plans to remove them from GHC. Simon From leledumbo_cool at yahoo.co.id Mon Jun 30 03:35:14 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Jun 30 03:26:27 2008 Subject: Error building GHC 6.8.3 with MinGW 4.2.1-2 dw2 Message-ID: <18190163.post@talk.nabble.com> I try to build a lite version (e.g. no extra libs) of GHC 6.8.3, I'm using MinGW GCC 4.2.1-2 with dwarf-2 exception and pre-compiled GHC 6.8.3. Here's my configure: sh configure --prefix=/c/ghc-new CFLAGS='-s -O2' LDFLAGS='-s -O2' --with-gmp-includes=/usr/local/gmp/include --with-gmp-libraries=/usr/local/gmp/lib And my make: make bootstrap3 But in the middle, I got this: Preprocessing library hpc-0.5.0.1... In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:28:17: error: gmp.h: No such file or directory In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:121: error: expected specifier-qua lifier-list before 'MP_INT' In file included from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:203: error: expected ')' before '*' token D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:204: error: expected ')' before '*' token compiling dist\build\Trace\Hpc\Reflect_hsc_make.c failed command was: gcc -c -mno-cygwin -D__GLASGOW_HASKELL__=608 -ID:/Sources/ghc/ghc-6 .8.3-lite/includes -ID:/Sources/ghc/ghc-6.8.3-lite/gmp/gmpbuild -I/usr/local/gmp /include -D__GLASGOW_HASKELL__=608 dist\build\Trace\Hpc\Reflect_hsc_make.c -o di st\build\Trace\Hpc\Reflect_hsc_make.o make[2]: Entering directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries/hpc' make[2]: *** No targets specified and no makefile found. Stop. make[2]: Leaving directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries/hpc' make[1]: *** [make.library.hpc] Error 2 make[1]: Leaving directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries' make: *** [stage1] Error 2 As you can see above, I have gmp installed under /usr/local/gmp. However, this is not the gmp that comes with GHC (version 4.2.1, mine is 4.2.2). PS: I must comment these two lines in IOManager.h: 12: extern void* GetCurrentFiber ( void ); 13: extern void* GetFiberData ( void ); or an error about "static declaration follows non-static declaration" will come up. -- View this message in context: http://www.nabble.com/Error-building-GHC-6.8.3-with-MinGW-4.2.1-2-dw2-tp18190163p18190163.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From benjamin.franksen at bessy.de Mon Jun 30 08:25:22 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Jun 30 08:21:15 2008 Subject: Takusen build error Message-ID: I get a strange error building Takusen (more precisely: the module Foreign/C/UTF8.hs) with ghc-6.8.3. It says aragon: .../ghc-6.8.3/Takusen-0.8.1 > ./Setup build -v Reading parameters from /srv/projects/ctl/franksen/haskell/ghc-6.8.3/Takusen-0.8.1/takusen.buildinfo Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library Takusen-0.8.1... Building Takusen-0.8.1... Building library... Creating dist/build (and its parents) Creating dist/build (and its parents) /projects/ctl/franksen/usr/bin/ghc -package-name Takusen-0.8.1 --make -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -I/opt/oracle/product/client/rdbms/demo -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package mtl-1.1.0.1 -package time-1.1.2.1 -package old-time-1.0.0.0 -O -XCPP Database.Enumerator Database.Util Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Database.InternalEnumerator [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, dist/build/Foreign/C/UTF8.o ) /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: /tmp/ghc18936_0/ghc18936_0.s:1257:0: Error: symbol `base_GHCziBase_Z0T_closure' is already defined I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. Any ideas? Cheers Ben