From simonpj at microsoft.com Mon Nov 2 04:32:24 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 2 04:08:49 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <72019503-77F1-4460-9CBA-2F9189D6BD9A@mac.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> <72019503-77F1-4460-9CBA-2F9189D6BD9A@mac.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061BDA33@DB3EX14MBXC310.europe.corp.microsoft.com> | Is there any difference between "-XImpredicativePolymorphism" and "- | XImpredicativeTypes"? No there isn't. There's only one flag, -XImpredicativeTypes. | Hyena uses the latter, and we're using Hyena somewhat "in anger". Interesting. I hope you can get along without it, perhaps with a bit more newtype wrapping/unwrapping code. As I say, the current situation is not good. Simon From marlowsd at gmail.com Mon Nov 2 06:36:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 2 06:12:47 2009 Subject: call for organizing next AFP summerschool (2010) Message-ID: <4AEEC431.6020706@gmail.com> [ posting on behalf of Rinus Plasmeijer ] ** *Call for organizers: The Advanced Functional Programming School, 2010.* http://www.cs.uu.nl/~johanj/afp/ We solicit plans for organizing the next Advanced Functional Programming School. Since 1995 there have been six Schools on Advanced Functional Programming: * 2008, LNCS 5832, Nijmegen, The Netherlands * 2004, LNCS 3622, Tartu, Estonia * 2002, LNCS 2638, Oxford, UK * 1998, LNCS 1608, Braga, Portugal * 1996, LNCS 1129, Olympia, WA, USA * 1995, LNCS 925, Baastad, Sweden ------------------------------------------------------------------------ *The goals of this series of schools are* * Bring computer scientists, in particular young researchers and programmers, up to date with the latest AFP techniques. * Use AFP techniques in "programming in the real world". * Bridge the gap between results presented at programming conferences and material from introductory textbooks on functional programming. *The approach we take to achieve these goals in the schools is* * In depth lectures about AFP techniques, taught by experts in the field. * Lectures are accompanied by practical problems to be solved by the students at the school. The problems guide the students' learning to a great extent. This implies that there has to be a lab at the school site. * Group work is stimulated, especially because the practical problems will typically be too large for a single person. By functional programming we mean programming in a style that emphasizes the evaluation of expressions rather than the execution of commands. ------------------------------------------------------------------------ The lecture notes of the Advanced Functional Programming schools are published after the school. The organizers are responsible for publishing the lecture notes. Please submit a proposal for organizing the next advanced functional programming school. *Your proposal should include* * the name of the organizers (preferably more than one) * a programme: lecturers (a mix of young and bright, and old and wise lecturers is preferred) and topics (keep in mind that lectures have to be about "programming in the real world". Applications of functional programming are very important for the school) * the approximate dates (preferably somewhere in 2010) * a location * a budget, including an estimation of the registration and hotel costs per participant. The programme, dates, location and budget don't have to be completely fixed when you submit your proposal, but there should be sufficient information to review your proposal. Your proposal will be reviewed by the steering committee of the Advanced Functional Programming Schools, consisting of ? Peter Achten (AFP6) * Pedro Henriques (AFP3) * Johan Jeuring (AFP4, AFP5) * Simon Peyton Jones (AFP4) * Pieter Koopman (AFP6) * Erik Meijer (AFP2) * Rinus Plasmeijer (Chairman, AFP6) * Tim Sheard (AFP2) * Doaitse Swierstra (AFP3, AFP6) * Tarmo Uustalu (AFP5) * Varmo Vene (AFP5) Submit your proposal to rinus@cs.ru.nl before December 15, 2009. Notification January 9, 2010. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091102/778e7217/attachment-0001.html From marlowsd at gmail.com Mon Nov 2 07:03:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 2 06:39:38 2009 Subject: GHC.IO was: Re: 6.12.1 release In-Reply-To: <4AE04A92.4020102@dfki.de> References: <4AE022AE.6090700@gmail.com> <4AE02F70.3080907@dfki.de> <4AE034ED.50301@gmail.com> <4AE04A92.4020102@dfki.de> Message-ID: <4AEECA85.9020804@gmail.com> On 22/10/2009 13:05, Christian Maeder wrote: > Simon Marlow schrieb: >> On 22/10/2009 11:09, Christian Maeder wrote: >>> Simon Marlow schrieb: >>>> Simon and I favour the RC2 option. What do others think? >>> >>> +1 >>> >>> I've quite some trouble to port our old code to ghc-6.12 >>> and did not test RC1 much. >>> >>> http://trac.informatik.uni-bremen.de:8080/hets/ticket/749 >>> http://www.informatik.uni-bremen.de/htk/ >> >> If you just need hPutBuf and hGetBuf, then get them from System.IO. > > Thanks for this hint. I got further (also after replacing some non-ascii > characters in comments, i.e. a broken bar "-- ? ..."). The next spot is: > > Posixutil/CopyFile.hs:124:19: Not in scope: `slurpFile' > > copyFileToCStringLen :: FilePath -> IO CStringLen > copyFileToCStringLen file = > do > (ptr,len)<- slurpFile file > return (castPtr ptr,len) slurpFile was an internal operation in the IO library that went away. You should probably use ByteString's readFile instead. Cheers, Simon From gkmo at cin.ufpe.br Mon Nov 2 09:02:02 2009 From: gkmo at cin.ufpe.br (Guilherme Oliveira) Date: Mon Nov 2 08:38:38 2009 Subject: Assembler errors when compiling nofib benchmarks with -optc-g In-Reply-To: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> References: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> Message-ID: <43a2d37b0911020602j2e8c856bjf5ab1c3f191c8510@mail.gmail.com> Hi guys, I am new on this nofib library, could you tell me where can I download it? Thanks, Guilherme Kely de Melo Oliveira 2009/10/31 Henry DeYoung > Hi, > > I am working with another grad student on a course project on cache > behavior of GHC programs. The first part of this project is to reproduce > some of the measurements from Nethercote and Mycroft's "The Cache Behavior > of Large Lazy Functional Programs on Stock Hardware". > > We've decided to use oprofile to sample cache misses recorded by the > performance counters. To get reasonable information out of oprofile, I'd > like to compile the nofib benchmarks via C with export of debugging > symbols. > > As a first step toward this, I've changed the NoFibHcOpts variable in > nofib/mk/boilerplate.mk to be: > > NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g > > However, when I do make in the nofib/real/compress directory, for example, > I get the following error message: > > ==nofib== compress: time to compile BinConv follows... > /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc > gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon > v.hs -o BinConv.o > < samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.14 > MUT (1.25 elapsed), 0.10 GC (0.12 elapsed) :ghc>> > 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+21251minor)pagefaults 0swaps > ==nofib== compress: size of BinConv.o follows... > text data bss dec hex filename > 6677 192 8 6877 1add BinConv.o > ==nofib== compress: time to compile BinTest follows... > /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc > gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes > t.hs -o BinTest.o > /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: > > /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:54:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:56:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:57:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:61:0: > Error: junk at end of line, first unrecognized character is `0' > > etc... > > Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc > gcc, everything works fine. > > Do you have any ideas what might be causing these errors? Is there a fix > or workaround to get the C compiler to export debugging symbols? > > > Second, it appears that a make with -fvia-C -pgmc gcc removes the C source > after it has been compiled. Is there a way to preserve this source so > that it can be annotated line by line using oprofile? > > > I apologize if these questions are rudimentary; this is my first > experience with GHC and nofib. Also, if these questions should be > directed toward a different mailing list, please let me know. > > Thanks for any help you can give with this! > > Henry > > > > _______________________________________________ > 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/20091102/99543451/attachment.html From marlowsd at gmail.com Mon Nov 2 09:05:01 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 2 08:41:21 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 In-Reply-To: References: Message-ID: <4AEEE70D.7040800@gmail.com> On 31/10/2009 14:14, Ganesh Sittampalam wrote: > [ 6 of 10] Compiling Data.Array.IO ( Data/Array/IO.hs, > dist/build/Data/Array/IO.o ) > > Data/Array/IO.hs:73:13: > `haFD' is not a (visible) field of constructor `Handle__' You need array 0.3.0.0 which comes with GHC 6.12rc1, but is (probably) not on Hackage yet. darcs get http://darcs.haskell.org/packages/array (when darcs.haskell.org is back up). Cheers, Simon From marlowsd at gmail.com Mon Nov 2 09:09:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 2 08:45:50 2009 Subject: Assembler errors when compiling nofib benchmarks with -optc-g In-Reply-To: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> References: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> Message-ID: <4AEEE81A.9020709@gmail.com> On 31/10/2009 18:27, Henry DeYoung wrote: > Hi, > > I am working with another grad student on a course project on cache > behavior of GHC programs. The first part of this project is to reproduce > some of the measurements from Nethercote and Mycroft's "The Cache Behavior > of Large Lazy Functional Programs on Stock Hardware". > > We've decided to use oprofile to sample cache misses recorded by the > performance counters. To get reasonable information out of oprofile, I'd > like to compile the nofib benchmarks via C with export of debugging > symbols. > > As a first step toward this, I've changed the NoFibHcOpts variable in > nofib/mk/boilerplate.mk to be: > > NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g That won't work, I'm afraid. The Evil Mangler script that post-processes the .s file output by gcc does not understand the debug annotations added by gcc's -g flag. The best you can do with oprofile is get assembly-level profiling. It's not too bad actually; I've used it in the past myself, although oprofile itself I found to be a bit flaky - for some reason it seems to stop counting randomly on my laptop. You might have better luck using the new performance counter support ("performance events") in Linux 2.6.31. I've not been able to test it yet myself because apparently it doesn't support the CPU in my laptop, but I plan to find another machine to try it on soon. Cheers, Simon From ross at soi.city.ac.uk Mon Nov 2 11:56:58 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 2 11:33:16 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 In-Reply-To: <4AEEE70D.7040800@gmail.com> References: <4AEEE70D.7040800@gmail.com> Message-ID: <20091102165658.GA23272@soi.city.ac.uk> On Mon, Nov 02, 2009 at 02:05:01PM +0000, Simon Marlow wrote: > You need array 0.3.0.0 which comes with GHC 6.12rc1, but is > (probably) not on Hackage yet. No it isn't: array-0.3.0.0 will be defined by what's released in GHC 6.12. From ganesh.sittampalam at credit-suisse.com Mon Nov 2 12:06:21 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Nov 2 11:42:41 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 In-Reply-To: <20091102165658.GA23272@soi.city.ac.uk> References: <4AEEE70D.7040800@gmail.com> <20091102165658.GA23272@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC30@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > On Mon, Nov 02, 2009 at 02:05:01PM +0000, Simon Marlow wrote: >> You need array 0.3.0.0 which comes with GHC 6.12rc1, but is >> (probably) not on Hackage yet. > > No it isn't: array-0.3.0.0 will be defined by what's released in GHC > 6.12. That creates a timing problem, given that people will want to test the GHC 6.12 RC against packages that will depend on array and other core libraries like it. Obviously they could install the development versions manually, but this seems rather inconvenient. I guess the problem with uploading it before the release is that people who don't want the bleeding edge will also pick up the upload by default. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From igloo at earth.li Mon Nov 2 12:25:02 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Nov 2 12:01:18 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC30@ELON17P32001A.csfb.cs-group.com> References: <20091102165658.GA23272@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B03B9FC30@ELON17P32001A.csfb.cs-group.com> Message-ID: <20091102172502.GA24533@matrix.chaos.earth.li> On Mon, Nov 02, 2009 at 05:06:21PM -0000, Sittampalam, Ganesh wrote: > Ross Paterson wrote: > > On Mon, Nov 02, 2009 at 02:05:01PM +0000, Simon Marlow wrote: > >> You need array 0.3.0.0 which comes with GHC 6.12rc1, but is > >> (probably) not on Hackage yet. > > > > No it isn't: array-0.3.0.0 will be defined by what's released in GHC > > 6.12. > > That creates a timing problem, given that people will want to test the > GHC 6.12 RC against packages that will depend on array and other core > libraries like it. You already have the array 0.3.0.0 package if you installed the RC. The problem is that the darcs.cabal file says: build-depends: [...] array >= 0.1 && < 0.3, [...] so it's not using it. Thanks Ian From ganesh.sittampalam at credit-suisse.com Mon Nov 2 13:11:24 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Nov 2 12:47:45 2009 Subject: array-0.2.0.0 doesn't build with 6.12rc1 In-Reply-To: <20091102172502.GA24533@matrix.chaos.earth.li> References: <20091102165658.GA23272@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B03B9FC30@ELON17P32001A.csfb.cs-group.com> <20091102172502.GA24533@matrix.chaos.earth.li> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC33@ELON17P32001A.csfb.cs-group.com> Ian Lynagh wrote: > You already have the array 0.3.0.0 package if you installed the RC. > The problem is that the darcs.cabal file says: build-depends: > [...] array >= 0.1 && < 0.3, > [...] > so it's not using it. Oh, I see. Sorry for the noise - I got confused about what has been removed from the GHC distro and what hasn't. (Looks like there's at least one dependency with the same problem, so it could all get rather fiddly. Natural consequence of the safety-first approach of the PVP, I guess.) Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From ganesh at earth.li Mon Nov 2 16:10:38 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Nov 2 15:46:50 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC1F@ELON17P32001A.csfb.cs-group.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com><1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9FC1F@ELON17P32001A.csfb.cs-group.com> Message-ID: On Fri, 30 Oct 2009, Sittampalam, Ganesh wrote: > Simon Peyton-Jones wrote: > >> Fortunately, I don't think a lot of people use the feature in anger. >> Please yell if you *are* using impredicative polymorphism for >> something serious. But if you are, we need to think of a workaround. >> The current situation seems unsustainable. > > I think darcs is using it. At least, I had to enable > ImpredicativePolymorphism to successfully build darcs with GHC 6.11 (a > snapshot from about February), although the flag is not required with > GHC 6.10. I haven't had a chance to try with the RC yet, but will do > this weekend. > > I'll have to check the full details of why it's needed, but from memory > I think it can be worked around at the cost of more verbosity by using > some newtypes in appropriate places. OK, I confirm the changes are fairly trivial. The main issue is that a couple of functions want to instantiate the argument to IO with a type scheme: restrictBoring :: IO (forall t m. FilterTree t m => t m -> t m) The newtype workaround works fine here and doesn't affect too much of the code. In one other place some code had type [(String, Foo)] where Foo is a type synonym for (forall x y . ), but it turned out the nested quantification wasn't required so (forall x y . [(String, )]) was ok in this case, if a little uglier. (Patch sent to darcs-users) Cheers, Ganesh From ben_moseley at mac.com Mon Nov 2 16:17:25 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Mon Nov 2 15:53:40 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BDA33@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> <72019503-77F1-4460-9CBA-2F9189D6BD9A@mac.com> <59543203684B2244980D7E4057D5FBC1061BDA33@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: I expect we can - we'll investigate. --Ben On 2 Nov 2009, at 09:32, Simon Peyton-Jones wrote: > | Is there any difference between "-XImpredicativePolymorphism" and "- > | XImpredicativeTypes"? > > No there isn't. There's only one flag, -XImpredicativeTypes. > > | Hyena uses the latter, and we're using Hyena somewhat "in anger". > > Interesting. I hope you can get along without it, perhaps with a > bit more newtype wrapping/unwrapping code. As I say, the current > situation is not good. > > > Simon From hdeyoung at cs.cmu.edu Mon Nov 2 16:49:56 2009 From: hdeyoung at cs.cmu.edu (Henry DeYoung) Date: Mon Nov 2 16:26:10 2009 Subject: Assembler errors when compiling nofib benchmarks with -optc-g In-Reply-To: <4AEEE81A.9020709@gmail.com> References: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> <4AEEE81A.9020709@gmail.com> Message-ID: <4363.71.60.115.140.1257198596.squirrel@webmail.cs.cmu.edu> On Mon, November 2, 2009 9:09 am, Simon Marlow wrote: > On 31/10/2009 18:27, Henry DeYoung wrote: > >> We've decided to use oprofile to sample cache misses recorded by the >> performance counters. To get reasonable information out of oprofile, >> I'd >> like to compile the nofib benchmarks via C with export of debugging >> symbols. >> >> As a first step toward this, I've changed the NoFibHcOpts variable in >> nofib/mk/boilerplate.mk to be: >> >> NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g >> > > That won't work, I'm afraid. The Evil Mangler script that > post-processes the .s file output by gcc does not understand the debug > annotations added by gcc's -g flag. > > The best you can do with oprofile is get assembly-level profiling. It's > not too bad actually; I've used it in the past myself, although oprofile > itself I found to be a bit flaky - for some reason it seems to stop > counting randomly on my laptop. > > You might have better luck using the new performance counter support > ("performance events") in Linux 2.6.31. I've not been able to test it > yet myself because apparently it doesn't support the CPU in my laptop, but > I plan to find another machine to try it on soon. So now I'm using NoFibHcOpts = -O -keep-s-files -opta-g which seems to work fine. You mentioned that assembly-level profiling is the best you can do with oprofile (in particular). Is there another profiler that would allow source-level (in Haskell or the generated C code) profiling, or is this as good as it gets for any profiler since GHC doesn't seem to export debugging symbols at the source level? Also, based on what you've heard, would you recommend the Linux 2.6.31 performance counter tools over the PAPI library? (I see that there is PAPI support in the GHC runtime: http://hackage.haskell.org/trac/ghc/wiki/PAPI) Thanks so much for all your help! Henry From marlowsd at gmail.com Tue Nov 3 05:26:04 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 3 05:02:23 2009 Subject: Assembler errors when compiling nofib benchmarks with -optc-g In-Reply-To: <4363.71.60.115.140.1257198596.squirrel@webmail.cs.cmu.edu> References: <1966.71.60.115.140.1257013625.squirrel@webmail.cs.cmu.edu> <4AEEE81A.9020709@gmail.com> <4363.71.60.115.140.1257198596.squirrel@webmail.cs.cmu.edu> Message-ID: <4AF0053C.6000909@gmail.com> On 02/11/2009 21:49, Henry DeYoung wrote: > On Mon, November 2, 2009 9:09 am, Simon Marlow wrote: >> On 31/10/2009 18:27, Henry DeYoung wrote: >> >>> We've decided to use oprofile to sample cache misses recorded by the >>> performance counters. To get reasonable information out of oprofile, >>> I'd >>> like to compile the nofib benchmarks via C with export of debugging >>> symbols. >>> >>> As a first step toward this, I've changed the NoFibHcOpts variable in >>> nofib/mk/boilerplate.mk to be: >>> >>> NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g >>> >> >> That won't work, I'm afraid. The Evil Mangler script that >> post-processes the .s file output by gcc does not understand the debug >> annotations added by gcc's -g flag. >> >> The best you can do with oprofile is get assembly-level profiling. It's >> not too bad actually; I've used it in the past myself, although oprofile >> itself I found to be a bit flaky - for some reason it seems to stop >> counting randomly on my laptop. >> >> You might have better luck using the new performance counter support >> ("performance events") in Linux 2.6.31. I've not been able to test it >> yet myself because apparently it doesn't support the CPU in my laptop, but >> I plan to find another machine to try it on soon. > > So now I'm using > > NoFibHcOpts = -O -keep-s-files -opta-g > > which seems to work fine. You mentioned that assembly-level profiling is > the best you can do with oprofile (in particular). Is there another > profiler that would allow source-level (in Haskell or the generated C > code) profiling, or is this as good as it gets for any profiler since GHC > doesn't seem to export debugging symbols at the source level? This is as good as it gets, yes. > Also, based on what you've heard, would you recommend the Linux 2.6.31 > performance counter tools over the PAPI library? (I see that there is > PAPI support in the GHC runtime: > http://hackage.haskell.org/trac/ghc/wiki/PAPI) The main difficulty with PAPI is that it is so hard to get it working. You need a patched kernel, and then building and installing PAPI itself is not at all easy. If I was going to install it on a new machine, I'd set aside a day to do it. The new Linux performance events infrastructure will be in the default kernel that comes with most distributions - Ubuntu Karmic includes it for example. That makes it a lot more attractive for me. Also it has support for annotating source (or assembly) with profiling results, like oprofile. I don't think PAPI has that, but I could be wrong. On the other hand, PAPI has an API for saving/restoring sets of counters, which is what we use in GHC's RTS for separating the GC counters from the mutator. I hope I'll be able to do that with perf events, but I don't know yet. > Thanks so much for all your help! Cheers, Simon From roland.zumkeller at gmail.com Tue Nov 3 13:28:55 2009 From: roland.zumkeller at gmail.com (Roland Zumkeller) Date: Tue Nov 3 13:05:26 2009 Subject: inferred type doesn't type-check (using type families) Message-ID: Hi, Compiling > class WithT a where > type T a > f :: T a -> a -> T a > f = undefined > g x = f x 42 with -XTypeFamilies -fwarn-missing-signatures gives: Inferred type: g :: forall a. (Num a) => T a -> T a Adding > g :: Num a => T a -> T a results in: Couldn't match expected type `T a' against inferred type `T a1' In the first argument of `f', namely `x' Is the inferred type not the right one? Is g typeable? Best, Roland -- http://alacave.net/~roland/ From daniel.is.fischer at web.de Tue Nov 3 14:20:00 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Nov 3 13:57:37 2009 Subject: inferred type doesn't type-check (using type families) In-Reply-To: References: Message-ID: <200911032020.00864.daniel.is.fischer@web.de> Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller: > Hi, > > Compiling > > > class WithT a where > > type T a > > > > f :: T a -> a -> T a > > f = undefined > > > > g x = f x 42 > > with -XTypeFamilies -fwarn-missing-signatures gives: > > Inferred type: g :: forall a. (Num a) => T a -> T a > > Adding > > > g :: Num a => T a -> T a > > results in: > > Couldn't match expected type `T a' against inferred type `T a1' > In the first argument of `f', namely `x' > > Is the inferred type not the right one? Is g typeable? The type function T isn't injective (or, it isn't guaranteed to be), so there's no way to determine which type a to use for 42. > > Best, > > Roland From batterseapower at hotmail.com Tue Nov 3 15:20:15 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Nov 3 14:56:25 2009 Subject: inferred type doesn't type-check (using type families) In-Reply-To: <200911032020.00864.daniel.is.fischer@web.de> References: <200911032020.00864.daniel.is.fischer@web.de> Message-ID: <9d4d38820911031220o170bd7f3n9e873ff0258dd915@mail.gmail.com> 2009/11/3 Daniel Fischer : > Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller: >> Hi, >> >> Compiling >> >> > class WithT a where >> > ? type T a >> > >> > f :: T a -> a -> T a >> > f = undefined >> > >> > g x = f x 42 >> >> with -XTypeFamilies -fwarn-missing-signatures gives: >> >> ? ? ? ? ? ? ?Inferred type: g :: forall a. (Num a) => T a -> T a >> >> Adding >> >> > g :: Num a => T a -> T a >> >> results in: >> >> ? ? Couldn't match expected type `T a' against inferred type `T a1' >> ? ? In the first argument of `f', namely `x' >> >> Is the inferred type not the right one? Is g typeable? > > The type function T isn't injective (or, it isn't guaranteed to be), so there's no way to > determine which type a to use for 42. I think (untested) that in this particular case you can get around the problem using scoped type variables: > g :: forall a. Num a => T a -> T a > g x = f x (42 :: a) In fact, this seems to be the general pattern for fixing problems like this with type families: add extra "witness" arguments which GHC can use to unify type variables that are "hidden" inside type family applications. Cheers, Max From dave at zednenem.com Tue Nov 3 20:38:41 2009 From: dave at zednenem.com (David Menendez) Date: Tue Nov 3 20:14:51 2009 Subject: inferred type doesn't type-check (using type families) In-Reply-To: <9d4d38820911031220o170bd7f3n9e873ff0258dd915@mail.gmail.com> References: <200911032020.00864.daniel.is.fischer@web.de> <9d4d38820911031220o170bd7f3n9e873ff0258dd915@mail.gmail.com> Message-ID: <49a77b7a0911031738q1af563c7l2c207ed5bb44939b@mail.gmail.com> On Tue, Nov 3, 2009 at 3:20 PM, Max Bolingbroke wrote: > 2009/11/3 Daniel Fischer : >> Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller: >>> Hi, >>> >>> Compiling >>> >>> > class WithT a where >>> > ? type T a >>> > >>> > f :: T a -> a -> T a >>> > f = undefined >>> > >>> > g x = f x 42 >>> >>> with -XTypeFamilies -fwarn-missing-signatures gives: >>> >>> ? ? ? ? ? ? ?Inferred type: g :: forall a. (Num a) => T a -> T a >>> >>> Adding >>> >>> > g :: Num a => T a -> T a >>> >>> results in: >>> >>> ? ? Couldn't match expected type `T a' against inferred type `T a1' >>> ? ? In the first argument of `f', namely `x' >>> >>> Is the inferred type not the right one? Is g typeable? >> >> The type function T isn't injective (or, it isn't guaranteed to be), so there's no way to >> determine which type a to use for 42. > > I think (untested) that in this particular case you can get around the > problem using scoped type variables: > >> g :: forall a. Num a => T a -> T a >> g x = f x (42 :: a) GHC accepts this, but arguably shouldn't as there's no way to call g. Neither the argument to g nor the context of g has enough information to specify a, so there's no way to know what's intended. > In fact, this seems to be the general pattern for fixing problems like > this with type families: add extra "witness" arguments which GHC can > use to unify type variables that are "hidden" inside type family > applications. This is true. You can use a dummy argument to force the choice of a, and if the dummy isn't used it gets removed in optimization. data Proxy a -- no values, so should always be removable during optimization g :: forall a. Num a => Proxy a -> T a -> T a g _ x = f x (42 :: a) -- works fine -- Dave Menendez From kazu at iij.ad.jp Wed Nov 4 02:07:34 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed Nov 4 01:43:47 2009 Subject: How to know data size in UDP? In-Reply-To: <20091029.173103.148260080.kazu@iij.ad.jp> References: <20091029.173103.148260080.kazu@iij.ad.jp> Message-ID: <20091104.160734.51399337.kazu@iij.ad.jp> Hello, > If my understating is correct, I cannot use recvFrom since it calls > recvfrom() with FFI. So, I use socketToHandle to translate a socket to > a handle. Sorry. This is my misunderstanding. recvFrom does not stop other threads at least on UNIX. So, my problem is solved. --Kazu From simonpj at microsoft.com Wed Nov 4 03:29:26 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 4 03:05:37 2009 Subject: inferred type doesn't type-check (using type families) In-Reply-To: <9d4d38820911031220o170bd7f3n9e873ff0258dd915@mail.gmail.com> References: <200911032020.00864.daniel.is.fischer@web.de> <9d4d38820911031220o170bd7f3n9e873ff0258dd915@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1061BEF79@DB3EX14MBXC310.europe.corp.microsoft.com> | I think (untested) that in this particular case you can get around the | problem using scoped type variables: | | > g :: forall a. Num a => T a -> T a | > g x = f x (42 :: a) | | In fact, this seems to be the general pattern for fixing problems like | this with type families: add extra "witness" arguments which GHC can | use to unify type variables that are "hidden" inside type family | applications. But in this case all you've done is to make g have an ambiguous type. I've drafted a FAQ about this at http://haskell.org/haskellwiki/GHC/Type_families#Frequently_asked_questions Please, everyone, edit and extend. Simon From colinpauladams at googlemail.com Wed Nov 4 10:08:27 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Wed Nov 4 09:44:34 2009 Subject: Porting to DragonFly BSD Message-ID: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date? -- Colin Adams Preston, Lancashire, ENGLAND From trebla at vex.net Wed Nov 4 21:15:05 2009 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed Nov 4 20:51:15 2009 Subject: Update on GHC 6.12.1 In-Reply-To: <1234953703-1256839514-cardhu_decombobulator_blackberry.rim.net-1877815428-@bda437.bisx.prod.on.blackberry> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com><1f3dc80d0910291024x412a6111of6f51b5f835e4b3d@mail.gmail.com> <1234953703-1256839514-cardhu_decombobulator_blackberry.rim.net-1877815428-@bda437.bisx.prod.on.blackberry> Message-ID: <4AF23529.6030208@vex.net> scooter.phd@gmail.com wrote: > Is there a good motivating example for recursive do? So far, I haven't grokked the various use cases, which are pretty terse. Maybe the syntax sugar gets in the way (dangling lets are a good case in point). There are some examples in http://www.haskell.org/haskellwiki/MonadFix In these examples I write both mdo versions and mfix versions. There are also some examples in the papers listed in http://www.haskell.org/haskellwiki/Research_papers/Monads_and_arrows#Recursion From niklas.broberg at gmail.com Thu Nov 5 19:13:01 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Nov 5 18:49:05 2009 Subject: Three patches for cabal In-Reply-To: <1245230688.13502.2939.camel@localhost> References: <1245230688.13502.2939.camel@localhost> Message-ID: >> Second there's the constructor NoMonoPatBinds, which actually >> describes the default Haskell 98 behavior, even if GHC has a different >> default. It's GHC's behavior that is the extension, so the constructor >> in cabal should really be named MonoPatBinds. >> >> Also, the PatternSignatures constructor has been deprecated in GHC and >> superceded by ScopedTypeVariables. > > Can someone please comment on these two proposed changes. I agree with > Niklas but I'm a bit reluctant to apply the patches without at least > some sign of agreement from someone else. > > Deprecating PatternSignatures seems uncontroversial, but the > NoMonoPatBinds is potentially controversial. GHC essentially uses > -XMonoPatBinds by default, even in H98 mode, and the user can use > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > the list of language extensions in Language.Haskell.Exceptions are > differences from H98 so it should be MonoPatBinds to get the difference > not NoMonoPatBinds to restore H98. > > In practise, since ghc uses MonoPatBinds by default it'd mean that > people who want to get back to H98 would need to use: > > ?ghc-options: -XNoMonoPatBinds > > Because the extensions field is additive, not subtractive. Using the > name MonoPatBinds allows other compilers to implement it without it > having to be the default. I had a look at the source for cabal HEAD and was surprised to see that this stuff had fallen by the wayside. What's holding it up? I can't imagine that anyone would be against the deprecation of PatternSignatures at least. Cheers, /Niklas From bos at serpentine.com Fri Nov 6 00:39:10 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Nov 6 00:15:13 2009 Subject: Reliably preventing let-floating and thunk overwriting? Message-ID: The criterion benchmarking package is pretty nice to use in general, but it has a property that sticks in my craw: ensuring that pure code actually gets evaluated on every iteration through the benchmarking loop is awkward and fragile. My current scheme is to increment an Int on every iteration and pass that to the function being benchmarked. I document the need for the function to somehow use this Int, lest it be let-floated out to the top level, where it will be evaluated just once and our measurements will become nonsensical. I wonder if anyone else has any clever ideas about approaches that might be less intrusive in the API. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091106/3d3f177c/attachment.html From marlowsd at gmail.com Fri Nov 6 03:56:00 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 6 03:32:08 2009 Subject: Porting to DragonFly BSD In-Reply-To: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> Message-ID: <4AF3E4A0.7000408@gmail.com> On 04/11/2009 15:08, Colin Adams wrote: > When GHC 6.12.1 is released, I'm going to have a go at porting it to > DragonFly BSD (32-bit incarnation). Is the porting page on the > wikiup-to-date? There are apparently some difficulties with porting right now: http://hackage.haskell.org/trac/ghc/ticket/3472 Depending on how similar the host/target archtectures are, it might be possible to follow the instructions to get a working port. We need to have another run at doing a port and iron out the bugs in the procedure. Cheers, Simon From marlowsd at gmail.com Fri Nov 6 04:03:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 6 03:39:12 2009 Subject: Reliably preventing let-floating and thunk overwriting? In-Reply-To: References: Message-ID: <4AF3E64A.2000503@gmail.com> On 06/11/2009 05:39, Bryan O'Sullivan wrote: > The criterion benchmarking package is pretty nice to use in general, but > it has a property that sticks in my craw: ensuring that pure code > actually gets evaluated on every iteration through the benchmarking loop > is awkward and fragile. > > My current scheme is to increment an Int on every iteration and pass > that to the function being benchmarked. I document the need for the > function to somehow use this Int, lest it be let-floated out to the top > level, where it will be evaluated just once and our measurements will > become nonsensical. > > I wonder if anyone else has any clever ideas about approaches that might > be less intrusive in the API. One reliable way to do this would be to dynamically load the code to be tested using the GHC API, and call this between each evaluation: foreign import ccall "revertCAFs" revertCAFs :: IO () (note revertCAFs only works on CAFs in dynamically-loaded object code, not interpreted or statically linked CAFs). Cheers, Simon From luca_ciciriello at hotmail.com Fri Nov 6 09:50:40 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Fri Nov 6 09:26:43 2009 Subject: NDP Message-ID: Hi All. Has someone heard something about "Nested Data Parallelism" in Haskell? Does exists some paper that I can read about this technology? Thanks in advance. Luca. _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/uk/windows/buy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091106/5d806660/attachment.html From dons at galois.com Fri Nov 6 12:40:11 2009 From: dons at galois.com (Don Stewart) Date: Fri Nov 6 12:16:17 2009 Subject: NDP In-Reply-To: References: Message-ID: <20091106174011.GB28579@whirlpool.galois.com> luca_ciciriello: > Hi All. > Has someone heard something about "Nested Data Parallelism" in Haskell? Does > exists some paper that I can read about this technology? > > Thanks in advance. Google will find it for you: http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell From luca_ciciriello at hotmail.com Fri Nov 6 13:28:14 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Fri Nov 6 13:04:20 2009 Subject: NDP In-Reply-To: <20091106174011.GB28579@whirlpool.galois.com> References: <20091106174011.GB28579@whirlpool.galois.com> Message-ID: Thanks, I had already found it just after i sent the mail. Sorry. Luca. On Nov 6, 2009, at 6:40 PM, Don Stewart wrote: > luca_ciciriello: >> Hi All. >> Has someone heard something about "Nested Data Parallelism" in >> Haskell? Does >> exists some paper that I can read about this technology? >> >> Thanks in advance. > > Google will find it for you: > > http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell > From kili at outback.escape.de Fri Nov 6 14:14:58 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Nov 6 13:51:05 2009 Subject: Porting to DragonFly BSD In-Reply-To: <4AF3E4A0.7000408@gmail.com> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <4AF3E4A0.7000408@gmail.com> Message-ID: <20091106191458.GB19687@nutty.outback.escape.de> On Fri, Nov 06, 2009 at 08:56:00AM +0000, Simon Marlow wrote: > On 04/11/2009 15:08, Colin Adams wrote: > >When GHC 6.12.1 is released, I'm going to have a go at porting it to > >DragonFly BSD (32-bit incarnation). Is the porting page on the > >wikiup-to-date? > > There are apparently some difficulties with porting right now: > > http://hackage.haskell.org/trac/ghc/ticket/3472 Unfortunately I didn't have much time after the OpenBSD p2k9 in Budapesst (where I got a little bit further with the bootstrapping), but I remember that I got parts of stage 1 built but then something in utils/* didn't compile. I hope to have a look this weekend (and to find the patches I wrote in Budapest). There are probably just some more pattern rules missing for the .hc file bootstrapping. > Depending on how similar the host/target archtectures are, it might be > possible to follow the instructions to get a working port. Once the make rules are complete, the Linker may be tricky (it already contains #ifdef'd sections specific to FreeBSD and OpenBSD), but I don't expect other parts of GHC to need tweaking. > We need to have another run at doing a port and iron out the bugs in the > procedure. At least I tried to correct some of the hints on the porting wiki page, but it's obviously still incomplete. Ciao, Kili From bos at serpentine.com Fri Nov 6 17:14:10 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Nov 6 16:50:14 2009 Subject: Reliably preventing let-floating and thunk overwriting? In-Reply-To: <4AF3E64A.2000503@gmail.com> References: <4AF3E64A.2000503@gmail.com> Message-ID: On Fri, Nov 6, 2009 at 1:03 AM, Simon Marlow wrote: > One reliable way to do this would be to dynamically load the code to be > tested using the GHC API, and call this between each evaluation: > > foreign import ccall "revertCAFs" revertCAFs :: IO () > > (note revertCAFs only works on CAFs in dynamically-loaded object code, not > interpreted or statically linked CAFs). > Good to know, thanks. I ended up doing this, which is simpler and seems to work (at least for now): http://hpaste.org/fastcgi/hpaste.fcgi/view?id=11887 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091106/5fe13975/attachment.html From info at goetz-isenmann.de Fri Nov 6 18:25:22 2009 From: info at goetz-isenmann.de (Goetz Isenmann) Date: Fri Nov 6 18:01:27 2009 Subject: Porting to DragonFly BSD In-Reply-To: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> Message-ID: <20091106232522.GA35866@horse.gocht-isenmann.de> On Wed, Nov 04, 2009 at 03:08:27PM +0000, Colin Adams wrote: > When GHC 6.12.1 is released, I'm going to have a go at porting it to > DragonFly BSD (32-bit incarnation). Is the porting page on the > wikiup-to-date? Maybe you could start with something like: $ curl -o ghc-6.10.4-3.tar.bz2 \ ; http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal update $ ./cabal install --user cabal-install I have just recompiled this ghc with itself using the attached patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit). The patches are only a stupid "do the same for dragonfly as for freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and (b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably the wrong way to fix a (can't remember the details) build problem. Until now I had no time and energie to dig deeper into the problem [1], that looks to me, like rts/Linker cannot load any object file that references errno. My guess is, that for dragonflys "extern __thread int errno;" we do not only need to add a new case in rts/Linker.c but also need to generate different code for this thread local storage access. Goetz [1] $ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. ghc: /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: unhandled ELF relocation(Rel) type 15 Loading package base ... linking ... ghc: unable to load package `base' -------------- next part -------------- diff -ru ghc-6.10.4-orig/compiler/nativeGen/NCG.h ghc-6.10.4/compiler/nativeGen/NCG.h --- ghc-6.10.4-orig/compiler/nativeGen/NCG.h 2009-07-14 19:10:51 +0200 +++ ghc-6.10.4/compiler/nativeGen/NCG.h 2009-11-06 21:10:07 +0100 @@ -38,6 +38,12 @@ # define IF_OS_freebsd(x,y) y #endif -- - - - - - - - - - - - - - - - - - - - - - +#if dragonfly_TARGET_OS +# define IF_OS_dragonfly(x,y) x +#else +# define IF_OS_dragonfly(x,y) y +#endif +-- - - - - - - - - - - - - - - - - - - - - - #if netbsd_TARGET_OS # define IF_OS_netbsd(x,y) x #else diff -ru ghc-6.10.4-orig/configure ghc-6.10.4/configure --- ghc-6.10.4-orig/configure 2009-07-14 19:24:26 +0200 +++ ghc-6.10.4/configure 2009-11-06 21:10:07 +0100 @@ -2307,6 +2307,15 @@ HostVendor_CPP='unknown' HostOS_CPP='freebsd' ;; +i[3456]86-*-dragonfly*) + HostPlatform=i386-unknown-dragonfly # hack again + TargetPlatform=i386-unknown-dragonfly + BuildPlatform=i386-unknown-dragonfly + HostPlatform_CPP='i386_unknown_dragonfly' + HostArch_CPP='i386' + HostVendor_CPP='unknown' + HostOS_CPP='dragonfly' + ;; i[3456]86-*-freebsd2*) # Older FreeBSDs are a.out HostPlatform=i386-unknown-freebsd2 # hack again TargetPlatform=i386-unknown-freebsd2 diff -ru ghc-6.10.4-orig/configure.ac ghc-6.10.4/configure.ac --- ghc-6.10.4-orig/configure.ac 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4/configure.ac 2009-11-06 21:10:07 +0100 @@ -260,6 +260,15 @@ HostVendor_CPP='unknown' HostOS_CPP='freebsd' ;; +i[[3456]]86-*-dragonfly*) + HostPlatform=i386-unknown-dragonfly # hack again + TargetPlatform=i386-unknown-dragonfly + BuildPlatform=i386-unknown-dragonfly + HostPlatform_CPP='i386_unknown_dragonfly' + HostArch_CPP='i386' + HostVendor_CPP='unknown' + HostOS_CPP='dragonfly' + ;; i[[3456]]86-*-freebsd2*) # Older FreeBSDs are a.out HostPlatform=i386-unknown-freebsd2 # hack again TargetPlatform=i386-unknown-freebsd2 diff -ru ghc-6.10.4-orig/distrib/configure-bin.ac ghc-6.10.4/distrib/configure-bin.ac --- ghc-6.10.4-orig/distrib/configure-bin.ac 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4/distrib/configure-bin.ac 2009-11-06 21:10:07 +0100 @@ -42,6 +42,8 @@ TargetPlatform=i386-unknown-freebsd2;; i[[3456]]86-*-freebsd[[3-9]]*) TargetPlatform=i386-unknown-freebsd;; +i[[3456]]86-*-dragonfly*) + TargetPlatform=i386-unknown-dragonfly;; i[[3456]]86-*-netbsd*) TargetPlatform=i386-unknown-netbsd;; i[[3456]]86-*-openbsd*) diff -ru ghc-6.10.4-orig/driver/mangler/ghc-asm.lprl ghc-6.10.4/driver/mangler/ghc-asm.lprl --- ghc-6.10.4-orig/driver/mangler/ghc-asm.lprl 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4/driver/mangler/ghc-asm.lprl 2009-11-06 21:10:07 +0100 @@ -160,12 +160,12 @@ $T_HDR_vector = "\.text\n\t\.align 4\n"; # NB: requires padding #--------------------------------------------------------# - } elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|gnu|freebsd|netbsd|openbsd|kfreebsdgnu)$/m ) { + } elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|gnu|freebsd|dragonfly|netbsd|openbsd|kfreebsdgnu)$/m ) { $T_STABBY = 0; # 1 iff .stab things (usually if a.out format) $T_US = ''; # _ if symbols have an underscore on the front $T_PRE_APP = # regexp that says what comes before APP/NO_APP - ($TargetPlatform =~ /-(linux|gnu|freebsd|netbsd|openbsd)$/m) ? '#' : '/' ; + ($TargetPlatform =~ /-(linux|gnu|freebsd|dragonfly|netbsd|openbsd)$/m) ? '#' : '/' ; $T_CONST_LBL = '^\.LC(\d+):$'; # regexp for what such a lbl looks like $T_POST_LBL = ':'; $T_X86_PRE_LLBL_PAT = '\.L'; @@ -216,7 +216,7 @@ $T_HDR_vector = "\.text\n\t\.align 8\n"; #--------------------------------------------------------# - } elsif ( $TargetPlatform =~ /^x86_64-.*-(linux|openbsd|freebsd|netbsd)$/m ) { + } elsif ( $TargetPlatform =~ /^x86_64-.*-(linux|openbsd|freebsd|dragonfly|netbsd)$/m ) { $T_STABBY = 0; # 1 iff .stab things (usually if a.out format) $T_US = ''; # _ if symbols have an underscore on the front diff -ru ghc-6.10.4-orig/libraries/unix/System/Posix/Signals.hsc ghc-6.10.4/libraries/unix/System/Posix/Signals.hsc --- ghc-6.10.4-orig/libraries/unix/System/Posix/Signals.hsc 2009-07-14 19:20:42 +0200 +++ ghc-6.10.4/libraries/unix/System/Posix/Signals.hsc 2009-11-06 21:10:07 +0100 @@ -292,7 +292,7 @@ raiseSignal :: Signal -> IO () raiseSignal sig = throwErrnoIfMinus1_ "raiseSignal" (c_raise sig) -#if defined(__GLASGOW_HASKELL__) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS)) +#if defined(__GLASGOW_HASKELL__) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS)) foreign import ccall unsafe "genericRaise" c_raise :: CInt -> IO CInt #else diff -ru ghc-6.10.4-orig/mk/config.mk.in ghc-6.10.4/mk/config.mk.in --- ghc-6.10.4-orig/mk/config.mk.in 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4/mk/config.mk.in 2009-11-06 21:10:07 +0100 @@ -298,7 +298,7 @@ # Whether to include GHCi in the compiler. Depends on whether the RTS linker # has support for this OS/ARCH combination. -OsSupportsGHCi=$(strip $(patsubst $(HostOS_CPP), YES, $(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd netbsd openbsd darwin))) +OsSupportsGHCi=$(strip $(patsubst $(HostOS_CPP), YES, $(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd dragonfly netbsd openbsd darwin))) ArchSupportsGHCi=$(strip $(patsubst $(HostArch_CPP), YES, $(findstring $(HostArch_CPP), i386 x86_64 powerpc sparc sparc64))) ifeq "$(OsSupportsGHCi)$(ArchSupportsGHCi)" "YESYES" diff -ru ghc-6.10.4-orig/rts/Linker.c ghc-6.10.4/rts/Linker.c --- ghc-6.10.4-orig/rts/Linker.c 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4/rts/Linker.c 2009-11-06 21:10:07 +0100 @@ -61,12 +61,12 @@ #include #endif -#if defined(ia64_HOST_ARCH) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(ia64_HOST_ARCH) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) #define USE_MMAP #include #include -#if defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) #ifdef HAVE_UNISTD_H #include #endif @@ -74,7 +74,7 @@ #endif -#if defined(linux_HOST_OS) || defined(solaris2_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(linux_HOST_OS) || defined(solaris2_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) # define OBJFORMAT_ELF #elif defined(cygwin32_HOST_OS) || defined (mingw32_HOST_OS) # define OBJFORMAT_PEi386 @@ -1327,7 +1327,7 @@ } else { if ((W_)result > 0x80000000) { // oops, we were given memory over 2Gb -#if defined(freebsd_HOST_OS) +#if defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) // Some platforms require MAP_FIXED. This is normally // a bad idea, because MAP_FIXED will overwrite // existing mappings. diff -ru ghc-6.10.4-orig/rts/Makefile ghc-6.10.4/rts/Makefile --- ghc-6.10.4-orig/rts/Makefile 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4/rts/Makefile 2009-11-06 21:10:07 +0100 @@ -139,7 +139,7 @@ STANDARD_OPTS += -I../includes -I. -Iparallel -Ism # COMPILING_RTS is only used when building Win32 DLL support. -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 # HC_OPTS is included in both .c and .cmm compilations, whereas CC_OPTS is # only included in .c compilations. HC_OPTS included the WAY_* opts, which diff -ru ghc-6.10.4-orig/rts/RtsUtils.c ghc-6.10.4/rts/RtsUtils.c --- ghc-6.10.4-orig/rts/RtsUtils.c 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4/rts/RtsUtils.c 2009-11-06 21:10:07 +0100 @@ -461,7 +461,7 @@ * genericRaise(), rather than raise(3). */ int genericRaise(int sig) { -#if defined(THREADED_RTS) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS)) +#if defined(THREADED_RTS) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS)) return pthread_kill(pthread_self(), sig); #else return raise(sig); From igloo at earth.li Sat Nov 7 09:07:37 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 7 08:43:36 2009 Subject: 6.12.1 Release Candidate: profiling and libHSffi_p.a In-Reply-To: <4AD88E77.7070802@kent.ac.uk> References: <4AD88E77.7070802@kent.ac.uk> Message-ID: <20091107140737.GA11086@matrix.chaos.earth.li> On Fri, Oct 16, 2009 at 04:17:11PM +0100, Neil Brown wrote: > > $ ghc -O1 -prof -auto-all --make CommsTime.hs > [1 of 1] Compiling Main ( CommsTime.hs, CommsTime.o ) > Linking CommsTime ... > /usr/bin/ld: cannot find -lHSffi_p > collect2: ld returned 1 exit status Thanks for the report. Fixed by: Mon Oct 12 11:19:52 BST 2009 Ian Lynagh * Install libHSffi_p.a Thanks Ian From igloo at earth.li Sat Nov 7 09:20:53 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 7 08:56:51 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <694519c50910181320y130eb60jf08e0bab0341c4d4@mail.gmail.com> References: <20091011204153.GA5338@matrix.chaos.earth.li> <694519c50910181320y130eb60jf08e0bab0341c4d4@mail.gmail.com> Message-ID: <20091107142053.GB11086@matrix.chaos.earth.li> On Sun, Oct 18, 2009 at 03:20:21PM -0500, Antoine Latter wrote: > > Note that what was spliced in as [] is now being spliced in as "", > which is incorrect. This has been filed as http://hackage.haskell.org/trac/ghc/ticket/3600 and fixed. Thanks Ian From e at xtendo.org Sat Nov 7 12:08:51 2009 From: e at xtendo.org (han) Date: Sat Nov 7 11:44:50 2009 Subject: Compiling to ANSI C Message-ID: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> I am (in fact we are) working to make Haskell code to run on an ARM Linux machine called GP2X Wiz, the open-source based handheld game console. I wish to finally make a Haskell cross-compiler for ARM Linux, and for now I am trying to make main = putStrLn "Hello, World!" to run on the machine. At first I did $ ghc hello.hs -o hello -fvia-C -keep-hc-files and tried to use the generated hc file, but figured that the code is (or at least some code in the included headers is) x86-dependent. I heard that the GHC can compile to ANSI C, and I want to use it as an intermediate code to ARM Linux before we can actually port the GHC to it. Is there any specific option I have to give in order to generate an ANSI C code from a Haskell source code? From thomas.dubuisson at gmail.com Sat Nov 7 12:56:04 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Nov 7 12:32:04 2009 Subject: Compiling to ANSI C In-Reply-To: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> Message-ID: <4c44d90b0911070956s2eb80dbsb9a47f890869daf9@mail.gmail.com> If I were you, I'd look at using the recent LLVM backend work as a means to translate Haskell -> ARM. Thomas On Sat, Nov 7, 2009 at 9:08 AM, han wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. > > I wish to finally make a Haskell cross-compiler for ARM Linux, and for > now I am trying to make > > main = putStrLn "Hello, World!" > > to run on the machine. At first I did > > $ ghc hello.hs -o hello -fvia-C -keep-hc-files > > and tried to use the generated hc file, but figured that the code is > (or at least some code in the included headers is) x86-dependent. > > I heard that the GHC can compile to ANSI C, and I want to use it as an > intermediate code to ARM Linux before we can actually port the GHC to > it. > > Is there any specific option I have to give in order to generate an > ANSI C code from a Haskell source code? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From pumpkingod at gmail.com Sat Nov 7 13:48:14 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Sat Nov 7 13:24:11 2009 Subject: Compiling to ANSI C In-Reply-To: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> Message-ID: You can use -fvia-C and -keep-hc-files but the generated C code is pretty platform-dependent (at least in terms of word sizes and so on... it may be possible to port across platforms with the same word sizes?), and probably won't help you cross-compile. It also doesn't look much like any c code any human would have written, and I think there are plans to deprecate the via-C compilation pathway eventually. If you are looking to add cross-compilation to GHC, the first thing I'd look at is detaching the choice of native code generator from the preprocessor and hooking it up to a front-end command-line option instead :) Someone on IRC (his username is dumael, not sure what his real name is) has already been working on an ARM native code generator for GHC recently. The recent LLVM back-end development should also make it pretty simple to generate code for other platforms (especially if we have a nice way to pass front-end options to the code generators) Dan On Sat, Nov 7, 2009 at 12:08 PM, han wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. > > I wish to finally make a Haskell cross-compiler for ARM Linux, and for > now I am trying to make > > main = putStrLn "Hello, World!" > > to run on the machine. At first I did > > $ ghc hello.hs -o hello -fvia-C -keep-hc-files > > and tried to use the generated hc file, but figured that the code is > (or at least some code in the included headers is) x86-dependent. > > I heard that the GHC can compile to ANSI C, and I want to use it as an > intermediate code to ARM Linux before we can actually port the GHC to > it. > > Is there any specific option I have to give in order to generate an > ANSI C code from a Haskell source code? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From aslatter at gmail.com Sat Nov 7 13:56:44 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Nov 7 13:32:42 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 1 In-Reply-To: <20091107142053.GB11086@matrix.chaos.earth.li> References: <20091011204153.GA5338@matrix.chaos.earth.li> <694519c50910181320y130eb60jf08e0bab0341c4d4@mail.gmail.com> <20091107142053.GB11086@matrix.chaos.earth.li> Message-ID: <694519c50911071056k7d2629aey441845641499f9d9@mail.gmail.com> On Sat, Nov 7, 2009 at 8:20 AM, Ian Lynagh wrote: > On Sun, Oct 18, 2009 at 03:20:21PM -0500, Antoine Latter wrote: >> >> Note that what was spliced in as [] is now being spliced in as "", >> which is incorrect. > > This has been filed as > ? ?http://hackage.haskell.org/trac/ghc/ticket/3600 > and fixed. > > Thanks for the quick fix - I've been running with the patch and have happstack going with minimal changes (entirely TH related, I think). Antoine From scooter.phd at gmail.com Sat Nov 7 14:16:40 2009 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Sat Nov 7 13:52:09 2009 Subject: Compiling to ANSI C Message-ID: <551440027-1257621368-cardhu_decombobulator_blackberry.rim.net-712933354-@bda437.bisx.prod.on.blackberry> Do we have a native LLVM bitcode writer or is it still FFI? ------Original Message------ From: Thomas DuBuisson Sender: glasgow-haskell-users-bounces@haskell.org To: han Cc: glasgow-haskell-users@haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 09:56 If I were you, I'd look at using the recent LLVM backend work as a means to translate Haskell -> ARM. Thomas On Sat, Nov 7, 2009 at 9:08 AM, han wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. > > I wish to finally make a Haskell cross-compiler for ARM Linux, and for > now I am trying to make > > main = putStrLn "Hello, World!" > > to run on the machine. At first I did > > $ ghc hello.hs -o hello -fvia-C -keep-hc-files > > and tried to use the generated hc file, but figured that the code is > (or at least some code in the included headers is) x86-dependent. > > I heard that the GHC can compile to ANSI C, and I want to use it as an > intermediate code to ARM Linux before we can actually port the GHC to > it. > > Is there any specific option I have to give in order to generate an > ANSI C code from a Haskell source code? > _______________________________________________ > 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 Sent from my Verizon Wireless BlackBerry From thomas.dubuisson at gmail.com Sat Nov 7 14:28:45 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Nov 7 14:04:43 2009 Subject: Compiling to ANSI C In-Reply-To: <551440027-1257621368-cardhu_decombobulator_blackberry.rim.net-712933354-@bda437.bisx.prod.on.blackberry> References: <551440027-1257621368-cardhu_decombobulator_blackberry.rim.net-712933354-@bda437.bisx.prod.on.blackberry> Message-ID: <4c44d90b0911071128o536be361rb0d75396dc4cdb91@mail.gmail.com> On Sat, Nov 7, 2009 at 11:16 AM, wrote: > Do we have a native LLVM bitcode writer or is it still FFI? I was referring to a paper [1] I just ran into on reddit. I only skimmed it, but it seems they (or just he?) integrated LLVM as a new backend for GHC. Thomas [1] http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf From scooter.phd at gmail.com Sat Nov 7 15:20:42 2009 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Sat Nov 7 14:56:07 2009 Subject: Compiling to ANSI C Message-ID: <1327544347-1257625207-cardhu_decombobulator_blackberry.rim.net-1049104279-@bda437.bisx.prod.on.blackberry> Believe it when it shows up in GHC pristine. ------Original Message------ From: Thomas DuBuisson To: scooter.phd@gmail.com Cc: han Cc: glasgow-haskell-users@haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 11:28 On Sat, Nov 7, 2009 at 11:16 AM, wrote: > Do we have a native LLVM bitcode writer or is it still FFI? I was referring to a paper [1] I just ran into on reddit. I only skimmed it, but it seems they (or just he?) integrated LLVM as a new backend for GHC. Thomas [1] http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf Sent from my Verizon Wireless BlackBerry From john at repetae.net Sat Nov 7 17:36:58 2009 From: john at repetae.net (John Meacham) Date: Sat Nov 7 17:12:57 2009 Subject: Compiling to ANSI C In-Reply-To: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> Message-ID: <20091107223658.GB21564@sliver.repetae.net> Jhc compiles to ANSI C and has been tested with other ARM targets and works fine. It may be suitable for your needs. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From bulat.ziganshin at gmail.com Sun Nov 8 02:19:26 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 8 01:55:37 2009 Subject: Compiling to ANSI C In-Reply-To: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> Message-ID: <781516827.20091108101926@gmail.com> Hello han, Saturday, November 7, 2009, 8:08:51 PM, you wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. seems that wizards are on holiday ATM, so i will help a little - ghc ports are divided into registerized (working with cpu registers) and unregisterized (just a C code generated). for the fist time, you need to make unregisterized port of course. nevertheless, ghc doesn't generate portable C afaik, but you will have much less work to do - i.e. tune wordsizes and so on. sorry, i don't know more, google for unregisterized ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kili at outback.escape.de Sun Nov 8 05:07:11 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Nov 8 04:44:00 2009 Subject: Compiling to ANSI C In-Reply-To: <781516827.20091108101926@gmail.com> References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> <781516827.20091108101926@gmail.com> Message-ID: <20091108100710.GA32758@nutty.outback.escape.de> On Sun, Nov 08, 2009 at 10:19:26AM +0300, Bulat Ziganshin wrote: > seems that wizards are on holiday ATM, so i will help a little - ghc > ports are divided into registerized (working with cpu registers) > and unregisterized (just a C code generated). I wouldn't touch the *registerized* variant using intermediate C files, because that means you probably would also have to modify the evil mangler, which is -- evil. Ciao, Kili From colin at colina.demon.co.uk Sun Nov 8 09:11:11 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 8 08:47:08 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091106232522.GA35866@horse.gocht-isenmann.de> (Goetz Isenmann's message of "Sat\, 7 Nov 2009 00\:25\:22 +0100") References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> Message-ID: >>>>> "Goetz" == Goetz Isenmann writes: Goetz> Maybe you could start with something like: Goetz> $ curl -o ghc-6.10.4-3.tar.bz2 \ ; Goetz> http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $ Goetz> curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar Goetz> xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $ Goetz> PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal Goetz> update $ ./cabal install --user cabal-install This looks confusing to me - you name the file .bz2 yet you are saying use tar xzf to extract it (as if it were gzipped0. Whatever, I can't decompress it. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Mon Nov 9 03:57:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 9 03:33:48 2009 Subject: Compiling to ANSI C In-Reply-To: References: <5b4dd2a10911070908n3733a2fajfbe17a172e4deebd@mail.gmail.com> Message-ID: <4AF7D98A.4020202@gmail.com> On 07/11/2009 18:48, Daniel Peebles wrote: > You can use -fvia-C and -keep-hc-files but the generated C code is > pretty platform-dependent (at least in terms of word sizes and so > on... it may be possible to port across platforms with the same word > sizes?), and probably won't help you cross-compile. It also doesn't > look much like any c code any human would have written, and I think > there are plans to deprecate the via-C compilation pathway eventually. > > If you are looking to add cross-compilation to GHC, the first thing > I'd look at is detaching the choice of native code generator from the > preprocessor and hooking it up to a front-end command-line option > instead :) We already compile in all the NCG backends, so that should be quite straightforward. What's much harder is arranging the rest of your cross-compilation environment - assembler, linker etc., and making sure you're using the right configuration parameters from the target machine for the build. It's generally easier to get an unregisterised port working first, and then use that to bootstrap an NCG/registerised version. > Someone on IRC (his username is dumael, not sure what his > real name is) has already been working on an ARM native code generator > for GHC recently. Interesting, I didn't know that. There's also the iPhone GHC port, which is unregisterised, I believe. >The recent LLVM back-end development should also > make it pretty simple to generate code for other platforms (especially > if we have a nice way to pass front-end options to the code > generators) Definitely, I think that will be a nice side-effect of the LLVM backend. Cheers, Simon From marlowsd at gmail.com Mon Nov 9 05:44:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 9 05:20:46 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091106232522.GA35866@horse.gocht-isenmann.de> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> Message-ID: <4AF7F29F.5030903@gmail.com> On 06/11/2009 23:25, Goetz Isenmann wrote: > On Wed, Nov 04, 2009 at 03:08:27PM +0000, Colin Adams wrote: >> When GHC 6.12.1 is released, I'm going to have a go at porting it to >> DragonFly BSD (32-bit incarnation). Is the porting page on the >> wikiup-to-date? > > Maybe you could start with something like: > > $ curl -o ghc-6.10.4-3.tar.bz2 \ > ; http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 > $ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal > $ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann > $ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH > $ ./cabal update > $ ./cabal install --user cabal-install > > I have just recompiled this ghc with itself using the attached > patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit). > > The patches are only a stupid "do the same for dragonfly as for > freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and > (b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably > the wrong way to fix a (can't remember the details) build problem. > > Until now I had no time and energie to dig deeper into the problem > [1], that looks to me, like rts/Linker cannot load any object file > that references errno. > > My guess is, that for dragonflys "extern __thread int errno;" we do > not only need to add a new case in rts/Linker.c but also need to > generate different code for this thread local storage access. Great work. I've added Dragonfly BSD to the list of Tier 2 platforms: http://hackage.haskell.org/trac/ghc/wiki/Platforms Would you be willing to be the maintainer for GHC on Dragonfly? We should get these patches into GHC. Most of them look straightforward, but I'm slightly suspicious of this: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 why was that necessary? Cheers, Simon From duncan.coutts at googlemail.com Mon Nov 9 07:31:34 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 9 07:07:29 2009 Subject: Three patches for cabal In-Reply-To: References: <1245230688.13502.2939.camel@localhost> Message-ID: <1257769894.4680.313.camel@localhost> On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote: > > Can someone please comment on these two proposed changes. I agree with > > Niklas but I'm a bit reluctant to apply the patches without at least > > some sign of agreement from someone else. > > > > Deprecating PatternSignatures seems uncontroversial, but the > > NoMonoPatBinds is potentially controversial. GHC essentially uses > > -XMonoPatBinds by default, even in H98 mode, and the user can use > > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > > the list of language extensions in Language.Haskell.Exceptions are > > differences from H98 so it should be MonoPatBinds to get the difference > > not NoMonoPatBinds to restore H98. > > > > In practise, since ghc uses MonoPatBinds by default it'd mean that > > people who want to get back to H98 would need to use: > > > > ghc-options: -XNoMonoPatBinds > > > > Because the extensions field is additive, not subtractive. Using the > > name MonoPatBinds allows other compilers to implement it without it > > having to be the default. > > I had a look at the source for cabal HEAD and was surprised to see > that this stuff had fallen by the wayside. What's holding it up? I > can't imagine that anyone would be against the deprecation of > PatternSignatures at least. I'd forgotten they were separate patches. I've applied the PatternSignatures one since that is indeed uncontroversial. I don't think the discussion on the other ones were conclusive yet. I think in the end I'm with Ian on his suggestion that we should allow the "No" prefix to invert an extension. This would help in this case and also let us handle things better when the default extensions change. Duncan From niklas.broberg at gmail.com Mon Nov 9 09:19:36 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Nov 9 08:55:28 2009 Subject: Three patches for cabal In-Reply-To: <1257769894.4680.313.camel@localhost> References: <1245230688.13502.2939.camel@localhost> <1257769894.4680.313.camel@localhost> Message-ID: > I think in the end I'm with Ian on his suggestion that we should allow > the "No" prefix to invert an extension. This would help in this case and > also let us handle things better when the default extensions change. I too agree with this position for the long run. /Niklas From info at goetz-isenmann.de Mon Nov 9 12:39:25 2009 From: info at goetz-isenmann.de (Goetz Isenmann) Date: Mon Nov 9 12:15:19 2009 Subject: Porting to DragonFly BSD In-Reply-To: <4AF7F29F.5030903@gmail.com> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> <4AF7F29F.5030903@gmail.com> Message-ID: <20091109173924.GA918@horse.gocht-isenmann.de> On Mon, Nov 09, 2009 at 10:44:47AM +0000, Simon Marlow wrote: > We should get these patches into GHC. Most of them look > straightforward, but I'm slightly suspicious of this: > > -STANDARD_OPTS += -DCOMPILING_RTS > +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 > > why was that necessary? Good that you ask. Can't remember why it was necessary back in april to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem today with ghc-6.10.4 on dragonfly-2.4.1. I am glad, that we do not need this define any more. I think it was a ugly workaround at best. From michael.serdar at gmail.com Mon Nov 9 13:28:33 2009 From: michael.serdar at gmail.com (Michael Serdar) Date: Mon Nov 9 13:04:27 2009 Subject: GHCI :reload module without erasing previous data Message-ID: I have a module that loads several dozen megabytes of static data into memory. This module is working properly. I have another module that I'm developing to analyze that data. As I make iterations on the analysis module, I would like it if the data loaded by the data module could stay in memory. In GHCI, every time I reload a module, it clears whatever data I have set with the "let" command. Is there a way to persist that data across calls to :reload, or is there an altogether different workflow I should be using for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091109/7dd2ffb8/attachment.html From twhitehead at gmail.com Mon Nov 9 13:41:04 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Nov 9 13:17:05 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091109173924.GA918@horse.gocht-isenmann.de> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <4AF7F29F.5030903@gmail.com> <20091109173924.GA918@horse.gocht-isenmann.de> Message-ID: <200911091341.09159.twhitehead@gmail.com> On November 9, 2009 12:39:25 Goetz Isenmann wrote: > On Mon, Nov 09, 2009 at 10:44:47AM +0000, Simon Marlow wrote: > > We should get these patches into GHC. Most of them look > > straightforward, but I'm slightly suspicious of this: > > > > -STANDARD_OPTS += -DCOMPILING_RTS > > +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 > > > > why was that necessary? > > Good that you ask. Can't remember why it was necessary back in april > to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem > today with ghc-6.10.4 on dragonfly-2.4.1. > > I am glad, that we do not need this define any more. I think it was a > ugly workaround at best. I'm not sure about dragonfly, but there are a bunch of similar options for glibc under Linux. For example, "man feature_test_macros" says you need to define _POSIX_C_SOURCE to 199309 or greater to use POSIX.1b functionality. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091109/40d3186b/attachment.bin From marlowsd at gmail.com Wed Nov 11 06:46:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 11 06:22:39 2009 Subject: GHCI :reload module without erasing previous data In-Reply-To: References: Message-ID: <4AFAA420.6000404@gmail.com> On 09/11/2009 18:28, Michael Serdar wrote: > I have a module that loads several dozen megabytes of static data into > memory. This module is working properly. I have another module that I'm > developing to analyze that data. As I make iterations on the analysis > module, I would like it if the data loaded by the data module could stay > in memory. > > In GHCI, every time I reload a module, it clears whatever data I have > set with the "let" command. Is there a way to persist that data across > calls to :reload, or is there an altogether different workflow I should > be using for this? GHCi always discards the current bindings when you :reload. The way to make them persistent is to put them in a module and :load it. Top-level bindings in interpreted modules will not be reverted, as long as the module itself is not recompiled, or depends (indirectly) on a module that has been recompiled. Cheers, Simon From daniil.elovkov at googlemail.com Thu Nov 12 03:01:22 2009 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Thu Nov 12 02:35:51 2009 Subject: 3 questions regarding profiling in ghc Message-ID: <4AFBC0D2.9080905@googlemail.com> Hello Sorry for the uninformative subject, but I've got no less than 3 questions about profiling in ghc. Here we go 1) Can I profile my program if I don't have all the libraries it depends on compiled with profiling? ghc says it can't find profiling variants of this and that module in other packages, when I try ghc -prof. I managed to build all the dependencies with profiling, but that being a necessity doesn't look good to me. Maybe there's a way to avoid that? Moreover, as far as I could tell functions from those packages didn't appear in the call graph after +RTS -p profiling. 2) Can I exclude a function from profiling? That probably means not assigning a cost centre to it. Typical case, I think. Database connect function is rather heavyweight (regarding time) compared to the rest of the code, and it takes up to 98% of time. So the rest of the picture is less informative than it could be. 3) Isn't it possible to have -p profiling data of the interrupted (ctrl-c) program? Thanks a lot! -- Daniil Elovkov From gale at sefer.org Thu Nov 12 09:40:48 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 12 09:16:54 2009 Subject: A few small points about GHCi command documentation in section 2.7 Message-ID: <2608b8a80911120640s2ca0ed50jf987fa85fff2b3f1@mail.gmail.com> Please add to the documentation for :set prompt: If you enclose \i{prompt} in quotes, you can use Haskell syntax for String literals. Actually, :set prompt is nearly useless without quotes, because GHCi strips off trailing spaces from commands. We should either add a space at the end of a prompt entered without quotes, or just require quotes. Or at least change the help text to be: :set prompt \"\" set the prompt used in GHCi\n so that people will know the right thing to do. Perhaps add a few more words of explanation to the docs in section 2.7 once we decide which of these to do. The :run command is not documented in section 2.7 - the only mention of it is buried within the documentation for the :main command. It is also not mentioned in helpText. Thanks, Yitz From duncan.coutts at googlemail.com Thu Nov 12 10:26:05 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Nov 12 10:02:42 2009 Subject: [Haskell-cafe] Fwd: (Solved) cabal install with external gcc tool chain not the ghc-bundled one In-Reply-To: <4AFBD979.4030203@googlemail.com> References: <4AFBD979.4030203@googlemail.com> Message-ID: <1258039565.4680.9645.camel@localhost> On Thu, 2009-11-12 at 10:46 +0100, Daniel Kahlenberg wrote: > to answer this question myself how the use of another gcc is specified > with effect, I used the following options with the 'cabal install' call: > > --ghc-options="-pgmc e:/programme/ghc/mingw-gcc4/bin/gcc.exe -pgml > e:/programme/ghc/mingw-gcc4/bin/gcc.exe" > > See > http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#replacing-phases > (searched in the wrong direction, too many trees...). Slightly tuned, > this should be the way to go in all similar cases. > > One thing I haven't considered yet is if the '--with-ld' and > '--with-gcc' options (if curious too, see logs in my previous mail - > Subject "[Haskell-cafe] caba install with external gcc toolchain not the > ghc-bundled one") only effect what gets written into the > setup-config/package.conf file or what other effects these have. Feel free to file a ticket about this. What makes me somewhat nervous is that the gcc you want to use for say .c files is not necessarily the same as the one ghc wants to use to compile .hc files or link stuff. This is particularly the case on Windows where ghc includes its own copy of gcc. Similarly on Solaris 10, ghc cannot use the /usr/bin/gcc because it's a hacked-up gcc that uses the Sun CC backend (which doesn't grok some of the crazy GNU C stuff that ghc uses). So it'd certainly be possible to have cabal's --with-gcc/ld override the ones that ghc uses by default, but the question is should it do so? I think it's worth asking the ghc hackers about this. Duncan From haskell at colquitt.org Thu Nov 12 13:35:33 2009 From: haskell at colquitt.org (John Dorsey) Date: Thu Nov 12 13:11:15 2009 Subject: 3 questions regarding profiling in ghc In-Reply-To: <4AFBC0D2.9080905@googlemail.com> References: <4AFBC0D2.9080905@googlemail.com> Message-ID: <20091112183533.GD23495@colquitt.org> Daniil, While you're waiting for an answer from a GHC internals expert, here's my experience as a fellow user. > 1) Can I profile my program if I don't have all the libraries it depends > on compiled with profiling? I don't know how to do that, and I don't know how to automatically reinstall all dependencies of my project with profiling enabled. I recently went through reinstalling said dependencies as I found them, iteratively. I could have blown away and reinstalled GHC instead, and saved time. To prevent a recurrence, I now have this in my ~/.cabal/config : library-vanilla: True library-profiling: True This should install both normal and profiling versions of every library that I install with cabal from here out. It's a little slower when installing new library packages, but it doesn't come up often enough to bother me. There may be some pain when I get around to bootstrapping GHC 6.12, if it doesn't install profiling builds of its bundled libs. > Moreover, as far as I could tell functions from those packages didn't > appear in the call graph after +RTS -p profiling. Did you use "-auto-all", to automatically create cost centers for all top-level functions? I find that I get very verbose cost info for definitions under imported libraries. > 2) Can I exclude a function from profiling? That probably means not > assigning a cost centre to it. If "-auto-all" doesn't please you, you can manually define your cost centers in your code, leaving out the ones you don't care about. But unless I'm mistaken, that doesn't exclude those costs, but rather includes them in the calling cost center. So it may not be what you're asking for. > Typical case, I think. Database connect function is rather heavyweight > (regarding time) compared to the rest of the code, and it takes up to > 98% of time. So the rest of the picture is less informative than it > could be. It's your business, but in that case why would you care about the (time) profile of the rest of the code? I wouldn't spend ten seconds time-optimizing anything but that hot spot. If it can't be improved, you're done. To be clear, I'm assuming you're talking about 98% of CPU time, not wall time; I don't think the profiler reports wall time, except maybe in the summary. > 3) Isn't it possible to have -p profiling data of the interrupted > (ctrl-c) program? When I ctrl-c out of my program, I get a nice .prof file in the directory where it's running. If you're not getting that, the difference could be OS environment (I'm developing on Linux), or it could be that I'm using happstack and calling a routine that catches the ctrl-c then exits cleanly. It's Happstack.State.waitForTermination; you can probably distill enough from it to get the same effect. http://hackage.haskell.org/packages/archive/happstack-state/0.3.4/doc/html/src/Happstack-State-Control.html#waitForTermination (Pardon the long link.) My main routine spins off threads to do all the work, and the main thread waits on waitForTermination then shuts down. Hope some of this helps. Regards, John Dorsey From bos at serpentine.com Fri Nov 13 02:04:27 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Nov 13 01:40:09 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences Message-ID: I'm working on measuring and improving the performance of the text library at the moment, and the very first test I tried demonstrated a piece of behaviour that I'm not completely able to understand. Actually, I'm not able to understand what's going on at all, beyond a very shallow level. All the comments below pertain to GHC 6.10.4. The text library uses stream fusion, and I want to measure the performance of UTF-8 decoding. The code I'm measuring is very simple: import qualified Data.ByteString as B import Data.Text.Encoding as T import qualified Data.Text as T import System.Environment (getArgs) import Control.Monad (forM_) main = do args <- getArgs forM_ args $ \a -> do s <- B.readFile a let t = T.decodeUtf8 s print (T.length t) The streamUtf8 function looks roughly like this: streamUtf8 :: OnDecodeError -> ByteString -> Stream Char streamUtf8 onErr bs = Stream next 0 (maxSize l) where l = B.length bs next i | i >= l = Done | U8.validate1 x1 = Yield (unsafeChr8 x1) (i+1) | {- etc. -} {-# INLINE [0] streamUtf8 #-} The values being Yielded from the inner function are, as you can see, themselves constructed by functions. Originally, with the inner next function manually marked as INLINE, I found that functions like unsafeChr8 were not being inlined by GHC, and performance was terrible due to the amount of boxing and unboxing happening in the inner loop. I somehow stumbled on the idea of removing the INLINE annotation from next, and performance suddenly improved by a significant integer multiple. This caused the body of streamUtf8 to be inlined into my test program, as I hoped. However, I wasn't yet out of the woods. The length function is defined as follows: length :: Text -> Int length t = Stream.length (Stream.stream t) {-# INLINE length #-} And the streaming length is: length :: Stream Char -> Int length = S.lengthI {-# INLINE[1] length #-} And the lengthI function is defined more generally, in the hope that I could use it for both Int and Int64 lengths: lengthI :: Integral a => Stream Char -> a lengthI (Stream next s0 _len) = loop_length 0 s0 where loop_length !z s = case next s of Done -> z Skip s' -> loop_length z s' Yield _ s' -> loop_length (z + 1) s' {-# INLINE[0] lengthI #-} Unfortunately, although lengthI is inlined into the Int-typed streaming length function, that function is not in turn marked with __inline_me in simplifier output, so the length/decodeUtf8 loops do not fuse. The code is pretty fast, but there's still a lot of boxing and unboxing happening for all the Yields. So. I am quite baffled by this, and I confess to having no idea what to do to get the remaining functions to fuse. But that's not quite confusing enough! Here's a one-byte change to my test code: main = do args <- getArgs forM_ args $ \a -> do s <- B.readFile a let !t = decodeUtf8 s *{- <-- notice the strictness annotation -}* print (T.length t) In principle, this should make the code a little slower, because I'm deliberately forcing a Text value to be created, instead of allowing stream/unstream fusion to occur. Now the length function seems to get inlined properly, but while the decodeUtf8 function is inlined, the functions in its inner loop that must be inlined for performance purposes are not. The result is very slow code. I found another site for this one test where removing a single INLINEannotation makes the strictified code above 2x faster, but that change causes the stream/unstream fusion rule to fail to fire entirely, so the strictness annotation no longer makes a difference to performance. All of these flip-flops in inliner behaviour are very difficult to understand, and they seem to be exceedingly fragile. Should I expect the situation to be better with the new inliner in 6.12? Thanks for bearing with that rather long narrative, Bryan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091113/2f0386b6/attachment-0001.html From simonpj at microsoft.com Fri Nov 13 03:12:43 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 13 02:48:27 2009 Subject: 3 questions regarding profiling in ghc In-Reply-To: <20091112183533.GD23495@colquitt.org> References: <4AFBC0D2.9080905@googlemail.com> <20091112183533.GD23495@colquitt.org> Message-ID: <59543203684B2244980D7E4057D5FBC1061C5465@DB3EX14MBXC310.europe.corp.microsoft.com> | > 1) Can I profile my program if I don't have all the libraries it depends | > on compiled with profiling? I'm afraid not. It's one of the shortcomings of GHC's profiler, but it's hard to overcome. Simon From rl at cse.unsw.edu.au Fri Nov 13 03:19:12 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Nov 13 02:54:55 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: Message-ID: On 13/11/2009, at 18:04, Bryan O'Sullivan wrote: > main = do > args <- getArgs > forM_ args $ \a -> do > s <- B.readFile a > let t = T.decodeUtf8 s > print (T.length t) > > The streamUtf8 function looks roughly like this: > > streamUtf8 :: OnDecodeError -> ByteString -> Stream Char > streamUtf8 onErr bs = Stream next 0 (maxSize l) > where > l = B.length bs > next i > | i >= l = Done > | U8.validate1 x1 = Yield (unsafeChr8 x1) (i+1) > | {- etc. -} > {-# INLINE [0] streamUtf8 #-} > > The values being Yielded from the inner function are, as you can > see, themselves constructed by functions. > > Originally, with the inner next function manually marked as INLINE, > I found that functions like unsafeChr8 were not being inlined by > GHC, and performance was terrible due to the amount of boxing and > unboxing happening in the inner loop. Let's see if I understand this correctly. In your code, decodeUtf8 calls streamUtf8. They both get inlined into main but then unsafeChr8 does not. Correct? If so, are you sure that unsafeChr8 is really called in the simplified code? IIUC, this isn't necessary if you don't actually inspect the Chars (which length presumably doesn't). So perhaps GHC removes the call altogether? If not, what does it do with the result? > I somehow stumbled on the idea of removing the INLINE annotation > from next, and performance suddenly improved by a significant > integer multiple. This caused the body of streamUtf8 to be inlined > into my test program, as I hoped. Or are you saying that it's streamUtf8 that isn't getting inlined into main? > length :: Text -> Int > length t = Stream.length (Stream.stream t) > {-# INLINE length #-} > > And the streaming length is: > > length :: Stream Char -> Int > length = S.lengthI > {-# INLINE[1] length #-} > > And the lengthI function is defined more generally, in the hope that > I could use it for both Int and Int64 lengths: > > lengthI :: Integral a => Stream Char -> a > lengthI (Stream next s0 _len) = loop_length 0 s0 > where > loop_length !z s = case next s of > Done -> z > Skip s' -> loop_length z s' > Yield _ s' -> loop_length (z + 1) s' > {-# INLINE[0] lengthI #-} > > Unfortunately, although lengthI is inlined into the Int-typed > streaming length function, that function is not in turn marked with > __inline_me in simplifier output, so the length/decodeUtf8 loops do > not fuse. The code is pretty fast, but there's still a lot of boxing > and unboxing happening for all the Yields. Does changing the definition of length to length = id S.lengthI help? GHC used to have a bug in this area but I haven't been bitten by it for quite some time. Also, I wonder how Stream.stream is defined. Is it strict in Text? If it isn't, does making it strict help? > All of these flip-flops in inliner behaviour are very difficult to > understand, and they seem to be exceedingly fragile. Should I expect > the situation to be better with the new inliner in 6.12? I suspect that the fragility you are seeing is just a symptom of a problem in how the UTF-8 library implements stream fusion. It's a bit tricky to get everything right. Generally, I've found the simplifier to be quite stable and predictable in the last year or so. Simon is working hard on making it even better. If you have a spare minute, perhaps you could try the HEAD with the new inliner and see if that helps? Although I somewhat doubt it, to be honest. Roman From simonpj at microsoft.com Fri Nov 13 03:26:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 13 03:02:21 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> Bryan | I'm working on measuring and improving the performance of the text library at the | moment, and the very first test I tried demonstrated a piece of behaviour | that I'm not completely able to understand. Actually, I'm not able to | understand what's going on at all, beyond a very shallow level. | All the comments below pertain to GHC 6.10.4. My goal is for INLINE pragmas to be very predictable. I can't decode your message enough to offer any insights; thank you Roman, who is closer to it, for helping. As Roman says, I committed a patch two days ago which constitutes a fairly radical overhaul of the way inlining works, strongly motivated by wanting predictability. So can you try the HEAD? If that doesn't work, let's make it concrete. You identify several cases where something unexpected happened. Can you submit a Trac ticket with instructions for reproducing this unexpected behaviour? Just to make it self contained, maybe include any non-standard libraries as an attachment? Simon From marlowsd at gmail.com Fri Nov 13 08:43:34 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 13 08:19:20 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: Message-ID: <4AFD6286.6010304@gmail.com> On 13/11/2009 07:04, Bryan O'Sullivan wrote: > I'm working on measuring and improving the performance of the text > library at the moment, and the very first test I tried demonstrated a > piece of behaviour that I'm not completely able to understand. Actually, > I'm not able to understand what's going on at all, beyond a very shallow > level. All the comments below pertain to GHC 6.10.4. > > The text library uses stream fusion, and I want to measure the > performance of UTF-8 decoding. > > The code I'm measuring is very simple: > > import qualified Data.ByteString as B > import Data.Text.Encoding as T > import qualified Data.Text as T > import System.Environment (getArgs) > import Control.Monad (forM_) > > main = do > args <- getArgs > forM_ args $ \a -> do > s <- B.readFile a > let t = T.decodeUtf8 s > print (T.length t) > > > The streamUtf8 function looks roughly like this: > > streamUtf8 :: OnDecodeError -> ByteString -> Stream Char > streamUtf8 onErr bs = Stream next 0 (maxSize l) > where > l = B.length bs > next i > | i >= l = Done > | U8.validate1 x1 = Yield (unsafeChr8 x1) (i+1) > | {- etc. -} > {-# INLINE [0] streamUtf8 #-} > > > The values being Yielded from the inner function are, as you can see, > themselves constructed by functions. > > Originally, with the inner next function manually marked as INLINE, I > found that functions like unsafeChr8 were not being inlined by GHC, and > performance was terrible due to the amount of boxing and unboxing > happening in the inner loop. > > I somehow stumbled on the idea of removing the INLINE annotation from > next, and performance suddenly improved by a significant integer > multiple. This caused the body of streamUtf8 to be inlined into my test > program, as I hoped. I think I can explain this one, at least partially. When you mark a function INLINE, GHC does not optimise the body of the function itself, on the grounds that it will be inlined at the call site anyway and get optimised there. Simon just changed this behaviour in GHC 6.12, so that GHC now keeps the original definition for inlining, but also optimises the original function as normal, which is useful if we can't or don't want to inline at a call site for some reason (or indeed if the calling module is being compiled without -O!). What we still don't understand, however, is why streamUtf8 was not being inlined at the call site. That is the root of the problem. We'll need to look more closely at the call site to understand what's going on. Cheers, Simon (PS if any of what I said contradicts what Simon and/or Roman said, then please ignore me and not them :-) From daniil.elovkov at googlemail.com Fri Nov 13 09:18:11 2009 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Fri Nov 13 08:52:35 2009 Subject: 3 questions regarding profiling in ghc In-Reply-To: <20091112183533.GD23495@colquitt.org> References: <4AFBC0D2.9080905@googlemail.com> <20091112183533.GD23495@colquitt.org> Message-ID: <4AFD6AA3.6090000@googlemail.com> John Dorsey wrote: > Daniil, > > While you're waiting for an answer from a GHC internals expert, here's my > experience as a fellow user. > >> 1) Can I profile my program if I don't have all the libraries it depends >> on compiled with profiling? > > I don't know how to do that, and I don't know how to automatically reinstall > all dependencies of my project with profiling enabled. I recently went > through reinstalling said dependencies as I found them, iteratively. I > could have blown away and reinstalled GHC instead, and saved time. > > To prevent a recurrence, I now have this in my ~/.cabal/config : > > library-vanilla: True > library-profiling: True > > This should install both normal and profiling versions of every library that > I install with cabal from here out. It's a little slower when installing > new library packages, but it doesn't come up often enough to bother me. > There may be some pain when I get around to bootstrapping GHC 6.12, if > it doesn't install profiling builds of its bundled libs. > >> Moreover, as far as I could tell functions from those packages didn't >> appear in the call graph after +RTS -p profiling. > > Did you use "-auto-all", to automatically create cost centers for all > top-level functions? I find that I get very verbose cost info for > definitions under imported libraries. Yeah, I've got it. Modules in packages were done by cabal configure -p. That probably doesn't imply -auto-all. > >> 2) Can I exclude a function from profiling? That probably means not >> assigning a cost centre to it. > > If "-auto-all" doesn't please you, you can manually define your cost centers > in your code, leaving out the ones you don't care about. But unless I'm > mistaken, that doesn't exclude those costs, but rather includes them in the > calling cost center. So it may not be what you're asking for. > >> Typical case, I think. Database connect function is rather heavyweight >> (regarding time) compared to the rest of the code, and it takes up to >> 98% of time. So the rest of the picture is less informative than it >> could be. > > It's your business, but in that case why would you care about the (time) > profile of the rest of the code? I wouldn't spend ten seconds > time-optimizing anything but that hot spot. If it can't be improved, you're > done. Makes sense. Well, in other circumstances that connect function may either take a lot less time or not run at all. Of course the answer here could be: so profile the program in _that_ case as well. Ok, I was just wondering :) > To be clear, I'm assuming you're talking about 98% of CPU time, not wall > time; I don't think the profiler reports wall time, except maybe in the > summary. > >> 3) Isn't it possible to have -p profiling data of the interrupted >> (ctrl-c) program? > > When I ctrl-c out of my program, I get a nice .prof file in the > directory where it's running. If you're not getting that, the difference > could be OS environment (I'm developing on Linux), or it could be that I'm > using happstack and calling a routine that catches the ctrl-c then exits > cleanly. It's Happstack.State.waitForTermination; you can probably distill > enough from it to get the same effect. > > http://hackage.haskell.org/packages/archive/happstack-state/0.3.4/doc/html/src/Happstack-State-Control.html#waitForTermination > > (Pardon the long link.) My main routine spins off threads to do all the > work, and the main thread waits on waitForTermination then shuts down. > Of course, catching ctrl-c and exiting normally alone is definitely sufficient to get the .prof file, because it's just no different than simply exiting. Thanks John, Simon. -- Daniil Elovkov From bulat.ziganshin at gmail.com Fri Nov 13 09:19:12 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 13 08:55:09 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: <4AFD6286.6010304@gmail.com> References: <4AFD6286.6010304@gmail.com> Message-ID: <1398005880.20091113171912@gmail.com> Hello Simon, Friday, November 13, 2009, 4:43:34 PM, you wrote: > I think I can explain this one, at least partially. When you mark a > function INLINE, GHC does not optimise the body of the function itself, > on the grounds that it will be inlined at the call site anyway and get > optimised there. yes! i've seen this problem in 6.4. in particular, if function to inline had a cycle (i.e. self-recursion), it wasn't optimized nor inlined -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at googlemail.com Fri Nov 13 09:40:29 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Nov 13 09:16:12 2009 Subject: 3 questions regarding profiling in ghc In-Reply-To: <4AFD6AA3.6090000@googlemail.com> References: <4AFBC0D2.9080905@googlemail.com> <20091112183533.GD23495@colquitt.org> <4AFD6AA3.6090000@googlemail.com> Message-ID: <1258123229.4680.12471.camel@localhost> On Fri, 2009-11-13 at 17:18 +0300, Daniil Elovkov wrote: > > Did you use "-auto-all", to automatically create cost centers for all > > top-level functions? I find that I get very verbose cost info for > > definitions under imported libraries. > > Yeah, I've got it. Modules in packages were done by cabal configure -p. > That probably doesn't imply -auto-all. Right, because you usually do not want to see cost centres for all of the dependent libs (especially not all the way down) to the bottom of the package stack. What we need is somewhat better control in Cabal so you can say, "actually I do want this package to have cost centres". Duncan From dave at zednenem.com Fri Nov 13 12:55:27 2009 From: dave at zednenem.com (David Menendez) Date: Fri Nov 13 12:31:05 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: Message-ID: <49a77b7a0911130955y26ba6c0oe3f3637da8251922@mail.gmail.com> On Fri, Nov 13, 2009 at 2:04 AM, Bryan O'Sullivan wrote: > > And the lengthI function is defined more generally, in the hope that I could > use it for both Int and Int64 lengths: > > lengthI :: Integral a => Stream Char -> a > lengthI (Stream next s0 _len) = loop_length 0 s0 > ?? ?where > ?? ? ?loop_length !z s ?= case next s of > ?? ? ? ? ? ? ? ? ? ? ? ? ? Done ? ? ? -> z > ?? ? ? ? ? ? ? ? ? ? ? ? ? Skip ? ?s' -> loop_length z s' > ?? ? ? ? ? ? ? ? ? ? ? ? ? Yield _ s' -> loop_length (z + 1) s' > {-# INLINE[0] lengthI #-} Would it help to SPECIALIZE lengthI for Int and Int64? -- Dave Menendez From dan.doel at gmail.com Fri Nov 13 17:58:54 2009 From: dan.doel at gmail.com (Dan Doel) Date: Fri Nov 13 17:34:37 2009 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <200911131758.54459.dan.doel@gmail.com> On Friday 30 October 2009 5:51:37 am Simon Peyton-Jones wrote: > One more update about GHC 6.12, concerning impredicative polymorphism. > > GHC has had an experimental implementation of impredicative polymorphism > for a year or two now (flag -XImpredicativePolymorphism). But > > a) The implementation is ridiculously complicated, and the complexity > is pervasive (in the type checker) rather than localized. > I'm very unhappy about this, especially as we add more stuff to > the type checker for type families. > > b) The specification (type system) is well-defined [1], but is also > pretty complicated, and it's just too hard to predict which programs will > typecheck and which will not. > > So it's time for a re-think. I propose to deprecate it in 6.12, and remove > it altogether in 6.14. We may by then have something else to put in its > place. (There is no lack of candidates [2,3,4]!) This may be a side issue, but... Someone was asking in #haskell yesterday about what exactly ImpredicativeTypes did, as it's a bit difficult to tell at first. I eventually came to the conclusion that some of the notation GHC uses may be rather poor. In a lambda cube/pure type system setting, the difference between an impredicative and predicative system are the rules: ([], *, *) vs. ([], *, []) Where the first rule says that, for instance: (Pi a:*. a -> a) : * while the second says: (Pi a:*. a -> a) : [] The first is impredicative due to * containing (Pi a:*. a -> a) itself, so the expression quantifies over a 'set' containing itself. But, if we ask GHC the kind of: forall a. a -> a it tells us the answer is *, even without ImpredicativeTypes. But that *looks* like a statement that the type system is impredicative already. And in fact, we can stick a signature on the identity function like: id :: (forall a. a -> a) -> (forall a. a -> a) which appears to allow impredicative instantiation of variables as long as they're only used in functions. But, of course, this fails for datatypes without the relevant flag. Maybe :: * -> *, but we're not allowed to apply it to (forall a. a -> a), even though GHC tells us the latter has type * (although, asking the kind of Maybe (forall a. a -> a) does not blow up; only trying to use it as a type does). At some point in the discussion, someone quoted from the boxy paper that in HM, quantification ranges over monotypes. Presumably, GHC maintains such a distinction internally, which is roughly analogous[1] to tracking the difference between * and []. But, when it comes time to display sorts, it shows both * and [] as *, which makes it somewhat unclear why Maybe (forall a. a) is invalid. So, to get to the point, whatever implementation is decided upon in the future, if predicativity is still around, I think it'd be useful to make that predicativity noticeable in the types/kinds/sorts, rather than the current situation, which to an observer looks like, "* contains both monotypes and polytypes, but quantification over * only really ranges over the monotypes (maybe)." I don't know how this would complicate GHC's current kind system, as I know it isn't set up like a pure type system, but it might be something to think about. Cheers, -- Dan [1] It probably isn't a perfect correspondence. For instance (based on my experience implementing rather naive interpreters), in a predicative, lambda cube F2, the type: forall a. forall b. a -> b is invalid, because 'forall b. a -> b' has sort [], and so the additional quantifier requires the rule ([],[],[]), which gets you to Fomega. forall a. (forall b. b) -> a = (forall b. b) -> (forall a. a) are similarly invalid. But, it feels a bit accidental to me that the Fomega rule allows these, so one could probably keep a sort divide between monotypes and polytypes while allowing repeated and higher-rank quantification, and also not allowing higher-order types (although Haskell has the latter anyway). From colin at colina.demon.co.uk Sat Nov 14 11:16:58 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Nov 14 10:52:36 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091106232522.GA35866@horse.gocht-isenmann.de> (Goetz Isenmann's message of "Sat\, 7 Nov 2009 00\:25\:22 +0100") References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> Message-ID: >>>>> "Goetz" == Goetz Isenmann writes: Goetz> Until now I had no time and energie to dig deeper into the Goetz> problem [1], that looks to me, like rts/Linker cannot load Goetz> any object file that references errno. Goetz> My guess is, that for dragonflys "extern __thread int Goetz> errno;" we do not only need to add a new case in Goetz> rts/Linker.c but also need to generate different code for Goetz> this thread local storage access. Goetz> [1] $ ghci GHCi, version 6.10.4: Goetz> http://www.haskell.org/ghc/ :? for help Loading package Goetz> ghc-prim ... linking ... done. Loading package integer Goetz> ... linking ... done. ghc: Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: Goetz> unhandled ELF relocation(Rel) type 15 Goetz> Loading package base ... linking ... ghc: unable to load Goetz> package `base' After some googling, and learning very little, I speclated that simply adding a third line for R_386_TLS_IE with the same action as the first line - just storing value, might work: case R_386_TLS_IE: *pP = value; break; This seems to work up to a point. That is I get no crashes in ghci. I do appear to have some line-feed problems. So if I type: Prelude> let x = 10 It appears to do nothing, but that is not the case - I can then overtype with :t x and ghci responds with: x :: Integerxx = 10 Prelude> So maybe this is a readline/haskelline issue? I then tried a cabal install of my website application. This fails, but I think it is because I need to apply various patches to haskelldb modules that are not yet in hackage. -- Colin Adams Preston Lancashire From info at goetz-isenmann.de Sun Nov 15 07:42:46 2009 From: info at goetz-isenmann.de (Goetz Isenmann) Date: Sun Nov 15 07:18:29 2009 Subject: Porting to DragonFly BSD In-Reply-To: References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> Message-ID: <20091115124246.GA98551@horse.gocht-isenmann.de> On Sat, Nov 14, 2009 at 04:16:58PM +0000, Colin Paul Adams wrote: > Goetz> Until now I had no time and energie to dig deeper into the > Goetz> problem [1], that looks to me, like rts/Linker cannot load > Goetz> any object file that references errno. Seems to be worse when I try to build snapshot ghc-6.13.20091111. I get a relocation error much earlier during the stage2 build. > Goetz> My guess is, that for dragonflys "extern __thread int > Goetz> errno;" we do not only need to add a new case in > Goetz> rts/Linker.c but also need to generate different code for > Goetz> this thread local storage access. I am still not sure, but the generated code might be ok 001e5565 <__hscore_get_errno>: 1e5565: 55 push %ebp 1e5566: 89 e5 mov %esp,%ebp 1e5568: 65 a1 00 00 00 00 mov %gs:0x0,%eax 1e556e: 8b 15 00 00 00 00 mov 0x0,%edx 1e5574: 8b 04 10 mov (%eax,%edx,1),%eax 1e5577: c9 leave 1e5578: c3 ret The corresponding relocation info is 001e5570 R_386_TLS_IE errno > Goetz> [1] $ ghci GHCi, version 6.10.4: > Goetz> http://www.haskell.org/ghc/ :? for help Loading package > Goetz> ghc-prim ... linking ... done. Loading package integer > Goetz> ... linking ... done. ghc: > Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: > Goetz> unhandled ELF relocation(Rel) type 15 > > Goetz> Loading package base ... linking ... ghc: unable to load > Goetz> package `base' > > After some googling, and learning very little, I speclated that simply > adding a third line for R_386_TLS_IE with the same action as the first > line - just storing value, might work: > > case R_386_TLS_IE: *pP = value; break; > > This seems to work up to a point. That is I get no crashes in ghci. I have also tried this, but I do not believe, that something that simple will work. At least it should pass this test: When you try to open a file that does not exist Prelude> System.IO.openFile "xxx" System.IO.ReadMode you should get *** Exception: xxx: openFile: does not exist (No such file or directory) and not (Unknown error: ...). My current strategie is, to avoid the problem in a first step. With the attached errno_ptr.{h,c} I create a shared library, that encapsulates the errno access, install the header file as /usr/pkg/include/errno_ptr.h and the shared lib as /usr/pkg/lib/liberrno_ptr.so Building ghc-6.10.4 with the attached patch (only a quick hack, to check the idea) I get a result, that looks much better. @Colin: Maybe you can test and use this hack. @Simon: I am not sure, in which direction I should look for solving this problem: 1. Avoid the tls problem a) Try to convince the dragonfly people, that it might be useful, to have something like the errno access wrapper in libc. b) If (1a) fails, try to create a patch for netbsd pkgsrc and/or ghc, so that an access wrapper will be created and installed as part of a ghc installation on dragonfly. 2. Fix the problem a) Try to add the necessary logic into the ghc runtime. b) Try to use the platforms loader. Have no clue, if and how (2a) or (2b) are possible, where to get some help or at least the necessary information. Goetz -------------- next part -------------- int *errno_ptr(void); -------------- next part -------------- #include #include int *errno_ptr(void) { return (&errno); } -------------- next part -------------- #! /bin/sh gcc -shared -o liberrno_ptr.so -I. -fPIC -O2 errno_ptr.c -------------- next part -------------- A non-text attachment was scrubbed... Name: liberrno_ptr.so Type: application/octet-stream Size: 4209 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091115/d6e1e43d/liberrno_ptr-0001.so -------------- next part -------------- diff -ru ghc-6.10.4/compiler/nativeGen/NCG.h ghc-6.10.4-dfly-5/compiler/nativeGen/NCG.h --- ghc-6.10.4/compiler/nativeGen/NCG.h 2009-07-14 19:10:51 +0200 +++ ghc-6.10.4-dfly-5/compiler/nativeGen/NCG.h 2009-11-11 17:53:20 +0100 @@ -38,6 +38,12 @@ # define IF_OS_freebsd(x,y) y #endif -- - - - - - - - - - - - - - - - - - - - - - +#if dragonfly_TARGET_OS +# define IF_OS_dragonfly(x,y) x +#else +# define IF_OS_dragonfly(x,y) y +#endif +-- - - - - - - - - - - - - - - - - - - - - - #if netbsd_TARGET_OS # define IF_OS_netbsd(x,y) x #else diff -ru ghc-6.10.4/configure ghc-6.10.4-dfly-5/configure --- ghc-6.10.4/configure 2009-07-14 19:24:26 +0200 +++ ghc-6.10.4-dfly-5/configure 2009-11-11 17:53:20 +0100 @@ -2307,6 +2307,15 @@ HostVendor_CPP='unknown' HostOS_CPP='freebsd' ;; +i[3456]86-*-dragonfly*) + HostPlatform=i386-unknown-dragonfly # hack again + TargetPlatform=i386-unknown-dragonfly + BuildPlatform=i386-unknown-dragonfly + HostPlatform_CPP='i386_unknown_dragonfly' + HostArch_CPP='i386' + HostVendor_CPP='unknown' + HostOS_CPP='dragonfly' + ;; i[3456]86-*-freebsd2*) # Older FreeBSDs are a.out HostPlatform=i386-unknown-freebsd2 # hack again TargetPlatform=i386-unknown-freebsd2 diff -ru ghc-6.10.4/configure.ac ghc-6.10.4-dfly-5/configure.ac --- ghc-6.10.4/configure.ac 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4-dfly-5/configure.ac 2009-11-11 17:53:20 +0100 @@ -260,6 +260,15 @@ HostVendor_CPP='unknown' HostOS_CPP='freebsd' ;; +i[[3456]]86-*-dragonfly*) + HostPlatform=i386-unknown-dragonfly # hack again + TargetPlatform=i386-unknown-dragonfly + BuildPlatform=i386-unknown-dragonfly + HostPlatform_CPP='i386_unknown_dragonfly' + HostArch_CPP='i386' + HostVendor_CPP='unknown' + HostOS_CPP='dragonfly' + ;; i[[3456]]86-*-freebsd2*) # Older FreeBSDs are a.out HostPlatform=i386-unknown-freebsd2 # hack again TargetPlatform=i386-unknown-freebsd2 diff -ru ghc-6.10.4/distrib/configure-bin.ac ghc-6.10.4-dfly-5/distrib/configure-bin.ac --- ghc-6.10.4/distrib/configure-bin.ac 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4-dfly-5/distrib/configure-bin.ac 2009-11-11 17:53:20 +0100 @@ -42,6 +42,8 @@ TargetPlatform=i386-unknown-freebsd2;; i[[3456]]86-*-freebsd[[3-9]]*) TargetPlatform=i386-unknown-freebsd;; +i[[3456]]86-*-dragonfly*) + TargetPlatform=i386-unknown-dragonfly;; i[[3456]]86-*-netbsd*) TargetPlatform=i386-unknown-netbsd;; i[[3456]]86-*-openbsd*) diff -ru ghc-6.10.4/driver/mangler/ghc-asm.lprl ghc-6.10.4-dfly-5/driver/mangler/ghc-asm.lprl --- ghc-6.10.4/driver/mangler/ghc-asm.lprl 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4-dfly-5/driver/mangler/ghc-asm.lprl 2009-11-11 17:53:20 +0100 @@ -160,12 +160,12 @@ $T_HDR_vector = "\.text\n\t\.align 4\n"; # NB: requires padding #--------------------------------------------------------# - } elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|gnu|freebsd|netbsd|openbsd|kfreebsdgnu)$/m ) { + } elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|gnu|freebsd|dragonfly|netbsd|openbsd|kfreebsdgnu)$/m ) { $T_STABBY = 0; # 1 iff .stab things (usually if a.out format) $T_US = ''; # _ if symbols have an underscore on the front $T_PRE_APP = # regexp that says what comes before APP/NO_APP - ($TargetPlatform =~ /-(linux|gnu|freebsd|netbsd|openbsd)$/m) ? '#' : '/' ; + ($TargetPlatform =~ /-(linux|gnu|freebsd|dragonfly|netbsd|openbsd)$/m) ? '#' : '/' ; $T_CONST_LBL = '^\.LC(\d+):$'; # regexp for what such a lbl looks like $T_POST_LBL = ':'; $T_X86_PRE_LLBL_PAT = '\.L'; @@ -216,7 +216,7 @@ $T_HDR_vector = "\.text\n\t\.align 8\n"; #--------------------------------------------------------# - } elsif ( $TargetPlatform =~ /^x86_64-.*-(linux|openbsd|freebsd|netbsd)$/m ) { + } elsif ( $TargetPlatform =~ /^x86_64-.*-(linux|openbsd|freebsd|dragonfly|netbsd)$/m ) { $T_STABBY = 0; # 1 iff .stab things (usually if a.out format) $T_US = ''; # _ if symbols have an underscore on the front diff -ru ghc-6.10.4/libraries/base/base.cabal ghc-6.10.4-dfly-5/libraries/base/base.cabal --- ghc-6.10.4/libraries/base/base.cabal 2009-07-14 19:13:10 +0200 +++ ghc-6.10.4-dfly-5/libraries/base/base.cabal 2009-11-14 22:40:17 +0100 @@ -164,12 +164,14 @@ cbits/dirUtils.c cbits/inputReady.c cbits/selectUtils.c - include-dirs: include + include-dirs: include /usr/pkg/include includes: HsBase.h install-includes: HsBase.h HsBaseConfig.h WCsubst.h dirUtils.h consUtils.h Typeable.h if os(windows) { extra-libraries: wsock32, user32, shell32 } + extra-lib-dirs: /usr/pkg/lib + extra-libraries: errno_ptr extensions: CPP -- We need to set the package name to base (without a version number) -- as it's magic. diff -ru ghc-6.10.4/libraries/base/include/HsBase.h ghc-6.10.4-dfly-5/libraries/base/include/HsBase.h --- ghc-6.10.4/libraries/base/include/HsBase.h 2009-07-14 19:13:10 +0200 +++ ghc-6.10.4-dfly-5/libraries/base/include/HsBase.h 2009-11-14 22:41:12 +0100 @@ -53,7 +53,7 @@ #endif #endif #if HAVE_ERRNO_H -#include +#include #endif #if HAVE_STRING_H #include @@ -220,8 +220,8 @@ # endif #endif -INLINE int __hscore_get_errno(void) { return errno; } -INLINE void __hscore_set_errno(int e) { errno = e; } +INLINE int __hscore_get_errno(void) { return *errno_ptr(); } +INLINE void __hscore_set_errno(int e) { *errno_ptr() = e; } #if !defined(_MSC_VER) INLINE int __hscore_s_isreg(mode_t m) { return S_ISREG(m); } diff -ru ghc-6.10.4/libraries/process/cbits/runProcess.c ghc-6.10.4-dfly-5/libraries/process/cbits/runProcess.c --- ghc-6.10.4/libraries/process/cbits/runProcess.c 2009-07-14 19:19:22 +0200 +++ ghc-6.10.4-dfly-5/libraries/process/cbits/runProcess.c 2009-11-14 22:43:20 +0100 @@ -13,6 +13,7 @@ #if !(defined(_MSC_VER) || defined(__MINGW32__) || defined(_WIN32)) #include "execvpe.h" +#include /* ---------------------------------------------------------------------------- UNIX versions @@ -215,7 +216,7 @@ else if (WIFSIGNALED(wstat)) { - errno = EINTR; + *errno_ptr() = EINTR; return -1; } else @@ -226,7 +227,7 @@ if (res == 0) return 0; - if (errno == ECHILD) + if (*errno_ptr() == ECHILD) { *pExitCode = 0; return 1; @@ -241,7 +242,7 @@ while (waitpid(handle, &wstat, 0) < 0) { - if (errno != EINTR) + if (*errno_ptr() != EINTR) { return -1; } diff -ru ghc-6.10.4/libraries/unix/System/Posix/Signals.hsc ghc-6.10.4-dfly-5/libraries/unix/System/Posix/Signals.hsc --- ghc-6.10.4/libraries/unix/System/Posix/Signals.hsc 2009-07-14 19:20:42 +0200 +++ ghc-6.10.4-dfly-5/libraries/unix/System/Posix/Signals.hsc 2009-11-11 17:53:20 +0100 @@ -292,7 +292,7 @@ raiseSignal :: Signal -> IO () raiseSignal sig = throwErrnoIfMinus1_ "raiseSignal" (c_raise sig) -#if defined(__GLASGOW_HASKELL__) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS)) +#if defined(__GLASGOW_HASKELL__) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS)) foreign import ccall unsafe "genericRaise" c_raise :: CInt -> IO CInt #else diff -ru ghc-6.10.4/libraries/unix/cbits/execvpe.c ghc-6.10.4-dfly-5/libraries/unix/cbits/execvpe.c --- ghc-6.10.4/libraries/unix/cbits/execvpe.c 2009-07-14 19:20:42 +0200 +++ ghc-6.10.4-dfly-5/libraries/unix/cbits/execvpe.c 2009-11-14 22:42:15 +0100 @@ -18,7 +18,7 @@ #include #include #include -#include +#include /* * We want the search semantics of execvp, but we want to provide our @@ -115,7 +115,7 @@ retry: (void) execve(bp, argv, envp); - switch (errno) { + switch (*errno_ptr()) { case EACCES: eacces = 1; break; @@ -147,9 +147,9 @@ } } if (eacces) - errno = EACCES; - else if (!errno) - errno = ENOENT; + *errno_ptr() = EACCES; + else if (!*errno_ptr()) + *errno_ptr() = ENOENT; done: if (path) free(path); diff -ru ghc-6.10.4/mk/config.mk.in ghc-6.10.4-dfly-5/mk/config.mk.in --- ghc-6.10.4/mk/config.mk.in 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4-dfly-5/mk/config.mk.in 2009-11-11 17:53:20 +0100 @@ -298,7 +298,7 @@ # Whether to include GHCi in the compiler. Depends on whether the RTS linker # has support for this OS/ARCH combination. -OsSupportsGHCi=$(strip $(patsubst $(HostOS_CPP), YES, $(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd netbsd openbsd darwin))) +OsSupportsGHCi=$(strip $(patsubst $(HostOS_CPP), YES, $(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd dragonfly netbsd openbsd darwin))) ArchSupportsGHCi=$(strip $(patsubst $(HostArch_CPP), YES, $(findstring $(HostArch_CPP), i386 x86_64 powerpc sparc sparc64))) ifeq "$(OsSupportsGHCi)$(ArchSupportsGHCi)" "YESYES" diff -ruN ghc-6.10.4-orig/rts/Linker.c ghc-6.10.4/rts/Linker.c --- ghc-6.10.4-orig/rts/Linker.c 2009-07-14 19:10:53 +0200 +++ ghc-6.10.4/rts/Linker.c 2009-11-27 09:49:16 +0100 @@ -61,12 +61,12 @@ #include #endif -#if defined(ia64_HOST_ARCH) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(ia64_HOST_ARCH) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) #define USE_MMAP #include #include -#if defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) #ifdef HAVE_UNISTD_H #include #endif @@ -74,7 +74,7 @@ #endif -#if defined(linux_HOST_OS) || defined(solaris2_HOST_OS) || defined(freebsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) +#if defined(linux_HOST_OS) || defined(solaris2_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS) || defined(openbsd_HOST_OS) # define OBJFORMAT_ELF #elif defined(cygwin32_HOST_OS) || defined (mingw32_HOST_OS) # define OBJFORMAT_PEi386 @@ -1327,7 +1327,7 @@ } else { if ((W_)result > 0x80000000) { // oops, we were given memory over 2Gb -#if defined(freebsd_HOST_OS) +#if defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS) // Some platforms require MAP_FIXED. This is normally // a bad idea, because MAP_FIXED will overwrite // existing mappings. diff -ru ghc-6.10.4/rts/RtsUtils.c ghc-6.10.4-dfly-5/rts/RtsUtils.c --- ghc-6.10.4/rts/RtsUtils.c 2009-07-14 19:10:52 +0200 +++ ghc-6.10.4-dfly-5/rts/RtsUtils.c 2009-11-11 17:53:20 +0100 @@ -461,7 +461,7 @@ * genericRaise(), rather than raise(3). */ int genericRaise(int sig) { -#if defined(THREADED_RTS) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS)) +#if defined(THREADED_RTS) && (defined(openbsd_HOST_OS) || defined(freebsd_HOST_OS) || defined(dragonfly_HOST_OS)) return pthread_kill(pthread_self(), sig); #else return raise(sig); --- ghc-6.10.4/libraries/base/cbits/inputReady.c-orig 2009-07-14 19:13:10 +0200 +++ ghc-6.10.4/libraries/base/cbits/inputReady.c 2009-11-14 23:24:53 +0100 @@ -7,6 +7,8 @@ /* select and supporting types is not Posix */ /* #include "PosixSource.h" */ #include "HsBase.h" +#include +#include /* * inputReady(fd) checks to see whether input is available on the file @@ -42,7 +44,7 @@ tv.tv_usec = (msecs % 1000) * 1000; while ((ready = select(maxfd, &rfd, &wfd, NULL, &tv)) < 0 ) { - if (errno != EINTR ) { + if (*errno_ptr() != EINTR ) { return -1; } } From luca_ciciriello at hotmail.com Sun Nov 15 07:46:07 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Sun Nov 15 07:21:45 2009 Subject: 32 to 64 bit problem In-Reply-To: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: Hi All. I think this is a not new question, but probably a missed it. On my MacOS X 10.5 (32 bit) I use GHC 6.10.4 (installed by Mac package GHC-6.10.4-i386.pkg) to build some halkell programs and all is fine. Yesterday I've updated the system to MacOS X 10.6 (64 bit) and now when I try to build the same programs I get the errors: /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: cannot do signed 4 byte relocation /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: cannot do signed 4 byte relocation Is there any solution to continue to use the installed GHC on the new 64 bit system? Thanks in advance for any answer. Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091115/545992cc/attachment.html From misc at alpheccar.org Sun Nov 15 07:49:36 2009 From: misc at alpheccar.org (alpheccar) Date: Sun Nov 15 07:25:13 2009 Subject: 32 to 64 bit problem In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1E9F7BBF-0109-4E9A-AF3E-14A97EF604D4@alpheccar.org> Hi, Change your /usr/bin/ghc to #!/bin/sh exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc -optc-m32 -opta-m32 -optl-m32 -B/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/. -dynload wrapped ${1+"$@"} The options -optc-m32 -opta-m32 -optl-m32 must be added. Christophe. > Hi All. > I think this is a not new question, but probably a missed it. > > On my MacOS X 10.5 (32 bit) I use GHC 6.10.4 (installed by Mac package GHC-6.10.4-i386.pkg) to build some halkell programs and all is fine. Yesterday I've updated the system to MacOS X 10.6 (64 bit) and now when I try to build the same programs I get the errors: > > /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: > 32-bit absolute addressing is not supported for x86-64 > > /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: > cannot do signed 4 byte relocation > > /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: > 32-bit absolute addressing is not supported for x86-64 > > /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: > cannot do signed 4 byte relocation > > Is there any solution to continue to use the installed GHC on the new 64 bit system? > > Thanks in advance for any answer. > > Luca > _______________________________________________ > 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/20091115/74512431/attachment.html From colin at colina.demon.co.uk Sun Nov 15 07:56:32 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Nov 15 07:32:12 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> (Goetz Isenmann's message of "Sun\, 15 Nov 2009 13\:42\:46 +0100") References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> <20091115124246.GA98551@horse.gocht-isenmann.de> Message-ID: >>>>> "Goetz" == Goetz Isenmann writes: Goetz> @Colin: Maybe you can test and use this hack. I won't have any time for the next three weeks (work then holiday). -- Colin Adams Preston Lancashire From luca_ciciriello at hotmail.com Sun Nov 15 08:03:22 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Sun Nov 15 07:39:01 2009 Subject: 32 to 64 bit problem In-Reply-To: <1E9F7BBF-0109-4E9A-AF3E-14A97EF604D4@alpheccar.org> References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> <1E9F7BBF-0109-4E9A-AF3E-14A97EF604D4@alpheccar.org> Message-ID: Thanks a lot Christophe. This solve my problem. Luca. On Nov 15, 2009, at 1:49 PM, alpheccar wrote: > Hi, > > Change your /usr/bin/ghc to > > #!/bin/sh > > exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc -optc-m32 -opta-m32 -optl-m32 -B/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/. -dynload wrapped ${1+"$@"} > > The options -optc-m32 -opta-m32 -optl-m32 must be added. > > Christophe. > > >> Hi All. >> I think this is a not new question, but probably a missed it. >> >> On my MacOS X 10.5 (32 bit) I use GHC 6.10.4 (installed by Mac package GHC-6.10.4-i386.pkg) to build some halkell programs and all is fine. Yesterday I've updated the system to MacOS X 10.6 (64 bit) and now when I try to build the same programs I get the errors: >> >> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: >> 32-bit absolute addressing is not supported for x86-64 >> >> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: >> cannot do signed 4 byte relocation >> >> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: >> 32-bit absolute addressing is not supported for x86-64 >> >> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: >> cannot do signed 4 byte relocation >> >> Is there any solution to continue to use the installed GHC on the new 64 bit system? >> >> Thanks in advance for any answer. >> >> Luca >> _______________________________________________ >> 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/20091115/7203fe6f/attachment.html From studt at dps.uibk.ac.at Sun Nov 15 08:07:13 2009 From: studt at dps.uibk.ac.at (Heiko Studt) Date: Sun Nov 15 07:42:55 2009 Subject: Ubuntu ghc6 package (german translation) Message-ID: To: glasgow-haskell-users Cc: ubuntu-devel-discuss Hi, the German translation of the ghc6 package description is some kind of wrong in the current Ubuntu 9.10: the technical term "lazy" is translated as "tr?ge" which means (slow, lazy) with an accent on slow. I don't know whether there is a default translation in the haskell universum (like "faul"). In my opinion the best would be to stay at the technical term "lazy". Possibly this mistake was done in other translations as well. Mit freundlichen Gr??en (With kindly regards) Heiko Studt From rmm-haskell at z.odi.ac Sun Nov 15 11:42:09 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Sun Nov 15 11:17:44 2009 Subject: 32 to 64 bit problem In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> <1E9F7BBF-0109-4E9A-AF3E-14A97EF604D4@alpheccar.org> Message-ID: Also /usr/bin/ghci, /usr/bin/runghc, /usr/bin/runhaskell to patch up all the holes. There may be others, also. Here is a reference to the original thread where someone found out SL broke GHC and then worked through temporarily resolving it: http://old.nabble.com/Snow-Leopard-Breaks-GHC-td25198347.html -Ross On Nov 15, 2009, at 8:03 AM, Luca Ciciriello wrote: > Thanks a lot Christophe. > This solve my problem. > > Luca. > > > On Nov 15, 2009, at 1:49 PM, alpheccar wrote: > >> Hi, >> >> Change your /usr/bin/ghc to >> >> #!/bin/sh >> >> exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc -optc-m32 -opta-m32 -optl-m32 -B/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/. -dynload wrapped ${1+"$@"} >> >> The options -optc-m32 -opta-m32 -optl-m32 must be added. >> >> Christophe. >> >> >>> Hi All. >>> I think this is a not new question, but probably a missed it. >>> >>> On my MacOS X 10.5 (32 bit) I use GHC 6.10.4 (installed by Mac package GHC-6.10.4-i386.pkg) to build some halkell programs and all is fine. Yesterday I've updated the system to MacOS X 10.6 (64 bit) and now when I try to build the same programs I get the errors: >>> >>> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: >>> 32-bit absolute addressing is not supported for x86-64 >>> >>> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1167:0: >>> cannot do signed 4 byte relocation >>> >>> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: >>> 32-bit absolute addressing is not supported for x86-64 >>> >>> /var/folders/vr/vrW2wwvtFKScalkhVEWujE+++TI/-Tmp-/ghc1613_0/ghc1613_0.s:1170:0: >>> cannot do signed 4 byte relocation >>> >>> Is there any solution to continue to use the installed GHC on the new 64 bit system? >>> >>> Thanks in advance for any answer. >>> >>> Luca >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091115/7cbc21db/attachment-0001.html From allbery at ece.cmu.edu Sun Nov 15 20:06:34 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Nov 15 19:42:19 2009 Subject: Porting to DragonFly BSD In-Reply-To: References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> Message-ID: <6F8C1A4F-0017-4F21-86E0-64D628D9DF37@ece.cmu.edu> On Nov 14, 2009, at 11:16 , Colin Paul Adams wrote: > This seems to work up to a point. That is I get no crashes in ghci. > > I do appear to have some line-feed problems. So if I type: > > Prelude> let x = 10 > > It appears to do nothing, but that is not the case - I can then > overtype with :t x and ghci responds with: > > x :: Integerxx = 10 > Prelude> > > So maybe this is a readline/haskelline issue? Known issue, yes, also seen on OSX. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091115/7104b7e1/PGP.bin From marlowsd at gmail.com Mon Nov 16 05:31:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 16 05:07:41 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091106232522.GA35866@horse.gocht-isenmann.de> <20091115124246.GA98551@horse.gocht-isenmann.de> Message-ID: <4B012A1C.7030908@gmail.com> On 15/11/2009 12:42, Goetz Isenmann wrote: > @Simon: I am not sure, in which direction I should look for solving > this problem: > > 1. Avoid the tls problem > a) Try to convince the dragonfly people, that it might be useful, > to have something like the errno access wrapper in libc. > b) If (1a) fails, try to create a patch for netbsd pkgsrc and/or > ghc, so that an access wrapper will be created and installed > as part of a ghc installation on dragonfly. You can write an access wrapper for errno, compile it into a .so shared object, and have GHCi load the .so. > 2. Fix the problem > a) Try to add the necessary logic into the ghc runtime. Have a look at what the system's linker does to resolve this reference: compile a C program, load it up into gdb, and disassemble the code. > b) Try to use the platforms loader. See above. Also when we have a dynamically linked GHCi this problem will partly go away for you (http://hackage.haskell.org/trac/ghc/ticket/3658). Cheers, Simon From Christian.Maeder at dfki.de Mon Nov 16 07:54:44 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Nov 16 07:30:18 2009 Subject: Ubuntu ghc6 package (german translation) In-Reply-To: References: Message-ID: <4B014B94.1060609@dfki.de> Heiko Studt schrieb: > To: glasgow-haskell-users > Cc: ubuntu-devel-discuss > > Hi, > > the German translation of the ghc6 package description is some kind of > wrong in the current Ubuntu 9.10: the technical term "lazy" is > translated as "tr?ge" which means (slow, lazy) with an accent on slow. I > don't know whether there is a default translation in the haskell > universum (like "faul"). The usual translation of "lazy evaluation" is "verz?gerte Auswertung". > In my opinion the best would be to stay at the > technical term "lazy". I agree, too. > Possibly this mistake was done in other translations as well. Yes, possibly on purpose (just to make it sound more funny) Cheers Christian From marlowsd at gmail.com Mon Nov 16 09:25:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 16 09:01:29 2009 Subject: Changes to the ticket system Message-ID: <4B0160EC.7010004@gmail.com> I've made a few changes to the ticket system today, in preparation for a push on cleaning up the ticket database (announcement to be made shortly). The changes are: 1. There's a new field "Type of Failure", with values None/Unknown Build failure Install failure GHC doesn't work at all Compile-time crash Runtime crash GHCi crash Incorrect result at runtime Compile-time performance bug Runtime performance bug Hopefully the values are self-explanatory. Setting this correctly will help us to focus on important tickets, and may help us automatically prioritize tickets in the future. 2. The "Severity" field has gone away. This field was intended to be used as a way for ticket submitters to communicate to us the importance of the bug to them, but in practice it wasn't clear how to use it, it hasn't been used consistently, and as a result we generally ignore it. The new "Type of Failure" is a much less ambiguous way to communicate some of the same information. 3. The "Difficulty" field has more sensible values representing a range of times, rather than just "1 hour" or "1 week": Unknown Easy (less than 1 hour) Moderate (less than a day) Difficult (2-5 days) Project (more than a week) Rocket Science Cheers, Simon From marlowsd at gmail.com Mon Nov 16 11:29:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 16 11:05:25 2009 Subject: Announcing the GHC Bug Sweep Message-ID: <4B017DFA.2060207@gmail.com> Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology! There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away. So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC. To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here http://hackage.haskell.org/trac/ghc/wiki/BugSweep including a list of suggestions for ways to make progress on a ticket. Cheers! Simon & the GHC team From twhitehead at gmail.com Mon Nov 16 14:28:19 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Nov 16 14:03:59 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091115124246.GA98551@horse.gocht-isenmann.de> Message-ID: <200911161428.26149.twhitehead@gmail.com> On November 15, 2009 07:42:46 Goetz Isenmann wrote: > I am still not sure, but the generated code might be ok > > 001e5565 <__hscore_get_errno>: > 1e5565: 55 push %ebp > 1e5566: 89 e5 mov %esp,%ebp > 1e5568: 65 a1 00 00 00 00 mov %gs:0x0,%eax > 1e556e: 8b 15 00 00 00 00 mov 0x0,%edx > 1e5574: 8b 04 10 mov (%eax,%edx,1),%eax > 1e5577: c9 leave > 1e5578: c3 ret > > The corresponding relocation info is > > 001e5570 R_386_TLS_IE errno Not sure about DragonFly, but under Linux that would be the TLS initial- executable model . It is assuming that the TLS memory has already been allocated and is at the location pointed to by the word at %gs:0x0. The default when working with position-independent code is the dynamic model. It has to go through ___tls_get_addr in order to give the dynamic loader a chance to allocate the thread local storage memory if this is the first access The GNU variant of the code for this model is 0x00 leal x@tlsgd(,%ebx,1),%eax 0x07 call ___tls_get_addr@plt It returns the address in eax. The two relocation are R_386_TLS_GD to load eax to point to the GOT entry for the desired symbol and R_386_PLT32 for the call ___tls_get_addr. For more details on the four different modes (each one is a successive optimization of the general dynamic model for cases where the symbol is in the some shared object and/or the TLS memory is know to be allocated) http://people.redhat.com/drepper/tls.pdf (pages 19, 27, 36, and 44 give the code for the fully generic and each combination of the optimizations respectively). Under gcc you can specify the model via the "-ftls-model=" option or on a per-identifier basis with __attribute__((tls_model(""))). Besides changing what code is emitted, it sets the STATIC_TLS flag in the dynamic section to tell force allocation at thread creation if required. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091116/1532e317/attachment.bin From ml at isaac.cedarswampstudios.org Mon Nov 16 15:52:31 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Nov 16 15:28:49 2009 Subject: Changes to the ticket system In-Reply-To: <4B0160EC.7010004@gmail.com> References: <4B0160EC.7010004@gmail.com> Message-ID: <4B01BB8F.1060504@isaac.cedarswampstudios.org> Simon Marlow wrote: > I've made a few changes to the ticket system today, in preparation for a > push on cleaning up the ticket database (announcement to be made > shortly). The changes are: > > 1. There's a new field "Type of Failure", with values > > None/Unknown > Build failure meaning failed building GHC, not that GHC building something failed. > Install failure > GHC doesn't work at all > Compile-time crash > Runtime crash > GHCi crash > Incorrect result at runtime > Compile-time performance bug > Runtime performance bug what about... Documentation is wrong. Type system is wrong (eg. rejects something that's correct), or similarly for syntax. Something strange that doesn't deserve its own category, but isn't "unknown" From twhitehead at gmail.com Mon Nov 16 17:32:00 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Nov 16 17:07:48 2009 Subject: Porting to DragonFly BSD In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091115124246.GA98551@horse.gocht-isenmann.de> Message-ID: <200911161732.12660.twhitehead@gmail.com> On November 15, 2009 07:42:46 Goetz Isenmann wrote: > 001e5565 <__hscore_get_errno>: > 1e5565: 55 push %ebp > 1e5566: 89 e5 mov %esp,%ebp > 1e5568: 65 a1 00 00 00 00 mov %gs:0x0,%eax > 1e556e: 8b 15 00 00 00 00 mov 0x0,%edx > 1e5574: 8b 04 10 mov (%eax,%edx,1),%eax > 1e5577: c9 leave > 1e5578: c3 ret > > The corresponding relocation info is > > 001e5570 R_386_TLS_IE errno > > > After some googling, and learning very little, I speclated that simply > > adding a third line for R_386_TLS_IE with the same action as the first > > line - just storing value, might work: > > > > case R_386_TLS_IE: *pP = value; break; > > > > This seems to work up to a point. That is I get no crashes in ghci. According to "ELF Handling For Thread-Local Storage", R_386_TLS_IE "resolves to the absolute address of the GOT [global offset table] slot" that is assigned to the TLS (thread local storage) symbol. http://people.redhat.com/drepper/tls.pdf (middle of page 37) The GOT slot is assigned a R_386_TLS_TPOFF relocation for the symbol. So, what you are suppose to get is: 1- While linking, the linker resolves the R_386_TLS_IE relocation by updating the instruction with the absolute address of the corresponding GOT slot. 2- While loading, the dynamic linker resolves the R_386_TLS_TPOFF relocation by updating the GOT slot to contain the offset of the symbol relative to the TLS pointer (which is stored at %gs:0x0). 3- The program then computes the address of the TLS variable by loading the TLS pointer (the "mov %gs:0x0,%eax" instruction) and adding to it the symbols TLS offset as stored in the GOT table (the updated "mov 0x0,%edx" instruction). Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091116/af9c0b9a/attachment-0001.bin From bos at serpentine.com Tue Nov 17 02:13:50 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Nov 17 01:49:18 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: On Fri, Nov 13, 2009 at 12:26 AM, Simon Peyton-Jones wrote: > My goal is for INLINE pragmas to be very predictable. I can't decode your > message enough to offer any insights; thank you Roman, who is closer to it, > for helping. > Things are considerably different with HEAD than with 6.10.4. HEAD is indeed spotting and exploiting many of the opportunities for inlining, while 6.10.4 is a bit of a morass. The difference is stark: my test program runs in 0.7 seconds with HEAD, and 1.2 with 6.10.4. Here's a rough table of my results: 6.10.4 8.39 seconds HEAD 0.50 HEAD* 0.50 6.10.4* 0.39 6.10.4** 0.34 The asterisk above denotes the removal of a single INLINE pragma from the text library. The doubled asterisk denotes the removal of a piece of indirection: instead of length defined as lengthI and both marked as INLINE, I manually inlined lengthI into the body of length. For your amusement, GNU "wc -m" takes 1.1 seconds to count the number of Unicode characters in the same file, so I think that our combination of performance and brevity is *wonderful*. Thanks! So HEAD is far better than 6.10.4 (yay!), but a little tweaking of the library code makes the 6.10.4 code faster again (boo!). The HEAD inliner seems, as you hoped, to be behaving far more predictably than its predecessor. If you'd like to investigate the remaining performance discrepancy between 6.10.4 and HEAD, I'll create a Trac ticket with instructions on how to reproduce my numbers. In the time between now and the release of 6.14, I wonder what to do. I'm building 6.12 to see how it fares, but my experience with 6.10 so far suggests that the behaviour of the 6.12 inliner will be fragile and difficult to understand, which is a bit of a shame. On that older code base, it seems that I can get really good fused performance, or okay unfused performance, but not both. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091117/4382dbfd/attachment.html From bos at serpentine.com Tue Nov 17 02:40:32 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Nov 17 02:16:03 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: Message-ID: On Fri, Nov 13, 2009 at 12:19 AM, Roman Leshchinskiy wrote: Let's see if I understand this correctly. In your code, decodeUtf8 calls > streamUtf8. They both get inlined into main but then unsafeChr8 does not. > Correct? > Here's what I see in the simplifer output with 6.10.4: the *unoptimised*body of streamUtf8 is being inlined into main, with many out-of-line functions called in its inner loop, then length is out-of-line applied to that result. I somehow stumbled on the idea of removing the INLINE annotation from next, >> and performance suddenly improved by a significant integer multiple. This >> caused the body of streamUtf8 to be inlined into my test program, as I >> hoped. >> > > Or are you saying that it's streamUtf8 that isn't getting inlined into > main? When I trimmed that INLINE out, the body of streamUtf8 was being inlined, but differently: all of the functions it had been calling out-of-line were now inlined. > Does changing the definition of length to > > length = id S.lengthI > > help? GHC used to have a bug in this area but I haven't been bitten by it > for quite some time. > That change makes no real difference. It changes the function called at that call site, but it's still out-of-line. > Also, I wonder how Stream.stream is defined. Is it strict in Text? If it > isn't, does making it strict help? It is strict in Text, yes. If you have a spare minute, perhaps you could try the HEAD with the new > inliner and see if that helps? Although I somewhat doubt it, to be honest. > I posted those numbers in a reply to Simon a little while ago. HEAD is generally much better than 6.10, which is great, but I'm still stuck with this mystery on versions of the compiler that people may actually be able to use :-\ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091117/bb1c07a2/attachment.html From simonpj at microsoft.com Tue Nov 17 03:24:44 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Nov 17 03:00:17 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC1084F3A77@DB3EX14MBXC310.europe.corp.microsoft.com> Bryan It?s good news that the HEAD is better. To be honest I?m not terribly enthusiastic about trying to nail down exactly what?s happening in 6.10 and 6.12 because, although they are indeed the compilers people will be using, it?s otherwise wasted work because the HEAD is so different. Can you try with 6.12 and see if you can find a recipe that does well enough? If you get desperate (ie there?s a huge perf bump that you can?t eliminate) then I?ll certainly try to help. Meanwhile, I don?t know why 6.10 is faster than HEAD (by 25% too) and I?d like to understand that. Can you submit a Trac ticket saying how to reproduce? You might need to bundle up the library too, to make sure we can reproduce it precisely. Thanks Simon From: Bryan O'Sullivan [mailto:bos@serpentine.com] Sent: 17 November 2009 07:14 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: Inliner behaviour - tiny changes lead to huge performance differences On Fri, Nov 13, 2009 at 12:26 AM, Simon Peyton-Jones > wrote: My goal is for INLINE pragmas to be very predictable. I can't decode your message enough to offer any insights; thank you Roman, who is closer to it, for helping. Things are considerably different with HEAD than with 6.10.4. HEAD is indeed spotting and exploiting many of the opportunities for inlining, while 6.10.4 is a bit of a morass. The difference is stark: my test program runs in 0.7 seconds with HEAD, and 1.2 with 6.10.4. Here's a rough table of my results: 6.10.4 8.39 seconds HEAD 0.50 HEAD* 0.50 6.10.4* 0.39 6.10.4** 0.34 The asterisk above denotes the removal of a single INLINE pragma from the text library. The doubled asterisk denotes the removal of a piece of indirection: instead of length defined as lengthI and both marked as INLINE, I manually inlined lengthI into the body of length. For your amusement, GNU "wc -m" takes 1.1 seconds to count the number of Unicode characters in the same file, so I think that our combination of performance and brevity is wonderful. Thanks! So HEAD is far better than 6.10.4 (yay!), but a little tweaking of the library code makes the 6.10.4 code faster again (boo!). The HEAD inliner seems, as you hoped, to be behaving far more predictably than its predecessor. If you'd like to investigate the remaining performance discrepancy between 6.10.4 and HEAD, I'll create a Trac ticket with instructions on how to reproduce my numbers. In the time between now and the release of 6.14, I wonder what to do. I'm building 6.12 to see how it fares, but my experience with 6.10 so far suggests that the behaviour of the 6.12 inliner will be fragile and difficult to understand, which is a bit of a shame. On that older code base, it seems that I can get really good fused performance, or okay unfused performance, but not both. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091117/b9e0b912/attachment-0001.html From ganesh.sittampalam at credit-suisse.com Tue Nov 17 04:49:54 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Nov 17 04:25:38 2009 Subject: [Haskell-cafe] Announcing the GHC Bug Sweep In-Reply-To: <4B017DFA.2060207@gmail.com> References: <4B017DFA.2060207@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCBA@ELON17P32001A.csfb.cs-group.com> Simon Marlow wrote: > This is a game for the whole family! We don't care how much progress > you make on each ticket, just as long as someone has taken a look and > moved the ticket forward in some way. For example, you might check > for duplicates, update the metadata, ask for more information from > the submitter, try to reproduce the bug against the latest version of > GHC. > > To claim a ticket all you have to do is remove it from the list on > the wiki. Full instructions are here > > http://hackage.haskell.org/trac/ghc/wiki/BugSweep > > including a list of suggestions for ways to make progress on a ticket. I've taken a look at a ticket and I think it should be closed as invalid, but I hesitate to make that decision on behalf of the GHC developers. What should I do in these circumstances, just draw it to your attention? I have added a comment to the ticket explaining why. http://hackage.haskell.org/trac/ghc/ticket/29 is the ticket in question. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From marlowsd at gmail.com Tue Nov 17 05:27:41 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 17 05:03:15 2009 Subject: [Haskell-cafe] Announcing the GHC Bug Sweep In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCBA@ELON17P32001A.csfb.cs-group.com> References: <4B017DFA.2060207@gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9FCBA@ELON17P32001A.csfb.cs-group.com> Message-ID: <4B027A9D.8020600@gmail.com> On 17/11/2009 09:49, Sittampalam, Ganesh wrote: > Simon Marlow wrote: > >> This is a game for the whole family! We don't care how much progress >> you make on each ticket, just as long as someone has taken a look and >> moved the ticket forward in some way. For example, you might check >> for duplicates, update the metadata, ask for more information from >> the submitter, try to reproduce the bug against the latest version of >> GHC. >> >> To claim a ticket all you have to do is remove it from the list on >> the wiki. Full instructions are here >> >> http://hackage.haskell.org/trac/ghc/wiki/BugSweep >> >> including a list of suggestions for ways to make progress on a ticket. > > I've taken a look at a ticket and I think it should be closed as > invalid, but I hesitate to make that decision on behalf of the GHC > developers. What should I do in these circumstances, just draw it to > your attention? I have added a comment to the ticket explaining why. > > http://hackage.haskell.org/trac/ghc/ticket/29 is the ticket in question. I agree. I think we kept the ticket open in the past because there are limited cases where you might be able to do something (e.g. if the type is known to be Int, then you know the properties of '<', '==' etc.), But that's far too vague for a ticket, and it's not clear that it's a good idea, being limited to built-in types and operations. Cheers, Simon From marlowsd at gmail.com Tue Nov 17 07:42:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 17 07:18:05 2009 Subject: Changes to the ticket system In-Reply-To: <4B01BB8F.1060504@isaac.cedarswampstudios.org> References: <4B0160EC.7010004@gmail.com> <4B01BB8F.1060504@isaac.cedarswampstudios.org> Message-ID: <4B029A37.5080103@gmail.com> On 16/11/2009 20:52, Isaac Dupree wrote: > Simon Marlow wrote: >> I've made a few changes to the ticket system today, in preparation for >> a push on cleaning up the ticket database (announcement to be made >> shortly). The changes are: >> >> 1. There's a new field "Type of Failure", with values >> >> None/Unknown >> Build failure > > meaning failed building GHC, not that GHC building something failed. Right. Changed to Building GHC failed >> Install failure Changed to Installing GHC failed >> GHC doesn't work at all >> Compile-time crash >> Runtime crash >> GHCi crash >> Incorrect result at runtime >> Compile-time performance bug >> Runtime performance bug > > what about... > > Documentation is wrong. Added "Documentation bug" > Type system is wrong (eg. rejects something that's correct), or > similarly for syntax. Good point: added "GHC rejects valid program" > Something strange that doesn't deserve its own category, but isn't > "unknown" such as? Cheers, Simon From matthijs at stdin.nl Tue Nov 17 07:45:35 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Tue Nov 17 07:21:04 2009 Subject: Changes to the ticket system In-Reply-To: <4B029A37.5080103@gmail.com> References: <4B0160EC.7010004@gmail.com> <4B01BB8F.1060504@isaac.cedarswampstudios.org> <4B029A37.5080103@gmail.com> Message-ID: <20091117124535.GR3418@katherina.student.utwente.nl> Hi Simon, > >Something strange that doesn't deserve its own category, but isn't > >"unknown" > > such as? I guess the distinction is between "I don't know in which of these categories the bug falls" and "I know that it does not fall in any of the above categories". e.g., "Unknown" vs "Other" ? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091117/5ef33095/attachment.bin From marlowsd at gmail.com Tue Nov 17 07:57:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 17 07:33:32 2009 Subject: Changes to the ticket system In-Reply-To: <20091117124535.GR3418@katherina.student.utwente.nl> References: <4B0160EC.7010004@gmail.com> <4B01BB8F.1060504@isaac.cedarswampstudios.org> <4B029A37.5080103@gmail.com> <20091117124535.GR3418@katherina.student.utwente.nl> Message-ID: <4B029DD7.9090805@gmail.com> On 17/11/2009 12:45, Matthijs Kooijman wrote: > Hi Simon, > >>> Something strange that doesn't deserve its own category, but isn't >>> "unknown" >> >> such as? > > I guess the distinction is between "I don't know in which of these categories > the bug falls" and "I know that it does not fall in any of the above > categories". e.g., "Unknown" vs "Other" ? Ok, I've added "Other". On balance I guess it's useful to know that "we've looked at this bug and decided that it doesn't fall into any of the other categories" vs. "it hasn't been assigned a category yet". Cheers, Simon From bos at serpentine.com Tue Nov 17 11:34:05 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Nov 17 11:09:32 2009 Subject: Inliner behaviour - tiny changes lead to huge performance differences In-Reply-To: <59543203684B2244980D7E4057D5FBC1084F3A77@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061C54F7@DB3EX14MBXC310.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC1084F3A77@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: On Tue, Nov 17, 2009 at 12:24 AM, Simon Peyton-Jones wrote: > To be honest I?m not terribly enthusiastic about trying to nail down > exactly what?s happening in 6.10 and 6.12 because, although they are indeed > the compilers people will be using, it?s otherwise wasted work because the > HEAD is so different. > I don't blame you! That's completely reasonable. > Can you try with 6.12 and see if you can find a recipe that does well > enough? If you get desperate (ie there?s a huge perf bump that you can?t > eliminate) then I?ll certainly try to help. > Will do, thanks. > Meanwhile, I don?t know why 6.10 is faster than HEAD (by 25% too) and I?d > like to understand that. Can you submit a Trac ticket saying how to > reproduce? You might need to bundle up the library too, to make sure we can > reproduce it precisely. > Certainly. The test program is tiny, but because of all the inlining in the library, the simplifier output is pretty fearsome. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091117/11f02990/attachment.html From marlowsd at gmail.com Wed Nov 18 06:55:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 06:30:50 2009 Subject: Announcing the GHC Bug Sweep In-Reply-To: <4B017DFA.2060207@gmail.com> References: <4B017DFA.2060207@gmail.com> Message-ID: <4B03E09F.9030406@gmail.com> On 16/11/2009 16:29, Simon Marlow wrote: > Help us weed the GHC ticket database, and get a warm fuzzy feeling from > contributing to Haskell core technology! > > There are currently ~750 tickets against GHC. Many of them have not been > looked at in months or years. Often when I go through old tickets I find > easy targets: bugs that have already been fixed, duplicates, bugs that > are not reproducible and the submitter has gone away. > > So the idea we have is this: do an incremental sweep of the whole > database, starting from the oldest tickets. Check each one, and try to > make some progress on it. If we get enough momentum going we can make > sure every ticket gets looked at every few months at the least. > > This is a game for the whole family! We don't care how much progress you > make on each ticket, just as long as someone has taken a look and moved > the ticket forward in some way. For example, you might check for > duplicates, update the metadata, ask for more information from the > submitter, try to reproduce the bug against the latest version of GHC. > > To claim a ticket all you have to do is remove it from the list on the > wiki. Full instructions are here > > http://hackage.haskell.org/trac/ghc/wiki/BugSweep > > including a list of suggestions for ways to make progress on a ticket. Thanks to all those who have helped out so far. The bug database now has fewer bugs than a couple of days ago (we're now at 738). It's not much, but we're heading in the right direction. Cheers, Simon From marlowsd at gmail.com Wed Nov 18 09:21:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 08:57:27 2009 Subject: ANNOUNCE: parallel-2.0.0.0 Message-ID: <4B040302.4070202@gmail.com> I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon --------------------------------------------------------------------- Version 1.x The original Strategies design is described in and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \"Runtime Support for Multicore Haskell\" . This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a -> Done@ and is now @a -> a@. This change helps to fix the space leak described in \"Runtime Support for Multicore Haskell\". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \"new\" value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead. From leather at cs.uu.nl Thu Nov 19 10:58:50 2009 From: leather at cs.uu.nl (Sean Leather) Date: Thu Nov 19 10:34:34 2009 Subject: GHC Trac says database is locked Message-ID: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> I tried to submit a comment on #2530 and got this error. Sean ------- Oops... *Trac detected an internal error:* If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team. Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below. TracGuide ? The Trac User and Administration Guide Python traceback Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/ticket/web_ui.py", line 279, in process_request self._do_save(req, db, ticket) File "/var/lib/python-support/python2.4/trac/ticket/web_ui.py", line 546, in _do_save cnum=internal_cnum): File "/var/lib/python-support/python2.4/trac/ticket/model.py", line 250, in save_changes (self.id, when, author, cnum, comment)) File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 237, in execute self.con._begin() File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 503, in _begin self.db.execute("BEGIN") OperationalError: database is locked -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091119/25bf9c11/attachment.html From leather at cs.uu.nl Thu Nov 19 12:34:01 2009 From: leather at cs.uu.nl (Sean Leather) Date: Thu Nov 19 12:09:43 2009 Subject: GHC Trac says database is locked In-Reply-To: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> References: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> Message-ID: <3c6288ab0911190934o79933e22j853b8fd34c3e363b@mail.gmail.com> On Thu, Nov 19, 2009 at 16:58, Sean Leather wrote: > I tried to submit a comment on #2530 and got this error. > Well, it works now, 1.5 hours later. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091119/8669c813/attachment.html From marlowsd at gmail.com Fri Nov 20 06:19:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 20 05:54:45 2009 Subject: GHC Trac says database is locked In-Reply-To: <3c6288ab0911190934o79933e22j853b8fd34c3e363b@mail.gmail.com> References: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> <3c6288ab0911190934o79933e22j853b8fd34c3e363b@mail.gmail.com> Message-ID: <4B067B39.8050807@gmail.com> On 19/11/2009 17:34, Sean Leather wrote: > > On Thu, Nov 19, 2009 at 16:58, Sean Leather wrote: > > I tried to submit a comment on #2530 and got this error. > > Well, it works now, 1.5 hours later. I think that happens when you clash with someone else doing something on the Trac. Usually I just retry and it works. Cheers, Simon From leather at cs.uu.nl Fri Nov 20 10:05:01 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Nov 20 09:40:40 2009 Subject: GHC Trac says database is locked In-Reply-To: <4B067B39.8050807@gmail.com> References: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> <3c6288ab0911190934o79933e22j853b8fd34c3e363b@mail.gmail.com> <4B067B39.8050807@gmail.com> Message-ID: <3c6288ab0911200705l6ae2d682x69e62e7d0f2fce8b@mail.gmail.com> > I tried to submit a comment on #2530 and got this error. >> >> Well, it works now, 1.5 hours later. >> > > I think that happens when you clash with someone else doing something on > the Trac. Usually I just retry and it works. > Thanks for the info. I retried probably 5 times within the space of 10 minutes. I suppose somebody could've been doing a large database operation... Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/c03830fa/attachment.html From igloo at earth.li Fri Nov 20 10:17:34 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Nov 20 09:52:52 2009 Subject: GHC Trac says database is locked In-Reply-To: <3c6288ab0911200705l6ae2d682x69e62e7d0f2fce8b@mail.gmail.com> References: <3c6288ab0911190758l6b996385ge2410a6a619364ed@mail.gmail.com> <3c6288ab0911190934o79933e22j853b8fd34c3e363b@mail.gmail.com> <4B067B39.8050807@gmail.com> <3c6288ab0911200705l6ae2d682x69e62e7d0f2fce8b@mail.gmail.com> Message-ID: <20091120151733.GA2520@matrix.chaos.earth.li> On Fri, Nov 20, 2009 at 04:05:01PM +0100, Sean Leather wrote: > > I tried to submit a comment on #2530 and got this error. > >> > >> Well, it works now, 1.5 hours later. > >> > > > > I think that happens when you clash with someone else doing something on > > the Trac. Usually I just retry and it works. > > > > Thanks for the info. I retried probably 5 times within the space of 10 > minutes. I suppose somebody could've been doing a large database > operation... I think what the error means is "Couldn't get a lock within 2 seconds" or something, which tends to mean that the machine is heavily loaded, e.g. backups were running. Thanks Ian From leather at cs.uu.nl Fri Nov 20 12:25:08 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Nov 20 12:00:47 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile Message-ID: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. Prelude> readFile "blah.txt" > "blah\nblah\nblah\nStopped at > _exception :: > e = GHC.Exception.SomeException (GHC.Exception.:DException _ > > (GHC.Show.:DShow ...) ....) > (GHC.IOBase.IOError Nothing > GHC.IOBase.EOF ....) > When I :set -fno-break-on-exception, I see no exception. I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/273eacd3/attachment.html From allbery at ece.cmu.edu Fri Nov 20 12:30:02 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Nov 20 12:05:32 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/27835756/PGP-0001.bin From pepeiborra at gmail.com Fri Nov 20 12:31:27 2009 From: pepeiborra at gmail.com (Jose Iborra) Date: Fri Nov 20 12:06:49 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> Message-ID: <410D708F-65CB-4597-91BE-72173A45E9AE@gmail.com> This is by design, -fbreak-on-exception breaks on any exception, be it captured or not, even on library code. I am not sure how readFile is implemented internally, but it probably reads from the file until an eoferror is thrown and then captures it gracefully. There is another debugger flag, -fbreak-on-error, which only breaks on unhandled exceptions. Is this what you want ? Regards, pepe On 20/11/2009, at 18:25, Sean Leather wrote: > Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. > > Prelude> readFile "blah.txt" > "blah\nblah\nblah\nStopped at > _exception :: > e = GHC.Exception.SomeException (GHC.Exception.:DException _ > (GHC.Show.:DShow ...) ....) > (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ....) > > When I :set -fno-break-on-exception, I see no exception. > > I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. > > Regards, > Sean > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bulat.ziganshin at gmail.com Fri Nov 20 12:42:07 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 20 12:17:32 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> Message-ID: <626754235.20091120204207@gmail.com> Hello Sean, Friday, November 20, 2009, 8:25:08 PM, you wrote: heh, the well known problem, i've seen it in Delphi. it even has a large list of exceptions to be ignored, but i think that better way will be to set this on a per-package and per-module basis > Perhaps I don't quite get how this works, but when I :set > -fbreak-on-exception in GHCi, I get an exception using readFile. It > reads the entire file and then throws what appears to be an EOF exception. Prelude>> readFile "blah.txt" > "blah\nblah\nblah\nStopped at > _exception :: > ? e = GHC.Exception.SomeException (GHC.Exception.:DException _ > ???????????????????????????????????????????????????????????? (GHC.Show.:DShow ...) ....) > ????????????????????????????????? (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ....) > When I :set -fno-break-on-exception, I see no exception. > I thought that lazy IO reads until it reaches the EOF, then closes > the file. This happens with both 6.10.1 and 6.8.3, so perhaps this > is standard stuff, and I'm missing something. > > Regards, > Sean > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From leather at cs.uu.nl Fri Nov 20 13:02:36 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Nov 20 12:38:14 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <410D708F-65CB-4597-91BE-72173A45E9AE@gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> <410D708F-65CB-4597-91BE-72173A45E9AE@gmail.com> Message-ID: <3c6288ab0911201002n529ce816yb421f5f569604c17@mail.gmail.com> On Fri, Nov 20, 2009 at 18:31, Jose Iborra wrote: > This is by design, -fbreak-on-exception breaks on any exception, be it > captured or not, even on library code. > Ah, that's what I missed. I would've guessed that it only breaks on uncaught exceptions. > I am not sure how readFile is implemented internally, but it probably reads > from the file until an eoferror is thrown and then captures it gracefully. > That's what I expect, too. I went fishing, but didn't find the exact spot where that happens within a few minutes. > There is another debugger flag, -fbreak-on-error, which only breaks on > unhandled exceptions. > Is this what you want ? > Probably. Now I see the difference in [1]. Thanks! [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#interactive-mode-options Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/d9ecccfb/attachment.html From leather at cs.uu.nl Fri Nov 20 13:06:58 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Nov 20 12:42:37 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <626754235.20091120204207@gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> <626754235.20091120204207@gmail.com> Message-ID: <3c6288ab0911201006y5309e1e8jaa839250a947c43e@mail.gmail.com> > heh, the well known problem, i've seen it in Delphi. it even has a large > list of exceptions to be ignored, but i think that better way will be > to set this on a per-package and per-module basis > Yes, that might be a better idea. In general though, it sounds as if -fbreak-on-error will be useful more often than -fbreak-on-exception. I was not aware of the former, and I had the latter in my .ghci. I think I'll remove it from there and just use the OPTIONS pragma when needed. > > Perhaps I don't quite get how this works, but when I :set > > -fbreak-on-exception in GHCi, I get an exception using readFile. It > > reads the entire file and then throws what appears to be an EOF > exception. > > Prelude>> readFile "blah.txt" > > "blah\nblah\nblah\nStopped at > > _exception :: > > e = GHC.Exception.SomeException (GHC.Exception.:DException _ > > > (GHC.Show.:DShow ...) ....) > > (GHC.IOBase.IOError Nothing > GHC.IOBase.EOF ....) > > > > When I :set -fno-break-on-exception, I see no exception. > > > I thought that lazy IO reads until it reaches the EOF, then closes > > the file. This happens with both 6.10.1 and 6.8.3, so perhaps this > > is standard stuff, and I'm missing something. > Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/dca255cd/attachment.html From allbery at ece.cmu.edu Fri Nov 20 13:12:19 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Nov 20 12:47:50 2009 Subject: :set -fbreak-on-exception in GHCi causes exception in readFile In-Reply-To: <3c6288ab0911201002n529ce816yb421f5f569604c17@mail.gmail.com> References: <3c6288ab0911200925k59f3a131y97ddbbb051d7d282@mail.gmail.com> <410D708F-65CB-4597-91BE-72173A45E9AE@gmail.com> <3c6288ab0911201002n529ce816yb421f5f569604c17@mail.gmail.com> Message-ID: <8ECB1043-2C16-4C86-A065-55A8CA5B9515@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091120/65362b65/PGP.bin From jgoerzen at complete.org Sat Nov 21 05:23:18 2009 From: jgoerzen at complete.org (jgoerzen@complete.org) Date: Sat Nov 21 04:58:37 2009 Subject: Mail System Error - Returned Mail Message-ID: <20091121095833.0BCAE324431@www.haskell.org> The original message was received at Sat, 21 Nov 2009 15:53:18 +0530 from [185.65.254.58] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to haskell.org.: 554 ... Mail quota exceeded 554 ... Service unavailable -------------- next part -------------- A non-text attachment was scrubbed... Name: attachment.zip Type: application/octet-stream Size: 29330 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091121/34a284d4/attachment-0001.obj From igloo at earth.li Sun Nov 22 12:53:07 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 22 12:28:18 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 Message-ID: <20091122175307.GA3953@matrix.chaos.earth.li> Hi all, We are pleased to announce the second release candidate for GHC 6.12.1: http://www.haskell.org/ghc/dist/6.12.1-rc2/ As well as the source tarball: ghc-6.12.0.20091121-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team From alexander.dunlap at gmail.com Sun Nov 22 16:35:00 2009 From: alexander.dunlap at gmail.com (Alex Dunlap) Date: Sun Nov 22 16:15:31 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122175307.GA3953@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: <20091122213500.GA15544@rhubarb.hsd1.wa.comcast.net> On Sun, Nov 22, 2009 at 05:53:07PM +0000, Ian Lynagh wrote: > > Hi all, > > We are pleased to announce the second release candidate for GHC 6.12.1: > > http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > As well as the source tarball: > ghc-6.12.0.20091121-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > 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 I installed this and tried to build the network package. Here's what happened: ---- SNIP ---- $ ~/usr/bin/ghc --make Setup.hs Linking Setup ... $ ./Setup configure Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) *** glibc detected *** ./Setup: double free or corruption (!prev): 0x09d33050 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b6c1)[0xb76446c1] /lib/libc.so.6(+0x6cf18)[0xb7645f18] /lib/libc.so.6(cfree+0x6d)[0xb7648f8d] /lib/libc.so.6(+0x1829c)[0xb75f129c] /lib/libc.so.6(iconv_close+0x1c)[0xb75f07ec] ./Setup[0x821f6b9] ======= Memory map: ======== 08048000-082be000 r-xp 00000000 fe:00 1603782 /home/alex/src/network-2.2.1.5/Setup 082be000-082ed000 rwxp 00275000 fe:00 1603782 /home/alex/src/network-2.2.1.5/Setup 082ed000-082f0000 rwxp 00000000 00:00 0 09cd1000-09d5c000 rwxp 00000000 00:00 0 [heap] b6f00000-b6f21000 rwxp 00000000 00:00 0 b6f21000-b7000000 ---p 00000000 00:00 0 b70c8000-b70e5000 r-xp 00000000 08:03 385336 /usr/lib/libgcc_s.so.1 b70e5000-b70e6000 rwxp 0001c000 08:03 385336 /usr/lib/libgcc_s.so.1 b7100000-b7300000 rwxp 00000000 00:00 0 b73bf000-b75bf000 r-xp 00000000 08:03 396531 /usr/lib/locale/locale-archive b75bf000-b75c0000 rwxp 00000000 00:00 0 b75c0000-b75d5000 r-xp 00000000 08:03 262160 /lib/libpthread-2.11.so b75d5000-b75d6000 r-xp 00014000 08:03 262160 /lib/libpthread-2.11.so b75d6000-b75d7000 rwxp 00015000 08:03 262160 /lib/libpthread-2.11.so b75d7000-b75d9000 rwxp 00000000 00:00 0 b75d9000-b7719000 r-xp 00000000 08:03 262169 /lib/libc-2.11.so b7719000-b771b000 r-xp 00140000 08:03 262169 /lib/libc-2.11.so b771b000-b771c000 rwxp 00142000 08:03 262169 /lib/libc-2.11.so b771c000-b771f000 rwxp 00000000 00:00 0 b771f000-b7743000 r-xp 00000000 08:03 262184 /lib/libm-2.11.so b7743000-b7744000 r-xp 00023000 08:03 262184 /lib/libm-2.11.so b7744000-b7745000 rwxp 00024000 08:03 262184 /lib/libm-2.11.so b7745000-b7746000 rwxp 00000000 00:00 0 b7746000-b7790000 r-xp 00000000 08:03 388239 /usr/lib/libgmp.so.3.5.0 b7790000-b7793000 rwxp 00049000 08:03 388239 /usr/lib/libgmp.so.3.5.0 b7793000-b7795000 r-xp 00000000 08:03 262188 /lib/libdl-2.11.so b7795000-b7796000 r-xp 00001000 08:03 262188 /lib/libdl-2.11.so b7796000-b7797000 rwxp 00002000 08:03 262188 /lib/libdl-2.11.so b7797000-b7799000 r-xp 00000000 08:03 262274 /lib/libutil-2.11.so b7799000-b779a000 r-xp 00001000 08:03 262274 /lib/libutil-2.11.so b779a000-b779b000 rwxp 00002000 08:03 262274 /lib/libutil-2.11.so b779b000-b77a2000 r-xp 00000000 08:03 262277 /lib/librt-2.11.so b77a2000-b77a3000 r-xp 00006000 08:03 262277 /lib/librt-2.11.so b77a3000-b77a4000 rwxp 00007000 08:03 262277 /lib/librt-2.11.so b77ba000-b77bc000 r-xp 00000000 08:03 184559 /usr/lib/gconv/UTF-32.so b77bc000-b77bd000 r-xp 00001000 08:03 184559 /usr/lib/gconv/UTF-32.so b77bd000-b77be000 rwxp 00002000 08:03 184559 /usr/lib/gconv/UTF-32.so b77be000-b77bf000 rwxp 00000000 00:00 0 b77bf000-b77c0000 r-xp 00000000 00:00 0 [vdso] b77c0000-b77dc000 r-xp 00000000 08:03 262276 /lib/ld-2.11.so b77dc000-b77dd000 r-xp 0001b000 08:03 262276 /lib/ld-2.11.so b77dd000-b77de000 rwxp 0001c000 08:03 262276 /lib/ld-2.11.so bf82d000-bf842000 rwxp 00000000 00:00 0 [stack] Aborted ---- SNIP ---- It works fine with the old GHC, so I assume this is some sort of problem with the new one. Alex From igloo at earth.li Sun Nov 22 17:26:02 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 22 17:01:14 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122213500.GA15544@rhubarb.hsd1.wa.comcast.net> References: <20091122175307.GA3953@matrix.chaos.earth.li> <20091122213500.GA15544@rhubarb.hsd1.wa.comcast.net> Message-ID: <20091122222602.GA7639@matrix.chaos.earth.li> On Sun, Nov 22, 2009 at 01:35:00PM -0800, Alex Dunlap wrote: > > I installed this and tried to build the network package. Here's what happened: > > ---- SNIP ---- > $ ~/usr/bin/ghc --make Setup.hs > Linking Setup ... > $ ./Setup configure > Warning: defaultUserHooks in Setup script is deprecated. > Configuring network-2.2.1.5... > Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) > *** glibc detected *** ./Setup: double free or corruption (!prev): 0x09d33050 *** Which ghc is in your path? It sounds like Cabal is finding your old GHC and trying to read its package database, but failing due to http://hackage.haskell.org/trac/hackage/ticket/609 Does that sound right? Thanks Ian From alexander.dunlap at gmail.com Sun Nov 22 17:58:27 2009 From: alexander.dunlap at gmail.com (Alex Dunlap) Date: Sun Nov 22 17:38:58 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122222602.GA7639@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> <20091122213500.GA15544@rhubarb.hsd1.wa.comcast.net> <20091122222602.GA7639@matrix.chaos.earth.li> Message-ID: <20091122225827.GB15544@rhubarb.hsd1.wa.comcast.net> On Sun, Nov 22, 2009 at 10:26:02PM +0000, Ian Lynagh wrote: > On Sun, Nov 22, 2009 at 01:35:00PM -0800, Alex Dunlap wrote: > > > > I installed this and tried to build the network package. Here's what happened: > > > > ---- SNIP ---- > > $ ~/usr/bin/ghc --make Setup.hs > > Linking Setup ... > > $ ./Setup configure > > Warning: defaultUserHooks in Setup script is deprecated. > > Configuring network-2.2.1.5... > > Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) > > *** glibc detected *** ./Setup: double free or corruption (!prev): 0x09d33050 *** > > Which ghc is in your path? It sounds like Cabal is finding your old GHC > and trying to read its package database, but failing due to > http://hackage.haskell.org/trac/hackage/ticket/609 > > Does that sound right? > > > Thanks > Ian > Yes, adding the new GHC to my PATH fixes the problem. It seems like that memory error is quite severe for trying to read a file with bad encoding?couldn't it fail with a simple "Bad encoding" exception or something? Alex From petersen at haskell.org Sun Nov 22 22:41:30 2009 From: petersen at haskell.org (Jens Petersen) Date: Sun Nov 22 22:16:40 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122175307.GA3953@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: <9436bffe0911221941w243b9fd2ve53274257aa75669@mail.gmail.com> > We are pleased to announce the second release candidate for GHC 6.12.1: > ? ?http://www.haskell.org/ghc/dist/6.12.1-rc2/ Thank you! > For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. Sorry if it is documented somewhere but what is the difference between them? Jens From korpios at korpios.com Sun Nov 22 23:00:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Sun Nov 22 22:36:15 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122175307.GA3953@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: On Nov 22, 2009, at 11:53 AM, Ian Lynagh wrote: > Hi all, > > We are pleased to announce the second release candidate for GHC 6.12.1: > > http://www.haskell.org/ghc/dist/6.12.1-rc2/ IIRC, an earlier 6.12 RC announcement mentioned that cabal-install wasn't working yet; has this been resolved? From inmachina at gmail.com Sun Nov 22 23:05:22 2009 From: inmachina at gmail.com (Paulo Tanimoto) Date: Sun Nov 22 22:40:52 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: On Sun, Nov 22, 2009 at 10:00 PM, Tom Tobin wrote: > On Nov 22, 2009, at 11:53 AM, Ian Lynagh wrote: >> Hi all, >> >> We are pleased to announce the second release candidate for GHC 6.12.1: >> >> ? ?http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > IIRC, an earlier 6.12 RC announcement mentioned that cabal-install wasn't working yet; has this been resolved? > I just got to try it here and it seems to work. I had to install a few packages manually, but nothing hard. I'm on Ubuntu 9.10 64-bit. I used cabal-install from the darcs repository -- I didn't try with the stable version, so I don't know if it would work. I've been compiling some of my code and everything worked so far. Thanks, GHC HQ! Paulo From anotheraddress at gmx.de Mon Nov 23 01:53:55 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Mon Nov 23 01:29:11 2009 Subject: Hsc2Hs/hGetContents encodings error (was: ANNOUNCE: GHC 6.12.1 Release Candidate 2) In-Reply-To: <20091122175307.GA3953@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: <200911230753.55244.anotheraddress@gmx.de> Hi, I don't think this is the same problem as the one mentioned by Alex (installing `network' works for me): {---------------------------------------------- $ cabal install X11 Resolving dependencies... Configuring X11-1.4.6.1... configure: WARNING: unrecognized options: --with-compiler checking for gcc... gcc checking for C compiler default output file name... a.out [... configure stuff omitted...] checking for X11/cursorfont.h... yes configure: creating ./config.status config.status: creating config.mk config.status: creating X11.buildinfo config.status: creating include/HsX11Config.h config.status: creating include/X11_extras_config.h configure: WARNING: unrecognized options: --with-compiler Preprocessing library X11-1.4.6.1... hsc2hs: Graphics/X11/Xlib/Extras.hsc: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) cabal: Error: some packages failed to install: X11-1.4.6.1 failed during the building phase. The exception was: ExitFailure 1 ----------------------------------------------} Converting the offending file (Extras.hsc) to UTF-8 manually solves it: {---------------------------------------------- $ file Extras.hsc Extras.hsc: ISO-8859 English text $ temp $ mv temp Extras.hsc $ cd ../../.. $ cabal install [OK] ----------------------------------------------} Greetings, Daniel On Sunday 22 November 2009 18:53:07 Ian Lynagh wrote: > Hi all, > > We are pleased to announce the second release candidate for GHC 6.12.1: > > http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > As well as the source tarball: > ghc-6.12.0.20091121-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > 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 > From anotheraddress at gmx.de Mon Nov 23 02:02:13 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Mon Nov 23 01:37:28 2009 Subject: Hsc2Hs/hGetContents encodings error (was: ANNOUNCE: GHC 6.12.1 Release Candidate 2) In-Reply-To: <200911230753.55244.anotheraddress@gmx.de> References: <20091122175307.GA3953@matrix.chaos.earth.li> <200911230753.55244.anotheraddress@gmx.de> Message-ID: <200911230802.13460.anotheraddress@gmx.de> P.S.: Locale is UTF-8, I guess hGetContents gets the default encoding from the locale now? On Monday 23 November 2009 07:53:55 Daniel Sch?ssler wrote: > Hi, > > I don't think this is the same problem as the one mentioned by Alex > (installing `network' works for me): > > {---------------------------------------------- > $ cabal install X11 > > Resolving dependencies... > Configuring X11-1.4.6.1... > configure: WARNING: unrecognized options: --with-compiler > checking for gcc... gcc > checking for C compiler default output file name... a.out > > [... configure stuff omitted...] > > checking for X11/cursorfont.h... yes > configure: creating ./config.status > config.status: creating config.mk > config.status: creating X11.buildinfo > config.status: creating include/HsX11Config.h > config.status: creating include/X11_extras_config.h > configure: WARNING: unrecognized options: --with-compiler > Preprocessing library X11-1.4.6.1... > hsc2hs: Graphics/X11/Xlib/Extras.hsc: hGetContents: invalid argument > (Invalid or incomplete multibyte or wide character) > cabal: Error: some packages failed to install: > X11-1.4.6.1 failed during the building phase. The exception was: > ExitFailure 1 > ----------------------------------------------} > > > Converting the offending file (Extras.hsc) to UTF-8 manually solves it: > > > {---------------------------------------------- > > $ file Extras.hsc > Extras.hsc: ISO-8859 English text > > $ temp > $ mv temp Extras.hsc > $ cd ../../.. > $ cabal install > [OK] > > ----------------------------------------------} > > > > Greetings, > Daniel > > On Sunday 22 November 2009 18:53:07 Ian Lynagh wrote: > > Hi all, > > > > We are pleased to announce the second release candidate for GHC 6.12.1: > > > > http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > > > As well as the source tarball: > > ghc-6.12.0.20091121-src.tar.bz2 > > there are installers for Windows (i386) and OS X (i386), and binary > > distributions for x86_64/Linux and i386/Linux. For the Linux binary > > distributions, the "linux-n" tarballs are recommended over the "linux" > > tarballs. > > > > > > Please test as much as possible; bugs are much cheaper if we find them > > before the release! > > > > > > 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 mechvel at botik.ru Mon Nov 23 08:26:44 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Nov 23 08:13:59 2009 Subject: testing 6.12.1-pre Message-ID: <20091123132644.GA29768@scico.botik.ru> Dear GHC team, I have tested ghc-6.12.0.20091121 by 1) installing its binary and making and running the DoCon and Dumatel programs, 2) making it from source by its binary, making and running on it the DoCon and Dumatel programs. It looks all right. I skipped profiling. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From petersen at haskell.org Mon Nov 23 09:39:26 2009 From: petersen at haskell.org (Jens Petersen) Date: Mon Nov 23 09:14:36 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122175307.GA3953@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: <9436bffe0911230639s3cfc41c3t562e2d5b1554a729@mail.gmail.com> > ? ?http://www.haskell.org/ghc/dist/6.12.1-rc2/ Here is a development test build for Fedora: http://koji.fedoraproject.org/koji/taskinfo?taskID=1824814 with shared libraries. :-) BTW I already succeeded in building a dynamically linked cabal-install rpm locally. For a comparison of size: 1.2M 2009-11-19 23:33 cabal-install-0.7.5-0.fc13.x86_64.rpm (static) 319K 2009-11-23 18:52 cabal-install-0.7.5-1.fc13.x86_64.rpm (dynamic) With thanks and congratulations to those who finally gave us working shared libraries on Linux! :) Happily, Jens ps This should all be landing in fedora development (rawhide) for F13 before too long. From marlowsd at gmail.com Mon Nov 23 10:20:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 23 09:55:56 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091122225827.GB15544@rhubarb.hsd1.wa.comcast.net> References: <20091122175307.GA3953@matrix.chaos.earth.li> <20091122213500.GA15544@rhubarb.hsd1.wa.comcast.net> <20091122222602.GA7639@matrix.chaos.earth.li> <20091122225827.GB15544@rhubarb.hsd1.wa.comcast.net> Message-ID: <4B0AA848.7040205@gmail.com> On 22/11/09 22:58, Alex Dunlap wrote: > On Sun, Nov 22, 2009 at 10:26:02PM +0000, Ian Lynagh wrote: >> On Sun, Nov 22, 2009 at 01:35:00PM -0800, Alex Dunlap wrote: >>> >>> I installed this and tried to build the network package. Here's what happened: >>> >>> ---- SNIP ---- >>> $ ~/usr/bin/ghc --make Setup.hs >>> Linking Setup ... >>> $ ./Setup configure >>> Warning: defaultUserHooks in Setup script is deprecated. >>> Configuring network-2.2.1.5... >>> Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) >>> *** glibc detected *** ./Setup: double free or corruption (!prev): 0x09d33050 *** >> >> Which ghc is in your path? It sounds like Cabal is finding your old GHC >> and trying to read its package database, but failing due to >> http://hackage.haskell.org/trac/hackage/ticket/609 >> >> Does that sound right? >> >> >> Thanks >> Ian >> > > Yes, adding the new GHC to my PATH fixes the problem. It seems like that memory error is quite severe for trying to read a file with bad encoding?couldn't it fail with a simple "Bad encoding" exception or something? I'm surprised by the memory error too. It may be a real bug. Would you mind reporting it, including the full output of 'ghc-pkg dump' for the GHC that was in your PATH in the above? Cheers, Simon From marlowsd at gmail.com Mon Nov 23 10:26:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 23 10:01:38 2009 Subject: Hsc2Hs/hGetContents encodings error In-Reply-To: <200911230753.55244.anotheraddress@gmx.de> References: <20091122175307.GA3953@matrix.chaos.earth.li> <200911230753.55244.anotheraddress@gmx.de> Message-ID: <4B0AA99B.2020705@gmail.com> On 23/11/09 06:53, Daniel Sch?ssler wrote: > Hi, > > I don't think this is the same problem as the one mentioned by Alex > (installing `network' works for me): > > {---------------------------------------------- > $ cabal install X11 > > Resolving dependencies... > Configuring X11-1.4.6.1... > configure: WARNING: unrecognized options: --with-compiler > checking for gcc... gcc > checking for C compiler default output file name... a.out > > [... configure stuff omitted...] > > checking for X11/cursorfont.h... yes > configure: creating ./config.status > config.status: creating config.mk > config.status: creating X11.buildinfo > config.status: creating include/HsX11Config.h > config.status: creating include/X11_extras_config.h > configure: WARNING: unrecognized options: --with-compiler > Preprocessing library X11-1.4.6.1... > hsc2hs: Graphics/X11/Xlib/Extras.hsc: hGetContents: invalid argument (Invalid > or incomplete multibyte or wide character) This is partly the result of new behaviour in 6.12.1RC2. hGetContents now throws an exception if an I/O error is encountered, in a deliberate diversion from the Haskell 98 spec which says that it should terminate the stream silently. We decided that this was the pertinent thing to do given that people are quite likely to encounter decoding errors with the new Unicode-aware I/O library, and silently ignoring the error would lead to large amounts of confusion. > cabal: Error: some packages failed to install: > X11-1.4.6.1 failed during the building phase. The exception was: > ExitFailure 1 > ----------------------------------------------} > > > Converting the offending file (Extras.hsc) to UTF-8 manually solves it: Thanks to the wonderfully precise error message, you were able to fix the problem and get going again. I declare this a victory :) Cheers, Simon From marlowsd at gmail.com Mon Nov 23 10:27:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 23 10:03:07 2009 Subject: Hsc2Hs/hGetContents encodings error In-Reply-To: <200911230802.13460.anotheraddress@gmx.de> References: <20091122175307.GA3953@matrix.chaos.earth.li> <200911230753.55244.anotheraddress@gmx.de> <200911230802.13460.anotheraddress@gmx.de> Message-ID: <4B0AA9FA.2060107@gmail.com> On 23/11/09 07:02, Daniel Sch?ssler wrote: > P.S.: > > Locale is UTF-8, I guess hGetContents gets the default encoding from the > locale now? Yes it does. It just occurred to me that hsc2hs should probably be setting the encoding to UTF8 explicitly before reading Haskell source files. Cheers, Simon > > > On Monday 23 November 2009 07:53:55 Daniel Sch?ssler wrote: >> Hi, >> >> I don't think this is the same problem as the one mentioned by Alex >> (installing `network' works for me): >> >> {---------------------------------------------- >> $ cabal install X11 >> >> Resolving dependencies... >> Configuring X11-1.4.6.1... >> configure: WARNING: unrecognized options: --with-compiler >> checking for gcc... gcc >> checking for C compiler default output file name... a.out >> >> [... configure stuff omitted...] >> >> checking for X11/cursorfont.h... yes >> configure: creating ./config.status >> config.status: creating config.mk >> config.status: creating X11.buildinfo >> config.status: creating include/HsX11Config.h >> config.status: creating include/X11_extras_config.h >> configure: WARNING: unrecognized options: --with-compiler >> Preprocessing library X11-1.4.6.1... >> hsc2hs: Graphics/X11/Xlib/Extras.hsc: hGetContents: invalid argument >> (Invalid or incomplete multibyte or wide character) >> cabal: Error: some packages failed to install: >> X11-1.4.6.1 failed during the building phase. The exception was: >> ExitFailure 1 >> ----------------------------------------------} >> >> >> Converting the offending file (Extras.hsc) to UTF-8 manually solves it: >> >> >> {---------------------------------------------- >> >> $ file Extras.hsc >> Extras.hsc: ISO-8859 English text >> >> $temp >> $ mv temp Extras.hsc >> $ cd ../../.. >> $ cabal install >> [OK] >> >> ----------------------------------------------} >> >> >> >> Greetings, >> Daniel >> >> On Sunday 22 November 2009 18:53:07 Ian Lynagh wrote: >>> Hi all, >>> >>> We are pleased to announce the second release candidate for GHC 6.12.1: >>> >>> http://www.haskell.org/ghc/dist/6.12.1-rc2/ >>> >>> As well as the source tarball: >>> ghc-6.12.0.20091121-src.tar.bz2 >>> there are installers for Windows (i386) and OS X (i386), and binary >>> distributions for x86_64/Linux and i386/Linux. For the Linux binary >>> distributions, the "linux-n" tarballs are recommended over the "linux" >>> tarballs. >>> >>> >>> Please test as much as possible; bugs are much cheaper if we find them >>> before the release! >>> >>> >>> 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 >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Mon Nov 23 11:53:55 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Nov 23 11:29:04 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <9436bffe0911221941w243b9fd2ve53274257aa75669@mail.gmail.com> References: <20091122175307.GA3953@matrix.chaos.earth.li> <9436bffe0911221941w243b9fd2ve53274257aa75669@mail.gmail.com> Message-ID: <20091123165355.GA13837@matrix.chaos.earth.li> On Mon, Nov 23, 2009 at 01:41:30PM +1000, Jens Petersen wrote: > > We are pleased to announce the second release candidate for GHC 6.12.1: > > ? ?http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > Thank you! > > > For the Linux binary > > distributions, the "linux-n" tarballs are recommended over the "linux" > > tarballs. > > Sorry if it is documented somewhere but what is the difference between them? The bindists without the -n are built by the nightly builders on something like a RedHat system. This has 2 libraries for ncurses: libncurses and libtinfo. Other systems, such as Debian, only have one library for ncurses: libncurses. If you try to use that bindist on such a system, then it will fail because it can't find libtinfo. The -n bindists are built manually on Debian, so only depend on libncurses. These binaries also work on systems with the split ncurses library. If anyone knows of an easy way to get the buildbots to output portable binaries, please let us know! Thanks Ian From anotheraddress at gmx.de Mon Nov 23 22:16:38 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Mon Nov 23 21:51:49 2009 Subject: "ghc-paths" package build error with GHC 6.12.1 RC2 Message-ID: <200911240416.39015.anotheraddress@gmx.de> Hi, see below. Greetings, Daniel $ cabal install ghc-paths Resolving dependencies... [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/dist/setup/Main.o ) /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: `preMakefile' is not a (visible) constructor field name cabal: Error: some packages failed to install: ghc-paths-0.1.0.5 failed during the configure step. The exception was: ExitFailure 1 From secludedsage at gmail.com Tue Nov 24 04:26:18 2009 From: secludedsage at gmail.com (=?UTF-8?B?56ug5a6P5Lmd?=) Date: Tue Nov 24 04:01:25 2009 Subject: Build ghc with hardened toolchain Message-ID: <955db7060911240126w10f38fdo9a51a32af3ba9c37@mail.gmail.com> Hello. I am using Gentoo with hardened features enabled. Recently i want to try yi-editor. I built GHC with emerge and nothing strange happened. However, I got following error information when i built yi: Building yi-0.6.1... [ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) [ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) [ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o ) [ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs, dist/build/Data/DelayList.o ) [ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o ) [ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs, dist/build/Data/Prototype.o ) [ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs, dist/build/HConf/Utils.o ) [ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs, dist/build/HConf/Paths.o ) [ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, dist/build/Paths_yi.o ) [ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o ) [ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, dist/build/Yi/Char/Unicode.o ) [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, dist/build/Yi/UI/Common.o-boot ) [ 14 of 119] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o ) [ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o ) [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, dist/build/Yi/Keymap/Completion.o ) [ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, dist/build/Yi/Editor.o-boot ) [ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o ) [ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs, dist/build/Yi/Prelude.o ) [ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs, dist/build/Yi/Dynamic.o ) [ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o ) [ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs, dist/build/Yi/Interact.o ) [ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, dist/build/Yi/Keymap.o-boot ) [ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o ) [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, dist/build/Yi/Style/Library.o ) [ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs, dist/build/Yi/Interpreter.o ) [ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs, dist/build/Shim/Utils.o ) [ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, dist/build/Shim/CabalInfo.o ) [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, dist/build/Yi/Buffer/Misc.o-boot ) [ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, dist/build/Yi/Buffer/Basic.o ) ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' Loading package ghc-prim ... linking ... ghc: unable to load package `ghc-prim' I notice that Gentoo has already done some works about disabling hardened features temporarily for Haskell. Here is the mk/build.mk: # Gentoo changes docdir = /usr/share/doc/ghc-6.10.4 htmldir = /usr/share/doc/ghc-6.10.4 SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl-nopie -optc-fno-PIE -opta-Wa,--noexecstack SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack XMLDocWays= HADDOCK_DOCS=NO SRC_HC_OPTS+=-w While talking on IRC (#gentoo-haskell and #haskell) I was told that this might be caused by a broken GHC. Although above shows that PIE are disabled, ghc-prim (maybe at least) is still built with PIE enabled. According to advice from #gentoo-haskell, I was told to seek for help here. I also submit a bug about it as #3668. (Very sorry that I ask everywhere. Forgive me, but until yesterday I forgot my password of my gmail and cannot join a mailling-list.) Thank igloo told me add "-nopie" in SRC_LD_OPTS. I did but still failed: ------------------------------------------------------------------------ == make boot - --no-print-directory -r --jobserver-fds=3,4 - --jobserver-fds=3,4 -j; in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/utils/genapply ------------------------------------------------------------------------ /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp -c GenApply.hs -o GenApply.o -ohi GenApply.hi /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -M -dep-makefile .depend -osuf o -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp GenApply.hs /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -o genapply -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp -nopie GenApply.o ghc: unrecognised flags: -nopie Usage: For basic information, try the `--help' option. make[2]: *** [genapply] Error 1 Failed making boot in genapply: 1 make[1]: *** [boot] Error 1 make: *** [stage1] Error 1 I am surprised that why "-nopie" is sent here. Since wiki only told me to see config.mk.in and it does not have any examples, I have no idea about SRC_LD_OPTS. I need help how to completely disable PIE for GHC. Thank you very much. Hongjiu Zhang From marlowsd at gmail.com Tue Nov 24 06:08:24 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 24 05:43:36 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: <20091123165355.GA13837@matrix.chaos.earth.li> References: <20091122175307.GA3953@matrix.chaos.earth.li> <9436bffe0911221941w243b9fd2ve53274257aa75669@mail.gmail.com> <20091123165355.GA13837@matrix.chaos.earth.li> Message-ID: <4B0BBEA8.4010506@gmail.com> On 23/11/2009 16:53, Ian Lynagh wrote: > On Mon, Nov 23, 2009 at 01:41:30PM +1000, Jens Petersen wrote: >>> We are pleased to announce the second release candidate for GHC 6.12.1: >>> http://www.haskell.org/ghc/dist/6.12.1-rc2/ >> >> Thank you! >> >>> For the Linux binary >>> distributions, the "linux-n" tarballs are recommended over the "linux" >>> tarballs. >> >> Sorry if it is documented somewhere but what is the difference between them? > > The bindists without the -n are built by the nightly builders on > something like a RedHat system. This has 2 libraries for ncurses: > libncurses and libtinfo. > > Other systems, such as Debian, only have one library for ncurses: > libncurses. If you try to use that bindist on such a system, then it > will fail because it can't find libtinfo. > > The -n bindists are built manually on Debian, so only depend on > libncurses. These binaries also work on systems with the split ncurses > library. If they work everywhere, then we should probably just supply the -n versions (and remove the -n suffix) to avoid confusion. Next time I reinstall our nightly builder machine I'll put some Debian derivative on it. Cheers, Simon From marlowsd at gmail.com Tue Nov 24 06:16:18 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 24 05:51:30 2009 Subject: "ghc-paths" package build error with GHC 6.12.1 RC2 In-Reply-To: <200911240416.39015.anotheraddress@gmx.de> References: <200911240416.39015.anotheraddress@gmx.de> Message-ID: <4B0BC082.3030206@gmail.com> On 24/11/2009 03:16, Daniel Sch?ssler wrote: > Hi, > > see below. > > Greetings, > Daniel > > > > $ cabal install ghc-paths > > Resolving dependencies... > [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- > paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- > paths-0.1.0.5/dist/setup/Main.o ) > > /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: > `preMakefile' is not a (visible) constructor field name > cabal: Error: some packages failed to install: > ghc-paths-0.1.0.5 failed during the configure step. The exception was: > ExitFailure 1 Fixed version 0.1.0.6 uploaded to Hackage. Thanks for the report! Cheers, Simon From anotheraddress at gmx.de Tue Nov 24 06:43:28 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Tue Nov 24 06:18:36 2009 Subject: "ghc-paths" package build error with GHC 6.12.1 RC2 In-Reply-To: <4B0BC082.3030206@gmail.com> References: <200911240416.39015.anotheraddress@gmx.de> <4B0BC082.3030206@gmail.com> Message-ID: <200911241243.28466.anotheraddress@gmx.de> Thanks :) Greetings, Daniel On Tuesday 24 November 2009 12:16:18 Simon Marlow wrote: > On 24/11/2009 03:16, Daniel Sch?ssler wrote: > > Hi, > > > > see below. > > > > Greetings, > > Daniel > > > > > > > > $ cabal install ghc-paths > > > > Resolving dependencies... > > [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- > > paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- > > paths-0.1.0.5/dist/setup/Main.o ) > > > > /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: > > `preMakefile' is not a (visible) constructor field name > > cabal: Error: some packages failed to install: > > ghc-paths-0.1.0.5 failed during the configure step. The exception was: > > ExitFailure 1 > > Fixed version 0.1.0.6 uploaded to Hackage. Thanks for the report! > > Cheers, > Simon > From duncan.coutts at googlemail.com Tue Nov 24 09:40:26 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Nov 24 09:15:38 2009 Subject: ANNOUNCE: GHC 6.12.1 Release Candidate 2 In-Reply-To: References: <20091122175307.GA3953@matrix.chaos.earth.li> Message-ID: <1259073626.4896.49979.camel@localhost> On Sun, 2009-11-22 at 22:00 -0600, Tom Tobin wrote: > On Nov 22, 2009, at 11:53 AM, Ian Lynagh wrote: > > Hi all, > > > > We are pleased to announce the second release candidate for GHC 6.12.1: > > > > http://www.haskell.org/ghc/dist/6.12.1-rc2/ > > IIRC, an earlier 6.12 RC announcement mentioned that cabal-install > wasn't working yet; has this been resolved? The current darcs version of cabal-install works with 6.12. darcs get --partial http://darcs.haskell.org/cabal-install/ Duncan From malcolm.wallace at cs.york.ac.uk Tue Nov 24 23:56:48 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 24 23:33:50 2009 Subject: -package-name flag in 6.10.x Message-ID: <1EA46DCB-B8FC-4473-80BF-09FD75A97204@cs.york.ac.uk> The ghc documentation at http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html says the following: > -package-name foo > Tells GHC the the module being compiled forms part of package foo. If this flag is omitted (a very common case) then the default package main is assumed. > Note: the argument to -package-name should be the full package identifier for the package, that is it should include the version number. For example: -package mypkg-1.2. I observe that the example uses -package rather than -package-name, and wonder if this is a mistake. Moreover, when I attempt to use the flag, like so: $ ghc -package-name hat-2.06 ... : cannot parse 'hat-2.06' as a package identifier This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have stopped working with ghc-6.10.x. I surmise that the leading zero after the version point separator is to blame? It seems an unfortunate regression. Regards, Malcolm From duncan.coutts at googlemail.com Wed Nov 25 04:31:14 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Nov 25 04:06:34 2009 Subject: -package-name flag in 6.10.x In-Reply-To: <1EA46DCB-B8FC-4473-80BF-09FD75A97204@cs.york.ac.uk> References: <1EA46DCB-B8FC-4473-80BF-09FD75A97204@cs.york.ac.uk> Message-ID: <1259141474.4896.55434.camel@localhost> On Wed, 2009-11-25 at 04:56 +0000, Malcolm Wallace wrote: > Moreover, when I attempt to use the flag, like so: > > $ ghc -package-name hat-2.06 ... > : cannot parse 'hat-2.06' as a package identifier > > This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have > stopped working with ghc-6.10.x. I surmise that the leading zero > after the version point separator is to blame? It seems an > unfortunate regression. On the contrary, it is good that it checks this now. The package name compiled into the code really ought to match the package name registered with ghc-pkg and the latter is a package identifier, not an arbitrary string. In principle it would be possible to parse 2.06 as a Version [2,6], however I think we decided that allowing that redundancy in the original string is not a good idea since people might expect 2.6 and 2.06 to be different. It would also mean we could not rely on lossless round trips between parser and printer which would be annoying for things like finding the file or directory containing a package (imagine we go looking for "2.6/" when the files are really in "2.06/"). Duncan From bos at serpentine.com Wed Nov 25 16:20:08 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Nov 25 15:55:12 2009 Subject: Build of HEAD fails in integer-gmp Message-ID: I get this error message, which suggests that the gmp-wrappers file should be compiled with -fPIC but isn't being: /usr/bin/ld: libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o: relocation R_X86_64_PC32 against undefined symbol `__gmpz_init' can not be used when making a shared object; recompile with -fPIC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091125/092ae2d1/attachment.html From aycan.irican at core.gen.tr Thu Nov 26 13:38:35 2009 From: aycan.irican at core.gen.tr (Aycan iRiCAN) Date: Thu Nov 26 13:14:00 2009 Subject: Porting to DragonFly BSD In-Reply-To: <200911161732.12660.twhitehead@gmail.com> References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com> <20091115124246.GA98551@horse.gocht-isenmann.de> <200911161732.12660.twhitehead@gmail.com> Message-ID: <39376c217b35f024afc41049f419b8bb@imap.core.gen.tr> Sorry, are there any advancements in dragonflybsd port of ghc? -- aycan From secludedsage at gmail.com Fri Nov 27 00:47:34 2009 From: secludedsage at gmail.com (=?UTF-8?B?56ug5a6P5Lmd?=) Date: Fri Nov 27 00:22:33 2009 Subject: Build ghc with hardened toolchain In-Reply-To: <955db7060911240126w10f38fdo9a51a32af3ba9c37@mail.gmail.com> References: <955db7060911240126w10f38fdo9a51a32af3ba9c37@mail.gmail.com> Message-ID: <955db7060911262147g3fbb30b8ia2cd1344ddc7377d@mail.gmail.com> More information: Gentoo's emerge --info: Portage 2.1.7.6 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-11-generic i686) ================================================================= System uname: Linux-2.6.31-11-generic-i686-Genuine_Intel-R-_CPU_T2050_@_1.60GHz-with-gentoo-1.12.13 Timestamp of tree: Mon, 23 Nov 2009 06:45:01 +0000 app-shells/bash: 4.0_p28 dev-lang/python: 2.6.2-r1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict test test-fail-continue unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirrors.163.com/gentoo http://gentoo.aditsu.net" LANG="zh_CN.UTF-8" LC_ALL="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="*" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/ebuilds/gentoo" PORTDIR_OVERLAY="/var/cache/portage/ebuilds/haskell /var/cache/portage/ebuilds/local" SYNC="rsync://mirror.averse.net/gentoo-portage" USE="X a52 aac acl acpi bash-completion berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups dbus dri dts dvd dvdr eds emboss encode evo fam flac gdbm gif gnome gpm gstreamer gtk hal hardened iconv ipv6 jpeg ldap libnotify lzma mad mikmod mmx mmxext modules mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdf perl pic png ppds pppd python quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd thunar tiff truetype unicode urandom usb vorbis win32codecs x264 x86 xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="*" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Maybe it is not a broken GHC, but a broken ghc-prim library (Some other libraries might also be affected.). But I do not know how to transfer "-nopie" cflags and ldflags to those library. Talked to igloo and tried $CONF_LD_OPTS+= -nopie, I still cannot get yi built. Thank you for all your help. From kitaev at iqi.caltech.edu Fri Nov 27 01:59:26 2009 From: kitaev at iqi.caltech.edu (Alexei Kitaev) Date: Fri Nov 27 01:34:54 2009 Subject: conservative optimizations Message-ID: <4B0F78CE.8020300@iqi.caltech.edu> Dear GHC team, I have observed a space leak in a simple program compiled with -O option. The problem is to compute the "Fibonacci rabbit sequence": [1,0,1,1,0,1,0,1,1,0,1,1,0,...] see e.g., this Haskell Cafe discussion: http://www.haskell.org/pipermail/haskell-cafe/2007-November/034236.html I like this problem because I studied the spectrum of the Schrodinger operator defined by this sequence a while ago. Anyway, here are two slightly different programs that compute the rabbit sequence: -- Version 1: O(n) time, O(n) space rs :: [Int] rs = 1: tail [x | r <- rs, x <- f r] where f 0 = [1] f 1 = [1,0] main :: IO () main = print $ take 100 rs -- Version 2: O(n) time, O(log n) space rs :: () -> [Int] rs () = 1: tail [x | r <- rs(), x <- f r] where f 0 = [1] f 1 = [1,0] -- test of memory usage main :: IO () main = print $ rs() !! (10^8) When the second program is compiled with -O flag (using GHC-6.10.4 or the latest version, 6.13.20091125), it eats up a lot of memory. After some web searching and experimentation, I found that the space leak can be fixed by compiling with -fno-full-laziness and inserting {-# NOINLINE rs #-} However, I still have a few of questions: 1) Why would inlining introduce a space leak? This looks like a compiler bug to me. 2) Is there a set of "safe" or, if this is a better word, "conservative" optimizations that never increase the running time or space usage more than by a constant factor? This leads to another question: relative to what? I understand that prescribing the exact evaluation order and other details would be impractical, but is it possible to define *some* aspects of the program behavior that would allow the programmer to guarantee the correct asymptotic efficiency? Thank you, Alexei Kitaev From secludedsage at gmail.com Fri Nov 27 09:14:17 2009 From: secludedsage at gmail.com (=?UTF-8?B?56ug5a6P5Lmd?=) Date: Fri Nov 27 08:49:14 2009 Subject: Build ghc with hardened toolchain In-Reply-To: <955db7060911240126w10f38fdo9a51a32af3ba9c37@mail.gmail.com> References: <955db7060911240126w10f38fdo9a51a32af3ba9c37@mail.gmail.com> Message-ID: <955db7060911270614q3ffa9a12p4f52fe936bc0fb8d@mail.gmail.com> Sorry, it is about ghc.wrapper. Add the options here to solve the problem. Thanks. 2009/11/24 ??? : > Hello. > > I am using Gentoo with hardened features enabled. Recently i want to > try yi-editor. I built GHC with emerge and nothing strange happened. > However, I got following error information when i built yi: > > Building yi-0.6.1... > [ ?1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, > dist/build/System/FriendlyPath.o ) > [ ?2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, > dist/build/Shim/ProjectContent.o ) > [ ?3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, > dist/build/Parser/Incremental.o ) > [ ?4 of 119] Compiling Data.Trie ? ? ? ?( Data/Trie.hs, dist/build/Data/Trie.o > ) > [ ?5 of 119] Compiling Data.DelayList ? ( Data/DelayList.hs, > dist/build/Data/DelayList.o ) > [ ?6 of 119] Compiling Data.Rope ? ? ? ?( Data/Rope.hs, dist/build/Data/Rope.o > ) > [ ?7 of 119] Compiling Data.Prototype ? ( Data/Prototype.hs, > dist/build/Data/Prototype.o ) > [ ?8 of 119] Compiling HConf.Utils ? ? ?( HConf/Utils.hs, > dist/build/HConf/Utils.o ) > [ ?9 of 119] Compiling HConf.Paths ? ? ?( HConf/Paths.hs, > dist/build/HConf/Paths.o ) > [ 10 of 119] Compiling Paths_yi ? ? ? ? ( dist/build/autogen/Paths_yi.hs, > dist/build/Paths_yi.o ) > [ 11 of 119] Compiling HConf ? ? ? ? ? ?( HConf.hs, dist/build/HConf.o ) > [ 12 of 119] Compiling Yi.Char.Unicode ?( Yi/Char/Unicode.hs, > dist/build/Yi/Char/Unicode.o ) > [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, > dist/build/Yi/UI/Common.o-boot ) > [ 14 of 119] Compiling Yi.String ? ? ? ?( Yi/String.hs, dist/build/Yi/String.o > ) > [ 15 of 119] Compiling Yi.Monad ? ? ? ? ( Yi/Monad.hs, dist/build/Yi/Monad.o ) > [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, > dist/build/Yi/Keymap/Completion.o ) > [ 17 of 119] Compiling Yi.Editor[boot] ?( Yi/Editor.hs-boot, > dist/build/Yi/Editor.o-boot ) > [ 18 of 119] Compiling Yi.Debug ? ? ? ? ( Yi/Debug.hs, dist/build/Yi/Debug.o ) > [ 19 of 119] Compiling Yi.Prelude ? ? ? ( Yi/Prelude.hs, > dist/build/Yi/Prelude.o ) > [ 20 of 119] Compiling Yi.Dynamic ? ? ? ( Yi/Dynamic.hs, > dist/build/Yi/Dynamic.o ) > [ 21 of 119] Compiling Yi.Event ? ? ? ? ( Yi/Event.hs, dist/build/Yi/Event.o ) > [ 22 of 119] Compiling Yi.Interact ? ? ?( Yi/Interact.hs, > dist/build/Yi/Interact.o ) > [ 23 of 119] Compiling Yi.Keymap[boot] ?( Yi/Keymap.hs-boot, > dist/build/Yi/Keymap.o-boot ) > [ 24 of 119] Compiling Yi.Style ? ? ? ? ( Yi/Style.hs, dist/build/Yi/Style.o ) > [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, > dist/build/Yi/Style/Library.o ) > [ 26 of 119] Compiling Yi.Interpreter ? ( Yi/Interpreter.hs, > dist/build/Yi/Interpreter.o ) > [ 27 of 119] Compiling Shim.Utils ? ? ? ( Shim/Utils.hs, > dist/build/Shim/Utils.o ) > [ 28 of 119] Compiling Shim.CabalInfo ? ( Shim/CabalInfo.hs, > dist/build/Shim/CabalInfo.o ) > [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, > dist/build/Yi/Buffer/Misc.o-boot ) > [ 30 of 119] Compiling Yi.Buffer.Basic ?( Yi/Buffer/Basic.hs, > dist/build/Yi/Buffer/Basic.o ) > ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol > `_GLOBAL_OFFSET_TABLE_' > Loading package ghc-prim ... linking ... ghc: unable to load package `ghc-prim' > > I notice that Gentoo has already done some works about disabling > hardened features temporarily for Haskell. Here is the mk/build.mk: > > # Gentoo changes > docdir = /usr/share/doc/ghc-6.10.4 > htmldir = /usr/share/doc/ghc-6.10.4 > SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie > -optl-nopie -optc-fno-PIE -opta-Wa,--noexecstack > SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack > XMLDocWays= > HADDOCK_DOCS=NO > SRC_HC_OPTS+=-w > > While talking on IRC (#gentoo-haskell and #haskell) I was told that > this might be caused by a broken GHC. Although above shows that PIE > are disabled, ghc-prim (maybe at least) is still built with PIE > enabled. According to advice from #gentoo-haskell, I was told to seek > for help here. > > I also submit a bug about it as #3668. (Very sorry that I ask > everywhere. Forgive me, but until yesterday I forgot my password of my > gmail and cannot join a mailling-list.) Thank igloo told me add > "-nopie" in SRC_LD_OPTS. I did but still failed: > > ------------------------------------------------------------------------ > == make boot - --no-print-directory -r --jobserver-fds=3,4 - > --jobserver-fds=3,4 -j; > ?in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/utils/genapply > ------------------------------------------------------------------------ > /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -package-conf > /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf > -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie > -opta-Wa,--noexecstack -w -package pretty -fforce-recomp ? ?-c > GenApply.hs -o GenApply.o ?-ohi GenApply.hi > /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -M -dep-makefile > .depend ?-osuf o -package-conf > /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf > ? -package-conf > /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf > -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie > -opta-Wa,--noexecstack -w -package pretty -fforce-recomp GenApply.hs > /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -o genapply > -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf > -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie > -opta-Wa,--noexecstack -w -package pretty -fforce-recomp ? ?-nopie > GenApply.o > ghc: unrecognised flags: -nopie > Usage: For basic information, try the `--help' option. > make[2]: *** [genapply] Error 1 > Failed making boot in genapply: 1 > make[1]: *** [boot] Error 1 > make: *** [stage1] Error 1 > > I am surprised that why "-nopie" is sent here. Since wiki only told me > to see config.mk.in and it does not have any examples, I have no idea > about SRC_LD_OPTS. > > I need help how to completely disable PIE for GHC. Thank you very much. > > > Hongjiu Zhang > From marlowsd at gmail.com Fri Nov 27 11:09:22 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Nov 27 10:44:52 2009 Subject: Build of HEAD fails in integer-gmp In-Reply-To: References: Message-ID: <4B0FF9B2.8010703@gmail.com> On 25/11/2009 21:20, Bryan O'Sullivan wrote: > I get this error message, which suggests that the gmp-wrappers file > should be compiled with -fPIC but isn't being: > > /usr/bin/ld: > libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o: > relocation R_X86_64_PC32 against undefined symbol `__gmpz_init' can not > be used when making a shared object; recompile with -fPIC This was temporary breakage, fixed a couple of days ago: http://www.haskell.org/pipermail/cvs-ghc/2009-November/051393.html I'm not sure why google isn't indexing the cvs-ghc archives, otherwise that would have been an easy one to find. Cheers, Simon From bos at serpentine.com Fri Nov 27 20:16:59 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Nov 27 19:51:55 2009 Subject: Build of HEAD fails in integer-gmp In-Reply-To: <4B0FF9B2.8010703@gmail.com> References: <4B0FF9B2.8010703@gmail.com> Message-ID: On Fri, Nov 27, 2009 at 8:09 AM, Simon Marlow wrote: > > This was temporary breakage, fixed a couple of days ago: > > http://www.haskell.org/pipermail/cvs-ghc/2009-November/051393.html > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091127/7370e893/attachment.html From donn at avvanta.com Sat Nov 28 00:47:33 2009 From: donn at avvanta.com (Donn Cave) Date: Sat Nov 28 00:22:29 2009 Subject: mysteriously hidden ghc-binary-0.5.0.2 Message-ID: <20091128054733.3F57B276C55@mail.avvanta.com> Trying to build ghc-6.12.0.20091121, from an hc bootstrap build of ghc-6.12.0.20091010 -- i.e., first self hosted build of ghc. I'm hung up at the point where, after building ghc-cabal, ghc-pkg, hsc2hs etc., it tries to generate dependencies (?) for a Binary.hs in libraries/bin-package-db. It can't find module 'Data.Binary' - "It is a member of the hidden package `ghc-binary-0.5.0.2'." OK, I am not familiar with packages, except insofar as encountered while trying to build GHC, but from "ghc-pkg list", I would not get the impression that ghc-binary-0.5.0.2 is hidden (no parentheses.) I get this result with either ghc-pkg, from the 20091010 build where ghc-stage2 is, or the newly built 20091121 version. The command line seems to correctly have -hide-all-packages, followed eventually by -package ghc-binary-0.5.0.2. The command and results below. Is this a configuration problem with 6.12.0, or is it more likely that my ghc build is defective? Thanks! Donn Cave, donn@avvanta.com /boot/home/src/ghc/ghc-6.12.0.20091010/inplace/bin/ghc-stage2 -v -M -include-pkg-deps -dep-makefile libraries/bin-package-db/dist-boot/build/.depend-v -H64m -O0 -fasm -package-conf libraries/bootstrapping.conf -package-name bin-package-db-0.0.0.0 -hide-all-packages -i -ilibraries/bin-package-db/. -ilibraries/bin-package-db/dist-boot/build -ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/dist-boot/build -Ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/. -optP-include -optPlibraries/bin-package-db/dist-boot/build/autogen/cabal_macros.h -package Cabal-1.8.0.1 -package base-4.2.0.0 -package ghc-binary-0.5.0.2 -fno-warn-deprecated-flags -odir libraries/bin-package-db/dist-boot/build -hidir libraries/bin-package-db/dist-boot/build -stubdir libraries/bin-package-db/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/bin-package-db/./Distribution/InstalledPackageInfo/Binary.hs Glasgow Haskell Compiler, Version 6.12.0.20091010, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using binary package database: /boot/home/src/ghc/ghc-6.12.0.20091010/inplace/lib/package.conf.d/package.cache Using package config file: libraries/bootstrapping.conf wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.2.0.0-inplace wired-in package base mapped to base-4.2.0.0-inplace wired-in package rts mapped to builtin_rts wired-in package haskell98 mapped to haskell98-1.0.1.1-inplace wired-in package template-haskell mapped to template-haskell-2.4.0.0-inplace wired-in package dph-seq mapped to dph-seq-0.4.0-inplace wired-in package dph-par mapped to dph-par-0.4.0-inplace Hsc static flags: -funregisterised -static Created temporary directory: /tmp/ghc47745_0 *** Chasing dependencies: Chasing modules from: *libraries/bin-package-db/Distribution/InstalledPackageInfo/Binary.hs libraries/bin-package-db/Distribution/InstalledPackageInfo/Binary.hs:21:7: Could not find module `Data.Binary': It is a member of the hidden package `ghc-binary-0.5.0.2'. locations searched: libraries/bin-package-db/./Data/Binary.hs libraries/bin-package-db/./Data/Binary.lhs libraries/bin-package-db/dist-boot/build/Data/Binary.hs libraries/bin-package-db/dist-boot/build/Data/Binary.lhs libraries/bin-package-db/dist-boot/build/autogen/Data/Binary.hs libraries/bin-package-db/dist-boot/build/autogen/Data/Binary.lhs *** Deleting temp files: Deleting: /tmp/ghc47745_0/ghc47745_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc47745_0 From aslatter at gmail.com Sat Nov 28 16:01:26 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Nov 28 15:36:20 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 Message-ID: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Hello folks, Everything has been going beautifully with the latest versions of GHC 6.12, except that anything involving zlib dies at run-time. In ghci: > :m Codec.Compression.Zlib > :m +Data.ByteString.Lazy.Char8 > :s -XOverloadedStrings > compress "hello" *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) I'm running OS X 10.6 on a 64-bit machine. I've heard of folks running into this with GHC 6.10 on OS X 10.6, who got rid of it by removing mac-ports. I tried that and it didn't change anything. My mac-ports install should have all been universal binaries anyway. I imagine I'm somehow building against a 64-bit version of the zlib library, but I'm not sure at what step I'm supposed to do things different, or what precisely I'm supposed to do different. Thanks, Antoine From nonowarn at gmail.com Sat Nov 28 16:54:42 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Sat Nov 28 16:29:36 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Message-ID: I think you installed zlib without proper flags to link with 32-bit libraries. configuring with ./Setup configure --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. See also http://hackage.haskell.org/trac/ghc/ticket/3681. HTH -~nwn On Sun, Nov 29, 2009 at 6:01 AM, Antoine Latter wrote: > Hello folks, > > Everything has been going beautifully with the latest versions of GHC > 6.12, except that anything involving zlib dies at run-time. In ghci: > >> :m Codec.Compression.Zlib >> :m +Data.ByteString.Lazy.Char8 >> :s -XOverloadedStrings >> compress "hello" > > *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) > > I'm running OS X 10.6 on a 64-bit machine. > > I've heard of folks running into this with GHC 6.10 on OS X 10.6, who > got rid of it by removing mac-ports. I tried that and it didn't change > anything. My mac-ports install should have all been universal binaries > anyway. > > I imagine I'm somehow building against a 64-bit version of the zlib > library, but I'm not sure at what step I'm supposed to do things > different, or what precisely I'm supposed to do different. > > Thanks, > Antoine > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From aslatter at gmail.com Sat Nov 28 18:00:57 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Nov 28 17:35:51 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Message-ID: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: > I think you installed zlib without proper flags to link with 32-bit > libraries. configuring with ./Setup configure > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. > > See also http://hackage.haskell.org/trac/ghc/ticket/3681. > > HTH > -~nwn The following worked like a charm: cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' Thanks for the tip. Antoine From nonowarn at gmail.com Sat Nov 28 20:27:05 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Sat Nov 28 20:01:57 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: I had wrote last mail without verifications, so ./Setup configure --hsc2hs-options='--cflag=-m32 --lflag=-m32' is correct. But I'm glad to know you got working fine with zlib :) ~-nwn On Sun, Nov 29, 2009 at 8:00 AM, Antoine Latter wrote: > On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: >> I think you installed zlib without proper flags to link with 32-bit >> libraries. configuring with ./Setup configure >> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. >> >> See also http://hackage.haskell.org/trac/ghc/ticket/3681. >> >> HTH >> -~nwn > > The following worked like a charm: > > cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' > > Thanks for the tip. > > Antoine > From chak at cse.unsw.edu.au Sun Nov 29 22:08:42 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Nov 29 21:43:39 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> Antoine Latter: > On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: >> I think you installed zlib without proper flags to link with 32-bit >> libraries. configuring with ./Setup configure >> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. >> >> See also http://hackage.haskell.org/trac/ghc/ticket/3681. >> >> HTH >> -~nwn > > The following worked like a charm: > > cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' Which version of 6.12 are you running? These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. (They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) Manuel From aslatter at gmail.com Sun Nov 29 23:49:17 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Nov 29 23:24:07 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> Message-ID: <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty wrote: > > Which version of 6.12 are you running? ?These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. ?(They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) > > Manuel I built it within the past few days, I'm not sure why the version number says 1120. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120 Installed from darcs via "configre --prefix=${HOME}/usr && make && make install" and such. Could an unpatched hsc2hs wrapper have been left around by my old GHC 6.10 installation? Antoine From nonowarn at gmail.com Mon Nov 30 02:25:55 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Mon Nov 30 02:00:44 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> Message-ID: This was reproduced on rc2, too. I installed ghc-6.12 rc2 by the installer. As the ticket I mentioned[1] says, The problem is the flags to build 32-bit binaries is not passed to the hsc2hs executable when the hsc2hs wrapper get any --cc parameter. Cabal passes --cc parameter to the wrapper to tell where gcc is. So when building a package with Cabal, hsc2hs goes wrong. [1]: http://hackage.haskell.org/trac/ghc/ticket/3681 --nwn On Mon, Nov 30, 2009 at 1:49 PM, Antoine Latter wrote: > On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty > wrote: >> >> Which version of 6.12 are you running? ?These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. ?(They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) >> >> Manuel > > I built it within the past few days, I'm not sure why the version > number says 1120. > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120 > > Installed from darcs via "configre --prefix=${HOME}/usr && make && > make install" and such. > > Could an unpatched hsc2hs wrapper have been left around by my old GHC > 6.10 installation? > > Antoine > From simonpj at microsoft.com Mon Nov 30 03:44:34 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 30 03:19:24 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Should this go in a FAQ? For GHC? Or for a particular architecture? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Antoine Latter | Sent: 28 November 2009 23:01 | To: Yusaku Hashimoto | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries | Subject: Re: GHC 6.12 + zlib + Mac OS 10.6 | | On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: | > I think you installed zlib without proper flags to link with 32-bit | > libraries. configuring with ./Setup configure | > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. | > | > See also http://hackage.haskell.org/trac/ghc/ticket/3681. | > | > HTH | > -~nwn | | The following worked like a charm: | | cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' | | Thanks for the tip. | | Antoine | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From nonowarn at gmail.com Mon Nov 30 05:38:29 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Mon Nov 30 05:13:18 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: I think this is a problem for architectures in which can only build 32-bit binaries. On such architectures, hsc2hs should ensure to work for 32-bit binaries as possible. So I think hsc2hs wrapper should be fixed to give the flags if gcc is used. --nwn On Mon, Nov 30, 2009 at 5:44 PM, Simon Peyton-Jones wrote: > Should this go in a FAQ? For GHC? Or for a particular architecture? > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Antoine Latter > | Sent: 28 November 2009 23:01 > | To: Yusaku Hashimoto > | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries > | Subject: Re: GHC 6.12 + zlib + Mac OS 10.6 > | > | On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: > | > I think you installed zlib without proper flags to link with 32-bit > | > libraries. configuring with ./Setup configure > | > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. > | > > | > See also http://hackage.haskell.org/trac/ghc/ticket/3681. > | > > | > HTH > | > -~nwn > | > | The following worked like a charm: > | > | cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' > | > | Thanks for the tip. > | > | Antoine > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From duncan.coutts at googlemail.com Mon Nov 30 05:41:24 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 30 05:16:16 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1259577684.4896.85147.camel@localhost> On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote: > Should this go in a FAQ? For GHC? Or for a particular architecture? For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow Leopard)" and should describe the changes required to the shell script wrappers of ghc and hsc2hs. It should also note that none of this is necessary for ghc-6.12+. For ghc-6.12, we should just fix ticket #3681. http://hackage.haskell.org/trac/ghc/ticket/3681 Duncan From simonpj at microsoft.com Mon Nov 30 07:20:24 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 30 06:55:15 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <1259577684.4896.85147.camel@localhost> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> <1259577684.4896.85147.camel@localhost> Message-ID: <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> | For ghc-6.12, we should just fix ticket #3681. OK, good. But who is "we"? Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf | Of Duncan Coutts | Sent: 30 November 2009 10:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries | Subject: RE: GHC 6.12 + zlib + Mac OS 10.6 | | On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote: | > Should this go in a FAQ? For GHC? Or for a particular architecture? | | For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow | Leopard)" and should describe the changes required to the shell script | wrappers of ghc and hsc2hs. It should also note that none of this is | necessary for ghc-6.12+. | | For ghc-6.12, we should just fix ticket #3681. | | http://hackage.haskell.org/trac/ghc/ticket/3681 | | | Duncan | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at googlemail.com Mon Nov 30 07:22:08 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 30 06:56:59 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> <1259577684.4896.85147.camel@localhost> <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1259583728.4896.85584.camel@localhost> On Mon, 2009-11-30 at 12:20 +0000, Simon Peyton-Jones wrote: > | For ghc-6.12, we should just fix ticket #3681. > > OK, good. But who is "we"? I think the short-term fix is just to change the hsc2hs wrapper script. So that'd be Ian. Longer term we might want to do it differently to allow a single hsc2hs instance to be used to target either 32 or 64bit ABIs on the same platform. Duncan From matthijs at stdin.nl Mon Nov 30 14:28:16 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon Nov 30 14:03:03 2009 Subject: Formal semantics for Core? Message-ID: <20091130192816.GQ13955@katherina.student.utwente.nl> Hi All, I was wondering if there are any formal semantics defined for GHC's core language? I'm working with some core to core rewriting passes for which I'd like to verify the soundness, but that would require some formal definition of the Core semantics of sorts... Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091130/dcf7447e/attachment.bin