From simonpj at microsoft.com Tue Apr 1 10:25:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 10:25:35 +0000 Subject: Buildbots In-Reply-To: <1396338146446-5746770.post@n5.nabble.com> References: <1396338146446-5746770.post@n5.nabble.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> Friends The nightly-build infrastructure for GHC is in disarray, and we could really do with help. We really want * Continuous integration so that new test failures show up fast * Nightly builds on a variety of platforms, giving snapshots that are easy to install Originally we used Buildbot (http://buildbot.net/). Then in 2010 Ian Lynagh put a lot of work into a build-bot infrastructure, implemented in Haskell as an open-source project, GHC Builder (?https://ghc.haskell.org/trac/ghc/wiki/Builder). See https://ghc.haskell.org/trac/ghc/wiki/Status/Apr10#Nightlybuilds for the reasoning at the time. As I understand it, Builder never "caught fire", and now that Ian has moved on I don't know that anyone is maintaining it; nor are the various builders working so far as I know. Perhaps competing technology has moved on, so that the original rationale no longer holds? I'm not sure. Regardless, we lack leadership in this area. Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Others have indicated interest/willingness. But it would be fantastic to have a person, or (more plausibly) a small group who assumed leadership. An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. Others will be better informed than me about all this... we'd love to hear from you. Thank you! Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of harry | Sent: 01 April 2014 08:42 | To: glasgow-haskell-users at haskell.org | Subject: Buildbots | | It having been suggested that a buildbot for Windows may be needed, and | it | being possible that I may receive permission from management for setting | one | up in my department's server room, I set about attempting to discover | what | this actually entails. | | A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, | which tells me that "Buildbot is currently down, and we are working on a | replacement. See Builder for more details." If I follow the 'down' link , | I | get to the GHC status April 2010 page, which says that buildbot has been | abandoned, suggesting that the page should be deleted. Could someone | confirm | before I go ahead and delete it? | | The Builder page has clear instructions on how to set up a build slave, | and | a link to the build results. The build results contains an assortment of | dud | links and builds from August and earlier. | | What is the current state of automated builds? | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | Nabble.com. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From alain.odea at gmail.com Tue Apr 1 10:43:09 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 10:43:09 +0000 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5A0B959C-7CA0-447A-9F76-964172FD83DD@gmail.com> Hi Simon: I'm happy to help with Buildbot, Travis CI, or whatever build system is preferred. I have administered and curated the continuous integration environment at Verafin for several years. I have reasonable experience with a variety of operating systems and test systems. I can't reasonably take lead on this, due to inexperience with GHC's test suite and Haskell testing in general. I am happy to act in a support role: troubleshooting, debugging, and programming to get this back up and keep it solid. I just need a mentor to point me at the right problems to solve. Best, Alain > On Apr 1, 2014, at 10:25, Simon Peyton Jones wrote: > > Friends > > The nightly-build infrastructure for GHC is in disarray, and we could really do with help. We really want > * Continuous integration so that new test failures show up fast > * Nightly builds on a variety of platforms, giving > snapshots that are easy to install > > Originally we used Buildbot (http://buildbot.net/). Then in 2010 Ian Lynagh put a lot of work into a build-bot infrastructure, implemented in Haskell as an open-source project, GHC Builder (?https://ghc.haskell.org/trac/ghc/wiki/Builder). See https://ghc.haskell.org/trac/ghc/wiki/Status/Apr10#Nightlybuilds for the reasoning at the time. > > As I understand it, Builder never "caught fire", and now that Ian has moved on I don't know that anyone is maintaining it; nor are the various builders working so far as I know. Perhaps competing technology has moved on, so that the original rationale no longer holds? I'm not sure. > > Regardless, we lack leadership in this area. Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Others have indicated interest/willingness. But it would be fantastic to have a person, or (more plausibly) a small group who assumed leadership. > > An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. > > Others will be better informed than me about all this... we'd love to hear from you. > > Thank you! > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of harry > | Sent: 01 April 2014 08:42 > | To: glasgow-haskell-users at haskell.org > | Subject: Buildbots > | > | It having been suggested that a buildbot for Windows may be needed, and > | it > | being possible that I may receive permission from management for setting > | one > | up in my department's server room, I set about attempting to discover > | what > | this actually entails. > | > | A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, > | which tells me that "Buildbot is currently down, and we are working on a > | replacement. See Builder for more details." If I follow the 'down' link , > | I > | get to the GHC status April 2010 page, which says that buildbot has been > | abandoned, suggesting that the page should be deleted. Could someone > | confirm > | before I go ahead and delete it? > | > | The Builder page has clear instructions on how to set up a build slave, > | and > | a link to the build results. The build results contains an assortment of > | dud > | links and builds from August and earlier. > | > | What is the current state of automated builds? > | > | > | > | -- > | View this message in context: > | http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html > | Sent from the Haskell - Glasgow-haskell-users mailing list archive at > | Nabble.com. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Tue Apr 1 10:46:05 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 12:46:05 +0200 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1396349165.2683.14.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: > Joachim Breitner has set up Travis-CI. (I don't know exactly what > that is, but it sounds useful.) Travis is a free cloud service that runs arbitrary tests (in our case, a stripped version of validate) upon pushes to git repositories on github. I set it up to validate our master, so we get a nice history of successes and failures on https://travis-ci.org/nomeata/ghc-complete/builds and I get mails when things fail; that is when I send hopefully polite enough mails to ghc-dev, asking people to fix their commits. (Unless I broke it myself; then I silently fix it and hide.) It is a makeshift solution until we get our own infrastructure working. > An early question would be: to continue to use a DIY system (Builder), > or to move to some other better-supported (but perhaps less malleable) > system. I don't even know what the options are. Sigh, test infrastructure are like content management systems: There are plenty out there to choose from, all can do lots of things one does not need, but none can do all, so one starts writing something selfmade, which eventually evolves in yet another of these beasts, just with fewer users. I?d recommend a move to existing, proven tools. Unfortunately, I cannot give advice as to what tool to move to. But if all these? projects are happy with buildbot, it might not be the worst choice. ? http://trac.buildbot.net/wiki/SuccessStories Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Apr 1 10:57:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 10:57:00 +0000 Subject: Haskell Support on Windows In-Reply-To: <1396268819897-5746711.post@n5.nabble.com> References: <1396268819897-5746711.post@n5.nabble.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D34C4@DB3PRD3001MB020.064d.mgd.msft.net> | I've been getting the impression that a lot of the stickier GHC bugs are | Windows specific, while very few GHC hackers actually use Windows, other | than to ensure that GHC works on it. ... | Perhaps it should be "demoted" to second-tier GHC support as well, at | least to the extent that Windows bugs won't hold up a release? That's true. But many, many people *use* GHC on Windows. It would be terribly sad to abandon them. What we need is more developers to volunteer to help look after the Windows version of GHC. One or two are doing so, but we need more. Please! Simon From alain.odea at gmail.com Tue Apr 1 11:08:13 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 11:08:13 +0000 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: Hi Joachim: From what I understand Travis CI limits running time for each build. We may be able to create binaries of stage1 and/or stage2 in one build and test them in another. We could also fan out the test process using a Build Matrix to let GHC's full suite fit into the time limit as fragments. That would require some changes to the testsuite or some lengthy build scripts for each segment that explicitly run many "make TEST=sometest" commands. I had to do something similar at Verafin because the whole test suite was taking too long as a whole unit. I split it into builds for each separate module and used more build agents so they could run in parallel. Verafin is using TeamCity, but I think the concepts are achievable in Buildbot or Travis CI. In my opinion, the best build and CI system is the one you can get working. Best, Alain > On Apr 1, 2014, at 10:46, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: >> Joachim Breitner has set up Travis-CI. (I don't know exactly what >> that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tests (in our case, a > stripped version of validate) upon pushes to git repositories on github. > I set it up to validate our master, so we get a nice history of > successes and failures on > https://travis-ci.org/nomeata/ghc-complete/builds > and I get mails when things fail; that is when I send hopefully polite > enough mails to ghc-dev, asking people to fix their commits. > > (Unless I broke it myself; then I silently fix it and hide.) > > It is a makeshift solution until we get our own infrastructure working. > >> An early question would be: to continue to use a DIY system (Builder), >> or to move to some other better-supported (but perhaps less malleable) >> system. I don't even know what the options are. > > Sigh, test infrastructure are like content management systems: There are > plenty out there to choose from, all can do lots of things one does not > need, but none can do all, so one starts writing something selfmade, > which eventually evolves in yet another of these beasts, just with fewer > users. > > I?d recommend a move to existing, proven tools. Unfortunately, I cannot > give advice as to what tool to move to. But if all these? projects are > happy with buildbot, it might not be the worst choice. > > ? http://trac.buildbot.net/wiki/SuccessStories > > Greetings, > Joachim > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From hvriedel at gmail.com Tue Apr 1 11:09:30 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 01 Apr 2014 13:09:30 +0200 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> (Joachim Breitner's message of "Tue, 01 Apr 2014 12:46:05 +0200") References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <87bnwl8fx1.fsf@gmail.com> On 2014-04-01 at 12:46:05 +0200, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: >> Joachim Breitner has set up Travis-CI. (I don't know exactly what >> that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tests (in our case, a > stripped version of validate) upon pushes to git repositories on github. > I set it up to validate our master, so we get a nice history of > successes and failures on > https://travis-ci.org/nomeata/ghc-complete/builds > and I get mails when things fail; that is when I send hopefully polite > enough mails to ghc-dev, asking people to fix their commits. What's more, we also have TravisCI set-up for the various libraries/* sub-packages, to make sure they work as announced by their respective .cabal files with older GHC/base-version configurations (so if anybody pushes a commit that breaks that contract, email notifications are sent out), here's a non-exhaustive list of examples: - https://travis-ci.org/ghc/packages-process - https://travis-ci.org/ghc/packages-unix - https://travis-ci.org/ghc/packages-hpc - https://travis-ci.org/ghc/packages-parallel - https://travis-ci.org/ghc/packages-deepseq Cheers, hvr From mail at joachim-breitner.de Tue Apr 1 11:11:04 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 13:11:04 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <1396350664.2683.17.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 11:08 +0000 schrieb Alain O'Dea: > From what I understand Travis CI limits running time for each build. > We may be able to create binaries of stage1 and/or stage2 in one build > and test them in another. We could also fan out the test process > using a Build Matrix to let GHC's full suite fit into the time limit > as fragments. That would require some changes to the testsuite or > some lengthy build scripts for each segment that explicitly run many > "make TEST=sometest" commands. The main problem with Travis is that it only tests on one architecture. There are more (e.g. very undetailed reporting compared to a buildbot waterfall/grid) Hence: Travis is _not_ going to be a solution for us; we will want our own infrastructure. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From alain.odea at gmail.com Tue Apr 1 11:22:16 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 11:22:16 +0000 Subject: Buildbots In-Reply-To: <1396350664.2683.17.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: <293EC480-09EF-43AD-8D36-B76F88033C84@gmail.com> Hi, > On Apr 1, 2014, at 11:11, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 01.04.2014, 11:08 +0000 schrieb Alain O'Dea: >> From what I understand Travis CI limits running time for each build. >> We may be able to create binaries of stage1 and/or stage2 in one build >> and test them in another. We could also fan out the test process >> using a Build Matrix to let GHC's full suite fit into the time limit >> as fragments. That would require some changes to the testsuite or >> some lengthy build scripts for each segment that explicitly run many >> "make TEST=sometest" commands. > > The main problem with Travis is that it only tests on one architecture. > There are more (e.g. very undetailed reporting compared to a buildbot > waterfall/grid) Good points. > Hence: Travis is _not_ going to be a solution for us; we will want our > own infrastructure. I'm happy to assist with getting whatever system fits the bill working. It seems like Buildbot should. Where can we get infrastructure on multiple architectures easily? I imagine we may need to mix and match. > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org From robstewart57 at gmail.com Tue Apr 1 11:35:25 2014 From: robstewart57 at gmail.com (Rob Stewart) Date: Tue, 1 Apr 2014 12:35:25 +0100 Subject: Buildbots In-Reply-To: <293EC480-09EF-43AD-8D36-B76F88033C84@gmail.com> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <293EC480-09EF-43AD-8D36-B76F88033C84@gmail.com> Message-ID: On 1 April 2014 12:22, Alain O'Dea wrote: > Where can we get infrastructure on multiple architectures easily? Given that the responsibilities of the Haskell.org committee include: * Setting the policy on what the servers owned by haskell.org may be used for * Determining how haskell.org funds are spent Is there an opportunity to use Haskell.org servers as GHC build servers, or use some of the Haskell.org funds on EC2 instances for every architecture and OS GHC intends to support? -- Rob From tuncer.ayaz at gmail.com Tue Apr 1 11:41:11 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 1 Apr 2014 13:41:11 +0200 Subject: Buildbots In-Reply-To: <1396350664.2683.17.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: On Tue, Apr 1, 2014 at 1:11 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 01.04.2014, 11:08 +0000 schrieb Alain O'Dea: > > From what I understand Travis CI limits running time for each > > build. We may be able to create binaries of stage1 and/or stage2 in > > one build and test them in another. We could also fan out the test > > process using a Build Matrix to let GHC's full suite fit into the > > time limit as fragments. That would require some changes to the > > testsuite or some lengthy build scripts for each segment that > > explicitly run many "make TEST=sometest" commands. > > The main problem with Travis is that it only tests on one > architecture. There are more (e.g. very undetailed reporting > compared to a buildbot waterfall/grid) > > Hence: Travis is _not_ going to be a solution for us; we will want our > own infrastructure. I do agree, but if anybody wants to look more closely into using Travis-CI, I suggest to also consider drone.io. It appears to fix some of the shortcomings and annoyances of Travis-CI. From karel.gardas at centrum.cz Tue Apr 1 11:45:58 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 01 Apr 2014 13:45:58 +0200 Subject: Buildbots In-Reply-To: <1396350664.2683.17.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: <533AA6F6.1090309@centrum.cz> Hi, I'm curious why not to use what's already written by Ian and others and which is currently running again? E.g. Janos Gabor Pali was so nice to start and keep builder server running on http://haskell.inf.elte.hu/builders/ Just few are there, but others may be added. Just send email to Janos to get the credentials and more information about what to get from where (recent builder client is needed). Perhaps we shall more advertise this option on GHC's builder wiki page? Thanks, Karel On 04/ 1/14 01:11 PM, Joachim Breitner wrote: > Hence: Travis is _not_ going to be a solution for us; we will want our > own infrastructure. From mail at joachim-breitner.de Tue Apr 1 11:48:57 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 13:48:57 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: <1396352937.2683.18.camel@kirk> Hi Tuncer, Am Dienstag, den 01.04.2014, 13:41 +0200 schrieb Tuncer Ayaz: > > Hence: Travis is _not_ going to be a solution for us; we will want our > > own infrastructure. > > I do agree, but if anybody wants to look more closely into using > Travis-CI, I suggest to also consider drone.io. It appears to fix some > of the shortcomings and annoyances of Travis-CI. but not the timelimit: Limits The following limits are placed upon all builds: * a build cannot exceed 15 minutes (free tier only) Expect https://drone.io/github.com/nomeata/ghc-complete/1 to fail in 10 minutes... Nevertheless, thanks for the pointer! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Apr 1 12:03:12 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 12:03:12 +0000 Subject: Buildbots In-Reply-To: <533AA6F6.1090309@centrum.cz> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Karel Gardas | Sent: 01 April 2014 12:46 | To: Joachim Breitner; ghc-devs at haskell.org; P?li G?bor J?nos | Cc: glasgow-haskell-users at haskell.org | Subject: Re: Buildbots | | | Hi, | | I'm curious why not to use what's already written by Ian and others and | which is currently running again? E.g. Janos Gabor Pali was so nice to | start and keep builder server running on | http://haskell.inf.elte.hu/builders/ | | Just few are there, but others may be added. Just send email to Janos to | get the credentials and more information about what to get from where | (recent builder client is needed). | | Perhaps we shall more advertise this option on GHC's builder wiki page? | | Thanks, | Karel | | | On 04/ 1/14 01:11 PM, Joachim Breitner wrote: | > Hence: Travis is _not_ going to be a solution for us; we will want our | > own infrastructure. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From tuncer.ayaz at gmail.com Tue Apr 1 12:04:36 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 1 Apr 2014 14:04:36 +0200 Subject: Buildbots In-Reply-To: <1396352937.2683.18.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <1396352937.2683.18.camel@kirk> Message-ID: On Tue, Apr 1, 2014 at 1:48 PM, Joachim Breitner wrote: > Hi Tuncer, > > Am Dienstag, den 01.04.2014, 13:41 +0200 schrieb Tuncer Ayaz: > > > Hence: Travis is _not_ going to be a solution for us; we will > > > want our own infrastructure. > > > > I do agree, but if anybody wants to look more closely into using > > Travis-CI, I suggest to also consider drone.io. It appears to fix > > some of the shortcomings and annoyances of Travis-CI. > > but not the timelimit: > Limits > > The following limits are placed upon all builds: > > * a build cannot exceed 15 minutes (free tier only) > > Expect https://drone.io/github.com/nomeata/ghc-complete/1 to fail in > 10 minutes... Yeah, but if you're serious about using their service, I wouldn't be surprised for them to make an exception for some open source projects. BTW, a reasonable hard timeout makes a lot of sense to me in case a build can be stuck. With that being said, I also agree with Karel wrt reinstating the "old" builder infrastructure, especially considering coverage of different hardware architectures. In fact, I recall an email from Ian some time ago with details on what would be required to restore that. From alain.odea at gmail.com Tue Apr 1 12:17:26 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 12:17:26 +0000 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm going to read up on Ian's Buildbot work and experiment with that in the meantime. If other challenges come up I'm glad to dive in and help. > On Apr 1, 2014, at 12:03, Simon Peyton Jones wrote: > > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Karel Gardas > | Sent: 01 April 2014 12:46 > | To: Joachim Breitner; ghc-devs at haskell.org; P?li G?bor J?nos > | Cc: glasgow-haskell-users at haskell.org > | Subject: Re: Buildbots > | > | > | Hi, > | > | I'm curious why not to use what's already written by Ian and others and > | which is currently running again? E.g. Janos Gabor Pali was so nice to > | start and keep builder server running on > | http://haskell.inf.elte.hu/builders/ > | > | Just few are there, but others may be added. Just send email to Janos to > | get the credentials and more information about what to get from where > | (recent builder client is needed). > | > | Perhaps we shall more advertise this option on GHC's builder wiki page? > | > | Thanks, > | Karel > | > | > | On 04/ 1/14 01:11 PM, Joachim Breitner wrote: > | > Hence: Travis is _not_ going to be a solution for us; we will want our > | > own infrastructure. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From kvanberendonck at gmail.com Tue Apr 1 12:54:20 2014 From: kvanberendonck at gmail.com (Kyle Van Berendonck) Date: Tue, 1 Apr 2014 23:54:20 +1100 Subject: Haskell Support on Windows (Simon Peyton Jones) Message-ID: A couple of poor assumptions are made here. The first is that the userbase of GHC on Windows is poor. This is false. In fact, the poor state of Windows is mentioned on #haskell more frequently as of late. In the last week I've talked almost every day to (different) people who have had Windows woes with using GHC. The hacker-base isn't here at the moment - I agree, but the user-base most certainly is. Could this be a problem with the demographic, or could it just be that Windows development isn't inviting? The build system and default test failures in-particular are a source of discouragement. The second assumption is that GHC/Haskell will be worth a dime in the RealWorld without Windows as a primary tier platform. I'm going to put a crude guess that given the overwhelming magnitude of C#/F# coming up on my local careers portal that there's far more industry on Windows than on OSX or Linux. Those are all the businesses where the probability that they will ever touch Haskell goes from `probably not right now` to `impossible`. Let me also remind you that Windows still holds 89.2% of operating system market share ie the people that hackers and developers actually have to deploy their applications to. Sorry to sound fumey, but there's all this suggesting that everyone would have a better day if we dropped Windows (let's be honest, if it wasn't a primary tier platform nobody would have fixed it for 7.8), but I doubt few of the people who think it's a "great idea" or sslt have actually thought through whether it's the best thing for Haskell or just the best thing to get 7.8 into their hands a couple weeks sooner. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 1 12:57:41 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 12:57:41 +0000 Subject: Haskell Support on Windows (Simon Peyton Jones) In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D38BB@DB3PRD3001MB020.064d.mgd.msft.net> A couple of poor assumptions are made here. I'm not sure where "here" is. In my email I specifically said exactly what you are saying (only I was not as eloquent as you). What we need is some developers who are willing to give some love and support to the Windows version of GHC. And they really are thin on the ground, unfortunately. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kyle Van Berendonck Sent: 01 April 2014 13:54 To: ghc-devs at haskell.org Subject: Re: Haskell Support on Windows (Simon Peyton Jones) A couple of poor assumptions are made here. The first is that the userbase of GHC on Windows is poor. This is false. In fact, the poor state of Windows is mentioned on #haskell more frequently as of late. In the last week I've talked almost every day to (different) people who have had Windows woes with using GHC. The hacker-base isn't here at the moment - I agree, but the user-base most certainly is. Could this be a problem with the demographic, or could it just be that Windows development isn't inviting? The build system and default test failures in-particular are a source of discouragement. The second assumption is that GHC/Haskell will be worth a dime in the RealWorld without Windows as a primary tier platform. I'm going to put a crude guess that given the overwhelming magnitude of C#/F# coming up on my local careers portal that there's far more industry on Windows than on OSX or Linux. Those are all the businesses where the probability that they will ever touch Haskell goes from `probably not right now` to `impossible`. Let me also remind you that Windows still holds 89.2% of operating system market share ie the people that hackers and developers actually have to deploy their applications to. Sorry to sound fumey, but there's all this suggesting that everyone would have a better day if we dropped Windows (let's be honest, if it wasn't a primary tier platform nobody would have fixed it for 7.8), but I doubt few of the people who think it's a "great idea" or sslt have actually thought through whether it's the best thing for Haskell or just the best thing to get 7.8 into their hands a couple weeks sooner. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 1 13:26:25 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 09:26:25 -0400 Subject: Haskell Support on Windows (Simon Peyton Jones) In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D38BB@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0D38BB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Kyle, we need you to help us with windows support! :-) On Tuesday, April 1, 2014, Simon Peyton Jones wrote: > A couple of poor assumptions are made here. > > > > I?m not sure where ?here? is. In my email I specifically said exactly > what you are saying (only I was not as eloquent as you). > > > > What we need is some developers who are willing to give some love and > support to the Windows version of GHC. And *they* really are thin on the > ground, unfortunately. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] > *On Behalf Of *Kyle Van Berendonck > *Sent:* 01 April 2014 13:54 > *To:* ghc-devs at haskell.org > *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones) > > > > A couple of poor assumptions are made here. > > The first is that the userbase of GHC on Windows is poor. This is false. > In fact, the poor state of Windows is mentioned on #haskell more frequently > as of late. In the last week I've talked almost every day to (different) > people who have had Windows woes with using GHC. The hacker-base isn't here > at the moment - I agree, but the user-base most certainly is. Could this be > a problem with the demographic, or could it just be that Windows > development isn't inviting? The build system and default test failures > in-particular are a source of discouragement. > > The second assumption is that GHC/Haskell will be worth a dime in the > RealWorld without Windows as a primary tier platform. I'm going to put a > crude guess that given the overwhelming magnitude of C#/F# coming up on my > local careers portal that there's far more industry on Windows than on OSX > or Linux. Those are all the businesses where the probability that they will > ever touch Haskell goes from `probably not right now` to `impossible`. Let > me also remind you that Windows still holds 89.2% of operating system > market share ie the people that hackers and developers actually have to > deploy their applications to. > > Sorry to sound fumey, but there's all this suggesting that everyone would > have a better day if we dropped Windows (let's be honest, if it wasn't a > primary tier platform nobody would have fixed it for 7.8), but I doubt few > of the people who think it's a "great idea" or sslt have actually thought > through whether it's the best thing for Haskell or just the best thing to > get 7.8 into their hands a couple weeks sooner. > > Regards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 1 13:45:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 09:45:30 -0400 Subject: Haskell Support on Windows (Simon Peyton Jones) In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0D38BB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hey roman! If you get stuck getting ghc to build on windows, please ask for help on the ghc mailing lists and/or on the #ghc channel on freenode. Just having more folks that regularly try to build and use ghc on windows would be huge. There's also countless ways to contrib To ghc too. On Tuesday, April 1, 2014, Roman Kuznetsov wrote: > Hello, > > -- sorry for incomplete email - typing from mobile is not easy :) > > I would like to participate in GHC on Windows. But I am a normal windows > developer and don't know much of that rather weird (to me) tool chain used > in this case. I frankly tried a few times before - every time with the same > result - I never get to the point, but trying to understand just how to > build it. I know there is a wiki, etc. > > But my question (and the reason I write here): is it possible to have some > kind of mini-course, a crush-course on developing GHC on Windows (as well > as on other platforms) - video course ... this is what comes to mind after > all these Coursera, Pluralsight, etc. > > You could say - there is a wiki. But that's not enough. Maybe it's just > me... I will take another analogy. Even though I'm coding for Windows > primarily, I am a linux user. So, I switched from Ubuntu to Arch Linux > recently which was possible due to the quality of their wiki documentation > (Arch is known to not be as user friendly as *buntu like systems). > > Sorry for not referring to any concrete problems, I just tried stating > what I think didn't let me start working with that. > > /Roman > > On 01 ???. 2014 ?., at 15:26, "Carter Schonwald" < > carter.schonwald at gmail.com> > wrote: > > Kyle, we need you to help us with windows support! :-) > > On Tuesday, April 1, 2014, Simon Peyton Jones > > wrote: > > A couple of poor assumptions are made here. > > > > I?m not sure where ?here? is. In my email I specifically said exactly > what you are saying (only I was not as eloquent as you). > > > > What we need is some developers who are willing to give some love and > support to the Windows version of GHC. And *they* really are thin on the > ground, unfortunately. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Kyle > Van Berendonck > *Sent:* 01 April 2014 13:54 > *To:* ghc-devs at haskell.org > *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones) > > > > A couple of poor assumptions are made here. > > The first is that the userbase of GHC on Windows is poor. This is false. > In fact, the poor state of Windows is mentioned on #haskell more frequently > as of late. In the last week I've talked almost every day to (different) > people who have had Windows woes with using GHC. The hacker-base isn't here > at the moment - I agree, but the user-base most certainly is. Could this be > a problem with the demographic, or could it just be that Windows > development isn't inviting? The build system and default test failures > in-particular are a source of discouragement. > > The second assumption is that GHC/Haskell will be worth a dime in the > RealWorld without Windows as a primary tier platform. I'm going to put a > crude guess that given the overwhelming magnitude of C#/F# coming up on my > local careers portal that there's far more industry on Windows than on OSX > or Linux. Those are all the businesses where the probability that they will > ever touch Haskell goes from `probably not right now` to `impossible`. Let > me also remind you that Windows still holds 89.2% of operating system > market share ie the people that hackers and developers actually have to > deploy their applications to. > > Sorry to sound fumey, but there's all this suggesting that everyone would > have a better day if we dropped Windows (let's be honest, if it wasn't a > primary tier platform nobody would have fixed it for 7.8), but I doubt few > of the people who think it's a "great idea" or sslt have actually thought > through whether it's the best thing for Haskell or just the best thing to > get 7.8 into their hands a couple weeks sooner. > > Regards. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 15:04:58 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 17:04:58 +0200 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the > options. But it depends on a critical evaluation of what the advantages and > disadvantages of different approaches are I found Ian's buildbot an appealing alternative as it does a full build, including testing, and uploads the resulting binaries to a common place where anybody can access them (but it can be configured to do almost anything). The builders may be configured individually from a single (Haskell-language) configuration file and they are run on various volunteer-supplied systems so it is also distributed. I use this to keep track of the status of the FreeBSD builds to make my work easier on building the releases and maintaining the associated ports in the FreeBSD Ports Collection, while offering regular developer snapshots for the users. This approach also allows me to control and maintain the builder environment too as it may require minor or major changes and fixes over time that I can do myself as a FreeBSD developer. In the past, there were cases where the build was failing due to bugs in the kernel or the userland, so this is not purely about GHC itself (unfortunately). In my humble opinon, there are merits for the Travis-based Continuous Integration, so as for the daily snapshot building on each supported platform. I do not care if it is not Haskell-based or it is hosted at a central place with individual Virtual Machines for each platform -- until I can keep doing what I have been doing for 4 years now. From carter.schonwald at gmail.com Tue Apr 1 17:45:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 13:45:27 -0400 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: hey all, I just exported the igloo builder code from darcs to git, and put it here https://github.com/cartazio/ghc-builder would this be something worth adding to github.com/haskell ? (i can easily add it if other folks it should be surfaced more visibly) On Tue, Apr 1, 2014 at 11:04 AM, P?li G?bor J?nos wrote: > 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : > > Indeed, there is no reason not to use Ian et al's Builder stuff. It's > one of the > > options. But it depends on a critical evaluation of what the advantages > and > > disadvantages of different approaches are > > I found Ian's buildbot an appealing alternative as it does a full > build, including testing, and uploads the resulting binaries to a > common place where anybody can access them (but it can be configured > to do almost anything). The builders may be configured individually > from a single (Haskell-language) configuration file and they are run > on various volunteer-supplied systems so it is also distributed. > > I use this to keep track of the status of the FreeBSD builds to make > my work easier on building the releases and maintaining the associated > ports in the FreeBSD Ports Collection, while offering regular > developer snapshots for the users. This approach also allows me to > control and maintain the builder environment too as it may require > minor or major changes and fixes over time that I can do myself as a > FreeBSD developer. In the past, there were cases where the build was > failing due to bugs in the kernel or the userland, so this is not > purely about GHC itself (unfortunately). > > In my humble opinon, there are merits for the Travis-based Continuous > Integration, so as for the daily snapshot building on each supported > platform. I do not care if it is not Haskell-based or it is hosted at > a central place with individual Virtual Machines for each platform -- > until I can keep doing what I have been doing for 4 years now. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Tue Apr 1 18:15:12 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 18:15:12 +0000 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Thank you Carter. I think it's reasonable to incubate it on your Github profile for now until we are certain it is fully working again. Either way works though :) Best, Alain > On Apr 1, 2014, at 17:45, Carter Schonwald wrote: > > hey all, I just exported the igloo builder code from darcs to git, and put it here https://github.com/cartazio/ghc-builder > would this be something worth adding to github.com/haskell ? (i can easily add it if other folks it should be surfaced more visibly) > > >> On Tue, Apr 1, 2014 at 11:04 AM, P?li G?bor J?nos wrote: >> 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : >> > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the >> > options. But it depends on a critical evaluation of what the advantages and >> > disadvantages of different approaches are >> >> I found Ian's buildbot an appealing alternative as it does a full >> build, including testing, and uploads the resulting binaries to a >> common place where anybody can access them (but it can be configured >> to do almost anything). The builders may be configured individually >> from a single (Haskell-language) configuration file and they are run >> on various volunteer-supplied systems so it is also distributed. >> >> I use this to keep track of the status of the FreeBSD builds to make >> my work easier on building the releases and maintaining the associated >> ports in the FreeBSD Ports Collection, while offering regular >> developer snapshots for the users. This approach also allows me to >> control and maintain the builder environment too as it may require >> minor or major changes and fixes over time that I can do myself as a >> FreeBSD developer. In the past, there were cases where the build was >> failing due to bugs in the kernel or the userland, so this is not >> purely about GHC itself (unfortunately). >> >> In my humble opinon, there are merits for the Travis-based Continuous >> Integration, so as for the daily snapshot building on each supported >> platform. I do not care if it is not Haskell-based or it is hosted at >> a central place with individual Virtual Machines for each platform -- >> until I can keep doing what I have been doing for 4 years now. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 18:45:30 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 20:45:30 +0200 Subject: Buildbots In-Reply-To: <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: 2014-04-01 20:15 GMT+02:00 Alain O'Dea : > until we are certain it is fully working again. In what sense? I have been using the latest checkout from the darcs repository for both the server and the clients, I seldom experienced any serious problems. Of course, there is place for improvements and there are some rough edges, but I think it is quite usable, even in its current state. From carter.schonwald at gmail.com Tue Apr 1 18:50:06 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 14:50:06 -0400 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: good to know (i assumed it was in working order from your remarks) I think making it more surfaced / discoverable might enable a lot more volunteer build bots (which is an issue aside from maintaining it) of course, officially moving it to github should be with ian's blessing, its mostly his work afaik :) On Tue, Apr 1, 2014 at 2:45 PM, P?li G?bor J?nos wrote: > 2014-04-01 20:15 GMT+02:00 Alain O'Dea : > > until we are certain it is fully working again. > > In what sense? I have been using the latest checkout from the darcs > repository for both the server and the clients, I seldom experienced > any serious problems. Of course, there is place for improvements and > there are some rough edges, but I think it is quite usable, even in > its current state. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 19:03:31 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 21:03:31 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: 2014-04-01 20:50 GMT+02:00 Carter Schonwald : > I think making it more surfaced / discoverable might enable a lot more > volunteer build bots (which is an issue aside from maintaining it) As Karel has indicated, I have been already running an instance of the server and I am generally open to adding further clients, if you think this would be useful. Perhaps the only limitation would be the disk space for storing all the snapshots builds for all the all clients, but I could easily solve this problem :-) Or, if you want to move the whole service to some more official place, e.g. under the haskell.org infrastructure, I am happy to help with restarting the service, I already earned some experience in running both sides over the years. From johan.tibell at gmail.com Tue Apr 1 19:07:47 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 1 Apr 2014 21:07:47 +0200 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: On Tue, Apr 1, 2014 at 12:46 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: > > Joachim Breitner has set up Travis-CI. (I don't know exactly what > > that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tests (in our case, a > stripped version of validate) upon pushes to git repositories on github. > I set it up to validate our master, so we get a nice history of > successes and failures on > https://travis-ci.org/nomeata/ghc-complete/builds > and I get mails when things fail; that is when I send hopefully polite > enough mails to ghc-dev, asking people to fix their commits. > > (Unless I broke it myself; then I silently fix it and hide.) > If the false positive rate is low, feel free to automatically have the emails sent to ghc-devs at . We want to know when we broke stuff ASAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Tue Apr 1 19:09:08 2014 From: igloo at earth.li (Ian Lynagh) Date: Tue, 1 Apr 2014 20:09:08 +0100 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <20140401190908.GA2827@matrix.chaos.earth.li> On Tue, Apr 01, 2014 at 12:46:05PM +0200, Joachim Breitner wrote: > > happy with buildbot, it might not be the worst choice. For reference, the reason we moved away from buildbot is that it needs to maintain a TCP connection for the duration of the build. With some builds taking many hours (either on old platforms, or on modern hardware but with a full testsuite run and nofib etc) it was common that a brief network glitch caused a build to not finish. Thanks Ian From mail at joachim-breitner.de Tue Apr 1 21:30:20 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 23:30:20 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <1396387820.26868.7.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 21:07 +0200 schrieb Johan Tibell: > If the false positive rate is low, feel free to automatically have the > emails sent to ghc-devs at . We want to know when we broke stuff ASAP. unfortunately, it is not as low as it should be, partially because of hitting the 50 minute limit, partially errors while cloning or other non-GHC-related errors. So unless you insist that we should try it I?ll rather do the manual filtering. Or we could have a "ghc-bots" mailinglist where any kind of machine-generated GHC-related mails can be sent to, then interested parties can subscribe. I can also manually add people to receive the travis mails, so if any of you feel QAish today, let me know. (I was about to suggest to add the statuses and links to build logs as git notes, so that "git log" would show that, but git notes are not pullable in a convenient way, so I don?t suggest that.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From pali.gabor at gmail.com Tue Apr 1 21:38:43 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 23:38:43 +0200 Subject: Buildbots In-Reply-To: <1396387820.26868.7.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396387820.26868.7.camel@kirk> Message-ID: 2014-04-01 23:30 GMT+02:00 Joachim Breitner : > Or we could have a "ghc-bots" mailinglist where any kind of > machine-generated GHC-related mails can be sent to, then interested > parties can subscribe. There is ghc-builds [1] for the daily snapshot builders, would not that be good for this purpose as well? [1] http://www.haskell.org/mailman/listinfo/ghc-builds From mail at joachim-breitner.de Tue Apr 1 21:42:50 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 23:42:50 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396387820.26868.7.camel@kirk> Message-ID: <1396388570.26868.9.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 23:38 +0200 schrieb P?li G?bor J?nos: > 2014-04-01 23:30 GMT+02:00 Joachim Breitner : > > Or we could have a "ghc-bots" mailinglist where any kind of > > machine-generated GHC-related mails can be sent to, then interested > > parties can subscribe. > > There is ghc-builds [1] for the daily snapshot builders, would not > that be good for this purpose as well? > > [1] http://www.haskell.org/mailman/listinfo/ghc-builds heh, I should check if things exist before suggesting them. Travis should now also send its notifications to that address. Let me know if the false positives annoy anyone. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvr at gnu.org Wed Apr 2 07:14:28 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 02 Apr 2014 09:14:28 +0200 Subject: Compiling GHC with Clang Message-ID: <87bnwki4ob.fsf@gnu.org> Hello *, I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by configuring the build with CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang but then, 'make' runs into ,---- | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-7.8.0.20140401 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.2 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno compiler/stage2/build/Lexer.dyn_o | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ?[Char]? with actual type ?Int#? | In the first argument of ?(>=)?, namely ?offset? | In the expression: (offset >= "0#") | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ?Int#? with actual type ?Bool? | In the expression: (offset >= "0#") | In the first argument of ?(&&)?, namely | ?(tagToEnum# (offset >= "0#"))? | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ?[Char]? with actual type ?Int#? | In the first argument of ?(==)?, namely ?check? | In the expression: (check == "ord_c") | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ?Int#? with actual type ?Bool? | In the expression: (check == "ord_c") | In the second argument of ?(&&)?, namely | ?(tagToEnum# (check == "ord_c"))? | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 | make: *** [all] Error 2 `---- the versions of happy & alex were: ,---- | $ happy --version | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow | | $ alex --version | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow `---- ...anyone know why this happens when using Clang instead of GCC, or better yet, what I need to do in order to build GHC with Clang on Linux? From Christian.Maeder at dfki.de Wed Apr 2 07:35:31 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 02 Apr 2014 09:35:31 +0200 Subject: Compiling GHC with Clang In-Reply-To: <87bnwki4ob.fsf@gnu.org> References: <87bnwki4ob.fsf@gnu.org> Message-ID: <533BBDC3.6040707@dfki.de> I had a similar problem on a Mac (and clang) that I could solve by updating to the versions of (happy and) alex that you already use. Are you sure that Lexer.hs was freshly (re-)generated? HTH Christian Am 02.04.2014 09:14, schrieb Herbert Valerio Riedel: > Hello *, > > I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by > configuring the build with > > CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang > > but then, 'make' runs into > > ,---- > | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-7.8.0.20140401 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package by testring- 0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.2 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno compiler/stage2/build/Lexer.dyn_o > | > | compiler/stage2/build/Lexer.hs:2426:41: > | Couldn't match expected type ?[Char]? with actual type ?Int#? > | In the first argument of ?(>=)?, namely ?offset? > | In the expression: (offset >= "0#") > | > | compiler/stage2/build/Lexer.hs:2426:41: > | Couldn't match expected type ?Int#? with actual type ?Bool? > | In the expression: (offset >= "0#") > | In the first argument of ?(&&)?, namely > | ?(tagToEnum# (offset >= "0#"))? > | In the expression: > | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) > | > | compiler/stage2/build/Lexer.hs:2426:73: > | Couldn't match expected type ?[Char]? with actual type ?Int#? > | In the first argument of ?(==)?, namely ?check? > | In the expression: (check == "ord_c") > | > | compiler/stage2/build/Lexer.hs:2426:73: > | Couldn't match expected type ?Int#? with actual type ?Bool? > | In the expression: (check == "ord_c") > | In the second argument of ?(&&)?, namely > | ?(tagToEnum# (check == "ord_c"))? > | In the expression: > | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) > | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 > | make: *** [all] Error 2 > `---- > > the versions of happy & alex were: > > ,---- > | $ happy --version > | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow > | > | $ alex --version > | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow > `---- > > ...anyone know why this happens when using Clang instead of GCC, or > better yet, what I need to do in order to build GHC with Clang on Linux? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From Christian.Maeder at dfki.de Wed Apr 2 07:44:03 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 02 Apr 2014 09:44:03 +0200 Subject: Compiling GHC with Clang In-Reply-To: <87bnwki4ob.fsf@gnu.org> References: <87bnwki4ob.fsf@gnu.org> Message-ID: <533BBFC3.10103@dfki.de> Maybe alex needs to be compiled with clang, too? C. Am 02.04.2014 09:14, schrieb Herbert Valerio Riedel: > Hello *, > > I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by > configuring the build with > > CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang > > but then, 'make' runs into > > ,---- > | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-7.8.0.20140401 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package by testring- 0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.2 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno compiler/stage2/build/Lexer.dyn_o > | > | compiler/stage2/build/Lexer.hs:2426:41: > | Couldn't match expected type ?[Char]? with actual type ?Int#? > | In the first argument of ?(>=)?, namely ?offset? > | In the expression: (offset >= "0#") > | > | compiler/stage2/build/Lexer.hs:2426:41: > | Couldn't match expected type ?Int#? with actual type ?Bool? > | In the expression: (offset >= "0#") > | In the first argument of ?(&&)?, namely > | ?(tagToEnum# (offset >= "0#"))? > | In the expression: > | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) > | > | compiler/stage2/build/Lexer.hs:2426:73: > | Couldn't match expected type ?[Char]? with actual type ?Int#? > | In the first argument of ?(==)?, namely ?check? > | In the expression: (check == "ord_c") > | > | compiler/stage2/build/Lexer.hs:2426:73: > | Couldn't match expected type ?Int#? with actual type ?Bool? > | In the expression: (check == "ord_c") > | In the second argument of ?(&&)?, namely > | ?(tagToEnum# (check == "ord_c"))? > | In the expression: > | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) > | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 > | make: *** [all] Error 2 > `---- > > the versions of happy & alex were: > > ,---- > | $ happy --version > | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow > | > | $ alex --version > | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow > `---- > > ...anyone know why this happens when using Clang instead of GCC, or > better yet, what I need to do in order to build GHC with Clang on Linux? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From hvriedel at gmail.com Wed Apr 2 07:49:35 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 02 Apr 2014 09:49:35 +0200 Subject: Compiling GHC with Clang In-Reply-To: <533BBDC3.6040707@dfki.de> (Christian Maeder's message of "Wed, 02 Apr 2014 09:35:31 +0200") References: <87bnwki4ob.fsf@gnu.org> <533BBDC3.6040707@dfki.de> Message-ID: <877g78i31s.fsf@gmail.com> On 2014-04-02 at 09:35:31 +0200, Christian Maeder wrote: > I had a similar problem on a Mac (and clang) that I could solve by > updating to the versions of (happy and) alex that you already use. Are > you sure that Lexer.hs was freshly (re-)generated? ...it was freshly generated (by [1] - I forced it to be recreated by removing it), and it has exactly the same content it has when using GCC for building (which succeeds compiling it) Does it make a difference whether 'Alex' was compiled by a Clang-configured GHC in the first place? [1]: "${HOME}/.cabal/bin/alex" -g --latin1 compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs ...and ${HOME}/.cabal/bin/alex is in fact version 3.1.3 From Christian.Maeder at dfki.de Wed Apr 2 08:21:53 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 02 Apr 2014 10:21:53 +0200 Subject: Compiling GHC with Clang In-Reply-To: <877g78i31s.fsf@gmail.com> References: <87bnwki4ob.fsf@gnu.org> <533BBDC3.6040707@dfki.de> <877g78i31s.fsf@gmail.com> Message-ID: <533BC8A1.1030000@dfki.de> In the sources of ghc-7.8-rc2 I only find the file compiler/parser/Lexer.x.source How is this one turned into a file Lexer.x? Am 02.04.2014 09:49, schrieb Herbert Valerio Riedel: > On 2014-04-02 at 09:35:31 +0200, Christian Maeder wrote: >> I had a similar problem on a Mac (and clang) that I could solve by >> updating to the versions of (happy and) alex that you already use. Are >> you sure that Lexer.hs was freshly (re-)generated? > > ...it was freshly generated (by [1] - I forced it to be recreated by > removing it), and it has exactly the same content it has when using GCC > for building (which succeeds compiling it) > > Does it make a difference whether 'Alex' was compiled by a > Clang-configured GHC in the first place? > > > > [1]: "${HOME}/.cabal/bin/alex" -g --latin1 compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs > > ...and ${HOME}/.cabal/bin/alex is in fact version 3.1.3 > > From hvr at gnu.org Wed Apr 2 10:18:08 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 02 Apr 2014 12:18:08 +0200 Subject: Compiling GHC with Clang In-Reply-To: <533BBFC3.10103@dfki.de> (Christian Maeder's message of "Wed, 02 Apr 2014 09:44:03 +0200") References: <87bnwki4ob.fsf@gnu.org> <533BBFC3.10103@dfki.de> Message-ID: <8738hwhw67.fsf@gnu.org> On 2014-04-02 at 09:44:03 +0200, Christian Maeder wrote: > Maybe alex needs to be compiled with clang, too? If that's really the case, I have a little bit of a bootstrapping problem: How can I get a Clang-built Alex, on a platform where I only have a GCC-configured GHC available? From Christian.Maeder at dfki.de Wed Apr 2 10:51:43 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 02 Apr 2014 12:51:43 +0200 Subject: Compiling GHC with Clang In-Reply-To: <533BC8A1.1030000@dfki.de> References: <87bnwki4ob.fsf@gnu.org> <533BBDC3.6040707@dfki.de> <877g78i31s.fsf@gmail.com> <533BC8A1.1030000@dfki.de> Message-ID: <533BEBBF.5090609@dfki.de> Am 02.04.2014 10:21, schrieb Christian Maeder: > In the sources of ghc-7.8-rc2 I only find the file > compiler/parser/Lexer.x.source > > How is this one turned into a file Lexer.x? Just by renaming! It seems Lexer.x was moved to Lexer.x.source in order to avoid regeneration of Lexer.hs. C. > > Am 02.04.2014 09:49, schrieb Herbert Valerio Riedel: >> On 2014-04-02 at 09:35:31 +0200, Christian Maeder wrote: >>> I had a similar problem on a Mac (and clang) that I could solve by >>> updating to the versions of (happy and) alex that you already use. Are >>> you sure that Lexer.hs was freshly (re-)generated? >> >> ...it was freshly generated (by [1] - I forced it to be recreated by >> removing it), and it has exactly the same content it has when using GCC >> for building (which succeeds compiling it) >> >> Does it make a difference whether 'Alex' was compiled by a >> Clang-configured GHC in the first place? >> >> >> >> [1]: "${HOME}/.cabal/bin/alex" -g --latin1 >> compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs >> >> ...and ${HOME}/.cabal/bin/alex is in fact version 3.1.3 >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > From hvr at gnu.org Wed Apr 2 12:41:07 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 02 Apr 2014 14:41:07 +0200 Subject: Compiling GHC with Clang In-Reply-To: <87bnwki4ob.fsf@gnu.org> (Herbert Valerio Riedel's message of "Wed, 02 Apr 2014 09:14:28 +0200") References: <87bnwki4ob.fsf@gnu.org> Message-ID: <87d2gzhpjw.fsf@gmail.com> On 2014-04-02 at 09:14:28 +0200, Herbert Valerio Riedel wrote: [...] > | compiler/stage2/build/Lexer.hs:2426:41: > | Couldn't match expected type ?[Char]? with actual type ?Int#? > | In the first argument of ?(>=)?, namely ?offset? > | In the expression: (offset >= "0#") FYI: I've found the cause, it's due to Clang's pre-processor: The line in question is new_s = if GTE(offset,0#) && EQ(check,ord_c) while the GET and EQ macros are defined as #if __GLASGOW_HASKELL__ > 706 #define GTE(n,m) (tagToEnum# (n >=# m)) #define EQ(n,m) (tagToEnum# (n ==# m)) #else #define GTE(n,m) (n >=# m) #define EQ(n,m) (n ==# m) #endif However, this is preprocessed into new_s = if (tagToEnum# (offset >="0#")) && (tagToEnum# (check =="ord_c")) meaning that Clang's CPP made use of the stringifying operator '#' to turn '0#' into '"0#"' From Christian.Maeder at dfki.de Wed Apr 2 14:06:12 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 02 Apr 2014 16:06:12 +0200 Subject: Compiling GHC with Clang In-Reply-To: <533BBDC3.6040707@dfki.de> References: <87bnwki4ob.fsf@gnu.org> <533BBDC3.6040707@dfki.de> Message-ID: <533C1954.9030109@dfki.de> Probably I could only update alex and happy after using https://www.haskell.org/platform/ghc-clang-wrapper that indirectly solved my problem. Sorry for the confusion. Christian Am 02.04.2014 09:35, schrieb Christian Maeder: > I had a similar problem on a Mac (and clang) that I could solve by > updating to the versions of (happy and) alex that you already use. Are > you sure that Lexer.hs was freshly (re-)generated? > > HTH Christian > > Am 02.04.2014 09:14, schrieb Herbert Valerio Riedel: >> Hello *, >> >> I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by >> configuring the build with >> >> CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang >> >> but then, 'make' runs into >> >> ,---- >> | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m >> -O0 -fasm -package-name ghc-7.8.0.20140401 -hide-all-packages -i >> -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen >> -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn >> -icompiler/iface -icompiler/llvmGen -icompiler/main >> -icompiler/nativeGen -icompiler/parser -icompiler/prelude >> -icompiler/profiling -icompiler/rename -icompiler/simplCore >> -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn >> -icompiler/stranal -icompiler/typecheck -icompiler/types >> -icompiler/utils -icompiler/vectorise -icompiler/stage2/build >> -icompiler/stage2/build/autogen -Icompiler/stage2/build >> -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser >> -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 >> -optP-DGHCI -optP-include >> -optPcompiler/stage2/build/autogen/cabal_macros.h -package >> Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package >> bin-package-db-0.0.0.0 -package by > testring- > 0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package > filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package > process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.2 > -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall > -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples > -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls > -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances > -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns > -XNondecreasingIndentation -optc-DTHREADED_RTS > -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-db > -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build > -stubdir compiler/stage2/build -dynamic-too -c > compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno > compiler/stage2/build/Lexer.dyn_o >> | >> | compiler/stage2/build/Lexer.hs:2426:41: >> | Couldn't match expected type ?[Char]? with actual type ?Int#? >> | In the first argument of ?(>=)?, namely ?offset? >> | In the expression: (offset >= "0#") >> | >> | compiler/stage2/build/Lexer.hs:2426:41: >> | Couldn't match expected type ?Int#? with actual type ?Bool? >> | In the expression: (offset >= "0#") >> | In the first argument of ?(&&)?, namely >> | ?(tagToEnum# (offset >= "0#"))? >> | In the expression: >> | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) >> | >> | compiler/stage2/build/Lexer.hs:2426:73: >> | Couldn't match expected type ?[Char]? with actual type ?Int#? >> | In the first argument of ?(==)?, namely ?check? >> | In the expression: (check == "ord_c") >> | >> | compiler/stage2/build/Lexer.hs:2426:73: >> | Couldn't match expected type ?Int#? with actual type ?Bool? >> | In the expression: (check == "ord_c") >> | In the second argument of ?(&&)?, namely >> | ?(tagToEnum# (check == "ord_c"))? >> | In the expression: >> | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) >> | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 >> | make: *** [all] Error 2 >> `---- >> >> the versions of happy & alex were: >> >> ,---- >> | $ happy --version >> | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow >> (c) 1997-2005 Simon Marlow >> | >> | $ alex --version >> | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow >> `---- >> >> ...anyone know why this happens when using Clang instead of GCC, or >> better yet, what I need to do in order to build GHC with Clang on Linux? >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Apr 2 14:17:40 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 2 Apr 2014 10:17:40 -0400 Subject: Backward-compatible role annotations In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456E! C6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> Message-ID: Ah -- I see. Interesting suggestion. As we're not thinking much now about the change to a nominal default (definitely too late for 7.8), I've recorded this idea on the roles wiki page (https://ghc.haskell.org/trac/ghc/wiki/Roles) for easy recovery in the future. I think the idea has merit, but there's no concrete action to take on it, at the moment. Thanks, Richard On Mar 31, 2014, at 2:12 PM, Dominique Devriese wrote: > Richard, > > Right, but I was thinking about the debate between > "nominal/non-parametric-by-default" or > "representational/parametric-by-default" for parameters of data types > that aren't forced to nominal from inspecting the datatype > implementation. As I understand it, representational-by-default > (currently used) may leave libraries that don't add role annotations > open for abuse, but won't unnecessarily break library users' code and > nominal-by-default prevents all abuse but may unnecessarily break code > that uses libraries that have not added proper role annotations. > > What I was wondering about is if the dilemma could be solved by > choosing nominal-by-default in the long term for the role inference > (so that library writers cannot accidentally leave abstraction holes > open by forgetting to add role annotations) and use them in the > long-term-supported SafeNewtypeDeriving extension, but provide a > deprecated not-quite-as-safe GND extension for helping out users of > libraries that have not yet added role annotations. I would fancy that > this not-quite-as-safe GND could use unsafeCoerce wherever the safe > one would give an error about annotated roles. > > Regards, > Dominique > > 2014-03-31 17:05 GMT+02:00 Richard Eisenberg : >> Hi Dominique, >> >> When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. >> >> The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. >> >> Richard >> >> On Mar 31, 2014, at 2:51 AM, Dominique Devriese wrote: >> >>> Richard, >>> >>> (re-posting because I first used an address that is not subscribed to the lists) >>> >>> I've been wondering about the following: it seems like the main >>> problem in this situation is that the GeneralizedNewtypeDeriving >>> extension changed meaning from "just coerce everything while deriving" >>> to "only coerce stuff if it's allowed by the relevant role >>> annotations". Would it not be an alternative solution to split up the >>> GND extension into >>> >>> * a backwards-compatible one (called GeneralizedNewtypeDeriving for >>> backwards compatibility ;)) that ignores role annotations (as before) >>> and uses unsafeCoerce whereever necessary >>> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations >>> >>> The first one could then be deprecated and removed in a release or >>> two. That might give library maintainers time to move their packages >>> to SafeNewtypeDeriving when they have tested that everything works... >>> >>> Regards, >>> Dominique >>> >>> P.S.: The above is based on a limited understanding of the problem, so >>> I'm sorry if it misses some aspect of the problem... >>> >>> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : >>>> I spent some time thinking about what, precisely, can be done here to make >>>> folks happier. (See the thread beginning here: >>>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the >>>> answer seemed to all be in the concrete syntax. The only logical alternative >>>> (that I could think of) to having roles is to disallow GND, and I don't >>>> think anyone is proposing that. And, it is impossible to infer an author's >>>> desired roles for a datatype. The heuristics mentioned here all seem far too >>>> fragile and hard to predict to become a lasting feature of GHC (in my >>>> opinion). What's left? Concrete syntax. >>>> >>>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible >>>> alternative to role annotations -- no CPP required. It's not as principled >>>> as proper role annotations, but it should do the job for most users. >>>> >>>> Here are two examples: >>>> >>>> 1. Datatypes: >>>> >>>>> import Language.Haskell.RoleAnnots >>>>> >>>>> data Map k v = >>>>> (Nominal k, Representational v) => MkMap [(k,v)] >>>> >>>> The constraints (which need be put on only one data constructor, if there >>>> are many) will get the built-in role inference mechanism to do what the user >>>> requests. In this example, the `Representational v` is actually redundant, >>>> but causes no harm. Because these classes have universal instances >>>> ("instance Nominal a") and have no methods, they should have no run-time >>>> significance. The only downside I can see is that the code above needs >>>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT >>>> nor has existentials. (Pattern-matching on such a definition needs no >>>> extensions.) >>>> >>>> 2. Newtypes: >>>> >>>> Newtype constructors cannot be constrained, unfortunately. So, we have to >>>> resort to Template Haskell: >>>> >>>>> import Language.Haskell.RoleAnnots >>>>> >>>>> roleAnnot [NominalR, RepresentationalR] >>>>> [d| newtype Map k v = MkMap [(k, v)] |] >>>> >>>> This is clearly worse, but I was able to come up with no other solution that >>>> worked for newtypes. Note that, in the example, I used the fact that >>>> Template Haskell interprets a bare top-level expression as a Template >>>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit >>>> about the use of TH. Also problematic here is that the code above requires >>>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using >>>> CPP, put it in a condition chunk in your .cabal file, like this: >>>> >>>>> if impl(ghc >= 7.8) >>>>> default-extensions: RoleAnnotations >>>> >>>> I hope this is helpful to everyone. Please feel free to post issues/pull >>>> requests to my github repo at github.com/goldfirere/no-role-annots. >>>> >>>> Thanks, >>>> Richard >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >> > From varosi at gmail.com Wed Apr 2 16:30:46 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Wed, 2 Apr 2014 19:30:46 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: <5335BAC4.40304@centrum.cz> References: <5335BAC4.40304@centrum.cz> Message-ID: Hello! Thanks, it continued with building until some LLVM errors. But will --with-gcc= arm based compiler will create GHC with: Host: x86 Ubuntu (where compilation should happen) Target: ARMv7 Linux ? Because I don't want to have GHC on my slow and restricted ARM machine. Best regards, Vassil 2014-03-28 20:09 GMT+02:00 Karel Gardas : > > Last time I did that (crossing to ARMv8) I needed to use --with-gcc= compiler> option since for some reason I had not time to debug setting > target triple with --target was not enough. Speaking about GHC HEAD as of > new year eve (2014) time... > > But well, since it this is already some time I'm not sure this was to cure > issue like you have now, but at least you may give it a try... > > Karel > > > On 03/28/14 06:08 PM, eng. Vassil Ognyanov Keremidchiev wrote: > >> Hello! >> >> Could someone help me with compiling GHC under Ubuntu as a ARM >> cross-compiler? >> >> Currently I have done those steps: >> sudo apt-get update >> sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev >> libncurses5-dev ghc-haddock >> sudo export PATH=~/.cabal/bin:$PATH >> sudo cabal install --reinstall happy alex terminfo libffi html >> regex-compat >> >> git clone http://darcs.haskell.org/ghc.git >> cd ghc >> >> ./sync-all --no-dph get >> ./sync-all pull >> ./boot >> sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised >> cp mk/build.mk.sample mk/build.mk >> >> # here I enable quick-cross configuration >> sudo make >> >> and I get: >> >> echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >> >> compiler/stage1/build/.depend-v.c_asm.tmp >> mv compiler/stage1/build/.depend-v.c_asm.tmp >> compiler/stage1/build/.depend-v.c_asm >> inplace/bin/deriveConstants --gen-header -o >> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir >> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" >> --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag >> -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header >> --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts >> --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm" >> /usr/bin/arm-linux-gnueabi-nm: >> includes/dist-derivedconstants/header/tmp.o: File format not recognized >> deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm >> "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed >> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] >> Error 1 >> make: *** [all] Error 2 >> >> >> What I have done wrong? I did not understand the error message well, too. >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Apr 2 16:58:34 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 2 Apr 2014 12:58:34 -0400 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> Message-ID: have you read the cross compiler directions on the wiki? :) https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation http://www.haskell.org/haskellwiki/ARM On Wed, Apr 2, 2014 at 12:30 PM, eng. Vassil Ognyanov Keremidchiev < varosi at gmail.com> wrote: > Hello! > > Thanks, it continued with building until some LLVM errors. > But will --with-gcc= arm based compiler will create GHC with: > Host: x86 Ubuntu (where compilation should happen) > Target: ARMv7 Linux ? > > Because I don't want to have GHC on my slow and restricted ARM machine. > > Best regards, > Vassil > > > 2014-03-28 20:09 GMT+02:00 Karel Gardas : > > >> Last time I did that (crossing to ARMv8) I needed to use >> --with-gcc= option since for some reason I had not time to >> debug setting target triple with --target was not enough. Speaking about >> GHC HEAD as of new year eve (2014) time... >> >> But well, since it this is already some time I'm not sure this was to >> cure issue like you have now, but at least you may give it a try... >> >> Karel >> >> >> On 03/28/14 06:08 PM, eng. Vassil Ognyanov Keremidchiev wrote: >> >>> Hello! >>> >>> Could someone help me with compiling GHC under Ubuntu as a ARM >>> cross-compiler? >>> >>> Currently I have done those steps: >>> sudo apt-get update >>> sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev >>> libncurses5-dev ghc-haddock >>> sudo export PATH=~/.cabal/bin:$PATH >>> sudo cabal install --reinstall happy alex terminfo libffi html >>> regex-compat >>> >>> git clone http://darcs.haskell.org/ghc.git >>> cd ghc >>> >>> ./sync-all --no-dph get >>> ./sync-all pull >>> ./boot >>> sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised >>> cp mk/build.mk.sample mk/build.mk >>> >>> # here I enable quick-cross configuration >>> sudo make >>> >>> and I get: >>> >>> echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >> >>> compiler/stage1/build/.depend-v.c_asm.tmp >>> mv compiler/stage1/build/.depend-v.c_asm.tmp >>> compiler/stage1/build/.depend-v.c_asm >>> inplace/bin/deriveConstants --gen-header -o >>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir >>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" >>> --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag >>> -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header >>> --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts >>> --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm" >>> /usr/bin/arm-linux-gnueabi-nm: >>> includes/dist-derivedconstants/header/tmp.o: File format not recognized >>> deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm >>> "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed >>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] >>> Error 1 >>> make: *** [all] Error 2 >>> >>> >>> What I have done wrong? I did not understand the error message well, too. >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 3 07:57:41 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 3 Apr 2014 07:57:41 +0000 Subject: [GHC] #8953: Inner Thigh Slimming Exercises for Women In-Reply-To: <046.99b081b1b136bc6f77e6abe124676ab6@haskell.org> References: <046.99b081b1b136bc6f77e6abe124676ab6@haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D7CBE@DB3PRD3001MB020.064d.mgd.msft.net> Folks, The GHC Trac is attracting spam. Does anyone know enough to stop it? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of | GHC | Sent: 03 April 2014 05:26 | Cc: ghc-tickets at haskell.org | Subject: [GHC] #8953: Inner Thigh Slimming Exercises for Women | | #8953: Inner Thigh Slimming Exercises for Women | ------------------------------------+----------------------------------- | ------------------------------------+-- | Reporter: szxdai1 | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Keywords: | Operating System: | Unknown/Multiple | Architecture: Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | | ------------------------------------+----------------------------------- | ------------------------------------+-- | How To Decline Thigh Coefficient or retrogress weight swift around your | thighs offers quite a bit to do with intrinsic helping slimming | exercises. | The easiest method to worsen weight from your thighs would be to do | exercises that aim your minify body. Inside serving slimming workouts | are those workouts that mostly rivet on the fat around your exclusive | thighs. | Virtuous some any portion training contributes to losing helping | coefficient mostly. When you essential to worsen coefficient around your | privileged thighs and immobile up, You may penury to accomplish several | special exercises that alter on this region. I am achievement to part | with you two of the most operative helping slimming exercises. | [http://tryabsolutegarciniacambogia.com/ ABSOLUTE GARCINIA CAMBOGIA] | Decline unit accelerated Around Your Thighs Workouts Leg Butterfly | Broad: -This use works rise for broad the intrinsical thighs, Making | yourself solon elastic and in acquisition it helps with the toning of | the thighs. To perform this workout, You instrument hump to sit on a | carpeted story after which juncture your soles from the feet together. | Your legs is accomplishment to be unstoppered but both of the feet | instrument attack apiece other. When you're in this berth, Countenance | the knees to alter to the flooring. Lessen your knees towards the | flooring as much as you can for the way pliable you are. Spell | performing this recitation, rub both hands stretchability around your | privileged thighs. | Intrinsical Serving Firmer Workout: -You give feature to fulfill this | helping slimming learn part a small layer and also be certain you | somebody a towel or a dinky wide to relax your brain on. To fulfil this | workout, Lie in your sinistral indorse and urinate careful your surface | is resting on a folded departed towel or bittie encompassing. This | truly is to coil. | And protect your manus leg change to the base, Slowly flex the best leg | towards the deceiver individuals. Now you gift essential to uprise your | unexhausted leg for active six inches off the level and suppress it for | many transactions. Then petty it to the turn item and now cultivate it | as existence presently as it touches the mat {other tract endorse. Do | that sleazy portion workout on the sides with the similar repeating. | These serving slimming workouts are painless to fulfil and they could | be comfortably through from the status of your own asylum. If you are | disagreeable to chant up and get narrow thighs, Then I suggest that you | do aerophilic exercises too. Recollect your fasting as what you eat | counts for your upbeat too. For statesman useful message on how to | retrograde serving coefficient in the subordinate part of your body, | Impose Privileged helping slimming exercises beneath. Recede metric | firm around your thighs is about punish in both consumption a growing | fasting organisation and regular workout.'''ABSOLUTE GARCINIA | CAMBOGIA''' | Decline metric allegro around your thighs else finest workouts which | are outgo extricated permit functional, Jogging and aquatics. They are | fun to do exercises that you ought to sicken benefit of. Don't think | that visiting the gym is the exclusive way to total serving slimming | exercises. | Keep your expensive gym body money and remain physically energetic by | exertion from base and doing fun aerophilous workouts inaccurate. | http://tryabsolutegarciniacambogia.com/ | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets From simonpj at microsoft.com Thu Apr 3 08:19:42 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 3 Apr 2014 08:19:42 +0000 Subject: GHC Trac donw Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D82B9@DB3PRD3001MB020.064d.mgd.msft.net> Accessing the GHC Trac yields https://ghc.haskell.org/trac/ghc/ Error TracError: The Trac Environment needs to be upgraded. Run "trac-admin /home/trac/ghc upgrade" Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Apr 3 08:27:58 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 03 Apr 2014 10:27:58 +0200 Subject: GHC Trac donw In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D82B9@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Thu, 3 Apr 2014 08:19:42 +0000") References: <618BE556AADD624C9C918AA5D5911BEF0D82B9@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87a9c2vmup.fsf@gmail.com> On 2014-04-03 at 10:19:42 +0200, Simon Peyton Jones wrote: > Accessing the GHC Trac yields [...] > TracError: The Trac Environment needs to be upgraded. > > Run "trac-admin /home/trac/ghc upgrade" Sorry, that was me; I was installing the spam-filter plugin and that required an upgrade long enough to be noticed... :-) From austin at well-typed.com Thu Apr 3 13:15:39 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 3 Apr 2014 08:15:39 -0500 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> Message-ID: Hi all, One final update: I have found a workaround for the issue Mateusz reported last week. Luckily it can be fought off somewhat easily for now for OS X users, but there are more details here: https://github.com/haskell/cabal/issues/1740 The final thing that ended up being a hold-up is now #8870 - the 32bit Windows distribution is segfaulting. At first, I thought this was an anomaly, but I saw several other people who also reported this problem. After a bit of sweat I've finally reproduced this bug and tracked this down part of the way, but I've been especially confused by this issue because apparently it does not affect everyone! Which is quite bizarre, as given the results I found, I'd suspect everyone to see it. Right now, Kyrill has suggested a fix I'm attempting (I slightly botched my first try), and I have found a way to avoid it at the moment by turning off optimization (which seems to reduce stack pressure enough to get by on Windows - see the ticket for details). Are there any Windows users who would be willing to test a 32bit Windows binary distribution, should I make a provisional one? I can have it up within a few hours from now. I'd really love some outside confirmation of this problem and a resolution once we have it! As this is the last bug, if I can at least get some confirmation a fix works, I can have the final release out immediately afterwords - the tree is otherwise quiet and will remain so. On Tue, Mar 25, 2014 at 5:24 PM, Austin Seipp wrote: > Hello all, > > As an updated, I'm looking into the report Mateusz had of 'free' > failing to build haddocks on OS X*, which I've reproduced. It seems > nasty - I'll follow up with details ASAP. > > * See his recent email to ghc-devs about this problem. > > On Tue, Mar 25, 2014 at 12:11 PM, Mateusz Kowalczyk > wrote: >> On 25/03/14 17:09, kyra wrote: >>> On 3/25/2014 20:52, Mateusz Kowalczyk wrote: >>>> The only instances of Haddock becoming really slow that I can think of >>>> is some rather old ticket (#101 on Haddock Trac) in presence of Template >>>> Haskell but I have closed it a while ago due to lack of information to >>>> go on and inability to replicate without the reporter's help. Perhaps >>>> this was your use case? >>>> >>> Aha, this is why I could not reproduce it! I checked it on packages >>> which used no TH, and that slow behaviour occurred when TH was involved! >>> >>> I think it is TH which really triggers producing and splitting of an >>> assembly output and in this case no-splitting gives *huge* benefit. >>> Sadly, I have no time to check this right now. >>> >>> Regards, >>> Kyra >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> There's no rush as it's not going to get into 7.8.1 anyway but I would >> love to see some numbers before 7.8.2 so please keep us in mind. >> >> Thanks! >> >> -- >> Mateusz K. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jpez.i.am at gmail.com Thu Apr 3 13:34:47 2014 From: jpez.i.am at gmail.com (Jim Perry) Date: Thu, 3 Apr 2014 15:34:47 +0200 Subject: Newcomer Contribution Message-ID: Hello, I am wanting to get involved in GHC development and I thought I'd help out with one of the noob tickets to get more experience. I though I would tackle #2258/#4114. I would be grateful for any advice/guidance for a kick-start. Cheers, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyrab at mail.ru Thu Apr 3 13:34:24 2014 From: kyrab at mail.ru (kyra) Date: Thu, 03 Apr 2014 17:34:24 +0400 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> Message-ID: <533D6360.2010005@mail.ru> On 4/3/2014 17:15, Austin Seipp wrote: > Right now, Kyrill has suggested a fix I'm attempting (I slightly > botched my first try), and I have found a way to avoid it at the > moment by turning off optimization (which seems to reduce stack > pressure enough to get by on Windows - see the ticket for details). It's absolutely not necessary to rebuild everything to check if this works, it's enough to edit ghc.exe with peflags utility (which has --stack-reserve and --stack-commit options) and look if it stop segfaulting. If I could reproduce the problem I'd have done this long ago. Cheers, Kyra From austin at well-typed.com Thu Apr 3 13:50:57 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 3 Apr 2014 08:50:57 -0500 Subject: 7.8.1 plan In-Reply-To: <533D6360.2010005@mail.ru> References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> <533D6360.2010005@mail.ru> Message-ID: Oh excellent, thank you for the tip Kyrill, I had no idea about this! My build is on the way, so I will try this and report back soon. On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote: > On 4/3/2014 17:15, Austin Seipp wrote: >> >> Right now, Kyrill has suggested a fix I'm attempting (I slightly >> botched my first try), and I have found a way to avoid it at the >> moment by turning off optimization (which seems to reduce stack >> pressure enough to get by on Windows - see the ticket for details). > > It's absolutely not necessary to rebuild everything to check if this works, > it's enough to edit ghc.exe with peflags utility (which has --stack-reserve > and --stack-commit options) and look if it stop segfaulting. If I could > reproduce the problem I'd have done this long ago. > > Cheers, > > Kyra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 3 14:00:08 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 3 Apr 2014 09:00:08 -0500 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> <533D6360.2010005@mail.ru> Message-ID: Kyrill, you are fantastic! I confirmed this incantation seems to have fixed the problem on my build: $ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe with the RC2 build, and not my own. Hooray! I will work up something soon. Thanks so much again! On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp wrote: > Oh excellent, thank you for the tip Kyrill, I had no idea about this! > My build is on the way, so I will try this and report back soon. > > On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote: >> On 4/3/2014 17:15, Austin Seipp wrote: >>> >>> Right now, Kyrill has suggested a fix I'm attempting (I slightly >>> botched my first try), and I have found a way to avoid it at the >>> moment by turning off optimization (which seems to reduce stack >>> pressure enough to get by on Windows - see the ticket for details). >> >> It's absolutely not necessary to rebuild everything to check if this works, >> it's enough to edit ghc.exe with peflags utility (which has --stack-reserve >> and --stack-commit options) and look if it stop segfaulting. If I could >> reproduce the problem I'd have done this long ago. >> >> Cheers, >> >> Kyra >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From varosi at gmail.com Thu Apr 3 14:05:59 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 17:05:59 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> Message-ID: Yes, but I don't know what is missing in my workflow. I did not know if I need LLVM runtime on my target ARM machine. Do I need? I read that there is unregisterised version for ARM that doesn't need LLVM. So I just could build Haskell cross-compiler that could work on my Ubuntu and create binaries for my ARM v7 machine. Am I right? 2014-04-02 19:58 GMT+03:00 Carter Schonwald : > have you read the cross compiler directions on the wiki? :) > https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation > http://www.haskell.org/haskellwiki/ARM > > > On Wed, Apr 2, 2014 at 12:30 PM, eng. Vassil Ognyanov Keremidchiev < > varosi at gmail.com> wrote: > >> Hello! >> >> Thanks, it continued with building until some LLVM errors. >> But will --with-gcc= arm based compiler will create GHC with: >> Host: x86 Ubuntu (where compilation should happen) >> Target: ARMv7 Linux ? >> >> Because I don't want to have GHC on my slow and restricted ARM machine. >> >> Best regards, >> Vassil >> >> >> 2014-03-28 20:09 GMT+02:00 Karel Gardas : >> >> >>> Last time I did that (crossing to ARMv8) I needed to use >>> --with-gcc= option since for some reason I had not time to >>> debug setting target triple with --target was not enough. Speaking about >>> GHC HEAD as of new year eve (2014) time... >>> >>> But well, since it this is already some time I'm not sure this was to >>> cure issue like you have now, but at least you may give it a try... >>> >>> Karel >>> >>> >>> On 03/28/14 06:08 PM, eng. Vassil Ognyanov Keremidchiev wrote: >>> >>>> Hello! >>>> >>>> Could someone help me with compiling GHC under Ubuntu as a ARM >>>> cross-compiler? >>>> >>>> Currently I have done those steps: >>>> sudo apt-get update >>>> sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev >>>> libncurses5-dev ghc-haddock >>>> sudo export PATH=~/.cabal/bin:$PATH >>>> sudo cabal install --reinstall happy alex terminfo libffi html >>>> regex-compat >>>> >>>> git clone http://darcs.haskell.org/ghc.git >>>> cd ghc >>>> >>>> ./sync-all --no-dph get >>>> ./sync-all pull >>>> ./boot >>>> sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised >>>> cp mk/build.mk.sample mk/build.mk >>>> >>>> # here I enable quick-cross configuration >>>> sudo make >>>> >>>> and I get: >>>> >>>> echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >> >>>> compiler/stage1/build/.depend-v.c_asm.tmp >>>> mv compiler/stage1/build/.depend-v.c_asm.tmp >>>> compiler/stage1/build/.depend-v.c_asm >>>> inplace/bin/deriveConstants --gen-header -o >>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir >>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" >>>> --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag >>>> -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header >>>> --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts >>>> --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm" >>>> /usr/bin/arm-linux-gnueabi-nm: >>>> includes/dist-derivedconstants/header/tmp.o: File format not recognized >>>> deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm >>>> "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed >>>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] >>>> Error 1 >>>> make: *** [all] Error 2 >>>> >>>> >>>> What I have done wrong? I did not understand the error message well, >>>> too. >>>> >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Thu Apr 3 14:13:57 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 03 Apr 2014 16:13:57 +0200 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> Message-ID: <533D6CA5.5030007@centrum.cz> On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: > Yes, but I don't know what is missing in my workflow. > > I did not know if I need LLVM runtime on my target ARM machine. No, you don't need LLVM runtime. You just need LLVM llc/opt if you'd like to cross-compile and build registerised ARM binaries. > Do I > need? I read that there is unregisterised version for ARM that doesn't > need LLVM. So I just could build Haskell cross-compiler that could work > on my Ubuntu and create binaries for my ARM v7 machine. If you'd like to use unregisterised /via-C binaries, then you don't need LLVM at all, you just need to configure with --enable-unregisterised IIRC, but I've not tested that so you are on your own. Also it comes with its own performance penalty of course: http://ghcarm.wordpress.com/2011/08/07/nofib-benchmarking/ Karel From kyrab at mail.ru Thu Apr 3 14:32:21 2014 From: kyrab at mail.ru (kyra) Date: Thu, 03 Apr 2014 18:32:21 +0400 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> <533D6360.2010005@mail.ru> Message-ID: <533D70F5.7000106@mail.ru> Btw, it is committed size which is important here. I proposed to increase both only to follow Linux/OSX linker policy which sets stack size to be 8mb by default, otherwise we could stay at 1mb for both reserved (windows' default value) and committed values. Regards, Kyra On 03.04.2014 18:00, Austin Seipp wrote: > Kyrill, you are fantastic! I confirmed this incantation seems to have > fixed the problem on my build: > > $ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe > > with the RC2 build, and not my own. Hooray! > > I will work up something soon. Thanks so much again! > > On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp wrote: >> Oh excellent, thank you for the tip Kyrill, I had no idea about this! >> My build is on the way, so I will try this and report back soon. >> >> On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote: >>> On 4/3/2014 17:15, Austin Seipp wrote: >>>> Right now, Kyrill has suggested a fix I'm attempting (I slightly >>>> botched my first try), and I have found a way to avoid it at the >>>> moment by turning off optimization (which seems to reduce stack >>>> pressure enough to get by on Windows - see the ticket for details). >>> It's absolutely not necessary to rebuild everything to check if this works, >>> it's enough to edit ghc.exe with peflags utility (which has --stack-reserve >>> and --stack-commit options) and look if it stop segfaulting. If I could >>> reproduce the problem I'd have done this long ago. >>> >>> Cheers, >>> >>> Kyra >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > From austin at well-typed.com Thu Apr 3 14:50:13 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 3 Apr 2014 09:50:13 -0500 Subject: 7.8.1 plan In-Reply-To: <533D70F5.7000106@mail.ru> References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> <533D6360.2010005@mail.ru> <533D70F5.7000106@mail.ru> Message-ID: Actually, the 0x200000 for the reserve was just the default in the executable - I just set it out based on what peflags told me initially. Thank you again Kyrill! On Thu, Apr 3, 2014 at 9:32 AM, kyra wrote: > Btw, it is committed size which is important here. I proposed to increase > both only to follow Linux/OSX linker policy which sets stack size to be 8mb > by default, otherwise we could stay at 1mb for both reserved (windows' > default value) and committed values. > > Regards, > Kyra > > > On 03.04.2014 18:00, Austin Seipp wrote: >> >> Kyrill, you are fantastic! I confirmed this incantation seems to have >> fixed the problem on my build: >> >> $ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe >> >> with the RC2 build, and not my own. Hooray! >> >> I will work up something soon. Thanks so much again! >> >> On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp >> wrote: >>> >>> Oh excellent, thank you for the tip Kyrill, I had no idea about this! >>> My build is on the way, so I will try this and report back soon. >>> >>> On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote: >>>> >>>> On 4/3/2014 17:15, Austin Seipp wrote: >>>>> >>>>> Right now, Kyrill has suggested a fix I'm attempting (I slightly >>>>> botched my first try), and I have found a way to avoid it at the >>>>> moment by turning off optimization (which seems to reduce stack >>>>> pressure enough to get by on Windows - see the ticket for details). >>>> >>>> It's absolutely not necessary to rebuild everything to check if this >>>> works, >>>> it's enough to edit ghc.exe with peflags utility (which has >>>> --stack-reserve >>>> and --stack-commit options) and look if it stop segfaulting. If I could >>>> reproduce the problem I'd have done this long ago. >>>> >>>> Cheers, >>>> >>>> Kyra >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From kyrab at mail.ru Thu Apr 3 14:56:43 2014 From: kyrab at mail.ru (Kyra) Date: Thu, 03 Apr 2014 18:56:43 +0400 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk> <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk> <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk> <533D6360.2010005@mail.ru> <533D70F5.7000106@mail.ru> Message-ID: <533D76AB.5030807@mail.ru> Ah, sorry. Now the policy is to set it to 2mb then. Cheers, Kyra On 03.04.2014 18:50, Austin Seipp wrote: > Actually, the 0x200000 for the reserve was just the default in the > executable - I just set it out based on what peflags told me > initially. > > Thank you again Kyrill! > > On Thu, Apr 3, 2014 at 9:32 AM, kyra wrote: >> Btw, it is committed size which is important here. I proposed to increase >> both only to follow Linux/OSX linker policy which sets stack size to be 8mb >> by default, otherwise we could stay at 1mb for both reserved (windows' >> default value) and committed values. >> >> Regards, >> Kyra >> >> >> On 03.04.2014 18:00, Austin Seipp wrote: >>> Kyrill, you are fantastic! I confirmed this incantation seems to have >>> fixed the problem on my build: >>> >>> $ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe >>> >>> with the RC2 build, and not my own. Hooray! >>> >>> I will work up something soon. Thanks so much again! >>> >>> On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp >>> wrote: >>>> Oh excellent, thank you for the tip Kyrill, I had no idea about this! >>>> My build is on the way, so I will try this and report back soon. >>>> >>>> On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote: >>>>> On 4/3/2014 17:15, Austin Seipp wrote: >>>>>> Right now, Kyrill has suggested a fix I'm attempting (I slightly >>>>>> botched my first try), and I have found a way to avoid it at the >>>>>> moment by turning off optimization (which seems to reduce stack >>>>>> pressure enough to get by on Windows - see the ticket for details). >>>>> It's absolutely not necessary to rebuild everything to check if this >>>>> works, >>>>> it's enough to edit ghc.exe with peflags utility (which has >>>>> --stack-reserve >>>>> and --stack-commit options) and look if it stop segfaulting. If I could >>>>> reproduce the problem I'd have done this long ago. >>>>> >>>>> Cheers, >>>>> >>>>> Kyra >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Austin Seipp, Haskell Consultant >>>> Well-Typed LLP, http://www.well-typed.com/ >>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > From alain.odea at gmail.com Thu Apr 3 16:32:09 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 3 Apr 2014 16:32:09 +0000 Subject: Newcomer Contribution In-Reply-To: References: Message-ID: <0C146CF6-AC26-49D0-A6D7-BC2161EB3CE7@gmail.com> > On Apr 3, 2014, at 13:34, Jim Perry wrote: > > Hello, > > I am wanting to get involved in GHC development and I thought I'd help out with one of the noob tickets to get more experience. I though I would tackle #2258/#4114. I would be grateful for any advice/guidance for a kick-start. > > Cheers, > Jim Hi Jim: Thank you for joining in :) Have you downloaded and built GHC? What kinds of bugs are you looking to fix (build, compiler, library)? Best, Alain From varosi at gmail.com Thu Apr 3 17:47:09 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 20:47:09 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: <533D6CA5.5030007@centrum.cz> References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> Message-ID: I'm trying to compile LLVM as is described in: http://bgamari.github.io/posts/cross-compiling_llvm.html without success. This is the error: llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build llvm[1]: Compiling TGParser.cpp for Debug+Asserts build llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a make[1]: Leaving directory `/home/varosi/haskell/llvm/build/lib/TableGen' make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' make[2]: Entering directory `/home/varosi/haskell/llvm/build/utils/FileCheck' llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build llvm[2]: Linking Debug+Asserts executable FileCheck /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, llvm::cl::OptionHidden)': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: undefined reference to `vtable for llvm::cl::Option' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: undefined reference to `llvm::cl::GeneralCategory' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::Option::~Option()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: undefined reference to `vtable for llvm::cl::Option' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: undefined reference to `vtable for llvm::cl::GenericOptionValue' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::OptionValue::OptionValue()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: undefined reference to `vtable for llvm::cl::OptionValue' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: undefined reference to `vtable for llvm::cl::basic_parser_impl' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char const* const*)': /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: undefined reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: undefined reference to `vtable for llvm::PrettyStackTraceProgram' /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: undefined reference to `llvm::EnablePrettyStackTrace()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::raw_ostream::operator<<(char)': /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: undefined reference to `llvm::raw_ostream::write(unsigned char)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::raw_ostream::operator<<(llvm::StringRef)': /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: undefined reference to `llvm::raw_ostream::write(char const*, unsigned long)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::raw_ostream::operator<<(std::string const&)': /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: undefined reference to `llvm::raw_ostream::write(char const*, unsigned long)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, llvm::SourceMgr&, unsigned int)': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:277: more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' follow /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, llvm::SourceMgr&, unsigned int)': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: undefined reference to `llvm::Regex::escape(llvm::StringRef)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned int&, llvm::SourceMgr&)': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: undefined reference to `llvm::Regex::isValid(std::string&)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: undefined reference to `llvm::Regex::getNumMatches() const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: undefined reference to `llvm::Regex::~Regex()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::Match(llvm::StringRef, unsigned long&, llvm::StringMap&) const': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: undefined reference to `llvm::Regex::escape(llvm::StringRef)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined reference to `llvm::Regex::match(llvm::StringRef, llvm::SmallVectorImpl*)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined reference to `llvm::Regex::~Regex()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::ComputeMatchDistance(llvm::StringRef, llvm::StringMap const&) const': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: undefined reference to `llvm::StringRef::edit_distance(llvm::StringRef, bool, unsigned int) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, llvm::StringRef, llvm::StringMap const&) const': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: undefined reference to `llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl&)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: undefined reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: undefined reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: undefined reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: undefined reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: undefined reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:484: more undefined references to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, llvm::StringRef, llvm::StringMap const&) const': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined reference to `llvm::raw_svector_ostream::str()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: undefined reference to `llvm::raw_svector_ostream::~raw_svector_ostream()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `Pattern::FindRegexVarEnd(llvm::StringRef, llvm::SourceMgr&)': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `CanonicalizeInputFile': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: undefined reference to `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::StringRef)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `CheckTypeSize': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `FindFirstCandidateMatch': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: undefined reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `ReadCheckFile': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: undefined reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, std::unique_ptr >&, long)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: undefined reference to `llvm::error_code::message() const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: undefined reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: undefined reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `PrintCheckFailed': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: undefined reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `CountNumNewlinesBetween': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: undefined reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `CheckString::CheckNext(llvm::SourceMgr const&, llvm::StringRef) const': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: undefined reference to `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1060: more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, llvm::SourceMgr::DiagKind, llvm::Twine const&, llvm::ArrayRef, llvm::ArrayRef, bool) const' follow /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `ValidateCheckPrefix': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined reference to `llvm::Regex::match(llvm::StringRef, llvm::SmallVectorImpl*)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined reference to `llvm::Regex::~Regex()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `main': /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: undefined reference to `llvm::cl::ParseCommandLineOptions(int, char const* const*, char const*)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: undefined reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, std::unique_ptr >&, long)' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: undefined reference to `llvm::error_code::message() const' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: undefined reference to `llvm::errs()' /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: undefined reference to `llvm::SourceMgr::~SourceMgr()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::GenericOptionValue::GenericOptionValue()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: undefined reference to `vtable for llvm::cl::GenericOptionValue' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::OptionValue::~OptionValue()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: undefined reference to `vtable for llvm::cl::OptionValue' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::basic_parser_impl::basic_parser_impl()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: undefined reference to `vtable for llvm::cl::basic_parser_impl' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::basic_parser::~basic_parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: undefined reference to `vtable for llvm::cl::basic_parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::parser::~parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::opt >::opt(llvm::cl::FormattingFlags const&, llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: undefined reference to `vtable for llvm::cl::opt >' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: undefined reference to `llvm::cl::opt >::done()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::opt >::opt, llvm::cl::value_desc>(char const (&) [11], llvm::cl::desc const&, llvm::cl::initializer const&, llvm::cl::value_desc const&)': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: undefined reference to `vtable for llvm::cl::opt >' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: undefined reference to `llvm::cl::opt >::done()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::list >::list(char const (&) [13], llvm::cl::desc const&)': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::basic_parser::basic_parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: undefined reference to `vtable for llvm::cl::basic_parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::basic_parser::~basic_parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: undefined reference to `vtable for llvm::cl::basic_parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::parser::parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::parser::~parser()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: undefined reference to `vtable for llvm::cl::parser' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::opt >::opt(char const (&) [18], llvm::cl::desc const&)': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: undefined reference to `vtable for llvm::cl::opt >' /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: undefined reference to `llvm::cl::opt >::done()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `std::enable_if::is_signed, bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) const': /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: undefined reference to `llvm::getAsSignedInteger(llvm::StringRef, unsigned int, long long&)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::StringMap::find(llvm::StringRef)': /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: undefined reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::StringMap::find(llvm::StringRef) const': /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: undefined reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::list >::done()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: undefined reference to `llvm::cl::Option::addArgument()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::StringMapEntry& llvm::StringMap::GetOrCreateValue(llvm::StringRef, llvm::StringRef)': /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined reference to `llvm::StringMapImpl::RehashTable()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::SmallVectorTemplateCommon::grow_pod(unsigned long, unsigned long)': /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, unsigned long)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::StringMapEntry& llvm::StringMap::GetOrCreateValue(llvm::StringRef, char)': /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined reference to `llvm::StringMapImpl::RehashTable()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `void llvm::cl::initializer::apply > >(llvm::cl::opt >&) const': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: undefined reference to `llvm::cl::opt >::setInitialValue(std::string const&)' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): undefined reference to `llvm::cl::Option::anchor()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ZTVN4llvm2cl11OptionValueIbEE]+0x28): undefined reference to `llvm::cl::GenericOptionValue::anchor()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseIbLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): undefined reference to `llvm::cl::GenericOptionValue::anchor()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): undefined reference to `llvm::cl::GenericOptionValue::anchor()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): undefined reference to `llvm::cl::GenericOptionValue::anchor()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::opt >::~opt()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: undefined reference to `vtable for llvm::cl::opt >' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::opt >::~opt()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: undefined reference to `vtable for llvm::cl::opt >' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram()': /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: undefined reference to `vtable for llvm::PrettyStackTraceProgram' /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: undefined reference to `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::list >::getOptionWidth() const': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: undefined reference to `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option const&) const' /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: In function `llvm::cl::list >::printOptionInfo(unsigned long) const': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: undefined reference to `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option const&, unsigned long) const' collect2: error: ld returned 1 exit status make[2]: *** [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] Error 1 make[2]: Leaving directory `/home/varosi/haskell/llvm/build/utils/FileCheck' make[1]: *** [FileCheck/.makeall] Error 2 make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' make: *** [all] Error 1 Another thing is that the link from: http://www.haskell.org/haskellwiki/ARM which is: http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html Is invalid and there could be some more information on the topic. I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. What could be the problem with LLVM? 2014-04-03 17:13 GMT+03:00 Karel Gardas : > On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: > >> Yes, but I don't know what is missing in my workflow. >> >> I did not know if I need LLVM runtime on my target ARM machine. >> > > No, you don't need LLVM runtime. You just need LLVM llc/opt if you'd like > to cross-compile and build registerised ARM binaries. > > > Do I >> need? I read that there is unregisterised version for ARM that doesn't >> need LLVM. So I just could build Haskell cross-compiler that could work >> on my Ubuntu and create binaries for my ARM v7 machine. >> > > If you'd like to use unregisterised /via-C binaries, then you don't need > LLVM at all, you just need to configure with --enable-unregisterised IIRC, > but I've not tested that so you are on your own. > > Also it comes with its own performance penalty of course: > http://ghcarm.wordpress.com/2011/08/07/nofib-benchmarking/ > > Karel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varosi at gmail.com Thu Apr 3 18:00:55 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 21:00:55 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> Message-ID: May be the problem is: arm-linux-gnueabi-gcc --version gives me 4.6.3 ? Is it possible to install earlier LLVM version? 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev < varosi at gmail.com>: > I'm trying to compile LLVM as is described in: > http://bgamari.github.io/posts/cross-compiling_llvm.html > without success. This is the error: > > llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build > llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build > llvm[1]: Compiling TGParser.cpp for Debug+Asserts build > llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build > llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a > make[1]: Leaving directory `/home/varosi/haskell/llvm/build/lib/TableGen' > make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' > make[2]: Entering directory > `/home/varosi/haskell/llvm/build/utils/FileCheck' > llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build > llvm[2]: Linking Debug+Asserts executable FileCheck > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, > llvm::cl::OptionHidden)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: > undefined reference to `vtable for llvm::cl::Option' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: > undefined reference to `llvm::cl::GeneralCategory' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::Option::~Option()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: > undefined reference to `vtable for llvm::cl::Option' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: > undefined reference to `vtable for llvm::cl::GenericOptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::OptionValue::OptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: > undefined reference to `vtable for llvm::cl::OptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: > undefined reference to `vtable for llvm::cl::basic_parser_impl' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, > char const* const*)': > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: > undefined reference to > `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: > undefined reference to `vtable for llvm::PrettyStackTraceProgram' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: > undefined reference to `llvm::EnablePrettyStackTrace()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(char)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: > undefined reference to `llvm::raw_ostream::write(unsigned char)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: > undefined reference to `llvm::raw_ostream::write(char const*, unsigned > long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(std::string const&)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: > undefined reference to `llvm::raw_ostream::write(char const*, unsigned > long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:277: > more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: undefined > reference to `llvm::Regex::escape(llvm::StringRef)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned int&, > llvm::SourceMgr&)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: undefined > reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: undefined > reference to `llvm::Regex::isValid(std::string&)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: undefined > reference to `llvm::Regex::getNumMatches() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: undefined > reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::Match(llvm::StringRef, unsigned long&, > llvm::StringMap&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: undefined > reference to `llvm::Regex::escape(llvm::StringRef)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined > reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined > reference to `llvm::Regex::match(llvm::StringRef, > llvm::SmallVectorImpl*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined > reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ComputeMatchDistance(llvm::StringRef, > llvm::StringMap const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: undefined > reference to `llvm::StringRef::edit_distance(llvm::StringRef, bool, > unsigned int) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap > const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: undefined > reference to > `llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl&)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: undefined > reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: undefined > reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: undefined > reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: undefined > reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: undefined > reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:484: > more undefined references to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap > const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined > reference to `llvm::raw_svector_ostream::str()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: undefined > reference to `llvm::raw_svector_ostream::~raw_svector_ostream()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::FindRegexVarEnd(llvm::StringRef, llvm::SourceMgr&)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CanonicalizeInputFile': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: undefined > reference to `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, > llvm::StringRef)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CheckTypeSize': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: undefined > reference to `llvm::llvm_unreachable_internal(char const*, char const*, > unsigned int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: undefined > reference to `llvm::llvm_unreachable_internal(char const*, char const*, > unsigned int)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `FindFirstCandidateMatch': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: undefined > reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `ReadCheckFile': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: undefined > reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, > std::unique_ptr > >&, long)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: undefined > reference to `llvm::error_code::message() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: undefined > reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned > long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: undefined > reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned > long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `PrintCheckFailed': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: undefined > reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned > long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CountNumNewlinesBetween': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: undefined > reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned > long) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CheckString::CheckNext(llvm::SourceMgr const&, > llvm::StringRef) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: undefined > reference to `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: undefined > reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1060: > more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) const' > follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `ValidateCheckPrefix': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: undefined > reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined > reference to `llvm::Regex::match(llvm::StringRef, > llvm::SmallVectorImpl*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined > reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `main': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: undefined > reference to `llvm::sys::PrintStackTraceOnErrorSignal()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: undefined > reference to `llvm::cl::ParseCommandLineOptions(int, char const* const*, > char const*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: undefined > reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, > std::unique_ptr > >&, long)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: undefined > reference to `llvm::error_code::message() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: undefined > reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: undefined > reference to `llvm::SourceMgr::~SourceMgr()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::GenericOptionValue::GenericOptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: > undefined reference to `vtable for llvm::cl::GenericOptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::OptionValue::~OptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: > undefined reference to `vtable for llvm::cl::OptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser_impl::basic_parser_impl()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: > undefined reference to `vtable for llvm::cl::basic_parser_impl' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::~basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::~parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::opt llvm::cl::desc, llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags > const&, llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::opt llvm::cl::initializer, llvm::cl::value_desc>(char const (&) [11], > llvm::cl::desc const&, llvm::cl::initializer const&, > llvm::cl::value_desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::list(char const > (&) [13], llvm::cl::desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::~basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::~parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt >::opt [18], llvm::cl::desc>(char const (&) [18], llvm::cl::desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: > undefined reference to `llvm::cl::opt > >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `std::enable_if::is_signed, > bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) const': > /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: undefined > reference to `llvm::getAsSignedInteger(llvm::StringRef, unsigned int, long > long&)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: undefined > reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(llvm::StringRef) const': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: undefined > reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::done()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: > undefined reference to `llvm::cl::Option::addArgument()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMapEntry& > llvm::StringMap llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, > llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined > reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined > reference to `llvm::StringMapImpl::RehashTable()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::SmallVectorTemplateCommon::grow_pod(unsigned > long, unsigned long)': > /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: undefined > reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, > unsigned long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMapEntry& llvm::StringMap llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, char)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined > reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined > reference to `llvm::StringMapImpl::RehashTable()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `void llvm::cl::initializer [2]>::apply > > >(llvm::cl::opt >&) > const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: > undefined reference to `llvm::cl::opt llvm::cl::parser >::setInitialValue(std::string const&)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): > undefined reference to `llvm::cl::Option::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ZTVN4llvm2cl11OptionValueIbEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseIbLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::~opt()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt >::~opt()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram()': > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: > undefined reference to `vtable for llvm::PrettyStackTraceProgram' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: > undefined reference to > `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::getOptionWidth() const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: > undefined reference to > `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option const&) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::printOptionInfo(unsigned long) const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: > undefined reference to > `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option const&, > unsigned long) const' > collect2: error: ld returned 1 exit status > make[2]: *** [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] > Error 1 > make[2]: Leaving directory > `/home/varosi/haskell/llvm/build/utils/FileCheck' > make[1]: *** [FileCheck/.makeall] Error 2 > make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' > make: *** [all] Error 1 > > > > Another thing is that the link from: > http://www.haskell.org/haskellwiki/ARM > > which is: > http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html > > Is invalid and there could be some more information on the topic. > I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. > > What could be the problem with LLVM? > > > 2014-04-03 17:13 GMT+03:00 Karel Gardas : > > On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: >> >>> Yes, but I don't know what is missing in my workflow. >>> >>> I did not know if I need LLVM runtime on my target ARM machine. >>> >> >> No, you don't need LLVM runtime. You just need LLVM llc/opt if you'd like >> to cross-compile and build registerised ARM binaries. >> >> >> Do I >>> need? I read that there is unregisterised version for ARM that doesn't >>> need LLVM. So I just could build Haskell cross-compiler that could work >>> on my Ubuntu and create binaries for my ARM v7 machine. >>> >> >> If you'd like to use unregisterised /via-C binaries, then you don't need >> LLVM at all, you just need to configure with --enable-unregisterised IIRC, >> but I've not tested that so you are on your own. >> >> Also it comes with its own performance penalty of course: >> http://ghcarm.wordpress.com/2011/08/07/nofib-benchmarking/ >> >> Karel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Thu Apr 3 18:05:21 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 03 Apr 2014 20:05:21 +0200 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> Message-ID: <533DA2E1.9040509@centrum.cz> I don't understand why you are trying to cross-compile LLVM? I've though you'd like to cross-compile GHC itself... Karel On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote: > May be the problem is: > arm-linux-gnueabi-gcc --version > gives me 4.6.3 ? > > Is it possible to install earlier LLVM version? > > 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev > >: > > I'm trying to compile LLVM as is described in: > http://bgamari.github.io/posts/cross-compiling_llvm.html > without success. This is the error: > > llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build > llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build > llvm[1]: Compiling TGParser.cpp for Debug+Asserts build > llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build > llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a > make[1]: Leaving directory > `/home/varosi/haskell/llvm/build/lib/TableGen' > make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' > make[2]: Entering directory > `/home/varosi/haskell/llvm/build/utils/FileCheck' > llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build > llvm[2]: Linking Debug+Asserts executable FileCheck > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, > llvm::cl::OptionHidden)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: > undefined reference to `vtable for llvm::cl::Option' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: > undefined reference to `llvm::cl::GeneralCategory' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::Option::~Option()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: > undefined reference to `vtable for llvm::cl::Option' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: > undefined reference to `vtable for llvm::cl::GenericOptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::OptionValue::OptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: > undefined reference to `vtable for llvm::cl::OptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: > undefined reference to `vtable for llvm::cl::basic_parser_impl' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function > `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char > const* const*)': > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: undefined > reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: undefined > reference to `vtable for llvm::PrettyStackTraceProgram' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: undefined > reference to `llvm::EnablePrettyStackTrace()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(char)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: > undefined reference to `llvm::raw_ostream::write(unsigned char)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: > undefined reference to `llvm::raw_ostream::write(char const*, > unsigned long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<(std::string const&)': > /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: > undefined reference to `llvm::raw_ostream::write(char const*, > unsigned long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:277: > more undefined references to > `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: > undefined reference to `llvm::Regex::escape(llvm::StringRef)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned > int&, llvm::SourceMgr&)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: > undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned > int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: > undefined reference to `llvm::Regex::isValid(std::string&)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: > undefined reference to `llvm::Regex::getNumMatches() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: > undefined reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::Match(llvm::StringRef, unsigned long&, > llvm::StringMap&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: > undefined reference to `llvm::Regex::escape(llvm::StringRef)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: > undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned > int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: > undefined reference to `llvm::Regex::match(llvm::StringRef, > llvm::SmallVectorImpl*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: > undefined reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::ComputeMatchDistance(llvm::StringRef, > llvm::StringMap const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: > undefined reference to > `llvm::StringRef::edit_distance(llvm::StringRef, bool, unsigned int) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap llvm::MallocAllocator> const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: > undefined reference to > `llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl&)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: > undefined reference to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: > undefined reference to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: > undefined reference to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: > undefined reference to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: > undefined reference to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:484: > more undefined references to > `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap llvm::MallocAllocator> const&) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: > undefined reference to `llvm::raw_svector_ostream::str()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: > undefined reference to > `llvm::raw_svector_ostream::~raw_svector_ostream()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `Pattern::FindRegexVarEnd(llvm::StringRef, > llvm::SourceMgr&)': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CanonicalizeInputFile': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: > undefined reference to > `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::StringRef)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CheckTypeSize': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: > undefined reference to `llvm::llvm_unreachable_internal(char const*, > char const*, unsigned int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: > undefined reference to `llvm::llvm_unreachable_internal(char const*, > char const*, unsigned int)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `FindFirstCandidateMatch': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: > undefined reference to `llvm::StringRef::find(llvm::StringRef, > unsigned long) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `ReadCheckFile': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: > undefined reference to > `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, > std::unique_ptr std::default_delete >&, long)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: > undefined reference to `llvm::error_code::message() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: > undefined reference to > `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: > undefined reference to > `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `PrintCheckFailed': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: > undefined reference to > `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CountNumNewlinesBetween': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: > undefined reference to > `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `CheckString::CheckNext(llvm::SourceMgr const&, > llvm::StringRef) const': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: > undefined reference to > `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: > undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1060: > more undefined references to > `llvm::SourceMgr::PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, llvm::ArrayRef, bool) > const' follow > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `ValidateCheckPrefix': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: > undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned > int)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: > undefined reference to `llvm::Regex::match(llvm::StringRef, > llvm::SmallVectorImpl*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: > undefined reference to `llvm::Regex::~Regex()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `main': > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: > undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: > undefined reference to `llvm::cl::ParseCommandLineOptions(int, char > const* const*, char const*)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: > undefined reference to > `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, > std::unique_ptr std::default_delete >&, long)' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: > undefined reference to `llvm::error_code::message() const' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: > undefined reference to `llvm::errs()' > /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: > undefined reference to `llvm::SourceMgr::~SourceMgr()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::GenericOptionValue::GenericOptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: > undefined reference to `vtable for llvm::cl::GenericOptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::OptionValue::~OptionValue()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: > undefined reference to `vtable for llvm::cl::OptionValue' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser_impl::basic_parser_impl()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: > undefined reference to `vtable for llvm::cl::basic_parser_impl' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::~basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::~parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::opt llvm::cl::desc, > llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags const&, > llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::opt llvm::cl::initializer, llvm::cl::value_desc>(char const > (&) [11], llvm::cl::desc const&, llvm::cl::initializer > const&, llvm::cl::value_desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::list llvm::cl::desc>(char const (&) [13], llvm::cl::desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::basic_parser::~basic_parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: > undefined reference to `vtable for llvm::cl::basic_parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::parser::~parser()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt > >::opt(char const (&) [18], > llvm::cl::desc const&)': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `std::enable_if::is_signed, > bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) > const': > /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: > undefined reference to `llvm::getAsSignedInteger(llvm::StringRef, > unsigned int, long long&)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: > undefined reference to > `llvm::StringMapImpl::FindKey(llvm::StringRef) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(llvm::StringRef) const': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: > undefined reference to > `llvm::StringMapImpl::FindKey(llvm::StringRef) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::done()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: > undefined reference to `llvm::cl::Option::addArgument()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMapEntry& > llvm::StringMap llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, > llvm::StringRef)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: > undefined reference to > `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: > undefined reference to `llvm::StringMapImpl::RehashTable()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::SmallVectorTemplateCommon void>::grow_pod(unsigned long, unsigned long)': > /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: > undefined reference to `llvm::SmallVectorBase::grow_pod(void*, > unsigned long, unsigned long)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::StringMapEntry& llvm::StringMap llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, char)': > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: > undefined reference to > `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' > /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: > undefined reference to `llvm::StringMapImpl::RehashTable()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `void llvm::cl::initializer [2]>::apply llvm::cl::parser > >(llvm::cl::opt llvm::cl::parser >&) const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: > undefined reference to `llvm::cl::opt llvm::cl::parser >::setInitialValue(std::string const&)' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): > undefined reference to `llvm::cl::Option::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ZTVN4llvm2cl11OptionValueIbEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseIbLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): > undefined reference to `llvm::cl::GenericOptionValue::anchor()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::~opt()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::opt > >::~opt()': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: > undefined reference to `vtable for llvm::cl::opt llvm::cl::parser >' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram()': > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: undefined > reference to `vtable for llvm::PrettyStackTraceProgram' > /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: undefined > reference to `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::getOptionWidth() const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: > undefined reference to > `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option > const&) const' > /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::printOptionInfo(unsigned long) const': > /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: > undefined reference to > `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option > const&, unsigned long) const' > collect2: error: ld returned 1 exit status > make[2]: *** > [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] Error 1 > make[2]: Leaving directory > `/home/varosi/haskell/llvm/build/utils/FileCheck' > make[1]: *** [FileCheck/.makeall] Error 2 > make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' > make: *** [all] Error 1 > > > > Another thing is that the link from: > http://www.haskell.org/haskellwiki/ARM > > which is: > http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html > > Is invalid and there could be some more information on the topic. > I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. > > What could be the problem with LLVM? > > > 2014-04-03 17:13 GMT+03:00 Karel Gardas >: > > On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: > > Yes, but I don't know what is missing in my workflow. > > I did not know if I need LLVM runtime on my target ARM machine. > > > No, you don't need LLVM runtime. You just need LLVM llc/opt if > you'd like to cross-compile and build registerised ARM binaries. > > > Do I > need? I read that there is unregisterised version for ARM > that doesn't > need LLVM. So I just could build Haskell cross-compiler that > could work > on my Ubuntu and create binaries for my ARM v7 machine. > > > If you'd like to use unregisterised /via-C binaries, then you > don't need LLVM at all, you just need to configure with > --enable-unregisterised IIRC, but I've not tested that so you > are on your own. > > Also it comes with its own performance penalty of course: > http://ghcarm.wordpress.com/__2011/08/07/nofib-benchmarking/ > > > Karel > > > From varosi at gmail.com Thu Apr 3 18:11:39 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 21:11:39 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> Message-ID: There is the same error for 3.0 and 3.2 release branches which I think supports ARM. 2014-04-03 21:00 GMT+03:00 eng. Vassil Ognyanov Keremidchiev < varosi at gmail.com>: > May be the problem is: > arm-linux-gnueabi-gcc --version > gives me 4.6.3 ? > > Is it possible to install earlier LLVM version? > > 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev < > varosi at gmail.com>: > > I'm trying to compile LLVM as is described in: >> http://bgamari.github.io/posts/cross-compiling_llvm.html >> without success. This is the error: >> >> llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build >> llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build >> llvm[1]: Compiling TGParser.cpp for Debug+Asserts build >> llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build >> llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a >> make[1]: Leaving directory `/home/varosi/haskell/llvm/build/lib/TableGen' >> make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' >> make[2]: Entering directory >> `/home/varosi/haskell/llvm/build/utils/FileCheck' >> llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build >> llvm[2]: Linking Debug+Asserts executable FileCheck >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, >> llvm::cl::OptionHidden)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >> undefined reference to `vtable for llvm::cl::Option' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >> undefined reference to `llvm::cl::GeneralCategory' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::Option::~Option()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: >> undefined reference to `vtable for llvm::cl::Option' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: >> undefined reference to `vtable for llvm::cl::GenericOptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::OptionValue::OptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: >> undefined reference to `vtable for llvm::cl::OptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: >> undefined reference to `vtable for llvm::cl::basic_parser_impl' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, >> char const* const*)': >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >> undefined reference to >> `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >> undefined reference to `vtable for llvm::PrettyStackTraceProgram' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: >> undefined reference to `llvm::EnablePrettyStackTrace()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(char)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: >> undefined reference to `llvm::raw_ostream::write(unsigned char)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: >> undefined reference to `llvm::raw_ostream::write(char const*, unsigned >> long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(std::string const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: >> undefined reference to `llvm::raw_ostream::write(char const*, unsigned >> long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >> llvm::SourceMgr&, unsigned int)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:277: >> more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >> llvm::SourceMgr&, unsigned int)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: undefined >> reference to `llvm::Regex::escape(llvm::StringRef)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned int&, >> llvm::SourceMgr&)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: undefined >> reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: undefined >> reference to `llvm::Regex::isValid(std::string&)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: undefined >> reference to `llvm::Regex::getNumMatches() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: undefined >> reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::Match(llvm::StringRef, unsigned long&, >> llvm::StringMap&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: undefined >> reference to `llvm::Regex::escape(llvm::StringRef)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined >> reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined >> reference to `llvm::Regex::match(llvm::StringRef, >> llvm::SmallVectorImpl*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: undefined >> reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::ComputeMatchDistance(llvm::StringRef, >> llvm::StringMap const&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: undefined >> reference to `llvm::StringRef::edit_distance(llvm::StringRef, bool, >> unsigned int) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >> llvm::StringRef, llvm::StringMap >> const&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: undefined >> reference to >> `llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl&)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: undefined >> reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: undefined >> reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: undefined >> reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: undefined >> reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: undefined >> reference to `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:484: >> more undefined references to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >> llvm::StringRef, llvm::StringMap >> const&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined >> reference to `llvm::raw_svector_ostream::str()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: undefined >> reference to `llvm::raw_svector_ostream::~raw_svector_ostream()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `Pattern::FindRegexVarEnd(llvm::StringRef, llvm::SourceMgr&)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `CanonicalizeInputFile': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: undefined >> reference to `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, >> llvm::StringRef)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `CheckTypeSize': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: undefined >> reference to `llvm::llvm_unreachable_internal(char const*, char const*, >> unsigned int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: undefined >> reference to `llvm::llvm_unreachable_internal(char const*, char const*, >> unsigned int)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `FindFirstCandidateMatch': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: undefined >> reference to `llvm::StringRef::find(llvm::StringRef, unsigned long) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `ReadCheckFile': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: undefined >> reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >> std::unique_ptr >> >&, long)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: undefined >> reference to `llvm::error_code::message() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: undefined >> reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned >> long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: undefined >> reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned >> long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `PrintCheckFailed': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: undefined >> reference to `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned >> long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `CountNumNewlinesBetween': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: undefined >> reference to `llvm::StringRef::find_first_of(llvm::StringRef, unsigned >> long) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `CheckString::CheckNext(llvm::SourceMgr const&, >> llvm::StringRef) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: undefined >> reference to `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: undefined >> reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1060: >> more undefined references to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) const' >> follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `ValidateCheckPrefix': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: undefined >> reference to `llvm::Regex::Regex(llvm::StringRef, unsigned int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined >> reference to `llvm::Regex::match(llvm::StringRef, >> llvm::SmallVectorImpl*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: undefined >> reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `main': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: undefined >> reference to `llvm::sys::PrintStackTraceOnErrorSignal()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: undefined >> reference to `llvm::cl::ParseCommandLineOptions(int, char const* const*, >> char const*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: undefined >> reference to `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >> std::unique_ptr >> >&, long)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: undefined >> reference to `llvm::error_code::message() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: undefined >> reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: undefined >> reference to `llvm::SourceMgr::~SourceMgr()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::GenericOptionValue::GenericOptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: >> undefined reference to `vtable for llvm::cl::GenericOptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::OptionValue::~OptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: >> undefined reference to `vtable for llvm::cl::OptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser_impl::basic_parser_impl()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: >> undefined reference to `vtable for llvm::cl::basic_parser_impl' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::~basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::parser::~parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::opt> llvm::cl::desc, llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags >> const&, llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::opt> llvm::cl::initializer, llvm::cl::value_desc>(char const (&) [11], >> llvm::cl::desc const&, llvm::cl::initializer const&, >> llvm::cl::value_desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::list(char const >> (&) [13], llvm::cl::desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::~basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::parser::parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::parser::~parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::opt >::opt> [18], llvm::cl::desc>(char const (&) [18], llvm::cl::desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: >> undefined reference to `llvm::cl::opt >> >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `std::enable_if::is_signed, >> bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) const': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: undefined >> reference to `llvm::getAsSignedInteger(llvm::StringRef, unsigned int, long >> long&)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::StringMap> llvm::MallocAllocator>::find(llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: undefined >> reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::StringMap> llvm::MallocAllocator>::find(llvm::StringRef) const': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: undefined >> reference to `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::done()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: >> undefined reference to `llvm::cl::Option::addArgument()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::StringMapEntry& >> llvm::StringMap> llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, >> llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined >> reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined >> reference to `llvm::StringMapImpl::RehashTable()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::SmallVectorTemplateCommon::grow_pod(unsigned >> long, unsigned long)': >> /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: undefined >> reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, >> unsigned long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::StringMapEntry& llvm::StringMap> llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, char)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: undefined >> reference to `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: undefined >> reference to `llvm::StringMapImpl::RehashTable()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `void llvm::cl::initializer> [2]>::apply >> > >(llvm::cl::opt >&) >> const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::setInitialValue(std::string const&)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): >> undefined reference to `llvm::cl::Option::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ZTVN4llvm2cl11OptionValueIbEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseIbLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::~opt()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::opt >::~opt()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram()': >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >> undefined reference to `vtable for llvm::PrettyStackTraceProgram' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >> undefined reference to >> `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::getOptionWidth() const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: >> undefined reference to >> `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option const&) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::printOptionInfo(unsigned long) const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: >> undefined reference to >> `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option const&, >> unsigned long) const' >> collect2: error: ld returned 1 exit status >> make[2]: *** >> [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] Error 1 >> make[2]: Leaving directory >> `/home/varosi/haskell/llvm/build/utils/FileCheck' >> make[1]: *** [FileCheck/.makeall] Error 2 >> make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' >> make: *** [all] Error 1 >> >> >> >> Another thing is that the link from: >> http://www.haskell.org/haskellwiki/ARM >> >> which is: >> http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html >> >> Is invalid and there could be some more information on the topic. >> I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. >> >> What could be the problem with LLVM? >> >> >> 2014-04-03 17:13 GMT+03:00 Karel Gardas : >> >> On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: >>> >>>> Yes, but I don't know what is missing in my workflow. >>>> >>>> I did not know if I need LLVM runtime on my target ARM machine. >>>> >>> >>> No, you don't need LLVM runtime. You just need LLVM llc/opt if you'd >>> like to cross-compile and build registerised ARM binaries. >>> >>> >>> Do I >>>> need? I read that there is unregisterised version for ARM that doesn't >>>> need LLVM. So I just could build Haskell cross-compiler that could work >>>> on my Ubuntu and create binaries for my ARM v7 machine. >>>> >>> >>> If you'd like to use unregisterised /via-C binaries, then you don't need >>> LLVM at all, you just need to configure with --enable-unregisterised IIRC, >>> but I've not tested that so you are on your own. >>> >>> Also it comes with its own performance penalty of course: >>> http://ghcarm.wordpress.com/2011/08/07/nofib-benchmarking/ >>> >>> Karel >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varosi at gmail.com Thu Apr 3 18:13:12 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 21:13:12 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: <533DA2E1.9040509@centrum.cz> References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> <533DA2E1.9040509@centrum.cz> Message-ID: I would like to build GHC as a cross-compiler. So it can still run on x86 Ubuntu, but producing code for ARM v7. What should I do? 2014-04-03 21:05 GMT+03:00 Karel Gardas : > > I don't understand why you are trying to cross-compile LLVM? I've though > you'd like to cross-compile GHC itself... > > Karel > > > On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote: > >> May be the problem is: >> arm-linux-gnueabi-gcc --version >> gives me 4.6.3 ? >> >> Is it possible to install earlier LLVM version? >> >> 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev >> >: >> >> >> I'm trying to compile LLVM as is described in: >> http://bgamari.github.io/posts/cross-compiling_llvm.html >> without success. This is the error: >> >> llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build >> llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build >> llvm[1]: Compiling TGParser.cpp for Debug+Asserts build >> llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build >> llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a >> make[1]: Leaving directory >> `/home/varosi/haskell/llvm/build/lib/TableGen' >> make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' >> make[2]: Entering directory >> `/home/varosi/haskell/llvm/build/utils/FileCheck' >> llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build >> llvm[2]: Linking Debug+Asserts executable FileCheck >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, >> llvm::cl::OptionHidden)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >> undefined reference to `vtable for llvm::cl::Option' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >> undefined reference to `llvm::cl::GeneralCategory' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::Option::~Option()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: >> undefined reference to `vtable for llvm::cl::Option' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: >> undefined reference to `vtable for llvm::cl::GenericOptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::OptionValue::OptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: >> undefined reference to `vtable for llvm::cl::OptionValue> string>' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: >> undefined reference to `vtable for llvm::cl::basic_parser_impl' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function >> `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char >> const* const*)': >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >> undefined >> reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >> undefined >> reference to `vtable for llvm::PrettyStackTraceProgram' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: >> undefined >> reference to `llvm::EnablePrettyStackTrace()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(char)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: >> undefined reference to `llvm::raw_ostream::write(unsigned char)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: >> undefined reference to `llvm::raw_ostream::write(char const*, >> unsigned long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::raw_ostream::operator<<(std::string const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: >> undefined reference to `llvm::raw_ostream::write(char const*, >> unsigned long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >> llvm::SourceMgr&, unsigned int)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >> FileCheck/FileCheck.cpp:277: >> more undefined references to >> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >> llvm::SourceMgr&, unsigned int)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: >> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned >> int&, llvm::SourceMgr&)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: >> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >> int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: >> undefined reference to `llvm::Regex::isValid(std::string&)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: >> undefined reference to `llvm::Regex::getNumMatches() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: >> undefined reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::Match(llvm::StringRef, unsigned long&, >> llvm::StringMap&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: >> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >> int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >> undefined reference to `llvm::Regex::match(llvm::StringRef, >> llvm::SmallVectorImpl*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >> undefined reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::ComputeMatchDistance(llvm::StringRef, >> llvm::StringMap const&) >> const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: >> undefined reference to >> `llvm::StringRef::edit_distance(llvm::StringRef, bool, unsigned int) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >> llvm::StringRef, llvm::StringMap> llvm::MallocAllocator> const&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: >> undefined reference to >> `llvm::raw_svector_ostream::raw_svector_ostream(llvm:: >> SmallVectorImpl&)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: >> undefined reference to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: >> undefined reference to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: >> undefined reference to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: >> undefined reference to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: >> undefined reference to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >> FileCheck/FileCheck.cpp:484: >> more undefined references to >> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >> llvm::StringRef, llvm::StringMap> llvm::MallocAllocator> const&) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >> undefined reference to `llvm::raw_svector_ostream::str()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: >> undefined reference to >> `llvm::raw_svector_ostream::~raw_svector_ostream()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `Pattern::FindRegexVarEnd(llvm::StringRef, >> llvm::SourceMgr&)': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `CanonicalizeInputFile': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: >> undefined reference to >> `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, >> llvm::StringRef)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `CheckTypeSize': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: >> undefined reference to `llvm::llvm_unreachable_internal(char const*, >> char const*, unsigned int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: >> undefined reference to `llvm::llvm_unreachable_internal(char const*, >> char const*, unsigned int)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `FindFirstCandidateMatch': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: >> undefined reference to `llvm::StringRef::find(llvm::StringRef, >> unsigned long) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `ReadCheckFile': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: >> undefined reference to >> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >> std::unique_ptr> std::default_delete >&, long)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: >> undefined reference to `llvm::error_code::message() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: >> undefined reference to >> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: >> undefined reference to >> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `PrintCheckFailed': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: >> undefined reference to >> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `CountNumNewlinesBetween': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: >> undefined reference to >> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `CheckString::CheckNext(llvm::SourceMgr const&, >> llvm::StringRef) const': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: >> undefined reference to >> `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: >> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >> FileCheck/FileCheck.cpp:1060: >> more undefined references to >> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >> llvm::SourceMgr::DiagKind, llvm::Twine const&, >> llvm::ArrayRef, llvm::ArrayRef, bool) >> const' follow >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `ValidateCheckPrefix': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: >> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >> int)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >> undefined reference to `llvm::Regex::match(llvm::StringRef, >> llvm::SmallVectorImpl*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >> undefined reference to `llvm::Regex::~Regex()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `main': >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: >> undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: >> undefined reference to `llvm::cl::ParseCommandLineOptions(int, char >> const* const*, char const*)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: >> undefined reference to >> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >> std::unique_ptr> std::default_delete >&, long)' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: >> undefined reference to `llvm::error_code::message() const' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: >> undefined reference to `llvm::errs()' >> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: >> undefined reference to `llvm::SourceMgr::~SourceMgr()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::GenericOptionValue::GenericOptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: >> undefined reference to `vtable for llvm::cl::GenericOptionValue' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::OptionValue::~OptionValue()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: >> undefined reference to `vtable for llvm::cl::OptionValue> string>' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser_impl::basic_parser_impl()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: >> undefined reference to `vtable for llvm::cl::basic_parser_impl' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::~basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser> string>' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::parser::~parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::opt> llvm::cl::desc, >> llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags const&, >> llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::opt> llvm::cl::initializer, llvm::cl::value_desc>(char const >> (&) [11], llvm::cl::desc const&, llvm::cl::initializer >> const&, llvm::cl::value_desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::list> llvm::cl::desc>(char const (&) [13], llvm::cl::desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::basic_parser::~basic_parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >> undefined reference to `vtable for llvm::cl::basic_parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::parser::parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::parser::~parser()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >> undefined reference to `vtable for llvm::cl::parser' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::opt >> >::opt(char const (&) [18], >> llvm::cl::desc const&)': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::done()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `std::enable_if::is_signed, >> bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) >> const': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: >> undefined reference to `llvm::getAsSignedInteger(llvm::StringRef, >> unsigned int, long long&)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::StringMap> llvm::MallocAllocator>::find(llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: >> undefined reference to >> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::StringMap> llvm::MallocAllocator>::find(llvm::StringRef) const': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: >> undefined reference to >> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::done()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: >> undefined reference to `llvm::cl::Option::addArgument()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::StringMapEntry& >> llvm::StringMap> llvm::MallocAllocator>::GetOrCreateValue> StringRef>(llvm::StringRef, >> llvm::StringRef)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >> undefined reference to >> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >> undefined reference to `llvm::StringMapImpl::RehashTable()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::SmallVectorTemplateCommon> void>::grow_pod(unsigned long, unsigned long)': >> /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: >> undefined reference to `llvm::SmallVectorBase::grow_pod(void*, >> unsigned long, unsigned long)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::StringMapEntry& llvm::StringMap> llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, >> char)': >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >> undefined reference to >> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >> undefined reference to `llvm::StringMapImpl::RehashTable()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `void llvm::cl::initializer> [2]>::apply> llvm::cl::parser > >(llvm::cl::opt> llvm::cl::parser >&) const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: >> undefined reference to `llvm::cl::opt> llvm::cl::parser >::setInitialValue(std::string const&)' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_ >> 6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): >> undefined reference to `llvm::cl::Option::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ >> ZTVN4llvm2cl11OptionValueIbEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseI >> bLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ >> ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ >> ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): >> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::opt> llvm::cl::parser >::~opt()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::opt >> >::~opt()': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >> undefined reference to `vtable for llvm::cl::opt> llvm::cl::parser >' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::PrettyStackTraceProgram::~ >> PrettyStackTraceProgram()': >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >> undefined >> reference to `vtable for llvm::PrettyStackTraceProgram' >> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >> undefined >> reference to `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::getOptionWidth() const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: >> undefined reference to >> `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option >> const&) const' >> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >> Asserts/FileCheck.o: >> In function `llvm::cl::list> llvm::cl::parser >::printOptionInfo(unsigned long) >> const': >> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: >> undefined reference to >> `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option >> const&, unsigned long) const' >> collect2: error: ld returned 1 exit status >> make[2]: *** >> [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] Error 1 >> make[2]: Leaving directory >> `/home/varosi/haskell/llvm/build/utils/FileCheck' >> make[1]: *** [FileCheck/.makeall] Error 2 >> make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' >> make: *** [all] Error 1 >> >> >> >> Another thing is that the link from: >> http://www.haskell.org/haskellwiki/ARM >> >> which is: >> http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html >> >> Is invalid and there could be some more information on the topic. >> I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. >> >> What could be the problem with LLVM? >> >> >> 2014-04-03 17:13 GMT+03:00 Karel Gardas > >: >> >> >> On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: >> >> Yes, but I don't know what is missing in my workflow. >> >> I did not know if I need LLVM runtime on my target ARM >> machine. >> >> >> No, you don't need LLVM runtime. You just need LLVM llc/opt if >> you'd like to cross-compile and build registerised ARM binaries. >> >> >> Do I >> need? I read that there is unregisterised version for ARM >> that doesn't >> need LLVM. So I just could build Haskell cross-compiler that >> could work >> on my Ubuntu and create binaries for my ARM v7 machine. >> >> >> If you'd like to use unregisterised /via-C binaries, then you >> don't need LLVM at all, you just need to configure with >> --enable-unregisterised IIRC, but I've not tested that so you >> are on your own. >> >> Also it comes with its own performance penalty of course: >> http://ghcarm.wordpress.com/__2011/08/07/nofib-benchmarking/ >> >> >> Karel >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varosi at gmail.com Thu Apr 3 18:32:22 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 21:32:22 +0300 Subject: Haskell Support on Windows (Simon Peyton Jones) In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0D38BB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I could try with building GHC on Windows as a cross-compiler for ARM if there is someone to help with building GHC. 2014-04-01 16:45 GMT+03:00 Carter Schonwald : > Hey roman! > If you get stuck getting ghc to build on windows, please ask for help on > the ghc mailing lists and/or on the #ghc channel on freenode. > Just having more folks that regularly try to build and use ghc on windows > would be huge. > There's also countless ways to contrib To ghc too. > > On Tuesday, April 1, 2014, Roman Kuznetsov wrote: > >> Hello, >> >> -- sorry for incomplete email - typing from mobile is not easy :) >> >> I would like to participate in GHC on Windows. But I am a normal windows >> developer and don't know much of that rather weird (to me) tool chain used >> in this case. I frankly tried a few times before - every time with the same >> result - I never get to the point, but trying to understand just how to >> build it. I know there is a wiki, etc. >> >> But my question (and the reason I write here): is it possible to have >> some kind of mini-course, a crush-course on developing GHC on Windows (as >> well as on other platforms) - video course ... this is what comes to mind >> after all these Coursera, Pluralsight, etc. >> >> You could say - there is a wiki. But that's not enough. Maybe it's just >> me... I will take another analogy. Even though I'm coding for Windows >> primarily, I am a linux user. So, I switched from Ubuntu to Arch Linux >> recently which was possible due to the quality of their wiki documentation >> (Arch is known to not be as user friendly as *buntu like systems). >> >> Sorry for not referring to any concrete problems, I just tried stating >> what I think didn't let me start working with that. >> >> /Roman >> >> On 01 ???. 2014 ?., at 15:26, "Carter Schonwald" < >> carter.schonwald at gmail.com> wrote: >> >> Kyle, we need you to help us with windows support! :-) >> >> On Tuesday, April 1, 2014, Simon Peyton Jones >> wrote: >> >> A couple of poor assumptions are made here. >> >> >> >> I?m not sure where ?here? is. In my email I specifically said exactly >> what you are saying (only I was not as eloquent as you). >> >> >> >> What we need is some developers who are willing to give some love and >> support to the Windows version of GHC. And *they* really are thin on >> the ground, unfortunately. >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Kyle >> Van Berendonck >> *Sent:* 01 April 2014 13:54 >> *To:* ghc-devs at haskell.org >> *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones) >> >> >> >> A couple of poor assumptions are made here. >> >> The first is that the userbase of GHC on Windows is poor. This is false. >> In fact, the poor state of Windows is mentioned on #haskell more frequently >> as of late. In the last week I've talked almost every day to (different) >> people who have had Windows woes with using GHC. The hacker-base isn't here >> at the moment - I agree, but the user-base most certainly is. Could this be >> a problem with the demographic, or could it just be that Windows >> development isn't inviting? The build system and default test failures >> in-particular are a source of discouragement. >> >> The second assumption is that GHC/Haskell will be worth a dime in the >> RealWorld without Windows as a primary tier platform. I'm going to put a >> crude guess that given the overwhelming magnitude of C#/F# coming up on my >> local careers portal that there's far more industry on Windows than on OSX >> or Linux. Those are all the businesses where the probability that they will >> ever touch Haskell goes from `probably not right now` to `impossible`. Let >> me also remind you that Windows still holds 89.2% of operating system >> market share ie the people that hackers and developers actually have to >> deploy their applications to. >> >> Sorry to sound fumey, but there's all this suggesting that everyone would >> have a better day if we dropped Windows (let's be honest, if it wasn't a >> primary tier platform nobody would have fixed it for 7.8), but I doubt few >> of the people who think it's a "great idea" or sslt have actually thought >> through whether it's the best thing for Haskell or just the best thing to >> get 7.8 into their hands a couple weeks sooner. >> >> Regards. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ ghc-devs mailing list >> ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Thu Apr 3 18:39:11 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 03 Apr 2014 19:39:11 +0100 Subject: 7.8.1 plan In-Reply-To: <53311BD4.3030008@mail.ru> References: <53311BD4.3030008@mail.ru> Message-ID: <533DAACF.3050801@fuuzetsu.co.uk> On 25/03/14 06:01, kyra wrote: > Will it include the latest commit to haddock? It solves this: > http://trac.haskell.org/haddock/ticket/292. This can greatly improve > performance of haddock in some situations (when a project is built with > --split-obj flag). > > Cheers, > Kyra Just as a follow up, as we had some more time, this is actually going into 7.8.1. Thanks -- Mateusz K. From varosi at gmail.com Thu Apr 3 19:04:22 2014 From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev) Date: Thu, 3 Apr 2014 22:04:22 +0300 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> <533DA2E1.9040509@centrum.cz> Message-ID: Okay, I got that LLVM is used here to build part of the GHC compiler for x86 and not for ARM directly. I have installed llvm-3.3 and build processed much longer until this error: configure: error: in `/home/varosi/haskell/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 I didn't found curses library at apt-get or cabal. 2014-04-03 21:13 GMT+03:00 eng. Vassil Ognyanov Keremidchiev < varosi at gmail.com>: > I would like to build GHC as a cross-compiler. So it can still run on x86 > Ubuntu, but producing code for ARM v7. > What should I do? > > > 2014-04-03 21:05 GMT+03:00 Karel Gardas : > > >> I don't understand why you are trying to cross-compile LLVM? I've though >> you'd like to cross-compile GHC itself... >> >> Karel >> >> >> On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote: >> >>> May be the problem is: >>> arm-linux-gnueabi-gcc --version >>> gives me 4.6.3 ? >>> >>> Is it possible to install earlier LLVM version? >>> >>> 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev >>> >: >>> >>> >>> I'm trying to compile LLVM as is described in: >>> http://bgamari.github.io/posts/cross-compiling_llvm.html >>> without success. This is the error: >>> >>> llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build >>> llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build >>> llvm[1]: Compiling TGParser.cpp for Debug+Asserts build >>> llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build >>> llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a >>> make[1]: Leaving directory >>> `/home/varosi/haskell/llvm/build/lib/TableGen' >>> make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' >>> make[2]: Entering directory >>> `/home/varosi/haskell/llvm/build/utils/FileCheck' >>> llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build >>> llvm[2]: Linking Debug+Asserts executable FileCheck >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, >>> llvm::cl::OptionHidden)': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >>> undefined reference to `vtable for llvm::cl::Option' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >>> undefined reference to `llvm::cl::GeneralCategory' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::Option::~Option()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: >>> undefined reference to `vtable for llvm::cl::Option' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: >>> undefined reference to `vtable for llvm::cl::GenericOptionValue' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::OptionValue::OptionValue()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: >>> undefined reference to `vtable for llvm::cl::OptionValue>> string>' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: >>> undefined reference to `vtable for llvm::cl::basic_parser_impl' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function >>> `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char >>> const* const*)': >>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >>> undefined >>> reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' >>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >>> undefined >>> reference to `vtable for llvm::PrettyStackTraceProgram' >>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: >>> undefined >>> reference to `llvm::EnablePrettyStackTrace()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::raw_ostream::operator<<(char)': >>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: >>> undefined reference to `llvm::raw_ostream::write(unsigned char)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::raw_ostream::operator<<(llvm::StringRef)': >>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: >>> undefined reference to `llvm::raw_ostream::write(char const*, >>> unsigned long)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::raw_ostream::operator<<(std::string const&)': >>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: >>> undefined reference to `llvm::raw_ostream::write(char const*, >>> unsigned long)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >>> llvm::SourceMgr&, unsigned int)': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>> FileCheck/FileCheck.cpp:277: >>> more undefined references to >>> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' follow >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef, >>> llvm::SourceMgr&, unsigned int)': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: >>> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned >>> int&, llvm::SourceMgr&)': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: >>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >>> int)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: >>> undefined reference to `llvm::Regex::isValid(std::string&)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: >>> undefined reference to `llvm::Regex::getNumMatches() const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: >>> undefined reference to `llvm::Regex::~Regex()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::Match(llvm::StringRef, unsigned long&, >>> llvm::StringMap&) const': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: >>> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >>> int)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>> undefined reference to `llvm::Regex::match(llvm::StringRef, >>> llvm::SmallVectorImpl*)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>> undefined reference to `llvm::Regex::~Regex()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::ComputeMatchDistance(llvm::StringRef, >>> llvm::StringMap const&) >>> const': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: >>> undefined reference to >>> `llvm::StringRef::edit_distance(llvm::StringRef, bool, unsigned int) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >>> llvm::StringRef, llvm::StringMap>> llvm::MallocAllocator> const&) const': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: >>> undefined reference to >>> `llvm::raw_svector_ostream::raw_svector_ostream(llvm:: >>> SmallVectorImpl&)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: >>> undefined reference to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: >>> undefined reference to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: >>> undefined reference to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: >>> undefined reference to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: >>> undefined reference to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>> FileCheck/FileCheck.cpp:484: >>> more undefined references to >>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >>> llvm::StringRef, llvm::StringMap>> llvm::MallocAllocator> const&) const': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >>> undefined reference to `llvm::raw_svector_ostream::str()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: >>> undefined reference to >>> `llvm::raw_svector_ostream::~raw_svector_ostream()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `Pattern::FindRegexVarEnd(llvm::StringRef, >>> llvm::SourceMgr&)': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `CanonicalizeInputFile': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: >>> undefined reference to >>> `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, >>> llvm::StringRef)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `CheckTypeSize': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: >>> undefined reference to `llvm::llvm_unreachable_internal(char const*, >>> char const*, unsigned int)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: >>> undefined reference to `llvm::llvm_unreachable_internal(char const*, >>> char const*, unsigned int)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `FindFirstCandidateMatch': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: >>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>> unsigned long) const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `ReadCheckFile': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: >>> undefined reference to >>> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >>> std::unique_ptr>> std::default_delete >&, long)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: >>> undefined reference to `llvm::error_code::message() const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: >>> undefined reference to >>> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: >>> undefined reference to >>> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `PrintCheckFailed': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: >>> undefined reference to >>> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `CountNumNewlinesBetween': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: >>> undefined reference to >>> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `CheckString::CheckNext(llvm::SourceMgr const&, >>> llvm::StringRef) const': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: >>> undefined reference to >>> `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: >>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>> FileCheck/FileCheck.cpp:1060: >>> more undefined references to >>> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>> llvm::ArrayRef, llvm::ArrayRef, bool) >>> const' follow >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `ValidateCheckPrefix': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: >>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, unsigned >>> int)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >>> undefined reference to `llvm::Regex::match(llvm::StringRef, >>> llvm::SmallVectorImpl*)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >>> undefined reference to `llvm::Regex::~Regex()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `main': >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: >>> undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: >>> undefined reference to `llvm::cl::ParseCommandLineOptions(int, char >>> const* const*, char const*)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: >>> undefined reference to >>> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >>> std::unique_ptr>> std::default_delete >&, long)' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: >>> undefined reference to `llvm::error_code::message() const' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: >>> undefined reference to `llvm::errs()' >>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: >>> undefined reference to `llvm::SourceMgr::~SourceMgr()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::GenericOptionValue::GenericOptionValue()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: >>> undefined reference to `vtable for llvm::cl::GenericOptionValue' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::OptionValue::~OptionValue()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: >>> undefined reference to `vtable for llvm::cl::OptionValue>> string>' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::basic_parser_impl::basic_parser_impl()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: >>> undefined reference to `vtable for llvm::cl::basic_parser_impl' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::basic_parser::~basic_parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>> undefined reference to `vtable for llvm::cl::basic_parser>> string>' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::parser::~parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::opt>> llvm::cl::parser >::opt>> llvm::cl::desc, >>> llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags const&, >>> llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >>> undefined reference to `vtable for llvm::cl::opt>> llvm::cl::parser >' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: >>> undefined reference to `llvm::cl::opt>> llvm::cl::parser >::done()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::opt>> llvm::cl::parser >::opt>> llvm::cl::initializer, llvm::cl::value_desc>(char const >>> (&) [11], llvm::cl::desc const&, llvm::cl::initializer >>> const&, llvm::cl::value_desc const&)': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >>> undefined reference to `vtable for llvm::cl::opt>> llvm::cl::parser >' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: >>> undefined reference to `llvm::cl::opt>> llvm::cl::parser >::done()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::list>> llvm::cl::parser >::list>> llvm::cl::desc>(char const (&) [13], llvm::cl::desc const&)': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::basic_parser::basic_parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>> undefined reference to `vtable for llvm::cl::basic_parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::basic_parser::~basic_parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>> undefined reference to `vtable for llvm::cl::basic_parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::parser::parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::parser::~parser()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >>> undefined reference to `vtable for llvm::cl::parser' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::opt >>> >::opt(char const (&) [18], >>> llvm::cl::desc const&)': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: >>> undefined reference to `vtable for llvm::cl::opt>> llvm::cl::parser >' >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: >>> undefined reference to `llvm::cl::opt>> llvm::cl::parser >::done()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `std::enable_if::is_signed, >>> bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) >>> const': >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: >>> undefined reference to `llvm::getAsSignedInteger(llvm::StringRef, >>> unsigned int, long long&)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::StringMap>> llvm::MallocAllocator>::find(llvm::StringRef)': >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: >>> undefined reference to >>> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::StringMap>> llvm::MallocAllocator>::find(llvm::StringRef) const': >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: >>> undefined reference to >>> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::list>> llvm::cl::parser >::done()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: >>> undefined reference to `llvm::cl::Option::addArgument()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::StringMapEntry& >>> llvm::StringMap>> llvm::MallocAllocator>::GetOrCreateValue>> StringRef>(llvm::StringRef, >>> llvm::StringRef)': >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >>> undefined reference to >>> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >>> undefined reference to `llvm::StringMapImpl::RehashTable()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::SmallVectorTemplateCommon>> void>::grow_pod(unsigned long, unsigned long)': >>> /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: >>> undefined reference to `llvm::SmallVectorBase::grow_pod(void*, >>> unsigned long, unsigned long)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::StringMapEntry& llvm::StringMap>> llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, >>> char)': >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >>> undefined reference to >>> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >>> undefined reference to `llvm::StringMapImpl::RehashTable()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `void llvm::cl::initializer>> [2]>::apply>> llvm::cl::parser > >(llvm::cl::opt>> llvm::cl::parser >&) const': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: >>> undefined reference to `llvm::cl::opt>> llvm::cl::parser >::setInitialValue(std::string const&)' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_ >>> 6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): >>> undefined reference to `llvm::cl::Option::anchor()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ >>> ZTVN4llvm2cl11OptionValueIbEE]+0x28): >>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseI >>> bLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): >>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ >>> ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): >>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ >>> ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): >>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::opt>> llvm::cl::parser >::~opt()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >>> undefined reference to `vtable for llvm::cl::opt>> llvm::cl::parser >' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::opt >>> >::~opt()': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >>> undefined reference to `vtable for llvm::cl::opt>> llvm::cl::parser >' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::PrettyStackTraceProgram::~ >>> PrettyStackTraceProgram()': >>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >>> undefined >>> reference to `vtable for llvm::PrettyStackTraceProgram' >>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >>> undefined >>> reference to `llvm::PrettyStackTraceEntry::~PrettyStackTraceEntry()' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::list>> llvm::cl::parser >::getOptionWidth() const': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: >>> undefined reference to >>> `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option >>> const&) const' >>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>> Asserts/FileCheck.o: >>> In function `llvm::cl::list>> llvm::cl::parser >::printOptionInfo(unsigned long) >>> const': >>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: >>> undefined reference to >>> `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option >>> const&, unsigned long) const' >>> collect2: error: ld returned 1 exit status >>> make[2]: *** >>> [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] Error >>> 1 >>> make[2]: Leaving directory >>> `/home/varosi/haskell/llvm/build/utils/FileCheck' >>> make[1]: *** [FileCheck/.makeall] Error 2 >>> make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' >>> make: *** [all] Error 1 >>> >>> >>> >>> Another thing is that the link from: >>> http://www.haskell.org/haskellwiki/ARM >>> >>> which is: >>> http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html >>> >>> Is invalid and there could be some more information on the topic. >>> I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. >>> >>> What could be the problem with LLVM? >>> >>> >>> 2014-04-03 17:13 GMT+03:00 Karel Gardas >> >: >>> >>> >>> On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: >>> >>> Yes, but I don't know what is missing in my workflow. >>> >>> I did not know if I need LLVM runtime on my target ARM >>> machine. >>> >>> >>> No, you don't need LLVM runtime. You just need LLVM llc/opt if >>> you'd like to cross-compile and build registerised ARM binaries. >>> >>> >>> Do I >>> need? I read that there is unregisterised version for ARM >>> that doesn't >>> need LLVM. So I just could build Haskell cross-compiler that >>> could work >>> on my Ubuntu and create binaries for my ARM v7 machine. >>> >>> >>> If you'd like to use unregisterised /via-C binaries, then you >>> don't need LLVM at all, you just need to configure with >>> --enable-unregisterised IIRC, but I've not tested that so you >>> are on your own. >>> >>> Also it comes with its own performance penalty of course: >>> http://ghcarm.wordpress.com/__2011/08/07/nofib-benchmarking/ >>> >>> >>> Karel >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Apr 3 19:14:01 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 3 Apr 2014 15:14:01 -0400 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> <533DA2E1.9040509@centrum.cz> Message-ID: try "libcurses" for more hands on support getting ghc working, #ghc on freenode (when people are around) also works are you following the cross compilation directions? On Thu, Apr 3, 2014 at 3:04 PM, eng. Vassil Ognyanov Keremidchiev < varosi at gmail.com> wrote: > Okay, I got that LLVM is used here to build part of the GHC compiler for > x86 and not for ARM directly. > I have installed llvm-3.3 and build processed much longer until this error: > > configure: error: in `/home/varosi/haskell/ghc/libraries/terminfo': > configure: error: curses library not found, so this package cannot be built > See `config.log' for more details > make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 > make: *** [all] Error 2 > > I didn't found curses library at apt-get or cabal. > > > 2014-04-03 21:13 GMT+03:00 eng. Vassil Ognyanov Keremidchiev < > varosi at gmail.com>: > > I would like to build GHC as a cross-compiler. So it can still run on x86 >> Ubuntu, but producing code for ARM v7. >> What should I do? >> >> >> 2014-04-03 21:05 GMT+03:00 Karel Gardas : >> >> >>> I don't understand why you are trying to cross-compile LLVM? I've though >>> you'd like to cross-compile GHC itself... >>> >>> Karel >>> >>> >>> On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote: >>> >>>> May be the problem is: >>>> arm-linux-gnueabi-gcc --version >>>> gives me 4.6.3 ? >>>> >>>> Is it possible to install earlier LLVM version? >>>> >>>> 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev >>>> >: >>>> >>>> >>>> I'm trying to compile LLVM as is described in: >>>> http://bgamari.github.io/posts/cross-compiling_llvm.html >>>> without success. This is the error: >>>> >>>> llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build >>>> llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build >>>> llvm[1]: Compiling TGParser.cpp for Debug+Asserts build >>>> llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build >>>> llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a >>>> make[1]: Leaving directory >>>> `/home/varosi/haskell/llvm/build/lib/TableGen' >>>> make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils' >>>> make[2]: Entering directory >>>> `/home/varosi/haskell/llvm/build/utils/FileCheck' >>>> llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build >>>> llvm[2]: Linking Debug+Asserts executable FileCheck >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag, >>>> llvm::cl::OptionHidden)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >>>> undefined reference to `vtable for llvm::cl::Option' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242: >>>> undefined reference to `llvm::cl::GeneralCategory' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::Option::~Option()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281: >>>> undefined reference to `vtable for llvm::cl::Option' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::GenericOptionValue::~GenericOptionValue()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356: >>>> undefined reference to `vtable for llvm::cl::GenericOptionValue' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::OptionValue::OptionValue()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: >>>> undefined reference to `vtable for llvm::cl::OptionValue>>> string>' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::basic_parser_impl::~basic_parser_impl()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702: >>>> undefined reference to `vtable for llvm::cl::basic_parser_impl' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function >>>> `llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char >>>> const* const*)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >>>> undefined >>>> reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()' >>>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: >>>> undefined >>>> reference to `vtable for llvm::PrettyStackTraceProgram' >>>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: >>>> undefined >>>> reference to `llvm::EnablePrettyStackTrace()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::raw_ostream::operator<<(char)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136: >>>> undefined reference to `llvm::raw_ostream::write(unsigned char)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::raw_ostream::operator<<(llvm::StringRef)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161: >>>> undefined reference to `llvm::raw_ostream::write(char const*, >>>> unsigned long)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::raw_ostream::operator<<(std::string const&)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177: >>>> undefined reference to `llvm::raw_ostream::write(char const*, >>>> unsigned long)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::ParsePattern(llvm::StringRef, >>>> llvm::StringRef, >>>> llvm::SourceMgr&, unsigned int)': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:198: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:202: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:234: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:247: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:260: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:269: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>>> FileCheck/FileCheck.cpp:277: >>>> more undefined references to >>>> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' follow >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::ParsePattern(llvm::StringRef, >>>> llvm::StringRef, >>>> llvm::SourceMgr&, unsigned int)': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:313: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:314: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:315: >>>> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::AddRegExToRegEx(llvm::StringRef, unsigned >>>> int&, llvm::SourceMgr&)': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:324: >>>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, >>>> unsigned >>>> int)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:326: >>>> undefined reference to `llvm::Regex::isValid(std::string&)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:328: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:333: >>>> undefined reference to `llvm::Regex::getNumMatches() const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:334: >>>> undefined reference to `llvm::Regex::~Regex()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::Match(llvm::StringRef, unsigned long&, >>>> llvm::StringMap&) const': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:376: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:403: >>>> undefined reference to `llvm::Regex::escape(llvm::StringRef)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, >>>> unsigned >>>> int)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>>> undefined reference to `llvm::Regex::match(llvm::StringRef, >>>> llvm::SmallVectorImpl*)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:418: >>>> undefined reference to `llvm::Regex::~Regex()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::ComputeMatchDistance(llvm::StringRef, >>>> llvm::StringMap const&) >>>> const': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:452: >>>> undefined reference to >>>> `llvm::StringRef::edit_distance(llvm::StringRef, bool, unsigned >>>> int) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >>>> llvm::StringRef, llvm::StringMap>>> llvm::MallocAllocator> const&) const': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:462: >>>> undefined reference to >>>> `llvm::raw_svector_ostream::raw_svector_ostream(llvm:: >>>> SmallVectorImpl&)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:468: >>>> undefined reference to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:469: >>>> undefined reference to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:472: >>>> undefined reference to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:480: >>>> undefined reference to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:483: >>>> undefined reference to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>>> FileCheck/FileCheck.cpp:484: >>>> more undefined references to >>>> `llvm::raw_ostream::write_escaped(llvm::StringRef, bool)' follow >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::PrintFailureInfo(llvm::SourceMgr const&, >>>> llvm::StringRef, llvm::StringMap>>> llvm::MallocAllocator> const&) const': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >>>> undefined reference to `llvm::raw_svector_ostream::str()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:489: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:490: >>>> undefined reference to >>>> `llvm::raw_svector_ostream::~raw_svector_ostream()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:527: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `Pattern::FindRegexVarEnd(llvm::StringRef, >>>> llvm::SourceMgr&)': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:558: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `CanonicalizeInputFile': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:655: >>>> undefined reference to >>>> `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, >>>> llvm::StringRef)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `CheckTypeSize': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:687: >>>> undefined reference to `llvm::llvm_unreachable_internal(char >>>> const*, >>>> char const*, unsigned int)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:690: >>>> undefined reference to `llvm::llvm_unreachable_internal(char >>>> const*, >>>> char const*, unsigned int)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `FindFirstCandidateMatch': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:748: >>>> undefined reference to `llvm::StringRef::find(llvm::StringRef, >>>> unsigned long) const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `ReadCheckFile': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:825: >>>> undefined reference to >>>> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >>>> std::unique_ptr>>> std::default_delete >&, long)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:827: >>>> undefined reference to `llvm::error_code::message() const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:826: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:868: >>>> undefined reference to >>>> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:871: >>>> undefined reference to >>>> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:886: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:897: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:926: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:930: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:932: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:935: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `PrintCheckFailed': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:947: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:951: >>>> undefined reference to >>>> `llvm::StringRef::find_first_not_of(llvm::StringRef, unsigned long) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:954: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `CountNumNewlinesBetween': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:972: >>>> undefined reference to >>>> `llvm::StringRef::find_first_of(llvm::StringRef, unsigned long) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `CheckString::CheckNext(llvm::SourceMgr const&, >>>> llvm::StringRef) const': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1036: >>>> undefined reference to >>>> `llvm::SourceMgr::FindBufferContainingLoc(llvm::SMLoc) const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1046: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1048: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1050: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1056: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1058: >>>> undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:/home/varosi/haskell/llvm/utils/ >>>> FileCheck/FileCheck.cpp:1060: >>>> more undefined references to >>>> `llvm::SourceMgr::PrintMessage(llvm::SMLoc, >>>> llvm::SourceMgr::DiagKind, llvm::Twine const&, >>>> llvm::ArrayRef, llvm::ArrayRef, bool) >>>> const' follow >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `ValidateCheckPrefix': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1170: >>>> undefined reference to `llvm::Regex::Regex(llvm::StringRef, >>>> unsigned >>>> int)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >>>> undefined reference to `llvm::Regex::match(llvm::StringRef, >>>> llvm::SmallVectorImpl*)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1171: >>>> undefined reference to `llvm::Regex::~Regex()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `main': >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1199: >>>> undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1201: >>>> undefined reference to `llvm::cl::ParseCommandLineOptions(int, char >>>> const* const*, char const*)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1204: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1222: >>>> undefined reference to >>>> `llvm::MemoryBuffer::getFileOrSTDIN(llvm::StringRef, >>>> std::unique_ptr>>> std::default_delete >&, long)' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1224: >>>> undefined reference to `llvm::error_code::message() const' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1223: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1229: >>>> undefined reference to `llvm::errs()' >>>> /home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:1298: >>>> undefined reference to `llvm::SourceMgr::~SourceMgr()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::GenericOptionValue::GenericOptionValue()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:355: >>>> undefined reference to `vtable for llvm::cl::GenericOptionValue' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::OptionValue::~OptionValue()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:458: >>>> undefined reference to `vtable for llvm::cl::OptionValue>>> string>' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::basic_parser_impl::basic_parser_impl()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:700: >>>> undefined reference to `vtable for llvm::cl::basic_parser_impl' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::basic_parser::~basic_parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>>> undefined reference to `vtable for llvm::cl::basic_parser>>> string>' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::parser::~parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:912: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::opt>>> llvm::cl::parser >::opt>>> llvm::cl::desc, >>>> llvm::cl::NumOccurrencesFlag>(llvm::cl::FormattingFlags const&, >>>> llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag const&)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >>>> undefined reference to `vtable for llvm::cl::opt>>> llvm::cl::parser >' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1225: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1227: >>>> undefined reference to `llvm::cl::opt>>> llvm::cl::parser >::done()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::opt>>> llvm::cl::parser >::opt>>> llvm::cl::initializer, llvm::cl::value_desc>(char const >>>> (&) [11], llvm::cl::desc const&, llvm::cl::initializer >>>> const&, llvm::cl::value_desc const&)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >>>> undefined reference to `vtable for llvm::cl::opt>>> llvm::cl::parser >' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1232: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1234: >>>> undefined reference to `llvm::cl::opt>>> llvm::cl::parser >::done()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::list>>> llvm::cl::parser >::list>>> llvm::cl::desc>(char const (&) [13], llvm::cl::desc const&)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1385: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::basic_parser::basic_parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>>> undefined reference to `vtable for llvm::cl::basic_parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::basic_parser::~basic_parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:739: >>>> undefined reference to `vtable for llvm::cl::basic_parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::parser::parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::parser::~parser()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:749: >>>> undefined reference to `vtable for llvm::cl::parser' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::opt >>>> >::opt(char const (&) [18], >>>> llvm::cl::desc const&)': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1217: >>>> undefined reference to `vtable for llvm::cl::opt>>> llvm::cl::parser >' >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1219: >>>> undefined reference to `llvm::cl::opt>>> llvm::cl::parser >::done()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `std::enable_if::is_signed, >>>> bool>::type llvm::StringRef::getAsInteger(unsigned int, int&) >>>> const': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringRef.h:346: >>>> undefined reference to `llvm::getAsSignedInteger(llvm::StringRef, >>>> unsigned int, long long&)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::StringMap>>> llvm::MallocAllocator>::find(llvm::StringRef)': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:274: >>>> undefined reference to >>>> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::StringMap>>> llvm::MallocAllocator>::find(llvm::StringRef) const': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:280: >>>> undefined reference to >>>> `llvm::StringMapImpl::FindKey(llvm::StringRef) const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::list>>> llvm::cl::parser >::done()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1362: >>>> undefined reference to `llvm::cl::Option::addArgument()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::StringMapEntry& >>>> llvm::StringMap>>> llvm::MallocAllocator>::GetOrCreateValue>>> StringRef>(llvm::StringRef, >>>> llvm::StringRef)': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >>>> undefined reference to >>>> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >>>> undefined reference to `llvm::StringMapImpl::RehashTable()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::SmallVectorTemplateCommon>>> void>::grow_pod(unsigned long, unsigned long)': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/SmallVector.h:82: >>>> undefined reference to `llvm::SmallVectorBase::grow_pod(void*, >>>> unsigned long, unsigned long)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::StringMapEntry& llvm::StringMap>>> llvm::MallocAllocator>::GetOrCreateValue(llvm::StringRef, >>>> char)': >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:345: >>>> undefined reference to >>>> `llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)' >>>> /home/varosi/haskell/llvm/include/llvm/ADT/StringMap.h:362: >>>> undefined reference to `llvm::StringMapImpl::RehashTable()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `void llvm::cl::initializer>>> [2]>::apply>>> llvm::cl::parser > >(llvm::cl::opt>>> llvm::cl::parser >&) const': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:315: >>>> undefined reference to `llvm::cl::opt>>> llvm::cl::parser >::setInitialValue(std::string >>>> const&)' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl4listISsbNS0_ >>>> 6parserISsEEEE[_ZTVN4llvm2cl4listISsbNS0_6parserISsEEEE]+0x20): >>>> undefined reference to `llvm::cl::Option::anchor()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ >>>> ZTVN4llvm2cl11OptionValueIbEE]+0x28): >>>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueBaseI >>>> bLb0EEE[_ZTVN4llvm2cl15OptionValueBaseIbLb0EEE]+0x28): >>>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyIbEE[_ >>>> ZTVN4llvm2cl15OptionValueCopyIbEE]+0x28): >>>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyISsEE[_ >>>> ZTVN4llvm2cl15OptionValueCopyISsEE]+0x28): >>>> undefined reference to `llvm::cl::GenericOptionValue::anchor()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::opt>>> llvm::cl::parser >::~opt()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >>>> undefined reference to `vtable for llvm::cl::opt>>> llvm::cl::parser >' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::opt >>>> >::~opt()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1156: >>>> undefined reference to `vtable for llvm::cl::opt>>> llvm::cl::parser >' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::PrettyStackTraceProgram::~ >>>> PrettyStackTraceProgram()': >>>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >>>> undefined >>>> reference to `vtable for llvm::PrettyStackTraceProgram' >>>> /home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:58: >>>> undefined >>>> reference to `llvm::PrettyStackTraceEntry:: >>>> ~PrettyStackTraceEntry()' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::list>>> llvm::cl::parser >::getOptionWidth() const': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1352: >>>> undefined reference to >>>> `llvm::cl::basic_parser_impl::getOptionWidth(llvm::cl::Option >>>> const&) const' >>>> /home/varosi/haskell/llvm/build/utils/FileCheck/Debug+ >>>> Asserts/FileCheck.o: >>>> In function `llvm::cl::list>>> llvm::cl::parser >::printOptionInfo(unsigned long) >>>> const': >>>> /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:1354: >>>> undefined reference to >>>> `llvm::cl::basic_parser_impl::printOptionInfo(llvm::cl::Option >>>> const&, unsigned long) const' >>>> collect2: error: ld returned 1 exit status >>>> make[2]: *** >>>> [/home/varosi/haskell/llvm/build/Debug+Asserts/bin/FileCheck] >>>> Error 1 >>>> make[2]: Leaving directory >>>> `/home/varosi/haskell/llvm/build/utils/FileCheck' >>>> make[1]: *** [FileCheck/.makeall] Error 2 >>>> make[1]: Leaving directory `/home/varosi/haskell/llvm/build/utils' >>>> make: *** [all] Error 1 >>>> >>>> >>>> >>>> Another thing is that the link from: >>>> http://www.haskell.org/haskellwiki/ARM >>>> >>>> which is: >>>> http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html >>>> >>>> Is invalid and there could be some more information on the topic. >>>> I had to install GCC 4.7 to compile latest LLVM on my Ubuntu 12. >>>> >>>> What could be the problem with LLVM? >>>> >>>> >>>> 2014-04-03 17:13 GMT+03:00 Karel Gardas >>> >: >>>> >>>> >>>> On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote: >>>> >>>> Yes, but I don't know what is missing in my workflow. >>>> >>>> I did not know if I need LLVM runtime on my target ARM >>>> machine. >>>> >>>> >>>> No, you don't need LLVM runtime. You just need LLVM llc/opt if >>>> you'd like to cross-compile and build registerised ARM binaries. >>>> >>>> >>>> Do I >>>> need? I read that there is unregisterised version for ARM >>>> that doesn't >>>> need LLVM. So I just could build Haskell cross-compiler that >>>> could work >>>> on my Ubuntu and create binaries for my ARM v7 machine. >>>> >>>> >>>> If you'd like to use unregisterised /via-C binaries, then you >>>> don't need LLVM at all, you just need to configure with >>>> --enable-unregisterised IIRC, but I've not tested that so you >>>> are on your own. >>>> >>>> Also it comes with its own performance penalty of course: >>>> http://ghcarm.wordpress.com/__2011/08/07/nofib-benchmarking/ >>>> >>>> >>>> Karel >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slyich at gmail.com Thu Apr 3 20:20:17 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Thu, 3 Apr 2014 23:20:17 +0300 Subject: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate In-Reply-To: <20140322222142.798abe7e@sf> References: <20140322222142.798abe7e@sf> Message-ID: <20140403232017.1c2b2db2@sf> On Sat, 22 Mar 2014 22:21:42 +0300 Sergei Trofimovich wrote: > Hello! > > I have noticed the problem in ghc-7.6.3 first > when tried to build all haskell userland with -O2 opt level. > > It led to amazing bugs! > > Here is one of those (highlighting-kate hackage package): > > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > > stack overflow: use +RTS -K to increase it > > How to reproduce it: > 1. Download a bundled file (6.6MB): > http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz > 2. Unpack and run there: > ./mk.sh > > The script is designed to plug any built ghc version w/o external depends. > > Command will fail as: > $ ./mk.sh > ... > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > stack overflow: use +RTS -K to increase it > > On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there > similar way. > > I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them > manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} > around. Nothing else. > > It's very hard to shrink such large thing manually down to 2-3 files. > Would be cool if ghc (and cabal) would be able to spit something > self-sufficient (like 'gcc -i' does) for devs to reproduce. > > Adding '-v' shows such log: > ... > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 21,973, types: 21,838, coercions: 1,842} > Result size of Simplifier iteration=2 > = {terms: 21,952, types: 21,819, coercions: 1,842} > Result size of Simplifier > = {terms: 21,950, types: 21,817, coercions: 1,842} > *** SpecConstr: > Result size of SpecConstr*** Nobody interested? Is it too scary? Such inliner blowups are hard to shrink down from real examples down to toy ones. I could try to but I need a bit of guidance. Maybe you need only an intermediate core step right before an OOM, whatever? Thanks! -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From karel.gardas at centrum.cz Thu Apr 3 22:06:07 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 04 Apr 2014 00:06:07 +0200 Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM In-Reply-To: References: <5335BAC4.40304@centrum.cz> <533D6CA5.5030007@centrum.cz> <533DA2E1.9040509@centrum.cz> Message-ID: <533DDB4F.4090604@centrum.cz> Your libncurses is for host so your cross-compiler can't use it. See http://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/ -- especially bits about sysroot. Karel On 04/ 3/14 09:04 PM, eng. Vassil Ognyanov Keremidchiev wrote: > Okay, I got that LLVM is used here to build part of the GHC compiler for > x86 and not for ARM directly. > I have installed llvm-3.3 and build processed much longer until this error: > > configure: error: in `/home/varosi/haskell/ghc/libraries/terminfo': > configure: error: curses library not found, so this package cannot be built > See `config.log' for more details > make[1]: *** [libraries/terminfo/dist-install/package-data.mk > ] Error 1 > make: *** [all] Error 2 > > I didn't found curses library at apt-get or cabal. > > > 2014-04-03 21:13 GMT+03:00 eng. Vassil Ognyanov Keremidchiev > >: > > I would like to build GHC as a cross-compiler. So it can still run > on x86 Ubuntu, but producing code for ARM v7. > What should I do? > > > 2014-04-03 21:05 GMT+03:00 Karel Gardas >: > > > I don't understand why you are trying to cross-compile LLVM? > I've though you'd like to cross-compile GHC itself... > > Karel > > > On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote: > > May be the problem is: > arm-linux-gnueabi-gcc --version > gives me 4.6.3 ? > > Is it possible to install earlier LLVM version? > > 2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev > > >>: > > > I'm trying to compile LLVM as is described in: > http://bgamari.github.io/__posts/cross-compiling_llvm.__html > > without success. This is the error: > > llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts > build > llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build > llvm[1]: Compiling TGParser.cpp for Debug+Asserts build > llvm[1]: Compiling TableGenBackend.cpp for > Debug+Asserts build > llvm[1]: Building Debug+Asserts Archive Library > libLLVMTableGen.a > make[1]: Leaving directory > `/home/varosi/haskell/llvm/__build/lib/TableGen' > make[1]: Entering directory > `/home/varosi/haskell/llvm/__build/utils' > make[2]: Entering directory > `/home/varosi/haskell/llvm/__build/utils/FileCheck' > llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build > llvm[2]: Linking Debug+Asserts executable FileCheck > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::Option::Option(__llvm::cl::NumOccurrencesFlag, > llvm::cl::OptionHidden)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:242: > undefined reference to `vtable for llvm::cl::Option' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:242: > undefined reference to `llvm::cl::GeneralCategory' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::Option::~Option()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:281: > undefined reference to `vtable for llvm::cl::Option' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::GenericOptionValue:__:~GenericOptionValue()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:356: > undefined reference to `vtable for > llvm::cl::GenericOptionValue' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::OptionValue::OptionValue()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:461: > undefined reference to `vtable for > llvm::cl::OptionValue' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::basic_parser_impl::__~basic_parser_impl()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:702: > undefined reference to `vtable for > llvm::cl::basic_parser_impl' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > > `llvm::__PrettyStackTraceProgram::__PrettyStackTraceProgram(int, > char > const* const*)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__PrettyStackTrace.h:63: > undefined > reference to > `llvm::PrettyStackTraceEntry::__PrettyStackTraceEntry()' > > /home/varosi/haskell/llvm/__include/llvm/Support/__PrettyStackTrace.h:63: > undefined > reference to `vtable for llvm::PrettyStackTraceProgram' > > /home/varosi/haskell/llvm/__include/llvm/Support/__PrettyStackTrace.h:64: > undefined > reference to `llvm::EnablePrettyStackTrace(__)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::raw_ostream::operator<<__(char)': > > /home/varosi/haskell/llvm/__include/llvm/Support/raw___ostream.h:136: > undefined reference to > `llvm::raw_ostream::write(__unsigned char)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::raw_ostream::operator<<__(llvm::StringRef)': > > /home/varosi/haskell/llvm/__include/llvm/Support/raw___ostream.h:161: > undefined reference to `llvm::raw_ostream::write(char > const*, > unsigned long)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::raw_ostream::operator<<__(std::string const&)': > > /home/varosi/haskell/llvm/__include/llvm/Support/raw___ostream.h:177: > undefined reference to `llvm::raw_ostream::write(char > const*, > unsigned long)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::__StringRef, > llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__176: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__182: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__183: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__198: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__202: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__234: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__247: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__260: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__269: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:/home/__varosi/haskell/llvm/utils/__FileCheck/FileCheck.cpp:277: > more undefined references to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' follow > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `Pattern::ParsePattern(llvm::__StringRef, > llvm::StringRef, > llvm::SourceMgr&, unsigned int)': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__313: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__314: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__315: > undefined reference to > `llvm::Regex::escape(llvm::__StringRef)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `Pattern::AddRegExToRegEx(__llvm::StringRef, unsigned > int&, llvm::SourceMgr&)': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__324: > undefined reference to > `llvm::Regex::Regex(llvm::__StringRef, unsigned > int)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__326: > undefined reference to > `llvm::Regex::isValid(std::__string&)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__328: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__333: > undefined reference to `llvm::Regex::getNumMatches() const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__334: > undefined reference to `llvm::Regex::~Regex()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `Pattern::Match(llvm::__StringRef, unsigned > long&, > llvm::StringMap llvm::MallocAllocator>&) const': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__376: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__403: > undefined reference to > `llvm::Regex::escape(llvm::__StringRef)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__418: > undefined reference to > `llvm::Regex::Regex(llvm::__StringRef, unsigned > int)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__418: > undefined reference to > `llvm::Regex::match(llvm::__StringRef, > llvm::SmallVectorImpl*)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__418: > undefined reference to `llvm::Regex::~Regex()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `Pattern::__ComputeMatchDistance(llvm::__StringRef, > llvm::StringMap llvm::MallocAllocator> const&) const': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__452: > undefined reference to > `llvm::StringRef::edit___distance(llvm::StringRef, > bool, unsigned int) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `Pattern::PrintFailureInfo(__llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap llvm::MallocAllocator> const&) const': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__462: > undefined reference to > > `llvm::raw_svector_ostream::__raw_svector_ostream(llvm::__SmallVectorImpl&)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__468: > undefined reference to > `llvm::raw_ostream::write___escaped(llvm::StringRef, bool)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__469: > undefined reference to > `llvm::raw_ostream::write___escaped(llvm::StringRef, bool)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__472: > undefined reference to > `llvm::raw_ostream::write___escaped(llvm::StringRef, bool)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__480: > undefined reference to > `llvm::raw_ostream::write___escaped(llvm::StringRef, bool)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__483: > undefined reference to > `llvm::raw_ostream::write___escaped(llvm::StringRef, bool)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:/home/__varosi/haskell/llvm/utils/__FileCheck/FileCheck.cpp:484: > more undefined references to > `llvm::raw_ostream::write___escaped(llvm::StringRef, > bool)' follow > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `Pattern::PrintFailureInfo(__llvm::SourceMgr const&, > llvm::StringRef, llvm::StringMap llvm::MallocAllocator> const&) const': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__489: > undefined reference to `llvm::raw_svector_ostream::__str()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__489: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__490: > undefined reference to > `llvm::raw_svector_ostream::~__raw_svector_ostream()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__527: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `Pattern::FindRegexVarEnd(__llvm::StringRef, > llvm::SourceMgr&)': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__558: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `CanonicalizeInputFile': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__655: > undefined reference to > > `llvm::MemoryBuffer::__getMemBufferCopy(llvm::__StringRef, > llvm::StringRef)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `CheckTypeSize': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__687: > undefined reference to > `llvm::llvm_unreachable___internal(char const*, > char const*, unsigned int)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__690: > undefined reference to > `llvm::llvm_unreachable___internal(char const*, > char const*, unsigned int)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `FindFirstCandidateMatch': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__748: > undefined reference to > `llvm::StringRef::find(llvm::__StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `ReadCheckFile': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__825: > undefined reference to > `llvm::MemoryBuffer::__getFileOrSTDIN(llvm::__StringRef, > std::unique_ptr std::default_delete >&, long)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__827: > undefined reference to `llvm::error_code::message() const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__826: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__868: > undefined reference to > `llvm::StringRef::find_first___not_of(llvm::StringRef, > unsigned long) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__871: > undefined reference to > `llvm::StringRef::find_first___of(llvm::StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__886: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__897: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__926: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__930: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__932: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__935: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `PrintCheckFailed': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__947: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__951: > undefined reference to > `llvm::StringRef::find_first___not_of(llvm::StringRef, > unsigned long) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__954: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `CountNumNewlinesBetween': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__972: > undefined reference to > `llvm::StringRef::find_first___of(llvm::StringRef, > unsigned long) const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `CheckString::CheckNext(llvm::__SourceMgr > const&, > llvm::StringRef) const': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1036: > undefined reference to > > `llvm::SourceMgr::__FindBufferContainingLoc(llvm::__SMLoc) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1046: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1048: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1050: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1056: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1058: > undefined reference to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:/home/__varosi/haskell/llvm/utils/__FileCheck/FileCheck.cpp:1060: > more undefined references to > `llvm::SourceMgr::__PrintMessage(llvm::SMLoc, > llvm::SourceMgr::DiagKind, llvm::Twine const&, > llvm::ArrayRef, > llvm::ArrayRef, bool) > const' follow > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `ValidateCheckPrefix': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1170: > undefined reference to > `llvm::Regex::Regex(llvm::__StringRef, unsigned > int)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1171: > undefined reference to > `llvm::Regex::match(llvm::__StringRef, > llvm::SmallVectorImpl*)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1171: > undefined reference to `llvm::Regex::~Regex()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `main': > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1199: > undefined reference to > `llvm::sys::__PrintStackTraceOnErrorSignal()__' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1201: > undefined reference to > `llvm::cl::__ParseCommandLineOptions(int, char > const* const*, char const*)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1204: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1222: > undefined reference to > `llvm::MemoryBuffer::__getFileOrSTDIN(llvm::__StringRef, > std::unique_ptr std::default_delete >&, long)' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1224: > undefined reference to `llvm::error_code::message() const' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1223: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1229: > undefined reference to `llvm::errs()' > > /home/varosi/haskell/llvm/__utils/FileCheck/FileCheck.cpp:__1298: > undefined reference to `llvm::SourceMgr::~SourceMgr()__' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::GenericOptionValue:__:GenericOptionValue()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:355: > undefined reference to `vtable for > llvm::cl::GenericOptionValue' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::OptionValue::~OptionValue()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:458: > undefined reference to `vtable for > llvm::cl::OptionValue' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::basic_parser_impl::__basic_parser_impl()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:700: > undefined reference to `vtable for > llvm::cl::basic_parser_impl' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::basic_parser::~basic_parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:739: > undefined reference to `vtable for > llvm::cl::basic_parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::parser__::~parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:912: > undefined reference to `vtable for > llvm::cl::parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser > >::opt llvm::cl::desc, > > llvm::cl::NumOccurrencesFlag>(__llvm::cl::FormattingFlags > const&, > llvm::cl::desc const&, llvm::cl::NumOccurrencesFlag > const&)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1225: > undefined reference to `vtable for > llvm::cl::opt llvm::cl::parser >' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1225: > undefined reference to `vtable for > llvm::cl::parser' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1227: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::opt llvm::cl::desc, > llvm::cl::initializer, > llvm::cl::value_desc>(char const > (&) [11], llvm::cl::desc const&, > llvm::cl::initializer > const&, llvm::cl::value_desc const&)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1232: > undefined reference to `vtable for > llvm::cl::opt llvm::cl::parser >' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1232: > undefined reference to `vtable for > llvm::cl::parser' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1234: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::list llvm::cl::desc>(char const (&) [13], llvm::cl::desc > const&)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1385: > undefined reference to `vtable for > llvm::cl::parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::basic_parser:__:basic_parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:739: > undefined reference to `vtable for > llvm::cl::basic_parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::cl::basic_parser:__:~basic_parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:739: > undefined reference to `vtable for > llvm::cl::basic_parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::parser::__parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::parser::~__parser()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:749: > undefined reference to `vtable for llvm::cl::parser' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser > >::opt(char const (&) [18], > llvm::cl::desc const&)': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1217: > undefined reference to `vtable for llvm::cl::opt false, > llvm::cl::parser >' > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1219: > undefined reference to `llvm::cl::opt llvm::cl::parser >::done()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `std::enable_if::is_signed, > bool>::type > llvm::StringRef::getAsInteger<__int>(unsigned int, int&) > const': > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringRef.h:__346: > undefined reference to > `llvm::getAsSignedInteger(__llvm::StringRef, > unsigned int, long long&)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(__llvm::StringRef)': > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__274: > undefined reference to > `llvm::StringMapImpl::FindKey(__llvm::StringRef) const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::StringMap llvm::MallocAllocator>::find(__llvm::StringRef) const': > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__280: > undefined reference to > `llvm::StringMapImpl::FindKey(__llvm::StringRef) const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::done()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1362: > undefined reference to `llvm::cl::Option::__addArgument()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::StringMapEntry& > llvm::StringMap > llvm::MallocAllocator>::__GetOrCreateValue(llvm::StringRef, > llvm::StringRef)': > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__345: > undefined reference to > `llvm::StringMapImpl::__LookupBucketFor(llvm::__StringRef)' > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__362: > undefined reference to > `llvm::StringMapImpl::__RehashTable()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::__SmallVectorTemplateCommon<__char, > void>::grow_pod(unsigned long, unsigned long)': > > /home/varosi/haskell/llvm/__include/llvm/ADT/SmallVector.__h:82: > undefined reference to > `llvm::SmallVectorBase::grow___pod(void*, > unsigned long, unsigned long)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::StringMapEntry& > llvm::StringMap > llvm::MallocAllocator>::__GetOrCreateValue(llvm::__StringRef, > char)': > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__345: > undefined reference to > `llvm::StringMapImpl::__LookupBucketFor(llvm::__StringRef)' > > /home/varosi/haskell/llvm/__include/llvm/ADT/StringMap.h:__362: > undefined reference to > `llvm::StringMapImpl::__RehashTable()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `void llvm::cl::initializer [2]>::apply llvm::cl::parser > > >(llvm::cl::opt llvm::cl::parser >&) const': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:315: > undefined reference to `llvm::cl::opt llvm::cl::parser > >::setInitialValue(std::string const&)' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:(.data.__rel.ro.___ZTVN4llvm2cl4listISsbNS0___6parserISsEEEE[___ZTVN4llvm2cl4listISsbNS0___6parserISsEEEE]+0x20): > undefined reference to `llvm::cl::Option::anchor()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:(.data.__rel.ro.___ZTVN4llvm2cl11OptionValueIbEE[_____ZTVN4llvm2cl11OptionValueIbEE]__+0x28): > undefined reference to > `llvm::cl::GenericOptionValue:__:anchor()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:(.data.__rel.ro.___ZTVN4llvm2cl15OptionValueBaseI__bLb0EEE[___ZTVN4llvm2cl15OptionValueBaseI__bLb0EEE]+0x28): > undefined reference to > `llvm::cl::GenericOptionValue:__:anchor()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:(.data.__rel.ro.___ZTVN4llvm2cl15OptionValueCopyI__bEE[___ZTVN4llvm2cl15OptionValueCopyI__bEE]+0x28): > undefined reference to > `llvm::cl::GenericOptionValue:__:anchor()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:(.data.__rel.ro.___ZTVN4llvm2cl15OptionValueCopyI__SsEE[___ZTVN4llvm2cl15OptionValueCopyI__SsEE]+0x28): > undefined reference to > `llvm::cl::GenericOptionValue:__:anchor()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser >::~opt()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1156: > undefined reference to `vtable for > llvm::cl::opt llvm::cl::parser >' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::opt llvm::cl::parser > >::~opt()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1156: > undefined reference to `vtable for llvm::cl::opt false, > llvm::cl::parser >' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function > `llvm::__PrettyStackTraceProgram::~__PrettyStackTraceProgram()': > > /home/varosi/haskell/llvm/__include/llvm/Support/__PrettyStackTrace.h:58: > undefined > reference to `vtable for llvm::PrettyStackTraceProgram' > > /home/varosi/haskell/llvm/__include/llvm/Support/__PrettyStackTrace.h:58: > undefined > reference to > `llvm::PrettyStackTraceEntry::__~PrettyStackTraceEntry()' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser >::getOptionWidth() const': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1352: > undefined reference to > > `llvm::cl::basic_parser_impl::__getOptionWidth(llvm::cl::__Option > const&) const' > > /home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o: > In function `llvm::cl::list llvm::cl::parser > >::printOptionInfo(unsigned long) const': > > /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:1354: > undefined reference to > > `llvm::cl::basic_parser_impl::__printOptionInfo(llvm::cl::__Option > const&, unsigned long) const' > collect2: error: ld returned 1 exit status > make[2]: *** > > [/home/varosi/haskell/llvm/__build/Debug+Asserts/bin/__FileCheck] > Error 1 > make[2]: Leaving directory > `/home/varosi/haskell/llvm/__build/utils/FileCheck' > make[1]: *** [FileCheck/.makeall] Error 2 > make[1]: Leaving directory > `/home/varosi/haskell/llvm/__build/utils' > make: *** [all] Error 1 > > > > Another thing is that the link from: > http://www.haskell.org/__haskellwiki/ARM > > > which is: > http://www.haskell.org/__pipermail/cvs-ghc/2012-__February/070791.html > > > Is invalid and there could be some more information on > the topic. > I had to install GCC 4.7 to compile latest LLVM on my > Ubuntu 12. > > What could be the problem with LLVM? > > > 2014-04-03 17:13 GMT+03:00 Karel Gardas > > >>: > > > On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov > Keremidchiev wrote: > > Yes, but I don't know what is missing in my > workflow. > > I did not know if I need LLVM runtime on my > target ARM machine. > > > No, you don't need LLVM runtime. You just need LLVM > llc/opt if > you'd like to cross-compile and build registerised > ARM binaries. > > > Do I > need? I read that there is unregisterised > version for ARM > that doesn't > need LLVM. So I just could build Haskell > cross-compiler that > could work > on my Ubuntu and create binaries for my ARM v7 > machine. > > > If you'd like to use unregisterised /via-C > binaries, then you > don't need LLVM at all, you just need to configure with > --enable-unregisterised IIRC, but I've not tested > that so you > are on your own. > > Also it comes with its own performance penalty of > course: > http://ghcarm.wordpress.com/____2011/08/07/nofib-benchmarking/ > > __> > > Karel > > > > > > From lonetiger at gmail.com Fri Apr 4 09:52:29 2014 From: lonetiger at gmail.com (Tamar Christina) Date: Fri, 4 Apr 2014 02:52:29 -0700 Subject: Haskell Support on Windows (Simon Peyton Jones) Message-ID: <4892408390949579463@unknownmsgid> I've been meaning to start contributing to ghc for windows for years but never got around to it since I don't know what I could contribute with. I've compiled various 6.x and early 7.x versions before and mostly did small modifications for my own testing. I've been away from Haskell for a few months, but I've been meaning to come back and I'm willing to contribute with what I can :) ------------------------------ From: Carter Schonwald Sent: 01/04/2014 15:26 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; Kyle Van Berendonck Subject: Re: Haskell Support on Windows (Simon Peyton Jones) Kyle, we need you to help us with windows support! :-) On Tuesday, April 1, 2014, Simon Peyton Jones wrote: > A couple of poor assumptions are made here. > > > > I'm not sure where "here" is. In my email I specifically said exactly > what you are saying (only I was not as eloquent as you). > > > > What we need is some developers who are willing to give some love and > support to the Windows version of GHC. And *they* really are thin on the > ground, unfortunately. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] > *On Behalf Of *Kyle Van Berendonck > *Sent:* 01 April 2014 13:54 > *To:* ghc-devs at haskell.org > *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones) > > > > A couple of poor assumptions are made here. > > The first is that the userbase of GHC on Windows is poor. This is false. > In fact, the poor state of Windows is mentioned on #haskell more frequently > as of late. In the last week I've talked almost every day to (different) > people who have had Windows woes with using GHC. The hacker-base isn't here > at the moment - I agree, but the user-base most certainly is. Could this be > a problem with the demographic, or could it just be that Windows > development isn't inviting? The build system and default test failures > in-particular are a source of discouragement. > > The second assumption is that GHC/Haskell will be worth a dime in the > RealWorld without Windows as a primary tier platform. I'm going to put a > crude guess that given the overwhelming magnitude of C#/F# coming up on my > local careers portal that there's far more industry on Windows than on OSX > or Linux. Those are all the businesses where the probability that they will > ever touch Haskell goes from `probably not right now` to `impossible`. Let > me also remind you that Windows still holds 89.2% of operating system > market share ie the people that hackers and developers actually have to > deploy their applications to. > > Sorry to sound fumey, but there's all this suggesting that everyone would > have a better day if we dropped Windows (let's be honest, if it wasn't a > primary tier platform nobody would have fixed it for 7.8), but I doubt few > of the people who think it's a "great idea" or sslt have actually thought > through whether it's the best thing for Haskell or just the best thing to > get 7.8 into their hands a couple weeks sooner. > > Regards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Apr 4 15:14:53 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 4 Apr 2014 15:14:53 +0000 Subject: Windows build broken Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E5E97@DB3PRD3001MB020.064d.mgd.msft.net> Can someone fix this? This is breakage on Windows. It was fine yesterday. Simon cc1.exe: warnings being treated as errors rts\Linker.c: In function 'loadArchive': rts\Linker.c:2631:17: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2632:17: error: passing argument 2 of 'strcpy' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2638:21: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2643:17: error: passing argument 1 of '_wfopen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: note: expected 'const wchar_t *' but argument is of type 'char *' rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Apr 4 15:55:36 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 4 Apr 2014 10:55:36 -0500 Subject: Windows build broken In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0E5E97@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0E5E97@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Looks like 5d7f59018703b94ebfe96cbef5574ec396a1c051 is the culprit. Simon M, perhaps you can look at this? I'm tied up in the 7.8 branch at the moment, but I can revert it temporarily at least (I imagine the fix is easy enough - if you can't get to it soon, I'll revert and fix it when I get a chance). On Fri, Apr 4, 2014 at 10:14 AM, Simon Peyton Jones wrote: > Can someone fix this? This is breakage on Windows. It was fine yesterday. > > Simon > > cc1.exe: warnings being treated as errors > > rts\Linker.c: In function 'loadArchive': > > > > rts\Linker.c:2631:17: > > error: passing argument 1 of 'strlen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: > note: expected 'const char *' but argument is of type 'pathchar *' > > > > rts\Linker.c:2632:17: > > error: passing argument 2 of 'strcpy' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: > note: expected 'const char *' but argument is of type 'pathchar *' > > > > rts\Linker.c:2638:21: > > error: passing argument 1 of 'strlen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: > note: expected 'const char *' but argument is of type 'pathchar *' > > > > rts\Linker.c:2643:17: > > error: passing argument 1 of '_wfopen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: > note: expected 'const wchar_t *' but argument is of type 'char *' > > rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed > > make[1]: *** [rts/dist/build/Linker.o] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > Makefile:64: recipe for target 'all' failed > > make: *** [all] Error 2 > > HEAD (master)$ > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From marlowsd at gmail.com Fri Apr 4 16:05:25 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 04 Apr 2014 17:05:25 +0100 Subject: Windows build broken In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0E5E97@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0E5E97@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <533ED845.7050308@gmail.com> Sorry, probably my fault. I've attached a patch that should fix it, which should get you going while I validate. Cheers, Simon On 04/04/2014 16:14, Simon Peyton Jones wrote: > Can someone fix this? This is breakage on Windows. It was fine yesterday. > > Simon > > cc1.exe: warnings being treated as errors > > rts\Linker.c: In function 'loadArchive': > > rts\Linker.c:2631:17: > > error: passing argument 1 of 'strlen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: > note: expected 'const char *' but argument is of type 'pathchar *' > > rts\Linker.c:2632:17: > > error: passing argument 2 of 'strcpy' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: > note: expected 'const char *' but argument is of type 'pathchar *' > > rts\Linker.c:2638:21: > > error: passing argument 1 of 'strlen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: > note: expected 'const char *' but argument is of type 'pathchar *' > > rts\Linker.c:2643:17: > > error: passing argument 1 of '_wfopen' from incompatible pointer type > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: > note: expected 'const wchar_t *' but argument is of type 'char *' > > rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed > > make[1]: *** [rts/dist/build/Linker.o] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > Makefile:64: recipe for target 'all' failed > > make: *** [all] Error 2 > > HEAD (master)$ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- >From f65e9fe435a72ac3de1487a3e5a24b347c1a809b Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Fri, 4 Apr 2014 17:02:20 +0100 Subject: [PATCH] Disable thin archive support on Windows --- rts/Linker.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/rts/Linker.c b/rts/Linker.c index 38d7c39..bed5496 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -2379,9 +2379,12 @@ loadArchive( pathchar *path ) if (n != 8) barf("loadArchive: Failed reading header from `%s'", path); if (strncmp(tmp, "!\n", 8) == 0) {} +#if !defined(mingw32_HOST_OS) + /* See Note [thin archives on Windows] */ else if (strncmp(tmp, "!\n", 8) == 0) { isThin = 1; } +#endif #if defined(darwin_HOST_OS) /* Not a standard archive, look for a fat archive magic number: */ else if (ntohl(*(uint32_t *)tmp) == FAT_MAGIC) { @@ -2622,6 +2625,14 @@ loadArchive( pathchar *path ) image = stgMallocBytes(memberSize, "loadArchive(image)"); #endif +#if !defined(mingw32_HOST_OS) + /* + * Note [thin archives on Windows] + * This doesn't compile on Windows because it assumes + * char* pathnames, and we use wchar_t* on Windows. It's + * not trivial to fix, so I'm leaving it disabled on + * Windows for now --SDM + */ if (isThin) { FILE *member; char *pathCopy, *dirName, *memberPath; @@ -2653,7 +2664,9 @@ loadArchive( pathchar *path ) stgFree(memberPath); stgFree(pathCopy); } - else { + else +#endif + { n = fread ( image, 1, memberSize, f ); if (n != memberSize) { barf("loadArchive: error whilst reading `%s'", path); -- 1.7.9.5 From simonpj at microsoft.com Fri Apr 4 16:19:48 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 4 Apr 2014 16:19:48 +0000 Subject: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate In-Reply-To: <20140403232017.1c2b2db2@sf> References: <20140322222142.798abe7e@sf> <20140403232017.1c2b2db2@sf> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E6085@DB3PRD3001MB020.064d.mgd.msft.net> Sergei SpecConstr is too aggressive: it sometimes blows up the program badly and we have no good solution. See Trac #7898, #7068, #7944, #5550, #8836. I notice that the latter three are actually fixed in 7.8, so worth trying that. If it still fails, do add instructions to reproduce to one of the above open tickets, or make a new one. Amos Robinson (cc'd) was working on this problem, but I have not heard anything recently. It surely ought to be possible to "throttle" it a bit so that it stops before generating too vast a program. Meanwhile you can use -fno-spec-constr to simply switch it off for offending modules. That should get you going. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Sergei Trofimovich | Sent: 03 April 2014 21:20 | To: ghc-devs at haskell.org | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- | citeproc / highlighting-kate | | On Sat, 22 Mar 2014 22:21:42 +0300 | Sergei Trofimovich wrote: | | > Hello! | > | > I have noticed the problem in ghc-7.6.3 first when tried to build all | > haskell userland with -O2 opt level. | > | > It led to amazing bugs! | > | > Here is one of those (highlighting-kate hackage package): | > > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) | > > stack overflow: use +RTS -K to increase it | > | > How to reproduce it: | > 1. Download a bundled file (6.6MB): | > | > http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8- | rc2.tar.gz | > 2. Unpack and run there: | > ./mk.sh | > | > The script is designed to plug any built ghc version w/o external | depends. | > | > Command will fail as: | > $ ./mk.sh | > ... | > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) | > stack overflow: use +RTS -K to increase it | > | > On ghc-7.6.3 it will progress a bit more: down to 452 file and will | > crash there similar way. | > | > I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them | > manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around. | > Nothing else. | > | > It's very hard to shrink such large thing manually down to 2-3 files. | > Would be cool if ghc (and cabal) would be able to spit something | > self-sufficient (like 'gcc -i' does) for devs to reproduce. | > | > Adding '-v' shows such log: | > ... | > *** Simplifier: | > Result size of Simplifier iteration=1 | > = {terms: 21,973, types: 21,838, coercions: 1,842} | > Result size of Simplifier iteration=2 | > = {terms: 21,952, types: 21,819, coercions: 1,842} | > Result size of Simplifier | > = {terms: 21,950, types: 21,817, coercions: 1,842} | > *** SpecConstr: | > Result size of SpecConstr*** | | Nobody interested? Is it too scary? | | Such inliner blowups are hard to shrink down from real examples down to | toy ones. I could try to but I need a bit of guidance. | | Maybe you need only an intermediate core step right before an OOM, | whatever? | | Thanks! | | -- | | Sergei From carter.schonwald at gmail.com Fri Apr 4 20:43:10 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 4 Apr 2014 16:43:10 -0400 Subject: core lint warnings when doing perf build of 7.8 tip Message-ID: should i be concerned about these? *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Tidy Core *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of CorePrep *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of CorePrep *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Apr 4 07:05:42 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 04 Apr 2014 00:05:42 -0700 Subject: GHC HQ on Launchpad Message-ID: <1396595015-sup-1148@sabre> Hello all, I've created a GHC team on Launchpad to manage the code imports and build recipes https://launchpad.net/~ghc Why? I recently was playing around with Launchpad's build recipes service, and realized that this could be another helpful source of builds for GHC (resulting in proper Ubuntu packages which then can be directly installed by installing a PPA). If you're not interested, you can just ignore (or remove yourself) from the group. Conversely, if I didn't find your Launchpad identifier, please ask to be added. Cheers, Edward From simonpj at microsoft.com Fri Apr 4 21:45:28 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 4 Apr 2014 21:45:28 +0000 Subject: core lint warnings when doing perf build of 7.8 tip In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E6ADE@DB3PRD3001MB020.064d.mgd.msft.net> No. It?s just an infelicity I have never gotten around to removing Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Carter Schonwald Sent: 04 April 2014 21:43 To: ghc-devs at haskell.org Subject: core lint warnings when doing perf build of 7.8 tip should i be concerned about these? *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of Tidy Core *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of CorePrep *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy *** Core Lint warnings : in result of CorePrep *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non-rule) loop breaker: Check.untidy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjgajda at gmail.com Sun Apr 6 04:01:17 2014 From: mjgajda at gmail.com (=?UTF-8?Q?Micha=C5=82_J_Gajda?=) Date: Sun, 6 Apr 2014 12:01:17 +0800 Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2 Message-ID: Hi, GHC 7.8 rc2 exhausts all memory on Bio.PDB.EventParser.PDBEventParser module in -O3 mode, but not in -O2 mode. The tail of -v3 input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with relatively low memory use RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. Since I am new to GHC core, may I have a hint what debugging information may help with this particular issue? *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr * I submitted the ticket: https://ghc.haskell.org/trac/ghc/ticket/8960 -- Best regards Micha? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu at ionita.at Sun Apr 6 10:27:49 2014 From: nicu at ionita.at (Niculae Ionita) Date: Sun, 06 Apr 2014 12:27:49 +0200 Subject: Trying to build 64 bit GHC on Windows with the 32 bit version Message-ID: <53412C25.90905@ionita.at> Hi, I got yesterday the sources (HEAD) of GHC and configured with ./configure --target=amd64-unknown-mingw32 which finally succeeded. But when I start make, I get almost in the beginning this error message: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist-install_GHCI_LIB not defined!. Stop. make: *** [all] Error 2 Is it really something wrong in the dph or am I do something wrong? I have currently the 32 bit Windows version of HP-2013.02.0.0 installed. Regards, Nicu From gergo at erdi.hu Sun Apr 6 13:35:23 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Sun, 6 Apr 2014 21:35:23 +0800 (SGT) Subject: Trac seems to think I'm a spambot...? Message-ID: Hi, I tried changing #8961 to `merge`, referring to commit 60ec752. However, I keep getting rejected with this error message: Submission rejected as potential spam Akismet says content is spam BotScout says this is spam (Y|MULTI|IP|0|MAIL|0|NAME|3) I don't even get a ReCaptcha box to work around it. Can anyone help me understanding what's going on and how to change 8961 to merge? Thanks, Gergo From simonpj at microsoft.com Sun Apr 6 18:49:30 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 6 Apr 2014 18:49:30 +0000 Subject: Perf tests failing Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E84DA@DB3PRD3001MB020.064d.mgd.msft.net> Several perf tests have started failing on 32-bit windows. (See below). Some of them have very small allocation anyway, so it may be a library issue. I'm wondering whether it might be a consequence of the new inline byte array stuff. I don't know which commit made this start happening, but it's pretty recent. Johan, did you test on 32 bit? Thanks Simon perf/should_run InlineByteArrayAlloc [stat not good enough] (normal) perf/should_run T4267 [stat not good enough] (normal) perf/should_run T5949 [stat not good enough] (normal) perf/should_run T7619 [stat not good enough] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Apr 6 20:22:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 6 Apr 2014 13:22:11 -0700 Subject: Perf tests failing In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0E84DA@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0E84DA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I don't have a 32-bit machine to test on, but I thought I set the InlineByteArrayAlloc test to only run on 64-bit. Feel free to set the expected value on 32-bit to whatever you're getting. On Sun, Apr 6, 2014 at 11:49 AM, Simon Peyton Jones wrote: > Several perf tests have started failing on 32-bit windows. (See > below). Some of them have very small allocation anyway, so it may be a > library issue. I'm wondering whether it might be a consequence of the new > inline byte array stuff. I don't know which commit made this start > happening, but it's pretty recent. > > Johan, did you test on 32 bit? > > Thanks > > Simon > > > > perf/should_run InlineByteArrayAlloc [stat not good > enough] (normal) > > perf/should_run T4267 [stat not good enough] (normal) > > perf/should_run T5949 [stat not good enough] (normal) > > perf/should_run T7619 [stat not good enough] (normal) > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Apr 6 20:25:22 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 6 Apr 2014 13:25:22 -0700 Subject: Perf tests failing In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0E84DA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Btw, you can set the -fmax-inline-alloc-size flag to a really high value to prevent inline allocation, if you want to test if that's the culprit. Inline allocation shouldn't change the amount being allocated though, just how it's allocated. T4267 doesn't use byte arrays at all so that should definitely not be related. On Sun, Apr 6, 2014 at 1:22 PM, Johan Tibell wrote: > I don't have a 32-bit machine to test on, but I thought I set the > InlineByteArrayAlloc test to only run on 64-bit. Feel free to set the > expected value on 32-bit to whatever you're getting. > > > On Sun, Apr 6, 2014 at 11:49 AM, Simon Peyton Jones > wrote: > >> Several perf tests have started failing on 32-bit windows. (See >> below). Some of them have very small allocation anyway, so it may be a >> library issue. I'm wondering whether it might be a consequence of the new >> inline byte array stuff. I don't know which commit made this start >> happening, but it's pretty recent. >> >> Johan, did you test on 32 bit? >> >> Thanks >> >> Simon >> >> >> >> perf/should_run InlineByteArrayAlloc [stat not good >> enough] (normal) >> >> perf/should_run T4267 [stat not good enough] >> (normal) >> >> perf/should_run T5949 [stat not good enough] >> (normal) >> >> perf/should_run T7619 [stat not good enough] >> (normal) >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From metaniklas at gmail.com Mon Apr 7 07:19:28 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Mon, 7 Apr 2014 09:19:28 +0200 Subject: SV: Trying to build 64 bit GHC on Windows with the 32 bit version Message-ID: <534251c0.0785700a.2559.30e5@mx.google.com> You need a 64-bit ghc and gcc to build a 64-bit ghc. If that's what you want instructions are here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 Niklas ----- Ursprungligt meddelande ----- Fr?n: "Niculae Ionita" Skickat: ?2014-?04-?06 12:27 Till: "GHC Dev List" ?mne: Trying to build 64 bit GHC on Windows with the 32 bit version Hi, I got yesterday the sources (HEAD) of GHC and configured with ./configure --target=amd64-unknown-mingw32 which finally succeeded. But when I start make, I get almost in the beginning this error message: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist-install_GHCI_LIB not defined!. Stop. make: *** [all] Error 2 Is it really something wrong in the dph or am I do something wrong? I have currently the 32 bit Windows version of HP-2013.02.0.0 installed. Regards, Nicu _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvanberendonck at gmail.com Mon Apr 7 09:43:23 2014 From: kvanberendonck at gmail.com (Kyle Van Berendonck) Date: Mon, 7 Apr 2014 19:43:23 +1000 Subject: Trac seems to think I'm a spambot...? Message-ID: Hmm. I just got flagged as a spambot trying to reply to a ticket too. It did give me a captcha option though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Apr 7 09:50:26 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 07 Apr 2014 11:50:26 +0200 Subject: Trac seems to think I'm a spambot...? In-Reply-To: (Kyle Van Berendonck's message of "Mon, 7 Apr 2014 19:43:23 +1000") References: Message-ID: <87bnwd31ul.fsf@gmail.com> On 2014-04-07 at 11:43:23 +0200, Kyle Van Berendonck wrote: > I just got flagged as a spambot trying to reply to a ticket too. It did > give me a captcha option though. It's surprisingly difficult to discriminate between humans and bots; I've enabled http://trac.edgewall.org/wiki/SpamFilter and I've tried tweaking its score weightings, but it still gets some false positives, and is tends to annoy with reCaptcha interaction (and to my surprise, even spambots seem to be able to outsmart reCaptcha these days) Does anyone here have more experience with spam-filtering who could help set up the Trac spam-filtering? From ky3 at atamo.com Mon Apr 7 10:17:43 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 7 Apr 2014 17:17:43 +0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <87bnwd31ul.fsf@gmail.com> References: <87bnwd31ul.fsf@gmail.com> Message-ID: Herbert, Off the top of my head: What email addresses are attached to the spamming trac accounts? Is there any pattern to them? More importantly, are external links nofollow'd [1] to reduce spam incentive? Doesn't appear so [2] if you view html source and search for "reddit thread". There's a whole bunch of material when I search for "trac nofollow", so maybe that's the answer. [1] https://support.google.com/webmasters/answer/96569?hl=en [2] https://ghc.haskell.org/trac/ghc/ticket/8955 -- Kim-Ee On Mon, Apr 7, 2014 at 4:50 PM, Herbert Valerio Riedel wrote: > On 2014-04-07 at 11:43:23 +0200, Kyle Van Berendonck wrote: > > I just got flagged as a spambot trying to reply to a ticket too. It did > > give me a captcha option though. > > It's surprisingly difficult to discriminate between humans and bots; > I've enabled http://trac.edgewall.org/wiki/SpamFilter and I've tried > tweaking its score weightings, but it still gets some false positives, > and is tends to annoy with reCaptcha interaction (and to my surprise, > even spambots seem to be able to outsmart reCaptcha these days) > > Does anyone here have more experience with spam-filtering who could help > set up the Trac spam-filtering? > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Mon Apr 7 10:45:49 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 7 Apr 2014 17:45:49 +0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: References: <87bnwd31ul.fsf@gmail.com> Message-ID: On Mon, Apr 7, 2014 at 5:17 PM, Kim-Ee Yeoh wrote: > More importantly, are external links nofollow'd [1] to reduce spam > incentive? Doesn't appear so [2] if you view html source and search for > "reddit thread". There's a whole bunch of material when I search for "trac > nofollow", so maybe that's the answer. Apparently 'nofollow' is not the answer, according to: http://trac.edgewall.org/ticket/1145 This guy has a lot of success leaning on Akismet and captcha for this tracspam setup: http://news.thedigitalmachine.com/2012/07/26/howto-configure-tracspam-to-allow-anonymous-ticket-creation-in-trac/ -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Apr 7 11:54:59 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 07 Apr 2014 13:54:59 +0200 Subject: Trac seems to think I'm a spambot...? In-Reply-To: (Kim-Ee Yeoh's message of "Mon, 7 Apr 2014 17:45:49 +0700") References: <87bnwd31ul.fsf@gmail.com> Message-ID: <877g712w30.fsf@gmail.com> On 2014-04-07 at 12:45:49 +0200, Kim-Ee Yeoh wrote: > On Mon, Apr 7, 2014 at 5:17 PM, Kim-Ee Yeoh wrote: > >> More importantly, are external links nofollow'd [1] to reduce spam >> incentive? Doesn't appear so [2] if you view html source and search for >> "reddit thread". There's a whole bunch of material when I search for "trac >> nofollow", so maybe that's the answer. > > > Apparently 'nofollow' is not the answer, according to: > > http://trac.edgewall.org/ticket/1145 > > This guy has a lot of success leaning on Akismet and captcha for this > tracspam setup: > > http://news.thedigitalmachine.com/2012/07/26/howto-configure-tracspam-to-allow-anonymous-ticket-creation-in-trac/ well, it was actually Akismet (as well as others) that declared Gergo's content (which was basically a pasted commit message) to be spam (ultimately giving it such a low scoring that even reCaptcha wouldn't compensate for it) Here's the score-computation: Akismet (-5): Akismet says content is spam AuthenticatedUserScore (4): User is authenticated BotScout (-2): BotScout says this is spam (Y|MULTI|IP|0|MAIL|0|NAME|3) Captcha (10): Human verified via CAPTCHA (Recaptcha) Defensio (2): Defensio says content is allowed (legitimate, 0.2, none) Session (0): Existing session found StopForumSpam (0): StopForumSpam says this is spam (username [0.01]) As for the previous question of whether the email-addresses of spammers follow any obvious pattern, not always; we've had a few spammers with ordinary looking gmail.com addresses as well; in the cases they do, one of the external anti-spam service usually classifies it as potential spam... From simonpj at microsoft.com Mon Apr 7 12:37:42 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 7 Apr 2014 12:37:42 +0000 Subject: GHC section of the Haskell Communities and Activities Report, May 2014 edition Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E9506@DB3PRD3001MB020.064d.mgd.msft.net> Austin, Mihai, GHC devs This is about the GHC section of the HCAR. Up to now, we have written a status report on the GHC Wiki (you can see them stretching back several years), and the HCAR team have generously done the conversion to Latex. Mihai, I hope that is still OK. Austin: you are the Managing Editor for the GHC status report. Could you * take a look at what has happened in the last six months (the 7.8 release notes would be a great start) * draft an outline for the report * delegate writing tasks to the rest of us By "writing task" I mean typically only a paragraph or two (see past reports), but specifically including pointers to further reading. Really every substantial item should have such a pointer. The status report should be a jumping off point for someone who wants to know more. There are technical things (eg pattern synonyms), but let's not forget the important process things (eg changes to the repository structure). All GHC devs: do feel free to add things that Austin omits. In particular, he may not be aware of "what's on the horizon" things that you are working on. Austin, do you think you could complete the sketch, and delegate tasks, as soon as the 7.8 release is out (which should only be hours away)? So it should be done by the end of this week. Thanks all Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Mihai | Maruseac | Sent: 05 April 2014 15:28 | To: haskell; haskell at haskell.org | Subject: [Haskell] Call for Contributions - Haskell Communities and | Activities Report, May 2014 edition | | Dear all, | | I would like to collect contributions for the 24th edition of the | | ================================================================ | Haskell Communities & Activities Report | | http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Rep | ort | | Submission deadline: 1 May 2014 | | (please send your contributions to hcar at haskell.org, | in plain text or LaTeX format) | ================================================================ | | This is the short story: | | * If you are working on any project that is in some way related | to Haskell, please write a short entry and submit it. Even if | the project is very small or unfinished or you think it is not | important enough --- please reconsider and submit an entry anyway! | | * If you are interested in an existing project related to Haskell that | has not previously been mentioned in the HCAR, please tell me, so | that I can contact the project leaders and ask them to submit an | entry. | | * Feel free to pass on this call for contributions to others that | might be interested. | | More detailed information: | | The Haskell Communities & Activities Report is a bi-annual overview of | the state of Haskell as well as Haskell-related projects over the | last, and possibly the upcoming six months. If you have only recently | been exposed to Haskell, it might be a good idea to browse the | previous edition --- you will find interesting projects described as | well as several starting points and links that may provide answers to | many questions. | | Contributions will be collected until the submission deadline. They | will then be compiled into a coherent report that is published online | as soon as it is ready. As always, this is a great opportunity to | update your webpages, make new releases, announce or even start new | projects, or to talk about developments you want every Haskeller to | know about! | | Looking forward to your contributions, | | Mihai Maruseac and Alejandro Serrano Mena (current co-editors) | | | FAQ: | | Q: What format should I write in? | | A: The required format is a LaTeX source file, adhering to the template | that is available at: | | http://haskell.org/communities/05-2013/template.tex | | There is also a LaTeX style file at | | http://haskell.org/communities/05-2013/hcar.sty | | that you can use to preview your entry. If you do not know LaTeX, then | use plain text. If you modify an old entry that you have written for an | earlier edition of the report, you should already have received your old | entry as a template (provided I have your valid email address). Please | modify that template, rather than using your own version of the old | entry as a template. | | Q: Can I include Haskell code? | | A: Yes. Please use lhs2tex syntax | (http://people.cs.uu.nl/andres/lhs2tex/). | The report is compiled in mode polycode.fmt. | | Q: Can I include images? | | A: Yes, you are even encouraged to do so. Please use .jpg format, then. | | Q: Should I send files in .zip archives or similar? | | A: No, plain file attachements are the way. | | Q: How much should I write? | | A: Authors are asked to limit entries to about one column of text. A | general introduction is helpful. Apart from that, you should focus on | recent or upcoming developments. Pointers to online content can be given | for more comprehensive or "historic" overviews of a project. Images do | not count towards the length limit, so you may want to use this | opportunity to pep up entries. There is no minimum length of an entry! | The report aims for being as complete as possible, so please consider | writing an entry, even if it is only a few lines long. | | Q: Which topics are relevant? | | A: All topics which are related to Haskell in some way are relevant. We | usually had reports from users of Haskell (private, academic, or | commercial), from authors or contributors to projects related to | Haskell, from people working on the Haskell language, libraries, on | language extensions or variants. We also like reports about | distributions of Haskell software, Haskell infrastructure, books and | tutorials on Haskell. Reports on past and upcoming events related to | Haskell are also relevant. Finally, there might be new topics we do not | even think about. As a rule of thumb: if in doubt, then it probably is | relevant and has a place in the HCAR. You can also ask the editor. | | Q: Is unfinished work relevant? Are ideas for projects relevant? | | A: Yes! You can use the HCAR to talk about projects you are currently | working on. You can use it to look for other developers that might help | you. | | Q: If I do not update my entry, but want to keep it in the report, what | should I do? | | A: Tell the editor that there are no changes. The old entry will | typically be reused in this case, but it might be dropped if it is older | than a year, to give more room and more attention to projects that | change a lot. Do not resend complete entries if you have not changed | them. | | Q: Will I get confirmation if I send an entry? How do I know whether my | email has even reached the editor, and not ended up in a spam folder? | | A: Prior to publication of the final report, the editor will send a | draft to all contributors, for possible corrections. So if you do not | hear from the editor within two weeks after the deadline, it is safer | to send another mail and check whether your first one was received. | | | -- | Mihai Maruseac (MM) | "If you don't know, the thing to do is not to get scared, but to | learn." -- Atlas Shrugged. | _______________________________________________ | Haskell mailing list | Haskell at haskell.org | http://www.haskell.org/mailman/listinfo/haskell From ky3 at atamo.com Mon Apr 7 14:27:32 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 7 Apr 2014 21:27:32 +0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <877g712w30.fsf@gmail.com> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> Message-ID: Could we try something? I'm thinking that recaptcha can be a PITA if only because it disrupts one's state of flow but people will put up with it to save trac from spam. What if we replace captcha with a short, static question, the web form equivalent of a secret handshake? And give it enough weighting to override akismet? E.g. * What is Haskell's middle name? * What is SPJ's middle name? The main drawback to this is that it'll only be a matter of time before spammers wise up. But that interval might be long enough for something better on the horizon, e.g. akismet gets a lot smarter, better blog posts on tracspam, etc. Also, spammers might be deterred enough to give up and look elsewhere. Another drawback is that some folks won't actually know the secret handshake. Hopefully those numbers are very small. p.s. A variant to this that's more search-proof is some trivial haskell: E.g. let fibs = 0:1: ... fibs in fibs !! n where n is randomly chosen from 2, 3, or 4; where the answer is an instantaneous n-1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Apr 7 14:51:33 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 07 Apr 2014 16:51:33 +0200 Subject: Trac seems to think I'm a spambot...? In-Reply-To: References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> Message-ID: <1396882293.2505.34.camel@kirk> Hi, Am Montag, den 07.04.2014, 21:27 +0700 schrieb Kim-Ee Yeoh: > What if we replace captcha with a short, static question, the web form > equivalent of a secret handshake? And give it enough weighting to > override akismet? > > > E.g. > > > * What is Haskell's middle name? > * What is SPJ's middle name? I made good experience with such checks on my blog. The answer can be really simple, ?What is SPJ?s first name?? tends to be sufficient. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From daniel.trstenjak at gmail.com Mon Apr 7 14:53:18 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 7 Apr 2014 16:53:18 +0200 Subject: Trac seems to think I'm a spambot...? In-Reply-To: References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> Message-ID: <20140407145318.GA21205@machine> On Mon, Apr 07, 2014 at 09:27:32PM +0700, Kim-Ee Yeoh wrote: > What if we replace captcha with a short, static question, the web form > equivalent of a secret handshake? And give it enough weighting to override > akismet? > > E.g. > > * What is Haskell's middle name? > * What is SPJ's middle name? Yeah, I thought about something similar like: what's the result of 'map (+1) [1,2]'. > The main drawback to this is that it'll only be a matter of time before > spammers wise up. But that interval might be long enough for something better > on the horizon, e.g. akismet gets a lot smarter, better blog posts on tracspam, > etc. I don't think that the ghc wiki is of particular interest for spammers or that they gain a lot by understanding Haskell specifics. Most likely they will never notice it. Greetings, Daniel From ekmett at gmail.com Mon Apr 7 17:07:18 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 7 Apr 2014 13:07:18 -0400 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <20140407145318.GA21205@machine> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> <20140407145318.GA21205@machine> Message-ID: <56808E2D-C740-48D7-BB07-399A572BEA80@gmail.com> What is Simon's middle name? Is Peyton not part of his surname? Oh crap. I'm a bot. Sent from my iPad > On Apr 7, 2014, at 10:53 AM, Daniel Trstenjak wrote: > >> On Mon, Apr 07, 2014 at 09:27:32PM +0700, Kim-Ee Yeoh wrote: >> What if we replace captcha with a short, static question, the web form >> equivalent of a secret handshake? And give it enough weighting to override >> akismet? >> >> E.g. >> >> * What is Haskell's middle name? >> * What is SPJ's middle name? > > Yeah, I thought about something similar like: what's the result of 'map (+1) [1,2]'. > >> The main drawback to this is that it'll only be a matter of time before >> spammers wise up. But that interval might be long enough for something better >> on the horizon, e.g. akismet gets a lot smarter, better blog posts on tracspam, >> etc. > > I don't think that the ghc wiki is of particular interest for spammers > or that they gain a lot by understanding Haskell specifics. Most likely > they will never notice it. > > > Greetings, > Daniel > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Mon Apr 7 18:19:12 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 07 Apr 2014 20:19:12 +0200 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <56808E2D-C740-48D7-BB07-399A572BEA80@gmail.com> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> <20140407145318.GA21205@machine> <56808E2D-C740-48D7-BB07-399A572BEA80@gmail.com> Message-ID: <1396894752.2505.39.camel@kirk> Hi, Am Montag, den 07.04.2014, 13:07 -0400 schrieb Edward Kmett: > What is Simon's middle name? Is Peyton not part of his surname? It is, he has a middle name, and that is the reason I don?t find https://ghc.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets without looking in my browser history :-) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ky3 at atamo.com Mon Apr 7 18:53:48 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 8 Apr 2014 01:53:48 +0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <20140407145318.GA21205@machine> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> <20140407145318.GA21205@machine> Message-ID: On Mon, Apr 7, 2014 at 9:53 PM, Daniel Trstenjak wrote: > Yeah, I thought about something similar like: what's the result of 'map > (+1) [1,2]'. Oooh, if we're going that route, I want to see 'succ <$> [1,2,3]'. I reckon we'd get [4,5,6] with some frequency. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Apr 7 09:56:55 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 07 Apr 2014 02:56:55 -0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <87bnwd31ul.fsf@gmail.com> References: <87bnwd31ul.fsf@gmail.com> Message-ID: <1396864437-sup-1323@sabre> Is the Akismet filter enabled? In my experience, combining it with a technique like NoSpamNX (some sort of "honey-pot" field which wide range spambots are susceptible to) lowers spam hits to a level where manually moderating the rest is fine. If it is too hard for contributors to mark entries as spam, maybe that's what needs to be fixed. Edward Excerpts from Herbert Valerio Riedel's message of 2014-04-07 02:50:26 -0700: > On 2014-04-07 at 11:43:23 +0200, Kyle Van Berendonck wrote: > > I just got flagged as a spambot trying to reply to a ticket too. It did > > give me a captcha option though. > > It's surprisingly difficult to discriminate between humans and bots; > I've enabled http://trac.edgewall.org/wiki/SpamFilter and I've tried > tweaking its score weightings, but it still gets some false positives, > and is tends to annoy with reCaptcha interaction (and to my surprise, > even spambots seem to be able to outsmart reCaptcha these days) > > Does anyone here have more experience with spam-filtering who could help > set up the Trac spam-filtering? > From alain.odea at gmail.com Tue Apr 8 01:06:27 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 08 Apr 2014 01:06:27 +0000 Subject: Offering GHC builder build slaves Message-ID: <53434B93.9000201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks: I have successfully built Ian Lynagh's GHC builder on Ubuntu and SmartOS and I would like to offer build slaves based on Carter's mirroring of the code to https://github.com/cartazio/ghc-builder. I can offer several build slaves, but I'm not sure what the process is. How do I run multiple build slaves? Do I need a separate username for each? Is there a username convention? The suggestion at https://ghc.haskell.org/trac/ghc/wiki/Builder is that I post a username and password to ghc at . There are two issues with this: 1. ghc@ does not exist as far as I can tell 2. Posting a password to a mailing list will make it publicly accessible and allow others to impersonate my build slaves I am happy to send this information if the admins of the GHC builder infrastructure are comfortable with the risks. Alternatively, I am able to send this via GPG encrypted email given the public key and email of an admin. Feel free to contact me on or off list about this. Best, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTQ0uTAAoJEP0rIXJNjNSA+fMH/2p9yeWgpfDeaTHilur5qoZ6 6DZiktJgvMpVeqFwHyaFMk+ubEp8/xU/VUrOEztr01jmzNLS2UoqDVH/7EZPZPtV 0ONh/bcYYA8EBa9SCqaVXVb9I8EdDE6w2cQGDqnwHqaFerAUqv8OiQEWyJCuJSdr 7EL/vcacNfr5Ix4oG2pkESvEJBHHEN4ZTXoKeJnyQT93o2RaC1fgImm6F6tgpdQE Jh+QInIX1dRuSl+pDlHg6kbLZqFG8Mnyz0bcWuUL2ekGQBp3HtT0MwonM9HUTmmG 0baRYUaK/moO5Q6lUXhI2eRT/UFl4qnzwJw/sIVuaL7h1Ikj0ZMOuPs0GjfRbY8= =/Rwk -----END PGP SIGNATURE----- From fuuzetsu at fuuzetsu.co.uk Tue Apr 8 01:32:18 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 08 Apr 2014 02:32:18 +0100 Subject: Offering GHC builder build slaves In-Reply-To: <53434B93.9000201@gmail.com> References: <53434B93.9000201@gmail.com> Message-ID: <534351A2.6070902@fuuzetsu.co.uk> On 08/04/14 02:06, Alain O'Dea wrote: > Hi folks: > > I have successfully built Ian Lynagh's GHC builder on Ubuntu and > SmartOS and I would like to offer build slaves based on Carter's > mirroring of the code to https://github.com/cartazio/ghc-builder. > > I can offer several build slaves, but I'm not sure what the process is. > > How do I run multiple build slaves? > > Do I need a separate username for each? > > Is there a username convention? > > The suggestion at https://ghc.haskell.org/trac/ghc/wiki/Builder is > that I post a username and password to ghc at . There are two issues > with this: > > 1. ghc@ does not exist as far as I can tell > 2. Posting a password to a mailing list will make it publicly > accessible and allow others to impersonate my build slaves > > I am happy to send this information if the admins of the GHC builder > infrastructure are comfortable with the risks. Alternatively, I am > able to send this via GPG encrypted email given the public key and > email of an admin. > > Feel free to contact me on or off list about this. > > Best, > Alain > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > I can offer a 32-bit Linux slave (or 2) myself. -- Mateusz K. From pali.gabor at gmail.com Tue Apr 8 07:23:12 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 09:23:12 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <53434B93.9000201@gmail.com> References: <53434B93.9000201@gmail.com> Message-ID: 2014-04-08 3:06 GMT+02:00 Alain O'Dea : > I can offer several build slaves, but I'm not sure what the process is. As far as I know, the infrastructure has become a volunteer-run effort, and it looks like I am the volunteer who runs it... :-) > How do I run multiple build slaves? Ideally, each of the slaves should run in their own isolated (mostly virtualized) environment. > Do I need a separate username for each? Yes. > Is there a username convention? So far I assigned names to the clients by the "${os}-${arch}-${branch}" scheme, such as linux-ppc64-head. > The suggestion at https://ghc.haskell.org/trac/ghc/wiki/Builder is > that I post a username and password to ghc at . There are two issues > with this: Actually, I think this wiki page is not valid any more -- the original builder infrastructure was abandoned last year. I have started to replicate the whole thing for my own clients, and it works well (for me, and nowadays for Karel) since then. However, my efforts has not been "blessed" and I am not sure if there are at least plans to make the builders part of the official haskell.org infrastructure. Either way it goes, I can update the corresponding wiki page with my contact information and start accommodation further clients until the fate of the service is decided, if there will not be any objections in the next few days. > I am happy to send this information if the admins of the GHC builder > infrastructure are comfortable with the risks. All right, I can follow up you with the details off-list. From pali.gabor at gmail.com Tue Apr 8 07:25:03 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 09:25:03 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <534351A2.6070902@fuuzetsu.co.uk> References: <53434B93.9000201@gmail.com> <534351A2.6070902@fuuzetsu.co.uk> Message-ID: 2014-04-08 3:32 GMT+02:00 Mateusz Kowalczyk : > I can offer a 32-bit Linux slave (or 2) myself. Please mail me with the specification of the host system (Linux distribution used, version, etc.) off-list and I could allocate a builder account for you. From simonpj at microsoft.com Tue Apr 8 08:03:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 8 Apr 2014 08:03:45 +0000 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> | > The suggestion at https://ghc.haskell.org/trac/ghc/wiki/Builder is | > that I post a username and password to ghc at . There are two issues | > with this: | | Actually, I think this wiki page is not valid any more -- the original | builder infrastructure was abandoned last year. I have started to | replicate the whole thing for my own clients, and it works well (for | me, and nowadays for Karel) since then. | | However, my efforts has not been "blessed" and I am not sure if there | are at least plans to make the builders part of the official | haskell.org infrastructure. Either way it goes, I can update the | corresponding wiki page with my contact information and start | accommodation further clients until the fate of the service is decided, | if there will not be any objections in the next few days. Bless you, my son! Seriously, I advertised a couple of weeks ago for help with our nightly-build infrastructure. Quite a few people responded -- thank you very much. So we have willing horsepower. But the moment we lack leadership. Alain rightly says "I don't know what the process is" because we don't *have* a process. We need a mechanism for creating a process, taking decisions, etc. I think what is needed is: * A group of people willing to act as a kind of committee. That could be everyone who replied. You could create a mailing list, or (initially better) just chat on ghc-devs. But it would be useful to have a list of who is involved. * Someone (or a couple of people) to play the role of chair. That doesn't mean an autocrat... it means someone who gently pushes discussions to a conclusion, and says "I propose that we do X". * Then the group can formulate a plan and proceed with it. For example, should Pali's efforts be "blessed"? I don't know enough to know, but you guys do. In my experience, people are often unwilling to put themselves forward as chair, not because they are unwilling, but because they feel it'd be "pushy". So I suggest this: if you think (based on the traffic you've seen) that X would be a chair you'd trust, suggest them. In short: power to the people! GHC is your compiler. Thanks! Simon From mail at joachim-breitner.de Tue Apr 8 08:30:52 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 08 Apr 2014 10:30:52 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1396945852.2514.17.camel@kirk> Hi, Am Dienstag, den 08.04.2014, 08:03 +0000 schrieb Simon Peyton Jones: > So we have willing horsepower. But the moment we lack leadership. > Alain rightly says "I don't know what the process is" because we don't > *have* a process. We need a mechanism for creating a process, taking > decisions, etc. we also need a culture of just doing stuff, and less asking for it. In Debian it works likes this: Someone has an idea (continuous integration), does it and tells the mailing list about it. Then people tell you that it?s great, or how it could be greater. If it works out, eventually it comes an official service, whatever that means. So in this case (independent of any committee or process): P?li, you have starting running some builder infrastructure. Great! Just keep doing it! And if you want people to join their builders, tell them what information you need from them and add them. Feel free to modify the wiki so that people find you. Make up some rules (about usernames etc.) as you go, if necessary. In essence what you said in > However, my efforts has not been "blessed" and I am not sure if there > are at least plans to make the builders part of the official > haskell.org infrastructure. Either way it goes, I can update the > corresponding wiki page with my contact information and start > accommodation further clients until the fate of the service is > decided, if there will not be any objections in the next few days. but without waiting for objections. Just do it. And tell us about your achievements. Also worry less about official or not. The Travis setup is not official, but (IMHO) has been useful quite a few times. I?d _like_ it to be official, i.e. hosted on git.haskell.org, but that is not important. If your service becomes ?critical? in some sense it is still time to move it some official infrastructure... but that can come second, and should not hinder anyone from contributing. Greetings, and thanks for your contributions, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvr at gnu.org Tue Apr 8 08:31:28 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 08 Apr 2014 10:31:28 +0200 Subject: GHC HQ on Launchpad In-Reply-To: <1396595015-sup-1148@sabre> (Edward Z. Yang's message of "Fri, 04 Apr 2014 00:05:42 -0700") References: <1396595015-sup-1148@sabre> Message-ID: <87y4zgql27.fsf@gmail.com> On 2014-04-04 at 09:05:42 +0200, Edward Z. Yang wrote: > Hello all, > > I've created a GHC team on Launchpad to manage the code imports and > build recipes https://launchpad.net/~ghc Why? I recently was playing > around with Launchpad's build recipes service, and realized that this > could be another helpful source of builds for GHC (resulting in proper > Ubuntu packages which then can be directly installed by installing a > PPA). Just a reminder, as not everybody may be aware yet: There's already daily GHC HEAD packages for Debian at http://deb.haskell.org/ ...as well as (more or less) daily Ubuntu 12.04 LTS packages (which work for later Ubuntu releases as-is) over at https://launchpad.net/~hvr/+archive/ghc/+packages Cheers, hvr From simonpj at microsoft.com Tue Apr 8 08:36:13 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 8 Apr 2014 08:36:13 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <1396945852.2514.17.camel@kirk> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0EA869@DB3PRD3001MB020.064d.mgd.msft.net> | we also need a culture of just doing stuff, and less asking for it. I agree with that -- hence "power to the people". You absolutely don't need the approval of a committee or of GHC HQ to just get on with something. But it also makes sense to work together, to achieve more as a group than a single individual can. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 08 April 2014 09:31 | To: ghc-devs at haskell.org | Subject: Re: Offering GHC builder build slaves | | Hi, | | Am Dienstag, den 08.04.2014, 08:03 +0000 schrieb Simon Peyton Jones: | > So we have willing horsepower. But the moment we lack leadership. | > Alain rightly says "I don't know what the process is" because we don't | > *have* a process. We need a mechanism for creating a process, taking | > decisions, etc. | | we also need a culture of just doing stuff, and less asking for it. | | In Debian it works likes this: Someone has an idea (continuous | integration), does it and tells the mailing list about it. Then people | tell you that it?s great, or how it could be greater. If it works out, | eventually it comes an official service, whatever that means. | | So in this case (independent of any committee or process): P?li, you | have starting running some builder infrastructure. Great! Just keep | doing it! | And if you want people to join their builders, tell them what | information you need from them and add them. Feel free to modify the | wiki so that people find you. Make up some rules (about usernames etc.) | as you go, if necessary. In essence what you said in | | > However, my efforts has not been "blessed" and I am not sure if there | > are at least plans to make the builders part of the official | > haskell.org infrastructure. Either way it goes, I can update the | > corresponding wiki page with my contact information and start | > accommodation further clients until the fate of the service is | > decided, if there will not be any objections in the next few days. | | but without waiting for objections. Just do it. And tell us about your | achievements. | | Also worry less about official or not. The Travis setup is not official, | but (IMHO) has been useful quite a few times. I?d _like_ it to be | official, i.e. hosted on git.haskell.org, but that is not important. | | If your service becomes ?critical? in some sense it is still time to | move it some official infrastructure... but that can come second, and | should not hinder anyone from contributing. | | Greetings, and thanks for your contributions, Joachim | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C | Debian Developer: nomeata at debian.org From pali.gabor at gmail.com Tue Apr 8 08:50:37 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 10:50:37 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <1396945852.2514.17.camel@kirk> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: 2014-04-08 10:30 GMT+02:00 Joachim Breitner : > we also need a culture of just doing stuff, and less asking for it. Yes, I was educated in the same spirit but in the FreeBSD Project. I did not ask much for it when I replicated the whole setup just for myself last year. > if you want people to join their builders, tell them what > information you need from them and add them. Feel free to modify the > wiki so that people find you. Make up some rules (about usernames etc.) > as you go, if necessary. That is good to hear. First, I had the impression from the previous discussions that Ian's solution is not proven enough so you want to go for some other solution. Second, I do not want to duplicate anybody else's efforts. Although I have already stated that I am willing to let others connect to my server and replied the related mails, but I felt that the offer was still ignored or lost. I do not want to be pushy, I do not like stepping on other's toes. But actually I can if that is what you want -- that is how I did eight BSD workshops and developer summits in the last four years and eventually become the secretary of the FreeBSD Core Team. > Just do it. And tell us about your achievements. I guess the ghc-builds mailing list speaks for itself. > Also worry less about official or not. The Travis setup is not official, > but (IMHO) has been useful quite a few times. I'd _like_ it to be > official, i.e. hosted on git.haskell.org, but that is not important. All right, if the rules of game are like that, let it be so... > If your service becomes "critical" in some sense it is still time to > move it some official infrastructure... but that can come second, and > should not hinder anyone from contributing. Okay, thanks for the clarification! From mail at joachim-breitner.de Tue Apr 8 08:58:11 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 08 Apr 2014 10:58:11 +0200 Subject: relocation R_X86_64_32 (Was: GHC HQ on Launchpad) In-Reply-To: <87y4zgql27.fsf@gmail.com> References: <1396595015-sup-1148@sabre> <87y4zgql27.fsf@gmail.com> Message-ID: <1396947491.2514.21.camel@kirk> Hi, Am Dienstag, den 08.04.2014, 10:31 +0200 schrieb Herbert Valerio Riedel: > Just a reminder, as not everybody may be aware yet: > > There's already daily GHC HEAD packages for Debian at > > http://deb.haskell.org/ thanks for the reminder. I guess I need to set up something that notifies me of failures... Since March 27 weeks, it seems, it is failing: [..] configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed make: *** [configure-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 http://deb.haskell.org/dailies/2014-04-07/ghc_7.9.20140407-0.daily_amd64.build Any ideas? I?m not an expert on linker issues. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From johan.tibell at gmail.com Tue Apr 8 09:22:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 8 Apr 2014 11:22:05 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: I'll mirror what Joachim said: just get something working. Having an email sent to ghc-devs@ every time something breaks (and getting down false positives here is very important) is already a huge win, no matter what kind of build system sits behind that email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 8 09:31:08 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 11:31:08 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: 2014-04-08 11:22 GMT+02:00 Johan Tibell : > I'll mirror what Joachim said: just get something working. Having an email > sent to ghc-devs@ every time something breaks (and getting down false > positives here is very important) is already a huge win, no matter what kind > of build system sits behind that email. The ghc-builds mailing list has the all the results -- however, earlier there was the concern that folks do not want to watch it every day. I still do, just to know everything is all right. Filtering the false positives out might be solved automatically, I think, hopefully I can come up with a solution soon. Anyway, for starter, here is a nice core dump for linux-ppc64: chmod +x inplace/bin/dll-split inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault make: *** [all] Error 2 For the details, please consult: http://haskell.inf.elte.hu/builders/linux-ppc64-head/6.html Karel (see CC'ed) runs the client, feel free to prod him for more. From johan.tibell at gmail.com Tue Apr 8 09:34:21 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 8 Apr 2014 11:34:21 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: On Tue, Apr 8, 2014 at 11:31 AM, P?li G?bor J?nos wrote: > 2014-04-08 11:22 GMT+02:00 Johan Tibell : > > I'll mirror what Joachim said: just get something working. Having an > email > > sent to ghc-devs@ every time something breaks (and getting down false > > positives here is very important) is already a huge win, no matter what > kind > > of build system sits behind that email. > > The ghc-builds mailing list has the all the results -- however, > earlier there was the concern that folks do not want to watch it every > day. I still do, just to know everything is all right. Filtering the > false positives out might be solved automatically, I think, hopefully > I can come up with a solution soon. > I don't read ghc-builds at all because I don't want to see emails that say "everything is fine" in my inbox. I assume everything is fine until something tells me it isn't. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 8 09:46:11 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 11:46:11 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: 2014-04-08 11:34 GMT+02:00 Johan Tibell : > I don't read ghc-builds at all because I don't want to see emails that say > "everything is fine" in my inbox. I assume everything is fine until > something tells me it isn't. :) For what it is worth, you do not have subscribe to any mailing list just to see a brief overview of the builders. The builder server maintains a nice web site for the results, e.g. [1]. But I see what you mean: I will work something out for forwarding valid breakage notifications directly to ghc-devs. [1] http://haskell.inf.elte.hu/builders/ From alain.odea at gmail.com Tue Apr 8 11:33:26 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 8 Apr 2014 11:33:26 +0000 Subject: relocation R_X86_64_32 (Was: GHC HQ on Launchpad) In-Reply-To: <1396947491.2514.21.camel@kirk> References: <1396595015-sup-1148@sabre> <87y4zgql27.fsf@gmail.com> <1396947491.2514.21.camel@kirk> Message-ID: <68BAA7CD-5930-43DE-80E7-7471CAC44F31@gmail.com> Hi, > On Apr 8, 2014, at 8:58, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 08.04.2014, 10:31 +0200 schrieb Herbert Valerio Riedel: >> Just a reminder, as not everybody may be aware yet: >> >> There's already daily GHC HEAD packages for Debian at >> >> http://deb.haskell.org/ > > thanks for the reminder. I guess I need to set up something that > notifies me of failures... > > Since March 27 weeks, it seems, it is failing: > > [..] > configure: Building in-tree ghc-pwd > /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC It looks to me like -fPIC needs to be added in LDFLAGS or wherever the launchpad build system sources the linker's flags from. > utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value > collect2: error: ld returned 1 exit status > configure: error: Building ghc-pwd failed > make: *** [configure-stamp] Error 1 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > http://deb.haskell.org/dailies/2014-04-07/ghc_7.9.20140407-0.daily_amd64.build > > Any ideas? I?m not an expert on linker issues. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From alain.odea at gmail.com Tue Apr 8 11:59:09 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 8 Apr 2014 11:59:09 +0000 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: This is great. I'm excited about this. P?li, I am happy to do troubleshooting, recruiting, and assistance for new build slave volunteers. I will gladly support your leadership on this. I will work to ensure that you don't carry an undue share of the effort. I have four (one in slings due to a busted PSU) reasonably powerful (if old) Dell Precision T3500s that can provide a variety of x86 and x86_64 OS builds on Xeon. They currently run SmartOS, but they can run other x86 and x86_64 guests. They are purpose-built for isolated virtualization. The biggest limitation for these right now is RAM (they have 6GB each), but I'm considering more soon. I'll send my first build slave username and password off list to you later today. Once I have that working I'll document the current process for volunteering and setting up build slaves. Best, Alain > On Apr 8, 2014, at 8:50, P?li G?bor J?nos wrote: > > 2014-04-08 10:30 GMT+02:00 Joachim Breitner : >> we also need a culture of just doing stuff, and less asking for it. > > Yes, I was educated in the same spirit but in the FreeBSD Project. I > did not ask much for it when I replicated the whole setup just for > myself last year. > >> if you want people to join their builders, tell them what >> information you need from them and add them. Feel free to modify the >> wiki so that people find you. Make up some rules (about usernames etc.) >> as you go, if necessary. > > That is good to hear. First, I had the impression from the previous > discussions that Ian's solution is not proven enough so you want to go > for some other solution. Second, I do not want to duplicate anybody > else's efforts. Although I have already stated that I am willing to > let others connect to my server and replied the related mails, but I > felt that the offer was still ignored or lost. > > I do not want to be pushy, I do not like stepping on other's toes. > But actually I can if that is what you want -- that is how I did eight > BSD workshops and developer summits in the last four years and > eventually become the secretary of the FreeBSD Core Team. > >> Just do it. And tell us about your achievements. > > I guess the ghc-builds mailing list speaks for itself. > >> Also worry less about official or not. The Travis setup is not official, >> but (IMHO) has been useful quite a few times. I'd _like_ it to be >> official, i.e. hosted on git.haskell.org, but that is not important. > > All right, if the rules of game are like that, let it be so... > >> If your service becomes "critical" in some sense it is still time to >> move it some official infrastructure... but that can come second, and >> should not hinder anyone from contributing. > > Okay, thanks for the clarification! > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Tue Apr 8 12:16:00 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 8 Apr 2014 07:16:00 -0500 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: Hello all, I was actually going to send an email about this as I'm wrapping up 7.8.1, but since it got started early... Yes, I would really like if someone would be willing to help manage infrastructure for build slaves. If people are willing to support and run with what we've got now, that's great! Simon and I talked about this recently - the decision about what infrastructure to use was somewhat in the air (custom infrastructure has the downside it has less overall support of course), but we figured we'd bring it to the people to discuss, but you beat me to it! Here's a few extra notes: - I can absolutely provide infrastructure, especially for Windows virtual machines, using Rackspace. This is one thing that's missing, and it's how I'm building binaries now. In addition, we can also offer a lot of Linux (and FreeBSD systems) through this. The prices for very low-powered builders are very cheap, and we could easily add several of them for either CI or nightly builds, in 32 and 64bit configurations. This can effectively be free for a lot of supported platforms. - I can also absolutely make any infrastructure 'official' by giving it a domain name, for example, and we can lean on this free infrastructure for what we can, in addition to any machines people are willing to offer. We'll need these extra machines for more platforms! - Whatever we do, I'd really like better visibility. I don't think ghc-builds is enough, personally - historically people seem to ignore it unless someone manages to eye a problem or alert someone else, and I think this was because in the past there was a lot of noise which lead to this sort of perception. But really, it would be great if we could offer a web interface or something. An IRC bot would be useful too - more and more 'regular' users hang out there, and it provides a nice form of passive but responsive feedback. There are certainly fairly pre-canned solutions to this I'm sure. Anyway, whatever we do, I'm happy to support people with the resources, access and visibility they need. Pali, since you seem to leading this - what are your thoughts? I'm more than willing to give you some hardware and put it under haskell.org domain, and just get out of your way if you'd like. :) On Tue, Apr 8, 2014 at 6:59 AM, Alain O'Dea wrote: > This is great. I'm excited about this. > > P?li, I am happy to do troubleshooting, recruiting, and assistance for new build slave volunteers. I will gladly support your leadership on this. I will work to ensure that you don't carry an undue share of the effort. > > I have four (one in slings due to a busted PSU) reasonably powerful (if old) Dell Precision T3500s that can provide a variety of x86 and x86_64 OS builds on Xeon. They currently run SmartOS, but they can run other x86 and x86_64 guests. They are purpose-built for isolated virtualization. The biggest limitation for these right now is RAM (they have 6GB each), but I'm considering more soon. > > I'll send my first build slave username and password off list to you later today. Once I have that working I'll document the current process for volunteering and setting up build slaves. > > Best, > Alain > >> On Apr 8, 2014, at 8:50, P?li G?bor J?nos wrote: >> >> 2014-04-08 10:30 GMT+02:00 Joachim Breitner : >>> we also need a culture of just doing stuff, and less asking for it. >> >> Yes, I was educated in the same spirit but in the FreeBSD Project. I >> did not ask much for it when I replicated the whole setup just for >> myself last year. >> >>> if you want people to join their builders, tell them what >>> information you need from them and add them. Feel free to modify the >>> wiki so that people find you. Make up some rules (about usernames etc.) >>> as you go, if necessary. >> >> That is good to hear. First, I had the impression from the previous >> discussions that Ian's solution is not proven enough so you want to go >> for some other solution. Second, I do not want to duplicate anybody >> else's efforts. Although I have already stated that I am willing to >> let others connect to my server and replied the related mails, but I >> felt that the offer was still ignored or lost. >> >> I do not want to be pushy, I do not like stepping on other's toes. >> But actually I can if that is what you want -- that is how I did eight >> BSD workshops and developer summits in the last four years and >> eventually become the secretary of the FreeBSD Core Team. >> >>> Just do it. And tell us about your achievements. >> >> I guess the ghc-builds mailing list speaks for itself. >> >>> Also worry less about official or not. The Travis setup is not official, >>> but (IMHO) has been useful quite a few times. I'd _like_ it to be >>> official, i.e. hosted on git.haskell.org, but that is not important. >> >> All right, if the rules of game are like that, let it be so... >> >>> If your service becomes "critical" in some sense it is still time to >>> move it some official infrastructure... but that can come second, and >>> should not hinder anyone from contributing. >> >> Okay, thanks for the clarification! >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From pali.gabor at gmail.com Tue Apr 8 12:17:23 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 14:17:23 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: 2014-04-08 13:59 GMT+02:00 Alain O'Dea : > I have four (one in slings due to a busted PSU) reasonably powerful (if old) Dell > Precision T3500s that can provide a variety of x86 and x86_64 OS builds on > Xeon. They currently run SmartOS, but they can run other x86 and x86_64 > guests. I think the best would be if we could cover all the possible and probable combination of architectures and platforms and avoid the redundancies. So far, we have the following: Solaris x86, Linux/arm and Linux/ppc64 (by Karel), FreeBSD/i386 and FreeBSD/amd64 (by myself), and Mateusz has written me about setting up a Linux x86 builder on Gentoo. We could certainly use Linux x86_64 builders, so as 32-bit and 64-bit Mac OS X and Windows ones. Regarding Linux, there might be builders for each of the distributions, however, I am not sure if need to store downloadable snapshots for all of them. > I'll send my first build slave username and password off list to you later today. You do not have to, I can generate both for you, once the OS and the architecture is known. > Once I have that working I'll document the current process for volunteering and > setting up build slaves. I think this has been already covered on the GHC Developers' wiki, there: https://ghc.haskell.org/trac/ghc/wiki/Builder Note that this page is also linked from the front page of the wiki. From pali.gabor at gmail.com Tue Apr 8 12:30:53 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 14:30:53 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: 2014-04-08 14:16 GMT+02:00 Austin Seipp : > Pali, since you seem to leading this - what are your thoughts? I'm > more than willing to give you some hardware and put it under > haskell.org domain, and just get out of your way if you'd like. :) I have summarized some of my thoughts in my previous mail to Alain: > I think the best would be if we could cover all the possible and > probable combination of architectures and platforms and avoid the > redundancies. Earlier, there was the concept of "sponsor" for the given platform, I guess it would still make sense to re-introduce it. The sponsor is somebody who is willing to pay attention to the given platform, run a builder client for it, therefore maintaining it. For Tier-1 platforms, such support was a requirement back then. So, we would need to set up at least the following builders: {Linux, Windows, Mac OS X} {x86, x86_64}, and then I could migrate all the others I have on my machine to there as well. From alain.odea at gmail.com Tue Apr 8 13:16:00 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 8 Apr 2014 13:16:00 +0000 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> Hi, > On Apr 8, 2014, at 12:17, P?li G?bor J?nos wrote: > > 2014-04-08 13:59 GMT+02:00 Alain O'Dea : >> I have four (one in slings due to a busted PSU) reasonably powerful (if old) Dell >> Precision T3500s that can provide a variety of x86 and x86_64 OS builds on >> Xeon. They currently run SmartOS, but they can run other x86 and x86_64 >> guests. > > I think the best would be if we could cover all the possible and > probable combination of architectures and platforms and avoid the > redundancies. > > So far, we have the following: Solaris x86, I think SmartOS can reasonably stand in for Illumos and Solaris x86_64 and can run Ubuntu x86_64 as a KVM guest. > Linux/arm and Linux/ppc64 > (by Karel), FreeBSD/i386 and FreeBSD/amd64 (by myself), and Mateusz > has written me about setting up a Linux x86 builder on Gentoo. We > could certainly use Linux x86_64 builders, so as 32-bit and 64-bit Mac > OS X and Windows ones. Regarding Linux, there might be builders for > each of the distributions, however, I am not sure if need to store > downloadable snapshots for all of them. > >> I'll send my first build slave username and password off list to you later today. > > You do not have to, I can generate both for you, once the OS and the > architecture is known. Cool, that's easier. I usually use AlainODea or alainodea as my base username, but that's immaterial. The two build slaves I intend to run are: - x86_64 Solaris (on SmartOS) - x86_64 Linux (on Ubuntu as a SmartOS KVM guest) > >> Once I have that working I'll document the current process for volunteering and >> setting up build slaves. > > I think this has been already covered on the GHC Developers' wiki, there: > > https://ghc.haskell.org/trac/ghc/wiki/Builder Good point. It needs some minor tweaks since the volunteers need to request a username and password by providing their OS and architecture to the list rather than sending their username and password to the list. > Note that this page is also linked from the front page of the wiki. From austin at well-typed.com Tue Apr 8 13:28:18 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 8 Apr 2014 08:28:18 -0500 Subject: 7.8.1 plan In-Reply-To: <533DAACF.3050801@fuuzetsu.co.uk> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: Hello all, The source distribution is now available: http://www.haskell.org/ghc/dist/7.8.1/ Feel free to make builds - I'll add them as they come in and will announce soon... On Thu, Apr 3, 2014 at 1:39 PM, Mateusz Kowalczyk wrote: > On 25/03/14 06:01, kyra wrote: >> Will it include the latest commit to haddock? It solves this: >> http://trac.haskell.org/haddock/ticket/292. This can greatly improve >> performance of haddock in some situations (when a project is built with >> --split-obj flag). >> >> Cheers, >> Kyra > > Just as a follow up, as we had some more time, this is actually going > into 7.8.1. > > Thanks > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Tue Apr 8 13:30:49 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 8 Apr 2014 15:30:49 +0200 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: On Tue, Apr 8, 2014 at 3:28 PM, Austin Seipp wrote: > Hello all, > > The source distribution is now available: > > http://www.haskell.org/ghc/dist/7.8.1/ > > Feel free to make builds - I'll add them as they come in and will > announce soon... Thanks for all your hard work Austin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Tue Apr 8 13:51:10 2014 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Tue, 8 Apr 2014 08:51:10 -0500 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: Well said Johan! Thanks to Austin and to everyone (eg our "build bots" :) that helped him navigate these cockroaches -- these bugs seemed very resilient! On Tue, Apr 8, 2014 at 8:30 AM, Johan Tibell wrote: > On Tue, Apr 8, 2014 at 3:28 PM, Austin Seipp wrote: > >> Hello all, >> >> The source distribution is now available: >> >> http://www.haskell.org/ghc/dist/7.8.1/ >> >> Feel free to make builds - I'll add them as they come in and will >> announce soon... > > > Thanks for all your hard work Austin. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 8 14:10:36 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Apr 2014 10:10:36 -0400 Subject: cant post to trac! Message-ID: I'm trying to comment on a ticket, and its unconditionally saying "nope, you're spam" can't we at least whitelist the 100+ known good user names?? -Carter heres the gem Submission rejected as potential spam - BotScout says this is spam (Y|MULTI|IP|0|MAIL|0|NAME|6) - Defensio says content is not allowed (spam, 0.99, none) - StopForumSpam says this is spam (username [99.44]) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 8 14:19:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Apr 2014 10:19:11 -0400 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 is my OS X build On Tue, Apr 8, 2014 at 9:51 AM, Nicolas Frisby wrote: > Well said Johan! Thanks to Austin and to everyone (eg our "build bots" :) > that helped him navigate these cockroaches -- these bugs seemed very > resilient! > > > On Tue, Apr 8, 2014 at 8:30 AM, Johan Tibell wrote: > >> On Tue, Apr 8, 2014 at 3:28 PM, Austin Seipp wrote: >> >>> Hello all, >>> >>> The source distribution is now available: >>> >>> http://www.haskell.org/ghc/dist/7.8.1/ >>> >>> Feel free to make builds - I'll add them as they come in and will >>> announce soon... >> >> >> Thanks for all your hard work Austin. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Tue Apr 8 15:34:07 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 08 Apr 2014 17:34:07 +0200 Subject: cant post to trac! In-Reply-To: (Carter Schonwald's message of "Tue, 8 Apr 2014 10:10:36 -0400") References: Message-ID: <87sipnsumo.fsf@gmail.com> On 2014-04-08 at 16:10:36 +0200, Carter Schonwald wrote: > I'm trying to comment on a ticket, and its unconditionally saying "nope, > you're spam" > > can't we at least whitelist the 100+ known good user names?? I've temporarily enabled "trust authenticated users"; I'll see if we can have a Haskell-specific captcha during registration; If everything fails, we can turn on moderated account registration... From hvriedel at gmail.com Tue Apr 8 16:57:48 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 08 Apr 2014 18:57:48 +0200 Subject: relocation R_X86_64_32 In-Reply-To: <1396947491.2514.21.camel@kirk> (Joachim Breitner's message of "Tue, 08 Apr 2014 10:58:11 +0200") References: <1396595015-sup-1148@sabre> <87y4zgql27.fsf@gmail.com> <1396947491.2514.21.camel@kirk> Message-ID: <87lhvfsqr7.fsf@gmail.com> On 2014-04-08 at 10:58:11 +0200, Joachim Breitner wrote: [...] > [..] > configure: Building in-tree ghc-pwd > /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 > against `stg_CHARLIKE_closure' can not be used when making a shared > object; recompile with -fPIC > utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value > collect2: error: ld returned 1 exit status > configure: error: Building ghc-pwd failed > make: *** [configure-stamp] Error 1 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > http://deb.haskell.org/dailies/2014-04-07/ghc_7.9.20140407-0.daily_amd64.build > > Any ideas? I?m not an expert on linker issues. I'm rather surprised about that (it doesn't occur on the Ubuntu 12.04 LTS PPA builds)... is this occuring on a vanilla Debian Wheezy? Btw, I've got proper 7.8.1 PPA .debs: https://launchpad.net/~hvr/+archive/ghc/+build/5888874 https://launchpad.net/~hvr/+archive/ghc/+build/5888875 ...when do you plan to build respective 7.8.1 debs for http://deb.haskell.org/stable/ ? From pali.gabor at gmail.com Tue Apr 8 17:17:47 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 8 Apr 2014 19:17:47 +0200 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: 2014-04-08 15:28 GMT+02:00 Austin Seipp : > Feel free to make builds - I'll add them as they come in and will > announce soon... The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html From yom at artyom.me Tue Apr 8 18:08:13 2014 From: yom at artyom.me (Artyom Kazak) Date: Tue, 08 Apr 2014 22:08:13 +0400 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <20140407145318.GA21205@machine> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> <20140407145318.GA21205@machine> Message-ID: <53443B0D.4050600@artyom.me> Look what I've found: http://codecha.org/ . It might be an easy solution to the Haskell-specific CAPTCHA problem. On 04/07/2014 06:53 PM, Daniel Trstenjak wrote: > On Mon, Apr 07, 2014 at 09:27:32PM +0700, Kim-Ee Yeoh wrote: >> What if we replace captcha with a short, static question, the web form >> equivalent of a secret handshake? And give it enough weighting to override >> akismet? >> >> E.g. >> >> * What is Haskell's middle name? >> * What is SPJ's middle name? > > Yeah, I thought about something similar like: what's the result of 'map (+1) [1,2]'. > >> The main drawback to this is that it'll only be a matter of time before >> spammers wise up. But that interval might be long enough for something better >> on the horizon, e.g. akismet gets a lot smarter, better blog posts on tracspam, >> etc. > > I don't think that the ghc wiki is of particular interest for spammers > or that they gain a lot by understanding Haskell specifics. Most likely > they will never notice it. > > > Greetings, > Daniel > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From afarmer at ittc.ku.edu Tue Apr 8 18:11:56 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Tue, 8 Apr 2014 13:11:56 -0500 Subject: Trac seems to think I'm a spambot...? In-Reply-To: <53443B0D.4050600@artyom.me> References: <87bnwd31ul.fsf@gmail.com> <877g712w30.fsf@gmail.com> <20140407145318.GA21205@machine> <53443B0D.4050600@artyom.me> Message-ID: That moment when spammers start pushing language research forward by generating functions from natural language specifications. On Tue, Apr 8, 2014 at 1:08 PM, Artyom Kazak wrote: > Look what I've found: http://codecha.org/ . It might be an easy solution > to the Haskell-specific CAPTCHA problem. > > On 04/07/2014 06:53 PM, Daniel Trstenjak wrote: > >> On Mon, Apr 07, 2014 at 09:27:32PM +0700, Kim-Ee Yeoh wrote: >> >>> What if we replace captcha with a short, static question, the web form >>> equivalent of a secret handshake? And give it enough weighting to >>> override >>> akismet? >>> >>> E.g. >>> >>> * What is Haskell's middle name? >>> * What is SPJ's middle name? >>> >> >> Yeah, I thought about something similar like: what's the result of 'map >> (+1) [1,2]'. >> >> The main drawback to this is that it'll only be a matter of time before >>> spammers wise up. But that interval might be long enough for something >>> better >>> on the horizon, e.g. akismet gets a lot smarter, better blog posts on >>> tracspam, >>> etc. >>> >> >> I don't think that the ghc wiki is of particular interest for spammers >> or that they gain a lot by understanding Haskell specifics. Most likely >> they will never notice it. >> >> >> Greetings, >> Daniel >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 8 19:39:45 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Apr 2014 15:39:45 -0400 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos wrote: > 2014-04-08 15:28 GMT+02:00 Austin Seipp : > > Feel free to make builds - I'll add them as they come in and will > > announce soon... > > The FreeBSD builds are now available, along with the respective SHA256 > sums and the updated README file, as usual: > > http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 > http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 > http://haskell.inf.elte.hu/ghc/SHA256SUMS > http://haskell.inf.elte.hu/ghc/README.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Tue Apr 8 20:17:59 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 08 Apr 2014 22:17:59 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> Message-ID: <53445977.6000505@centrum.cz> On 04/ 8/14 03:16 PM, Alain O'Dea wrote: > The two build slaves I intend to run are: > - x86_64 Solaris (on SmartOS) Please name it smartos-x86 then. I'm running real Solaris 11.1 as a builder here so let's make it different name builder and see if there are any incompatibilities between those two (I hope still very close) platforms. BTW: what's your platform triple detected by config.guess? Thanks! Karel From alain.odea at gmail.com Wed Apr 9 01:41:25 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Wed, 09 Apr 2014 01:41:25 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <53445977.6000505@centrum.cz> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> Message-ID: <5344A545.8090906@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14-04-08 08:17 PM, Karel Gardas wrote: > On 04/ 8/14 03:16 PM, Alain O'Dea wrote: >> The two build slaves I intend to run are: - x86_64 Solaris (on >> SmartOS) > > Please name it smartos-x86 then. I'm running real Solaris 11.1 as > a builder here so let's make it different name builder and see if > there are any incompatibilities between those two (I hope still > very close) platforms. > > BTW: what's your platform triple detected by config.guess? > > Thanks! Karel Hi Karel, My platform triple detected by config.guess is: x86_64-unknown-solaris2 I got that by running `cat config.status | grep TargetPlatformFull`. Best, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRKVFAAoJEP0rIXJNjNSAYAsH/16CiNTRvrx2aTEekMw/Rf19 2XgNLliGzqmMZn8tub2+CN6p2eeaYUWbxm3C4Hczca3h3HPpThMvqMc7vZ1v6Dav gGyC6OJpXHhlGQUxmAzXrYVJ/MZOwC8o+rXCulEv9xZJWZMsxffMN57/3azNdMwm SAj9qmeLieyK1rOLoA+vWcnobkOGfVtjFLxej1xs8tRZrdq3aLaEl65k737COT7p q24LUwgSo3YOC+uf3/8SQdsbtvAroB5+IYoi9nuBDmHImRmw58Mu8n3Cn7wDqfaB jCHTQQoVsweSAZuxDGNBn07eQXB4gq8j0X4SL/mYNDLA7/MiCdcKtawJKY1Zw7o= =iK6S -----END PGP SIGNATURE----- From austin at well-typed.com Wed Apr 9 01:51:06 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 8 Apr 2014 20:51:06 -0500 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: Right, I can provide right now, with minimal fuss:: - 64 bit Linux (32bit as well, if you just use a chroot - not hard. Rackspace just doesn't provide 32bit VMs by default these days). 24/7 365 availability, roughty. - 32 bit Windows and 64bit Windows. 24/7 365 availability, roughly. - I do have a dedicated OS X Lion machine that can be a 64bit Mac build slave. But no 32bit machine. And occasionally the network sometimes cuts out, but this is normally fixable and/or transient. So I think I can already cobble together all the necessary Tier 1 platforms to get us going, I just need to point the machines somewhere to get them started. In lieu of anyone else, I can monitor the Windows client. I can monitor the Linux and OS X builds of course (and do so regularly anyway), since it seems FreeBSD and Solaris are well cared for (hooray!) But ideally someone else can do so too, and I'd really like that! Anyone willing? I'll look into getting these running with builder clients as soon as possible and follow up. On Tue, Apr 8, 2014 at 7:30 AM, P?li G?bor J?nos wrote: > 2014-04-08 14:16 GMT+02:00 Austin Seipp : >> Pali, since you seem to leading this - what are your thoughts? I'm >> more than willing to give you some hardware and put it under >> haskell.org domain, and just get out of your way if you'd like. :) > > I have summarized some of my thoughts in my previous mail to Alain: > >> I think the best would be if we could cover all the possible and >> probable combination of architectures and platforms and avoid the >> redundancies. > > Earlier, there was the concept of "sponsor" for the given platform, I > guess it would still make sense to re-introduce it. The sponsor is > somebody who is willing to pay attention to the given platform, run a > builder client for it, therefore maintaining it. For Tier-1 > platforms, such support was a requirement back then. > > So, we would need to set up at least the following builders: {Linux, > Windows, Mac OS X} {x86, x86_64}, and then I could migrate all the > others I have on my machine to there as well. > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ml at isaac.cedarswampstudios.org Wed Apr 9 02:28:49 2014 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue, 08 Apr 2014 22:28:49 -0400 Subject: Backward-compatible role annotations In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> Message-ID: <5344B061.709@isaac.cedarswampstudios.org> I've been wondering whether there are any cases where the ability to coerce a parameter should not be exported (as for Set) but where the implementation would like to use some coercions (for example, if it internally wanted to coerce the contained type to a specific newtype, to change some of the contained type's instances while being able to guarantee that the invariant-related instances stayed safe). This would call for coercibility to be something you can import and export. What if, in the long term, there were a flag ExplicitRoleExports (probably rarely used): - with ExplicitRoleExports on, role signatures would be listed in the export list and must be at least as restrictive as the roles visible within the module. Exported types without role signatures in the export list would default to being exported as all-nominal. - with ExplicitRoleExports off, any types the modules export would be exported with the same roles visible inside the module. As is currently, the default role at a type's definition site would allow as many coercions as is segfault-safe. -Isaac P.S. I think this particular proposal likely has issues. If you import (T :: * -> * -> *) as "nominal, representational" and from elsewhere as "representational, nominal", do those roles combine somehow? What about contravariant [or is it covariant] roles as in (T :: (* -> *) -> *)? I haven't thought these through. Also I haven't thought of any concrete use cases for export-controlled roles; perhaps there aren't any. On 03/31/2014 02:12 PM, Dominique Devriese wrote: > Richard, > > Right, but I was thinking about the debate between > "nominal/non-parametric-by-default" or > "representational/parametric-by-default" for parameters of data types > that aren't forced to nominal from inspecting the datatype > implementation. As I understand it, representational-by-default > (currently used) may leave libraries that don't add role annotations > open for abuse, but won't unnecessarily break library users' code and > nominal-by-default prevents all abuse but may unnecessarily break code > that uses libraries that have not added proper role annotations. > > What I was wondering about is if the dilemma could be solved by > choosing nominal-by-default in the long term for the role inference > (so that library writers cannot accidentally leave abstraction holes > open by forgetting to add role annotations) and use them in the > long-term-supported SafeNewtypeDeriving extension, but provide a > deprecated not-quite-as-safe GND extension for helping out users of > libraries that have not yet added role annotations. I would fancy that > this not-quite-as-safe GND could use unsafeCoerce wherever the safe > one would give an error about annotated roles. > > Regards, > Dominique > > 2014-03-31 17:05 GMT+02:00 Richard Eisenberg : >> Hi Dominique, >> >> When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. >> >> The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. >> >> Richard >> >> On Mar 31, 2014, at 2:51 AM, Dominique Devriese wrote: >> >>> Richard, >>> >>> (re-posting because I first used an address that is not subscribed to the lists) >>> >>> I've been wondering about the following: it seems like the main >>> problem in this situation is that the GeneralizedNewtypeDeriving >>> extension changed meaning from "just coerce everything while deriving" >>> to "only coerce stuff if it's allowed by the relevant role >>> annotations". Would it not be an alternative solution to split up the >>> GND extension into >>> >>> * a backwards-compatible one (called GeneralizedNewtypeDeriving for >>> backwards compatibility ;)) that ignores role annotations (as before) >>> and uses unsafeCoerce whereever necessary >>> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations >>> >>> The first one could then be deprecated and removed in a release or >>> two. That might give library maintainers time to move their packages >>> to SafeNewtypeDeriving when they have tested that everything works... >>> >>> Regards, >>> Dominique >>> >>> P.S.: The above is based on a limited understanding of the problem, so >>> I'm sorry if it misses some aspect of the problem... >>> >>> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : >>>> I spent some time thinking about what, precisely, can be done here to make >>>> folks happier. (See the thread beginning here: >>>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the >>>> answer seemed to all be in the concrete syntax. The only logical alternative >>>> (that I could think of) to having roles is to disallow GND, and I don't >>>> think anyone is proposing that. And, it is impossible to infer an author's >>>> desired roles for a datatype. The heuristics mentioned here all seem far too >>>> fragile and hard to predict to become a lasting feature of GHC (in my >>>> opinion). What's left? Concrete syntax. >>>> >>>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible >>>> alternative to role annotations -- no CPP required. It's not as principled >>>> as proper role annotations, but it should do the job for most users. >>>> >>>> Here are two examples: >>>> >>>> 1. Datatypes: >>>> >>>>> import Language.Haskell.RoleAnnots >>>>> >>>>> data Map k v = >>>>> (Nominal k, Representational v) => MkMap [(k,v)] >>>> >>>> The constraints (which need be put on only one data constructor, if there >>>> are many) will get the built-in role inference mechanism to do what the user >>>> requests. In this example, the `Representational v` is actually redundant, >>>> but causes no harm. Because these classes have universal instances >>>> ("instance Nominal a") and have no methods, they should have no run-time >>>> significance. The only downside I can see is that the code above needs >>>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT >>>> nor has existentials. (Pattern-matching on such a definition needs no >>>> extensions.) >>>> >>>> 2. Newtypes: >>>> >>>> Newtype constructors cannot be constrained, unfortunately. So, we have to >>>> resort to Template Haskell: >>>> >>>>> import Language.Haskell.RoleAnnots >>>>> >>>>> roleAnnot [NominalR, RepresentationalR] >>>>> [d| newtype Map k v = MkMap [(k, v)] |] >>>> >>>> This is clearly worse, but I was able to come up with no other solution that >>>> worked for newtypes. Note that, in the example, I used the fact that >>>> Template Haskell interprets a bare top-level expression as a Template >>>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit >>>> about the use of TH. Also problematic here is that the code above requires >>>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using >>>> CPP, put it in a condition chunk in your .cabal file, like this: >>>> >>>>> if impl(ghc >= 7.8) >>>>> default-extensions: RoleAnnotations >>>> >>>> I hope this is helpful to everyone. Please feel free to post issues/pull >>>> requests to my github repo at github.com/goldfirere/no-role-annots. >>>> >>>> Thanks, >>>> Richard >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From pavel.ryzhov at gmail.com Wed Apr 9 05:31:18 2014 From: pavel.ryzhov at gmail.com (Pavel Ryzhov) Date: Wed, 9 Apr 2014 07:31:18 +0200 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald wrote: > ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 > > > On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos wrote: > 2014-04-08 15:28 GMT+02:00 Austin Seipp : > > Feel free to make builds - I'll add them as they come in and will > > announce soon... > > The FreeBSD builds are now available, along with the respective SHA256 > sums and the updated README file, as usual: > > http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 > http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 > http://haskell.inf.elte.hu/ghc/SHA256SUMS > http://haskell.inf.elte.hu/ghc/README.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From juhpetersen at gmail.com Wed Apr 9 05:48:08 2014 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 9 Apr 2014 14:48:08 +0900 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: On 8 April 2014 22:28, Austin Seipp wrote: > The source distribution is now available: > http://www.haskell.org/ghc/dist/7.8.1/ > Feel free to make builds - I'll add them as they come in and will > announce soon... Thank you! It builds fine on Fedora 21 devel for x86_64 and i686, but unfortunately it fails on ARM with: : inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for the full build.log, etc. I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From petersen at fedoraproject.org Wed Apr 9 08:21:50 2014 From: petersen at fedoraproject.org (Jens Petersen) Date: Wed, 9 Apr 2014 17:21:50 +0900 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: On 9 April 2014 14:48, Jens Petersen wrote: > On 8 April 2014 22:28, Austin Seipp wrote: > >> The source distribution is now available: >> http://www.haskell.org/ghc/dist/7.8.1/ > > It builds fine on Fedora 21 devel for x86_64 and i686, but unfortunately it > fails on ARM with: > > inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell > "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId > BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr > ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo > CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform > CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC > CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 > CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs > CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon > Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception > ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString > FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl > Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn > HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType > InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes > MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName > OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic > PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl > PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg > RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep > StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky > StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad > TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn > Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" > dll-split: internal error: evacuate(static): strange closure type 0 > (GHC version 7.8.1 for arm_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > make[1]: *** [compiler/stage2/dll-split.stamp] Aborted > > See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for the > full build.log, etc. > I reproduced this two times now. RC2 built okay on ARM so I am not sure > what changed. > I tested and this also happens on Fedora 20 ARM [1] so I now doubt it could be due to any recent changes in Fedora devel (Rawhide). I filed . Anyway I suppose it may be too late to fix for the 7.8.1 release but hopefully soon for 7.8.2. Jens [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720188 -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Wed Apr 9 08:36:32 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 09 Apr 2014 10:36:32 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <5344A545.8090906@gmail.com> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> <5344A545.8090906@gmail.com> Message-ID: <53450690.3000901@centrum.cz> On 04/ 9/14 03:41 AM, Alain O'Dea wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14-04-08 08:17 PM, Karel Gardas wrote: >> On 04/ 8/14 03:16 PM, Alain O'Dea wrote: >>> The two build slaves I intend to run are: - x86_64 Solaris (on >>> SmartOS) >> >> Please name it smartos-x86 then. I'm running real Solaris 11.1 as >> a builder here so let's make it different name builder and see if >> there are any incompatibilities between those two (I hope still >> very close) platforms. >> >> BTW: what's your platform triple detected by config.guess? >> >> Thanks! Karel > > Hi Karel, > > My platform triple detected by config.guess is: > x86_64-unknown-solaris2 > > I got that by running `cat config.status | grep TargetPlatformFull`. Hi Alain, hmm, that's after GHC own platform processing is done, but what does sh config.guess tells you? E.g. on my two Solaris 11 I get: $ sh config.guess i386-pc-solaris2.11 $ sh config.guess sparc-sun-solaris2.11 BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I think Christian (cced) may be interested as he is currently working on cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some bugs along the way. So if you do have already binary for GHC on that, then perhaps it'll work on Solaris too... You may wonder why I'm so picky about Solaris, but I've just been hit on Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so in the past I needed to switch off shared libs on Solaris 10 and keep this functionality on Solaris 11 so I'm curious what third member to Solaris family will bring here. I hope SmartOS is still more closer to Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project... Thanks, Karel From karel.gardas at centrum.cz Wed Apr 9 08:49:44 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 09 Apr 2014 10:49:44 +0200 Subject: 7.8.1 plan In-Reply-To: <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> Message-ID: <534509A8.3070309@centrum.cz> Hi Pavel, I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi The first link is binary tarball while the second is sha256. Karel On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: > Hi, > > I made Solaris 11 x86 bindist. It seems to be working fine. I will try > to make IPS package later than. > > https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 > sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 > > Regards, > Pavel Ryzhov > > On 08 Apr 2014, at 21:39, Carter Schonwald > wrote: > >> ok, did a sha256 on my bindist >> 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for >> https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 >> >> >> On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos > > wrote: >> >> 2014-04-08 15:28 GMT+02:00 Austin Seipp > >: >> > Feel free to make builds - I'll add them as they come in and will >> > announce soon... >> >> The FreeBSD builds are now available, along with the respective SHA256 >> sums and the updated README file, as usual: >> >> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 >> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 >> http://haskell.inf.elte.hu/ghc/SHA256SUMS >> http://haskell.inf.elte.hu/ghc/README.html >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From karel.gardas at centrum.cz Wed Apr 9 08:53:42 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 09 Apr 2014 10:53:42 +0200 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> Message-ID: <53450A96.50209@centrum.cz> Hi Jens, Ben Gamari (cced) documented it well here: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html Looks like the issue is caused by binutils' linker while fixed in gold. Cheers, Karel On 04/ 9/14 10:21 AM, Jens Petersen wrote: > dll-split: internal error: evacuate(static): strange closure type 0 > (GHC version 7.8.1 for arm_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > make[1]: *** [compiler/stage2/dll-split.stamp] Aborted > > See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for > the full build.log, etc. > I reproduced this two times now. RC2 built okay on ARM so I am not > sure what changed. > > > I tested and this also happens on Fedora 20 ARM [1] so I now doubt it > could be due to any recent changes in Fedora devel (Rawhide). > I filed . > > Anyway I suppose it may be too late to fix for the 7.8.1 release but > hopefully soon for 7.8.2. > > Jens > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720188 > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Wed Apr 9 10:00:36 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 9 Apr 2014 12:00:36 +0200 Subject: Avoiding bumping the major version of base in every release Message-ID: Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Wed Apr 9 11:49:58 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Wed, 9 Apr 2014 11:49:58 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <53450690.3000901@centrum.cz> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> <5344A545.8090906@gmail.com> <53450690.3000901@centrum.cz> Message-ID: <5A2B6C7F-0F01-40C7-844A-13FC93AF7645@gmail.com> > On Apr 9, 2014, at 8:36, Karel Gardas wrote: > >> On 04/ 9/14 03:41 AM, Alain O'Dea wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >>> On 14-04-08 08:17 PM, Karel Gardas wrote: >>>> On 04/ 8/14 03:16 PM, Alain O'Dea wrote: >>>> The two build slaves I intend to run are: - x86_64 Solaris (on >>>> SmartOS) >>> >>> Please name it smartos-x86 then. I'm running real Solaris 11.1 as >>> a builder here so let's make it different name builder and see if >>> there are any incompatibilities between those two (I hope still >>> very close) platforms. >>> >>> BTW: what's your platform triple detected by config.guess? >>> >>> Thanks! Karel >> >> Hi Karel, >> >> My platform triple detected by config.guess is: >> x86_64-unknown-solaris2 >> >> I got that by running `cat config.status | grep TargetPlatformFull`. > > Hi Alain, > > hmm, that's after GHC own platform processing is done, but what does > > sh config.guess > > tells you? E.g. on my two Solaris 11 I get: > > $ sh config.guess > i386-pc-solaris2.11 > > $ sh config.guess > sparc-sun-solaris2.11 Ah. I'll have to send that later today. > BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I think Christian (cced) may be interested as he is currently working on cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some bugs along the way. So if you do have already binary for GHC on that, then perhaps it'll work on Solaris too... Christian, the SmartOS GHC binaries should work unmodified on Solaris 10 and 11. Both 32- and 64-bit GHC 7.6.3 are available in SmartOS PKGSRC. I have successfully used them as bootstrap for GHC 7.8. The binaries should be separable. I can get the build details if desired. > You may wonder why I'm so picky about Solaris, but I've just been hit on Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so in the past I needed to switch off shared libs on Solaris 10 and keep this functionality on Solaris 11 so I'm curious what third member to Solaris family will bring here. It seems SmartOS builds GHC 7.8 cleanly without patches. There are some test failures which I'm working on. > I hope SmartOS is still more closer to Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project... SmartOS is an Illumos distro (like Ubuntu is to Linux). Illumos is descended directly from the last public commit of OpenSolaris 10 (grr Oracle). > Thanks, > Karel From johan.tibell at gmail.com Wed Apr 9 12:12:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 9 Apr 2014 14:12:05 +0200 Subject: Avoiding bumping the major version of base in every release In-Reply-To: References: Message-ID: I just noticed that 7.8.1 bumps the major version of base, but I can't see any breaking changes in the release notes: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/release-7-8-1.html On Wed, Apr 9, 2014 at 12:00 PM, Johan Tibell wrote: > Hi! > > Bumping the major version number of base creates a bunch of work for > package maintainers. Some times this work is justified, when there were > actual non-backwards compatible API changes and maintainers need to fix > their code. Often the work is busy work, as there were no real breakages > and maintainers need to update their version bounds and make a new release. > > When bumps to the major version leads to busy work, maintainers often > express a desire to get rid of version bounds altogether. While that might > be a natural reaction, I don't think that's actually a good idea and it > will lead to more breakages in the end*. > > All this is to say, we should try to avoid major version bumps to base. > Here's my suggestion > > *Short term* > > - Make sure we only bump the major version number when we actually > make a breaking change. We don't need to bump base because the major GHC > version number changed. > - Try harder to not make breaking changes. Breaking changes has a very > high cost to users and are seldom worth it to them. For example, avoid > renaming functions just because the new name feels cleaner. Just add a new > function and have the old function call the new function. All successful > languages do this. > > *Medium term* > > - Break up base a bit. There are several other good reasons to do > this, but having a monolithic base means that breaking changes to the most > obscure modules cause a major version bump for the package as a whole. > > * But in the case of missing upper bounds, the breakages and extra work > falls on the users of libraries, not on their maintainers. That's really > bad as the users are not really in a position to deal with the breakages. > > -- Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Apr 9 12:17:52 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 09 Apr 2014 14:17:52 +0200 Subject: Avoiding bumping the major version of base in every release In-Reply-To: (Johan Tibell's message of "Wed, 9 Apr 2014 12:00:36 +0200") References: Message-ID: <87mwfu4ryn.fsf@gmail.com> On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote: [...] > All this is to say, we should try to avoid major version bumps to base. > Here's my suggestion > > *Short term* > > - Make sure we only bump the major version number when we actually make > a breaking change. We don't need to bump base because the major GHC version > number changed. Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the changelog to check whether the major bump was justified; but since a couple of deprecated functions where removed, several new typeclass instances were added (however, this isn't a justification anymore), the rather disruptive Typeable change occured, as well as the PrimBool changes (which may leak into the API exposed by base) I believed it was well justified. > - Try harder to not make breaking changes. Breaking changes has a very > high cost to users and are seldom worth it to them. For example, avoid > renaming functions just because the new name feels cleaner. Just add a new > function and have the old function call the new function. All successful > languages do this. Aren't we already following this practice in base? > *Medium term* > > - Break up base a bit. There are several other good reasons to do this, > but having a monolithic base means that breaking changes to the most > obscure modules cause a major version bump for the package as a whole. > > * But in the case of missing upper bounds, the breakages and extra work > falls on the users of libraries, not on their maintainers. That's really > bad as the users are not really in a position to deal with the breakages. From johan.tibell at gmail.com Wed Apr 9 12:51:48 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 9 Apr 2014 14:51:48 +0200 Subject: Avoiding bumping the major version of base in every release In-Reply-To: <87mwfu4ryn.fsf@gmail.com> References: <87mwfu4ryn.fsf@gmail.com> Message-ID: On Wed, Apr 9, 2014 at 2:17 PM, Herbert Valerio Riedel wrote: > On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote: > > *Short term* > > > > - Make sure we only bump the major version number when we actually > make > > a breaking change. We don't need to bump base because the major GHC > version > > number changed. > > Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the > changelog to check whether the major bump was justified; but since a > couple of deprecated functions where removed, several new typeclass > instances were added (however, this isn't a justification anymore), the > rather disruptive Typeable change occured, as well as the PrimBool > changes (which may leak into the API exposed by base) I believed it was > well justified. > I wasn't aware there was a more detailed changelog. Thanks for pointing it out. I just wanted to make sure we're all on the same page here. > > - Try harder to not make breaking changes. Breaking changes has a very > > high cost to users and are seldom worth it to them. For example, avoid > > renaming functions just because the new name feels cleaner. Just add > a new > > function and have the old function call the new function. All > successful > > languages do this. > > Aren't we already following this practice in base? > I am and I'm hoping others are too. Since hope is not a strategy I just thought I'd spell it out to make sure we all agree. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Apr 9 13:39:09 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 09 Apr 2014 15:39:09 +0200 Subject: Avoiding bumping the major version of base in every release In-Reply-To: (Johan Tibell's message of "Wed, 9 Apr 2014 14:51:48 +0200") References: <87mwfu4ryn.fsf@gmail.com> Message-ID: <87y4ze39mq.fsf@gmail.com> On 2014-04-09 at 14:51:48 +0200, Johan Tibell wrote: [...] >> Fwiw, I did go over the changes in base-4.7.0.0 when I compiled the >> changelog to check whether the major bump was justified; but since a >> couple of deprecated functions where removed, several new typeclass >> instances were added (however, this isn't a justification anymore), the >> rather disruptive Typeable change occured, as well as the PrimBool >> changes (which may leak into the API exposed by base) I believed it was >> well justified. >> > > I wasn't aware there was a more detailed changelog. Thanks for pointing it > out. I just wanted to make sure we're all on the same page here. Oh, and btw, here's also a somewhat older API delta (which is only as accurate as the hoogle txt files generated -- i.e. take it with a grain of salt) I generated some time ago: https://gist.github.com/hvr/6648575 From eir at cis.upenn.edu Wed Apr 9 14:43:42 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 9 Apr 2014 10:43:42 -0400 Subject: Backward-compatible role annotations In-Reply-To: <5344B061.709@isaac.cedarswampstudios.org> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> <5344B061.7! 09@isaac.cedarswampstudios.org> Message-ID: We indeed had unexported "internal coercions" as a desideratum during the design process, but we didn't have a specific use case and it didn't mesh with our eventual decision to use class instances. Now that the whole thing is implemented, Coercible instances are actually fully magical inside of GHC. Thus, there would be nothing especially difficult, from an implementation standpoint, of adding the feature described below in a later release. There is always the niggling issue of concrete syntax. So, if you (or others) hit upon a nice, real use case desiring this feature and want to come up with a design, please propose it! I do think it would likely be easy to make happen. Richard On Apr 8, 2014, at 10:28 PM, Isaac Dupree wrote: > I've been wondering whether there are any cases where the ability to coerce a parameter should not be exported (as for Set) but where the implementation would like to use some coercions (for example, if it internally wanted to coerce the contained type to a specific newtype, to change some of the contained type's instances while being able to guarantee that the invariant-related instances stayed safe). > > This would call for coercibility to be something you can import and export. What if, in the long term, there were a flag ExplicitRoleExports (probably rarely used): > > - with ExplicitRoleExports on, role signatures would be listed in the export list and must be at least as restrictive as the roles visible within the module. Exported types without role signatures in the export list would default to being exported as all-nominal. > > - with ExplicitRoleExports off, any types the modules export would be exported with the same roles visible inside the module. > > As is currently, the default role at a type's definition site would allow as many coercions as is segfault-safe. > > -Isaac > > P.S. I think this particular proposal likely has issues. If you import (T :: * -> * -> *) as "nominal, representational" and from elsewhere as "representational, nominal", do those roles combine somehow? What about contravariant [or is it covariant] roles as in (T :: (* -> *) -> *)? I haven't thought these through. Also I haven't thought of any concrete use cases for export-controlled roles; perhaps there aren't any. > > > On 03/31/2014 02:12 PM, Dominique Devriese wrote: >> Richard, >> >> Right, but I was thinking about the debate between >> "nominal/non-parametric-by-default" or >> "representational/parametric-by-default" for parameters of data types >> that aren't forced to nominal from inspecting the datatype >> implementation. As I understand it, representational-by-default >> (currently used) may leave libraries that don't add role annotations >> open for abuse, but won't unnecessarily break library users' code and >> nominal-by-default prevents all abuse but may unnecessarily break code >> that uses libraries that have not added proper role annotations. >> >> What I was wondering about is if the dilemma could be solved by >> choosing nominal-by-default in the long term for the role inference >> (so that library writers cannot accidentally leave abstraction holes >> open by forgetting to add role annotations) and use them in the >> long-term-supported SafeNewtypeDeriving extension, but provide a >> deprecated not-quite-as-safe GND extension for helping out users of >> libraries that have not yet added role annotations. I would fancy that >> this not-quite-as-safe GND could use unsafeCoerce wherever the safe >> one would give an error about annotated roles. >> >> Regards, >> Dominique >> >> 2014-03-31 17:05 GMT+02:00 Richard Eisenberg : >>> Hi Dominique, >>> >>> When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. >>> >>> The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. >>> >>> Richard >>> >>> On Mar 31, 2014, at 2:51 AM, Dominique Devriese wrote: >>> >>>> Richard, >>>> >>>> (re-posting because I first used an address that is not subscribed to the lists) >>>> >>>> I've been wondering about the following: it seems like the main >>>> problem in this situation is that the GeneralizedNewtypeDeriving >>>> extension changed meaning from "just coerce everything while deriving" >>>> to "only coerce stuff if it's allowed by the relevant role >>>> annotations". Would it not be an alternative solution to split up the >>>> GND extension into >>>> >>>> * a backwards-compatible one (called GeneralizedNewtypeDeriving for >>>> backwards compatibility ;)) that ignores role annotations (as before) >>>> and uses unsafeCoerce whereever necessary >>>> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations >>>> >>>> The first one could then be deprecated and removed in a release or >>>> two. That might give library maintainers time to move their packages >>>> to SafeNewtypeDeriving when they have tested that everything works... >>>> >>>> Regards, >>>> Dominique >>>> >>>> P.S.: The above is based on a limited understanding of the problem, so >>>> I'm sorry if it misses some aspect of the problem... >>>> >>>> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : >>>>> I spent some time thinking about what, precisely, can be done here to make >>>>> folks happier. (See the thread beginning here: >>>>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the >>>>> answer seemed to all be in the concrete syntax. The only logical alternative >>>>> (that I could think of) to having roles is to disallow GND, and I don't >>>>> think anyone is proposing that. And, it is impossible to infer an author's >>>>> desired roles for a datatype. The heuristics mentioned here all seem far too >>>>> fragile and hard to predict to become a lasting feature of GHC (in my >>>>> opinion). What's left? Concrete syntax. >>>>> >>>>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible >>>>> alternative to role annotations -- no CPP required. It's not as principled >>>>> as proper role annotations, but it should do the job for most users. >>>>> >>>>> Here are two examples: >>>>> >>>>> 1. Datatypes: >>>>> >>>>>> import Language.Haskell.RoleAnnots >>>>>> >>>>>> data Map k v = >>>>>> (Nominal k, Representational v) => MkMap [(k,v)] >>>>> >>>>> The constraints (which need be put on only one data constructor, if there >>>>> are many) will get the built-in role inference mechanism to do what the user >>>>> requests. In this example, the `Representational v` is actually redundant, >>>>> but causes no harm. Because these classes have universal instances >>>>> ("instance Nominal a") and have no methods, they should have no run-time >>>>> significance. The only downside I can see is that the code above needs >>>>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT >>>>> nor has existentials. (Pattern-matching on such a definition needs no >>>>> extensions.) >>>>> >>>>> 2. Newtypes: >>>>> >>>>> Newtype constructors cannot be constrained, unfortunately. So, we have to >>>>> resort to Template Haskell: >>>>> >>>>>> import Language.Haskell.RoleAnnots >>>>>> >>>>>> roleAnnot [NominalR, RepresentationalR] >>>>>> [d| newtype Map k v = MkMap [(k, v)] |] >>>>> >>>>> This is clearly worse, but I was able to come up with no other solution that >>>>> worked for newtypes. Note that, in the example, I used the fact that >>>>> Template Haskell interprets a bare top-level expression as a Template >>>>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit >>>>> about the use of TH. Also problematic here is that the code above requires >>>>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using >>>>> CPP, put it in a condition chunk in your .cabal file, like this: >>>>> >>>>>> if impl(ghc >= 7.8) >>>>>> default-extensions: RoleAnnotations >>>>> >>>>> I hope this is helpful to everyone. Please feel free to post issues/pull >>>>> requests to my github repo at github.com/goldfirere/no-role-annots. >>>>> >>>>> Thanks, >>>>> Richard >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From pavel.ryzhov at gmail.com Wed Apr 9 14:49:20 2014 From: pavel.ryzhov at gmail.com (Pavel Ryzhov) Date: Wed, 9 Apr 2014 16:49:20 +0200 Subject: 7.8.1 plan In-Reply-To: <534509A8.3070309@centrum.cz> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> <534509A8.3070309@centrum.cz> Message-ID: <4A7CF78C-9146-4801-843F-CC67E2362056@gmail.com> Hi Karel, That is great! Do you know if there any plans for 64-bit build of GHC for Solaris 11? Regards, Pavel On 09 Apr 2014, at 10:49, Karel Gardas wrote: > > Hi Pavel, > > I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. > > Solaris 2.10: > https://app.box.com/s/s1bysqga0x5f3itysu7g > https://app.box.com/s/fbfki0szetnp4pghpeuk > > Solaris 2.11: > https://app.box.com/s/zstci63pt10t4yix74s8 > https://app.box.com/s/9375dyx8hwu9cnox2lgi > > The first link is binary tarball while the second is sha256. > > Karel > > On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: >> Hi, >> >> I made Solaris 11 x86 bindist. It seems to be working fine. I will try >> to make IPS package later than. >> >> https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 >> sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 >> >> Regards, >> Pavel Ryzhov >> >> On 08 Apr 2014, at 21:39, Carter Schonwald > > wrote: >> >>> ok, did a sha256 on my bindist >>> 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for >>> https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 >>> >>> >>> On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos >> > wrote: >>> >>> 2014-04-08 15:28 GMT+02:00 Austin Seipp >> >: >>> > Feel free to make builds - I'll add them as they come in and will >>> > announce soon... >>> >>> The FreeBSD builds are now available, along with the respective SHA256 >>> sums and the updated README file, as usual: >>> >>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 >>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 >>> http://haskell.inf.elte.hu/ghc/SHA256SUMS >>> http://haskell.inf.elte.hu/ghc/README.html >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From simonpj at microsoft.com Wed Apr 9 20:50:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 9 Apr 2014 20:50:18 +0000 Subject: Avoiding bumping the major version of base in every release In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0FA804@DB3PRD3001MB020.064d.mgd.msft.net> Sounds reasonable to me, but I'm fwding this to the Core Libraries committee, who are in charge of all this. On the question of breaking up 'base', see https://ghc.haskell.org/trac/ghc/wiki/SplitBase, which seems stalled for lack of anyone willing to take up the cudgels. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 09 April 2014 11:01 To: ghc-devs at haskell.org Subject: Avoiding bumping the major version of base in every release Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion Short term * Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. * Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. Medium term * Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Apr 9 21:48:52 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 9 Apr 2014 17:48:52 -0400 Subject: [core libraries] RE: Avoiding bumping the major version of base in every release In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0FA804@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0FA804@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: The current plan with breaking up base is mostly to push it out until we get the lower hanging fruit out of the way for 7.10, and to start moving forward more aggressively on that around 7.12. Back at ICFP we made the call to more or less take greater ownership of base upon the release of 7.8. Given the release timeline that was perhaps, in hindsight, a mistake, as it drained a lot of momentum. That said, now that 7.8 is out the door we can at least get started on the Foldable/Traversable/Applicative/Monoid changes and AMP. The orginal plan, and one that I think is still a good plan going forward, is that the changes for 7.10 should be done in such a way that most users can work around them all without CPP at all, and just enjoy the greater flexibility of Foldable/Traversable/Applicative/Monoid in Prelude. I think the major things broken by those inclusions are <> and <$> in the pretty printing libraries, which could hide two symbols, and a boatload of redundant import warnings. Almost any serious stab at breaking up base to meet the demands of the javascript crowd, one of the two major reasons for breaking up base, is going to cause some serious challenges for the very makeup of the Prelude we export today. I'm all for doing splitting up base, but it is definitely stalled for a reason, and I think that given the scope of work in just modernizing the Prelude, we've got a lot bitten off already for this coming year in 7.10. Beyond that, one potentially viable plan is to break it up in phases -- if the more invasive changes needed to make the ghcjs/haste crowd can't converge for 7.12 we could at least start splintering off some parts of base that don't feed into the Prelude. That would let us better meet Johan's goal of an eventually more stable base version number as those things at the fringes of base are the kinds of thing that iterate quickly, but very little of the Prelude itself changes from release to release -- although, 7.10 will be a rather large exception in that regard. -Edward On Wed, Apr 9, 2014 at 4:50 PM, Simon Peyton Jones wrote: > Sounds reasonable to me, but I?m fwding this to the Core Libraries > committee, who are in charge of all this. > > > > On the question of breaking up ?base?, see > https://ghc.haskell.org/trac/ghc/wiki/SplitBase, which seems stalled for > lack of anyone willing to take up the cudgels. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Johan > Tibell > *Sent:* 09 April 2014 11:01 > *To:* ghc-devs at haskell.org > *Subject:* Avoiding bumping the major version of base in every release > > > > Hi! > > > > Bumping the major version number of base creates a bunch of work for > package maintainers. Some times this work is justified, when there were > actual non-backwards compatible API changes and maintainers need to fix > their code. Often the work is busy work, as there were no real breakages > and maintainers need to update their version bounds and make a new release. > > > > When bumps to the major version leads to busy work, maintainers often > express a desire to get rid of version bounds altogether. While that might > be a natural reaction, I don't think that's actually a good idea and it > will lead to more breakages in the end*. > > > > All this is to say, we should try to avoid major version bumps to base. > Here's my suggestion > > > > *Short term* > > - Make sure we only bump the major version number when we actually > make a breaking change. We don't need to bump base because the major GHC > version number changed. > - Try harder to not make breaking changes. Breaking changes has a very > high cost to users and are seldom worth it to them. For example, avoid > renaming functions just because the new name feels cleaner. Just add a new > function and have the old function call the new function. All successful > languages do this. > > *Medium term* > > - Break up base a bit. There are several other good reasons to do > this, but having a monolithic base means that breaking changes to the most > obscure modules cause a major version bump for the package as a whole. > > * But in the case of missing upper bounds, the breakages and extra work > falls on the users of libraries, not on their maintainers. That's really > bad as the users are not really in a position to deal with the breakages. > > > > -- Johan > > > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Wed Apr 9 22:12:10 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Thu, 10 Apr 2014 00:12:10 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <603234EA-24AA-4201-B4D7-D62491B949AD@orthanc.ca> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <603234EA-24AA-4201-B4D7-D62491B949AD@orthanc.ca> Message-ID: 2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg : > Is there any way to verify that builder-client can actually do a successful build, > without having access to the build system server? 'builder-client --do-build' > wants to connect and authenticate first; it would be helpful if there was a way > to bypass that so that I can first verify the local build environment is sane. This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it. You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command. [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html From slyich at gmail.com Wed Apr 9 22:34:48 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Thu, 10 Apr 2014 01:34:48 +0300 Subject: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0E6085@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140322222142.798abe7e@sf> <20140403232017.1c2b2db2@sf> <618BE556AADD624C9C918AA5D5911BEF0E6085@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140410013448.0d5f5dce@sf> On Fri, 4 Apr 2014 16:19:48 +0000 Simon Peyton Jones wrote: Filed the reproducer as a new ticket: https://ghc.haskell.org/trac/ghc/ticket/8980 [ Looks like highlighting-kate asks to be added to compiler performance benchmarks (are there such ones?) It tends to stress ghc all the time: http://hackage.haskell.org/trac/ghc/ticket/3664 ] Thanks! > Sergei > > SpecConstr is too aggressive: it sometimes blows up the program badly and we have no good solution. See Trac #7898, #7068, #7944, #5550, #8836. > > I notice that the latter three are actually fixed in 7.8, so worth trying that. If it still fails, do add instructions to reproduce to one of the above open tickets, or make a new one. > > > Amos Robinson (cc'd) was working on this problem, but I have not heard anything recently. > > It surely ought to be possible to "throttle" it a bit so that it stops before generating too vast a program. > > Meanwhile you can use -fno-spec-constr to simply switch it off for offending modules. That should get you going. > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Sergei Trofimovich > | Sent: 03 April 2014 21:20 > | To: ghc-devs at haskell.org > | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- > | citeproc / highlighting-kate > | > | On Sat, 22 Mar 2014 22:21:42 +0300 > | Sergei Trofimovich wrote: > | > | > Hello! > | > > | > I have noticed the problem in ghc-7.6.3 first when tried to build all > | > haskell userland with -O2 opt level. > | > > | > It led to amazing bugs! > | > > | > Here is one of those (highlighting-kate hackage package): > | > > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( > | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, > | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > | > > stack overflow: use +RTS -K to increase it > | > > | > How to reproduce it: > | > 1. Download a bundled file (6.6MB): > | > > | > http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8- > | rc2.tar.gz > | > 2. Unpack and run there: > | > ./mk.sh > | > > | > The script is designed to plug any built ghc version w/o external > | depends. > | > > | > Command will fail as: > | > $ ./mk.sh > | > ... > | > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( > | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, > | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > | > stack overflow: use +RTS -K to increase it > | > > | > On ghc-7.6.3 it will progress a bit more: down to 452 file and will > | > crash there similar way. > | > > | > I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them > | > manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around. > | > Nothing else. > | > > | > It's very hard to shrink such large thing manually down to 2-3 files. > | > Would be cool if ghc (and cabal) would be able to spit something > | > self-sufficient (like 'gcc -i' does) for devs to reproduce. > | > > | > Adding '-v' shows such log: > | > ... > | > *** Simplifier: > | > Result size of Simplifier iteration=1 > | > = {terms: 21,973, types: 21,838, coercions: 1,842} > | > Result size of Simplifier iteration=2 > | > = {terms: 21,952, types: 21,819, coercions: 1,842} > | > Result size of Simplifier > | > = {terms: 21,950, types: 21,817, coercions: 1,842} > | > *** SpecConstr: > | > Result size of SpecConstr*** > | > | Nobody interested? Is it too scary? > | > | Such inliner blowups are hard to shrink down from real examples down to > | toy ones. I could try to but I need a bit of guidance. > | > | Maybe you need only an intermediate core step right before an OOM, > | whatever? -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From austin at well-typed.com Thu Apr 10 00:34:13 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 9 Apr 2014 19:34:13 -0500 Subject: 7.8.2 bugs and beyond Message-ID: Hello all, 7.8.1 is out. Yay! Now, on to the next thing. Here's the very preliminary 7.8.2 buglist: - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 Note that this list has effectively received zero curation so far. I plan on fixing that soon, and in the process I am probably going to touch a lot of trac tickets (so I apologize in advance for the mail spam, because y'all are probably going to get a lot of it). This will include re-prioritizing these bugs, so take things with a grain of salt right now. Note that the bug tracker now has 7.8.1 as the default version - if you're filing bugs, please be sure to try it first of course. :) And don't forget to set the milestone to 7.8.2 if you think it qualifies for a fix. There are already a couple of things in the merge queue. There's currently no expected date for 7.8.2. Should it arrive quickly? Or slowly? Simon, Simon and I are inclined to just let things play out for a while of course, which is the traditional way things are done. But this release window has been especially awkward, so we'll see what happens. This of course leaves timeline questions for 7.10 open - but before we decide that, now's a time to just get some hacking done I suppose... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alain.odea at gmail.com Thu Apr 10 00:52:43 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 10 Apr 2014 00:52:43 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <5A2B6C7F-0F01-40C7-844A-13FC93AF7645@gmail.com> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> <5344A545.8090906@gmail.com> <53450690.3000901@centrum.cz> <5A2B6C7F-0F01-40C7-844A-13FC93AF7645@gmail.com> Message-ID: <5345EB5B.5050505@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14-04-09 11:49 AM, Alain O'Dea wrote: >> On Apr 9, 2014, at 8:36, Karel Gardas >> wrote: >> >>> On 04/ 9/14 03:41 AM, Alain O'Dea wrote: -----BEGIN PGP SIGNED >>> MESSAGE----- Hash: SHA1 >>> >>>> On 14-04-08 08:17 PM, Karel Gardas wrote: >>>>> On 04/ 8/14 03:16 PM, Alain O'Dea wrote: The two build >>>>> slaves I intend to run are: - x86_64 Solaris (on SmartOS) >>>> >>>> Please name it smartos-x86 then. I'm running real Solaris >>>> 11.1 as a builder here so let's make it different name >>>> builder and see if there are any incompatibilities between >>>> those two (I hope still very close) platforms. >>>> >>>> BTW: what's your platform triple detected by config.guess? >>>> >>>> Thanks! Karel >>> >>> Hi Karel, >>> >>> My platform triple detected by config.guess is: >>> x86_64-unknown-solaris2 >>> >>> I got that by running `cat config.status | grep >>> TargetPlatformFull`. >> >> Hi Alain, >> >> hmm, that's after GHC own platform processing is done, but what >> does >> >> sh config.guess >> >> tells you? E.g. on my two Solaris 11 I get: >> >> $ sh config.guess i386-pc-solaris2.11 >> >> $ sh config.guess sparc-sun-solaris2.11 Karel, I think I finally have what you were looking for: x86_64-pc-solaris2.11 i386-pc-solaris2.11 G?bor sent me usernames and passwords for my builders and I'm in the process of setting those up now. > > Ah. I'll have to send that later today. > >> BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, >> then I think Christian (cced) may be interested as he is >> currently working on cross-compiling from i386/Solaris to >> AMD64/Solaris and he is hit by some bugs along the way. So if you >> do have already binary for GHC on that, then perhaps it'll work >> on Solaris too... > > Christian, the SmartOS GHC binaries should work unmodified on > Solaris 10 and 11. Both 32- and 64-bit GHC 7.6.3 are available in > SmartOS PKGSRC. I have successfully used them as bootstrap for GHC > 7.8. The binaries should be separable. I can get the build > details if desired. > >> You may wonder why I'm so picky about Solaris, but I've just been >> hit on Solaris 10 by bugs (in linker) which are not presented on >> Solaris 11 so in the past I needed to switch off shared libs on >> Solaris 10 and keep this functionality on Solaris 11 so I'm >> curious what third member to Solaris family will bring here. > > It seems SmartOS builds GHC 7.8 cleanly without patches. There are > some test failures which I'm working on. > >> I hope SmartOS is still more closer to Solaris 11 than Solaris 10 >> thanks to its roots in OpenSolaris project... > > SmartOS is an Illumos distro (like Ubuntu is to Linux). Illumos is > descended directly from the last public commit of OpenSolaris 10 > (grr Oracle). > >> Thanks, Karel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRetbAAoJEP0rIXJNjNSAGpIH/Rd0Kp4K3OV5jIdwiT3x1GNI jbed0L48bOB9u4ChasoLsq+12iOhwYkb4eBd+hAWGnjW+/EDsX7F19qfuBugsr9a GiYyGRprRaMFMUQ0DR1pFPqeLKe5EUaNw5Al4KVW5i9W3LDCwGL3pQI8D0dRYzlN 4QlG7OcDG9DN8mTyiFAtWOjFloqkQN1G6EQG1GbwkHSdjKrXVRfeatAxMl9QfS7H I1o9sLDKJWQTL38XmnMuXWKqLmvxundO0UUJNmvmKoJdSnRnBvD5m4BvnpIN1Cl2 xVnIvPef5PuPE5I1EXqZu61zUD2qgqmyVCHZui5D+ltZoEUS0Hh94JSzb2YOSGs= =mu2x -----END PGP SIGNATURE----- From petersen at fedoraproject.org Thu Apr 10 01:03:42 2014 From: petersen at fedoraproject.org (Jens Petersen) Date: Thu, 10 Apr 2014 10:03:42 +0900 Subject: 7.8.1 plan In-Reply-To: <53450A96.50209@centrum.cz> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53450A96.50209@centrum.cz> Message-ID: On 9 April 2014 17:53, Karel Gardas wrote: > Ben Gamari (cced) documented it well here: http://bgamari.github.io/ > posts/2014-03-06-compiling-ghc-7.8-on-arm.html > > Looks like the issue is caused by binutils' linker while fixed in gold. > Thanks a lot, Karel! I will try Ben's hack later. I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now? On 04/ 9/14 10:21 AM, Jens Petersen wrote: > >> dll-split: internal error: evacuate(static): strange closure type 0 >> > See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for >> > > I reproduced this two times now. RC2 built okay on ARM so I am not >> sure what changed. >> > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Apr 10 01:09:39 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 9 Apr 2014 20:09:39 -0500 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53450A96.50209@centrum.cz> Message-ID: Jens, It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which was merged post RC2. I base this on the fact your build is failing during the dynamic build. Do try a reverse patch and see if it helps. I believe Karel is right - you just need to use Gold. Ben actually had patches to make the build fail if using binutils ld was detected, but I believe I had reservations about the patch which I cannot recall off the top of my head. In any case, a fix like that can certainly go in 7.8.2. Do let us know how it goes. [1] https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen wrote: > On 9 April 2014 17:53, Karel Gardas wrote: >> >> Ben Gamari (cced) documented it well here: >> http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html >> >> Looks like the issue is caused by binutils' linker while fixed in gold. > > > Thanks a lot, Karel! I will try Ben's hack later. > > I am still surprised that RC2 builds fine on ARM (I re-verified that > yesterday [1]) but not final 7.8.1. > Were there some late ARM or linking changes that cause this now? > >> On 04/ 9/14 10:21 AM, Jens Petersen wrote: >>> >>> dll-split: internal error: evacuate(static): strange closure type 0 >> >> >>> >>> See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for > > >>> >>> I reproduced this two times now. RC2 built okay on ARM so I am not >>> sure what changed. > > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mjgajda at gmail.com Thu Apr 10 06:26:11 2014 From: mjgajda at gmail.com (Michal J. Gajda) Date: Thu, 10 Apr 2014 14:26:11 +0800 Subject: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-, citeproc / highlighting-kate In-Reply-To: References: Message-ID: <53463983.7010801@gmail.com> Dear Devs, On 04/10/2014 09:09 AM, ghc-devs-request at haskell.org wrote: > Filed the reproducer as a new ticket: > https://ghc.haskell.org/trac/ghc/ticket/8980 > > [ Looks like highlighting-kate asks to be added to > compiler performance benchmarks (are there such ones?) > It tends to stress ghc all the time: > http://hackage.haskell.org/trac/ghc/ticket/3664 > ] Please consider adding hPDB too, if you want to stress the optimizer. It shows GHC optimizer at its best, with at least 10-20% improvement in every major version of the compiler since 6.12. Unfortunately at cost of very long compile times. Please let me know if I should submit a driver code for automatic benchmarks it (it is in hPDB-examples.) Thanks! >> > SpecConstr is too aggressive: it sometimes blows up the program badly and we have no good solution. See Trac #7898, #7068, #7944, #5550, #8836. And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy to reproduce by just `cabal install hPDB`. >> > I notice that the latter three are actually fixed in 7.8, so worth trying that. If it still fails, do add instructions to reproduce to one of the above open tickets, or make a new one. >> > >> > Meanwhile you can use -fno-spec-constr to simply switch it off for offending modules. That should get you going. -- Best regards Michal From simonpj at microsoft.com Thu Apr 10 07:34:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 10 Apr 2014 07:34:45 +0000 Subject: Breaking bug in 7.8.1 Message-ID: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> Austin, Simon (and others) As you'll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1. Do you agree? Sorry about this. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Thu Apr 10 07:39:08 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 10 Apr 2014 09:39:08 +0200 Subject: 64bit Solaris was: Re: 7.8.1 plan In-Reply-To: <4A7CF78C-9146-4801-843F-CC67E2362056@gmail.com> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> <534509A8.3070309@centrum.cz> <4A7CF78C-9146-4801-843F-CC67E2362056@gmail.com> Message-ID: <53464A9C.8070807@dfki.de> Hi, I've tried to cross-compile https://ghc.haskell.org/trac/ghc/ticket/8910 but did not succeed, yet. There seem to be problems with Int64 and/or Word data types. The proper start would be to make a careful comparison of the test-suite results, but there are already failures for the 32bit version (under Solaris 10). Unfortunately I don't have time to look into it further. Cheers Christian Am 09.04.2014 16:49, schrieb Pavel Ryzhov: > Hi Karel, > > That is great! > > Do you know if there any plans for 64-bit build of GHC for Solaris 11? > > Regards, > Pavel > > On 09 Apr 2014, at 10:49, Karel Gardas wrote: > >> >> Hi Pavel, >> >> I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. >> >> Solaris 2.10: >> https://app.box.com/s/s1bysqga0x5f3itysu7g >> https://app.box.com/s/fbfki0szetnp4pghpeuk >> >> Solaris 2.11: >> https://app.box.com/s/zstci63pt10t4yix74s8 >> https://app.box.com/s/9375dyx8hwu9cnox2lgi >> >> The first link is binary tarball while the second is sha256. >> >> Karel >> >> On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: >>> Hi, >>> >>> I made Solaris 11 x86 bindist. It seems to be working fine. I will try >>> to make IPS package later than. >>> >>> https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 >>> sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 >>> >>> Regards, >>> Pavel Ryzhov >>> >>> On 08 Apr 2014, at 21:39, Carter Schonwald >> > wrote: >>> >>>> ok, did a sha256 on my bindist >>>> 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for >>>> https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 >>>> >>>> >>>> On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos >>> > wrote: >>>> >>>> 2014-04-08 15:28 GMT+02:00 Austin Seipp >>> >: >>>> > Feel free to make builds - I'll add them as they come in and will >>>> > announce soon... >>>> >>>> The FreeBSD builds are now available, along with the respective SHA256 >>>> sums and the updated README file, as usual: >>>> >>>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 >>>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 >>>> http://haskell.inf.elte.hu/ghc/SHA256SUMS >>>> http://haskell.inf.elte.hu/ghc/README.html >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From Thomas.Winant at cs.kuleuven.be Thu Apr 10 07:48:36 2014 From: Thomas.Winant at cs.kuleuven.be (Thomas Winant) Date: Thu, 10 Apr 2014 09:48:36 +0200 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: <532062AB.50108@cs.kuleuven.be> References: <532062AB.50108@cs.kuleuven.be> Message-ID: Hi, I'm back with a status update. We implemented Austin's suggestion to make wildcards in partial type signatures behave like holes. Let's demonstrate the new behaviour with an example. The example program: > module Example where > > foo :: (Show _a, _) => _a -> _ > foo x = show (succ x) Compiled with GHC master gives: > Example.hs:3:18: parse error on input ?_? When we compile it with our branch: > Example.hs:3:18: > Instantiated extra-constraints wildcard ?_? to: > (Enum _a) > in the type signature for foo :: (Show _a, _) => _a -> _ > at Example.hs:3:8-30 > The complete inferred type is: > foo :: forall _a. (Show _a, Enum _a) => _a -> String > To use the inferred type, enable PartialTypeSignatures > > Example.hs:3:30: > Instantiated wildcard ?_? to: String > in the type signature for foo :: (Show _a, _) => _a -> _ > at Example.hs:3:8-30 > The complete inferred type is: > foo :: forall _a. (Show _a, Enum _a) => _a -> String > To use the inferred type, enable PartialTypeSignatures Now the types the wildcards were instantiated to are reported. Note that `_a` is still treated as a type variable, as prescribed in Haskell 2010. To treat it as a /named wildcard/, we pass the -XNamedWildcards flag and get: > [..] > Example.hs:3:24: > Instantiated wildcard ?_a? to: tw_a > in the type signature for foo :: (Show _a, _) => _a -> _ > at Example.hs:3:8-30 > The complete inferred type is: > foo :: forall tw_a. (Show tw_a, Enum tw_a) => tw_a -> String > To use the inferred type, enable PartialTypeSignatures > [..] An extra error message appears, reporting that `_a` was instantiated to a new type variable (`tw_a`). Finally, when passed the -XPartialTypeSignatures flag, the typechecker will just use the inferred types for the wildcards and compile the program without generating any error messages. We added this example and a section about the monomorphism restriction to the wiki page [1]. Comments and feedback are still welcome. Cheers, Thomas Winant [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From karel.gardas at centrum.cz Thu Apr 10 07:52:51 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 10 Apr 2014 09:52:51 +0200 Subject: 64bit Solaris was: Re: 7.8.1 plan In-Reply-To: <53464A9C.8070807@dfki.de> References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53E2835B-4D02-466F-9F14-2E860DFB97F2@gmail.com> <534509A8.3070309@centrum.cz> <4A7CF78C-9146-4801-843F-CC67E2362056@gmail.com> <53464A9C.8070807@dfki.de> Message-ID: <53464DD3.6060908@centrum.cz> Hi, thanks to an advice put by Alain (cced), I've grabbed the copy of SmartOS and installed GHC there. It looks like this package is AMD64 based. I've then moved it to my Solaris 11.1 and it runs fine and compile the code well: $ ghc --make HelloWorld.lhs [1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o ) Linking HelloWorld ... $ ./HelloWorld Hello world! $ file HelloWorld HelloWorld: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped $ ldd HelloWorld libiconv.so.2 => /opt/local/lib/libiconv.so.2 libgmp.so.10 => /opt/local/lib/libgmp.so.10 libm.so.2 => /lib/64/libm.so.2 librt.so.1 => /lib/64/librt.so.1 libdl.so.1 => /lib/64/libdl.so.1 libc.so.1 => /lib/64/libc.so.1 libumem.so.1 => /lib/64/libumem.so.1 libgcc_s.so.1 => /opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1 Well, so this is IMHO a easier way to bootstrap GHC HEAD on Solaris/AMD64. I currently do not have a time to deal with it, but hopefully will find some during the weekend -- well, if nobody is faster, otherwise I will devote my "weekend ghc hobby" time to SPARC NCG debugging. :-) Cheers, Karel On 04/10/14 09:39 AM, Christian Maeder wrote: > Hi, > > I've tried to cross-compile > https://ghc.haskell.org/trac/ghc/ticket/8910 > but did not succeed, yet. > > There seem to be problems with Int64 and/or Word data types. > The proper start would be to make a careful comparison of the test-suite > results, but there are already failures for the 32bit version (under > Solaris 10). Unfortunately I don't have time to look into it further. > > Cheers Christian > > Am 09.04.2014 16:49, schrieb Pavel Ryzhov: >> Hi Karel, >> >> That is great! >> >> Do you know if there any plans for 64-bit build of GHC for Solaris 11? >> >> Regards, >> Pavel >> >> On 09 Apr 2014, at 10:49, Karel Gardas wrote: >> >>> >>> Hi Pavel, >>> >>> I've too built binary dist for Solaris 11 and Solaris 10. The >>> advantage of Solaris 11 build is that it supports shared libs and is >>> built using system provided gmp and ffi libs. >>> >>> Solaris 2.10: >>> https://app.box.com/s/s1bysqga0x5f3itysu7g >>> https://app.box.com/s/fbfki0szetnp4pghpeuk >>> >>> Solaris 2.11: >>> https://app.box.com/s/zstci63pt10t4yix74s8 >>> https://app.box.com/s/9375dyx8hwu9cnox2lgi >>> >>> The first link is binary tarball while the second is sha256. >>> >>> Karel >>> >>> On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: >>>> Hi, >>>> >>>> I made Solaris 11 x86 bindist. It seems to be working fine. I will try >>>> to make IPS package later than. >>>> >>>> https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 >>>> >>>> sha256: >>>> 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 >>>> >>>> Regards, >>>> Pavel Ryzhov >>>> >>>> On 08 Apr 2014, at 21:39, Carter Schonwald >>> > wrote: >>>> >>>>> ok, did a sha256 on my bindist >>>>> 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for >>>>> https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 >>>>> >>>>> >>>>> >>>>> On Tue, Apr 8, 2014 at 1:17 PM, P?li G?bor J?nos >>>> > wrote: >>>>> >>>>> 2014-04-08 15:28 GMT+02:00 Austin Seipp >>>> >: >>>>> > Feel free to make builds - I'll add them as they come in and will >>>>> > announce soon... >>>>> >>>>> The FreeBSD builds are now available, along with the respective SHA256 >>>>> sums and the updated README file, as usual: >>>>> >>>>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 >>>>> http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 >>>>> >>>>> http://haskell.inf.elte.hu/ghc/SHA256SUMS >>>>> http://haskell.inf.elte.hu/ghc/README.html >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > From karel.gardas at centrum.cz Thu Apr 10 07:57:16 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 10 Apr 2014 09:57:16 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <5345EB5B.5050505@gmail.com> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> <5344A545.8090906@gmail.com> <53450690.3000901@centrum.cz> <5A2B6C7F-0F01-40C7-844A-13FC93AF7645@gmail.com> <5345EB5B.5050505@gmail.com> Message-ID: <53464EDC.3080500@centrum.cz> On 04/10/14 02:52 AM, Alain O'Dea wrote: >>> hmm, that's after GHC own platform processing is done, but what >>> does >>> >>> sh config.guess >>> >>> tells you? E.g. on my two Solaris 11 I get: >>> >>> $ sh config.guess i386-pc-solaris2.11 >>> >>> $ sh config.guess sparc-sun-solaris2.11 > > Karel, I think I finally have what you were looking for: > > x86_64-pc-solaris2.11 > i386-pc-solaris2.11 Great, so this means SmartOS is just another member of Solaris family. I've installed it and verified that `ld' and `nm' are really what we expect on real Solaris. In fact thanks for your advice I've been able to use its packaged GHC on my Solaris 11 to compile some code and even attempted the bootstrap of HEAD for Solaris/AMD64 platform. There are some outstanding issues with bootstrap so this needs to wait till my weekend ghc hobby time...(if someone does not solved it faster of course...) Thanks! Karel From simonpj at microsoft.com Thu Apr 10 07:58:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 10 Apr 2014 07:58:49 +0000 Subject: GHC's performance Message-ID: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> Friends The thread below concerns GHC's performance. I'm writing to ask for your help. In developing GHC we always run 'validate', which runs a lot of regression tests. A few of those are performance tests, but because we do so frequently, none of these performance tests run for long, and none depend on other packages. And they tend to test something very specific. What we lack is a sustained effort to track a) The performance of GHC itself b) The performance of GHC-compiled programs At GHC HQ we *aspire* to track this stuff, but in practice we simply don't. Bug-fixing, portability, etc etc always ends up taking priority. But it's a pity that we don't. For example, Michal's comment below (that his GHC-compiled program has run 10-20% faster with each release of GHC from 6.12) is fantastic -- but we have no data to back it up, or know whether it's just Michael, or more widely true. I also suspect that sometimes we regress and don't know it. People do report this (e.g. #8971), but it's a bit random. Again, it would be great to have a more systematic way to know. In many cases it might be easy to fix; but we can only fix if we know. We have the nofib suite, and we take that very seriously, but it is showing its age, uses no advanced features, and I'm not sure how representative it is any more. Johan Tibell and Bryan O'Sullivan agreed to become GHC's Performance Tsars a year or two ago, with a view to focusing on (b) at least, but they are both extremely busy. And I don't think they even attempt to focus on (a). So I'm wondering: would anyone like to help here? It would mean * Soliciting and gathering together some more substantial benchmarks * Gathering performance numbers * Yelling quickly if the numbers go bad. * Investigating why (e.g. no one has seriously profiled GHC itself for a while, both space and time. I bet there are improvements to be had there.) Maybe it could be part of the new buildbot team's work? Certainly it'd make sense to use the same nightly-build infrastructure. Anyway, I'm advertising that there's an un-met need, and I'd love some help. Thanks Simon | -----Original Message----- | From: Michal J. Gajda [mailto:mjgajda at gmail.com] | Sent: 10 April 2014 07:26 | To: ghc-devs at haskell.org; Sergei Trofimovich; Manuel Chakravarty; Simon | Peyton Jones | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- | ,citeproc / highlighting-kate | | Dear Devs, | | On 04/10/2014 09:09 AM, ghc-devs-request at haskell.org wrote: | > Filed the reproducer as a new ticket: | > https://ghc.haskell.org/trac/ghc/ticket/8980 | > | > [ Looks like highlighting-kate asks to be added to | > compiler performance benchmarks (are there such ones?) | > It tends to stress ghc all the time: | > http://hackage.haskell.org/trac/ghc/ticket/3664 | > ] | Please consider adding hPDB too, if you want to stress the optimizer. | It shows GHC optimizer at its best, with at least 10-20% improvement in | every major version of | the compiler since 6.12. Unfortunately at cost of very long compile | times. | Please let me know if I should submit a driver code for automatic | benchmarks it (it is in hPDB-examples.) Thanks! | >> > SpecConstr is too aggressive: it sometimes blows up the program | badly and we have no good | solution. See Trac #7898, #7068, #7944, #5550, #8836. | And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy | to reproduce by just `cabal install hPDB`. | >> > I notice that the latter three are actually fixed in 7.8, so worth | trying that. If it | still fails, do add instructions to reproduce to one of the above open | tickets, or make a new one. | >> > | >> > Meanwhile you can use -fno-spec-constr to simply switch it off for | offending modules. That should get you going. | -- | Best regards | Michal From hvr at gnu.org Thu Apr 10 08:55:47 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 10 Apr 2014 10:55:47 +0200 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ Message-ID: <87fvll4l7w.fsf@gmail.com> Hello, I know this has come up various times. So this is mostly an attempt to see what the current position is on this topic: The current scheme is documented as ,---- | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the | integer xyy (if y is a single digit, then a leading zero is added, so | for example in version 6.8.2 of GHC we would have | __GLASGOW_HASKELL__==608). `---- This has lead to confusion in the past, e.g. the following two values __GLASGOW_HASKELL__ == 702 __GLASGOW_HASKELL__ == 704 were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 respectively. And sometimes when writing conditionals, it also happened that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. Moreover, when GHC 7.2.2 came out, it would have been useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some SafeHaskell properties changed between 7.2.1 and 7.2.2. Therefore, I'd propose to extend this constant by a patch-level digit for future GHC versions (starting with 7.10.1), i.e. __GLASGOW_HASKELL__ == 7090 -- 7.9 branch __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates __GLASGOW_HASKELL__ == 7101 -- 7.10.1 __GLASGOW_HASKELL__ == 7102 -- 7.10.2 __GLASGOW_HASKELL__ == 7121 -- 7.12.2 NB: this ensures that __GLASGOW_HASKELL__ retains its ordering relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing code using conditionals such as #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) for currently existing GHC versions will continue to work as expected. Alternative ideas: - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the patch-level number. (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) This one might have the least impact, as its existence can be ignored safely, and we could even use this starting with GHC 7.8.2 with low risk of affecting users. - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of Cabal's MIN_VERSION_() macros While this has the most structure, this has also the issue of backward compatibility, as for earlier GHC versions you'd have to check for the existence of the macro before using it to avoid compile-time errors. Cheers, hvr From johan.tibell at gmail.com Thu Apr 10 09:57:47 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 10 Apr 2014 11:57:47 +0200 Subject: GHC's performance In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: There are a few "projects" in this area I think we should undertake: ## Set up a performance dashboard Example: http://goperfd.appspot.com/ (try clicking the "Perf" and "Graphs" buttons.) I think the way to go here is: * Figure out how to build GHC and run the nofib suite in a repeatable (i.e. scripted) manner. * Set up a Jenkins build bot on a "quiet" machine. Have it run the above script in "exclusive" mode (i.e. no other Jenkins jobs can run in parallel). * Write a script that gathers the nofib output and sticks it in a database. The database should be keyed by the commit hash. Use a mature DB (e.g. MySQL, sqlite, postgress). * Write a little web frontend that graphs the results over time. Don't reinvent the wheel/shave all the Yaks. You might be able to reuse the Go frontend and run it on appengine. * Bonus points: have the jenkins job send an email if performance regresses above some threshold. There might already exist Jenkins plugins that can help with the last 4 steps. ## Improve our benchmarks Many of the benchmarks in nofib have too short runtime nowadays to be accurate enough when comparing the performance of two GHC builds. The shootout benchmarks are good (I've checked), but the remaining ones should be considered suspicious. We ought to weed out or improve benchmarks that are no longer accurate. This might involve having the run on bigger inputs and thus run for longer. In addition, running the existing benchmark suites of some core libraries (e.g. from the HP) would also be very useful. The difficulty is to get Criterion to build with HEAD reliably. ## One-off nofib run against the lastest N major GHC releases To see if we have already regressed (and see where we have regressed) I think we should just run the current nofib suite (probably using the "slow" mode) against 6.12 and up to see where we have already regressed. File a bug for each regression, optionally with a small analysis of why we regressed (e.g. look at the Core and the output of +RTS -s). Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Apr 10 11:18:11 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 10 Apr 2014 14:18:11 +0300 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: <87fvll4l7w.fsf@gmail.com> References: <87fvll4l7w.fsf@gmail.com> Message-ID: <20140410111811.GA25090@sniper> I've never needed this so far, but if this gets implemented, I'm in favour of a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro. As you say, the existing scheme is somewhat non-intuitive. But having two schemes simultaneously carries an even bigger mental overhead. And it's too easy to forget that the scheme has changed when testing for newer ghc versions. Roman * Herbert Valerio Riedel [2014-04-10 10:55:47+0200] > Hello, > > I know this has come up various times. So this is mostly an attempt to > see what the current position is on this topic: > > The current scheme is documented as > > ,---- > | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the > | integer xyy (if y is a single digit, then a leading zero is added, so > | for example in version 6.8.2 of GHC we would have > | __GLASGOW_HASKELL__==608). > `---- > > This has lead to confusion in the past, e.g. the following two values > > __GLASGOW_HASKELL__ == 702 > > __GLASGOW_HASKELL__ == 704 > > were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 > respectively. And sometimes when writing conditionals, it also happened > that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. > > Moreover, when GHC 7.2.2 came out, it would have been > useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some > SafeHaskell properties changed between 7.2.1 and 7.2.2. > > Therefore, I'd propose to extend this constant by a patch-level digit > for future GHC versions (starting with 7.10.1), i.e. > > __GLASGOW_HASKELL__ == 7090 -- 7.9 branch > > __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates > __GLASGOW_HASKELL__ == 7101 -- 7.10.1 > __GLASGOW_HASKELL__ == 7102 -- 7.10.2 > > __GLASGOW_HASKELL__ == 7121 -- 7.12.2 > > NB: this ensures that __GLASGOW_HASKELL__ retains its ordering > relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing > code using conditionals such as > > #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) > > for currently existing GHC versions will continue to work as expected. > > Alternative ideas: > > - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the > patch-level number. > > (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) > > This one might have the least impact, as its existence can be ignored > safely, and we could even use this starting with GHC 7.8.2 with low > risk of affecting users. > > - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of > Cabal's MIN_VERSION_() macros > > While this has the most structure, this has also the issue of > backward compatibility, as for earlier GHC versions you'd have to > check for the existence of the macro before using it to avoid > compile-time errors. > > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From lukexipd at gmail.com Thu Apr 10 12:04:05 2014 From: lukexipd at gmail.com (Luke Iannini) Date: Thu, 10 Apr 2014 05:04:05 -0700 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53450A96.50209@centrum.cz> Message-ID: Hi Austin/all, Here's GHC iOS 7.8.1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1-device/ghc-7.8.1-arm-apple-ios.tar.bz2 (sha 4b98f55212b33296ed9d59d7e30eaa12d7a34a3b) https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1/ghc-7.8.1-i386-apple-ios.tar.bz2 (sha bcd213b4da15f77aaa4b1b06c51867785f262002) and README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers Luke On Wed, Apr 9, 2014 at 6:09 PM, Austin Seipp wrote: > Jens, > > It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which > was merged post RC2. I base this on the fact your build is failing > during the dynamic build. Do try a reverse patch and see if it helps. > > I believe Karel is right - you just need to use Gold. Ben actually had > patches to make the build fail if using binutils ld was detected, but > I believe I had reservations about the patch which I cannot recall off > the top of my head. In any case, a fix like that can certainly go in > 7.8.2. > > Do let us know how it goes. > > [1] > https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 > > On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen > wrote: > > On 9 April 2014 17:53, Karel Gardas wrote: > >> > >> Ben Gamari (cced) documented it well here: > >> http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html > >> > >> Looks like the issue is caused by binutils' linker while fixed in gold. > > > > > > Thanks a lot, Karel! I will try Ben's hack later. > > > > I am still surprised that RC2 builds fine on ARM (I re-verified that > > yesterday [1]) but not final 7.8.1. > > Were there some late ARM or linking changes that cause this now? > > > >> On 04/ 9/14 10:21 AM, Jens Petersen wrote: > >>> > >>> dll-split: internal error: evacuate(static): strange closure type 0 > >> > >> > >>> > >>> See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for > > > > > >>> > >>> I reproduced this two times now. RC2 built okay on ARM so I am not > >>> sure what changed. > > > > > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Apr 10 12:28:03 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 07:28:03 -0500 Subject: Breaking bug in 7.8.1 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This seems good to me. I'll go ahead and prep the tree then and get some things ready. To everyone: I'm going to carefully review the outstanding patches etc besides #8979, but I'm not inclined to take very many - if any - besides this one. So if you missed the 7.8.1 train, but you *really* want something in 7.8.2, please talk to me soon... On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones wrote: > Austin, Simon (and others) > > As you?ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded > in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it > seems to matter. (Because of the windows seg-fault saga, RC2 was active for > a long time, and none of our regression tests showed up this bug.) > > It looks to me that we have little choice but to push out 7.8.2, more or > less immediately, and advise everyone to ignore 7.8.1. Do you agree? > > Sorry about this. > > Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 10 12:53:02 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 07:53:02 -0500 Subject: 7.8.2 bugs and beyond In-Reply-To: References: Message-ID: Hello all, Misfortune has struck unfortunately - we shipped with a bit of an awful bug in 7.8.1, see #8978. The good news is Simon already has a fix! Yay! However, I'll probably be going ahead and releasing an immediate today. For everyone, I don't think this changes much regarding my last email - just substitute '7.8.2' with '7.8.3' where you might see it. Here's the list of 7.8.3 bugs for reference, I migrated the old 7.8.2 tickets here: https://ghc.haskell.org/trac/ghc/query?milestone=7.8.3&group=status Thanks! On Wed, Apr 9, 2014 at 7:34 PM, Austin Seipp wrote: > Hello all, > > 7.8.1 is out. Yay! Now, on to the next thing. > > Here's the very preliminary 7.8.2 buglist: > > - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 > > Note that this list has effectively received zero curation so far. I > plan on fixing that soon, and in the process I am probably going to > touch a lot of trac tickets (so I apologize in advance for the mail > spam, because y'all are probably going to get a lot of it). This will > include re-prioritizing these bugs, so take things with a grain of > salt right now. > > Note that the bug tracker now has 7.8.1 as the default version - if > you're filing bugs, please be sure to try it first of course. :) And > don't forget to set the milestone to 7.8.2 if you think it qualifies > for a fix. There are already a couple of things in the merge queue. > > There's currently no expected date for 7.8.2. Should it arrive > quickly? Or slowly? Simon, Simon and I are inclined to just let things > play out for a while of course, which is the traditional way things > are done. But this release window has been especially awkward, so > we'll see what happens. > > This of course leaves timeline questions for 7.10 open - but before we > decide that, now's a time to just get some hacking done I suppose... > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 10 12:54:06 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 07:54:06 -0500 Subject: Breaking bug in 7.8.1 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This fix is now merged in the 7.8 branch and is ready to go. Unless someone speaks soon, I'm going to go ahead and start the builds... On Thu, Apr 10, 2014 at 7:28 AM, Austin Seipp wrote: > This seems good to me. I'll go ahead and prep the tree then and get > some things ready. > > To everyone: I'm going to carefully review the outstanding patches etc > besides #8979, but I'm not inclined to take very many - if any - > besides this one. So if you missed the 7.8.1 train, but you *really* > want something in 7.8.2, please talk to me soon... > > On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones > wrote: >> Austin, Simon (and others) >> >> As you?ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded >> in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it >> seems to matter. (Because of the windows seg-fault saga, RC2 was active for >> a long time, and none of our regression tests showed up this bug.) >> >> It looks to me that we have little choice but to push out 7.8.2, more or >> less immediately, and advise everyone to ignore 7.8.1. Do you agree? >> >> Sorry about this. >> >> Simon > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 10 13:42:01 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 08:42:01 -0500 Subject: Breaking bug in 7.8.1 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm now building the source distribution and sanity checking it before I push the tags. Stay tuned. On Thu, Apr 10, 2014 at 7:54 AM, Austin Seipp wrote: > This fix is now merged in the 7.8 branch and is ready to go. Unless > someone speaks soon, I'm going to go ahead and start the builds... > > On Thu, Apr 10, 2014 at 7:28 AM, Austin Seipp wrote: >> This seems good to me. I'll go ahead and prep the tree then and get >> some things ready. >> >> To everyone: I'm going to carefully review the outstanding patches etc >> besides #8979, but I'm not inclined to take very many - if any - >> besides this one. So if you missed the 7.8.1 train, but you *really* >> want something in 7.8.2, please talk to me soon... >> >> On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones >> wrote: >>> Austin, Simon (and others) >>> >>> As you?ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded >>> in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it >>> seems to matter. (Because of the windows seg-fault saga, RC2 was active for >>> a long time, and none of our regression tests showed up this bug.) >>> >>> It looks to me that we have little choice but to push out 7.8.2, more or >>> less immediately, and advise everyone to ignore 7.8.1. Do you agree? >>> >>> Sorry about this. >>> >>> Simon >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 10 13:55:12 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 08:55:12 -0500 Subject: Website repository Message-ID: Hello all, While making the release the other day, one thing I found odd is that the GHC website is still under Darcs version control on the website. I'm not sure how many people are generally aware of this, however, but you should just be able to darcs get http://haskell.org/ghc I'm wondering if we should move this somewhere else more public. I've wanted someone to perhaps look into updating the website to something a little more modern an easier to update for a while now.* Right now it's just a bunch of SHTML pages stamped together, and it could probably be a lot easier to maintain. I don't necessarily propose we put it in the GHC repository (the LLVM folks do this, but I think it would make actually *updating* the website somewhat confusing), just somewhere more public. Does anyone have any inputs? My first inclination is to just put it on git.haskell.org, but perhaps the github.com/haskell organization is a better place (a bit more public). Just wondering if anyone has thoughts. * If someone out there is interested in doing this that would be excellent, by the way, and I'm sure everyone would appreciate it :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Thu Apr 10 13:56:55 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 10 Apr 2014 15:56:55 +0200 Subject: Website repository In-Reply-To: References: Message-ID: On Thu, Apr 10, 2014 at 3:55 PM, Austin Seipp wrote: > I don't necessarily propose we put it in the GHC repository (the LLVM > folks do this, but I think it would make actually *updating* the > website somewhat confusing), just somewhere more public. Does anyone > have any inputs? My first inclination is to just put it on > git.haskell.org, but perhaps the github.com/haskell organization is a > better place (a bit more public). > I say put it on git.haskell.org and have our GitHub mirroring mirror it to github.com/ghc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Apr 10 13:57:26 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 08:57:26 -0500 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: <20140410111811.GA25090@sniper> References: <87fvll4l7w.fsf@gmail.com> <20140410111811.GA25090@sniper> Message-ID: I agree with Roman. I think just adding a new PATCHLEVEL macro is the way to go and complementary to the existing setup, without confusing things. On Thu, Apr 10, 2014 at 6:18 AM, Roman Cheplyaka wrote: > I've never needed this so far, but if this gets implemented, I'm in favour of > a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro. > > As you say, the existing scheme is somewhat non-intuitive. But having two > schemes simultaneously carries an even bigger mental overhead. > And it's too easy to forget that the scheme has changed when testing for newer > ghc versions. > > Roman > > * Herbert Valerio Riedel [2014-04-10 10:55:47+0200] >> Hello, >> >> I know this has come up various times. So this is mostly an attempt to >> see what the current position is on this topic: >> >> The current scheme is documented as >> >> ,---- >> | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the >> | integer xyy (if y is a single digit, then a leading zero is added, so >> | for example in version 6.8.2 of GHC we would have >> | __GLASGOW_HASKELL__==608). >> `---- >> >> This has lead to confusion in the past, e.g. the following two values >> >> __GLASGOW_HASKELL__ == 702 >> >> __GLASGOW_HASKELL__ == 704 >> >> were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 >> respectively. And sometimes when writing conditionals, it also happened >> that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. >> >> Moreover, when GHC 7.2.2 came out, it would have been >> useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some >> SafeHaskell properties changed between 7.2.1 and 7.2.2. >> >> Therefore, I'd propose to extend this constant by a patch-level digit >> for future GHC versions (starting with 7.10.1), i.e. >> >> __GLASGOW_HASKELL__ == 7090 -- 7.9 branch >> >> __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates >> __GLASGOW_HASKELL__ == 7101 -- 7.10.1 >> __GLASGOW_HASKELL__ == 7102 -- 7.10.2 >> >> __GLASGOW_HASKELL__ == 7121 -- 7.12.2 >> >> NB: this ensures that __GLASGOW_HASKELL__ retains its ordering >> relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing >> code using conditionals such as >> >> #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) >> >> for currently existing GHC versions will continue to work as expected. >> >> Alternative ideas: >> >> - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the >> patch-level number. >> >> (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) >> >> This one might have the least impact, as its existence can be ignored >> safely, and we could even use this starting with GHC 7.8.2 with low >> risk of affecting users. >> >> - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of >> Cabal's MIN_VERSION_() macros >> >> While this has the most structure, this has also the issue of >> backward compatibility, as for earlier GHC versions you'd have to >> check for the existence of the macro before using it to avoid >> compile-time errors. >> >> >> Cheers, >> hvr >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 10 14:00:13 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 10 Apr 2014 09:00:13 -0500 Subject: Website repository In-Reply-To: References: Message-ID: I thought that too, but the reason I suggest GitHub is because it might make people more inclined to submit patches. I still hear people who want the GitHub mirrors to allow pull requests, but I think moving it to the haskell organization would be easier and allow that anyway in the short term without mirror complications.* * Note I'm not interested in having the debate about allowing PRs on GitHub mirrors right now - it's just a recommendation as a result of that. On Thu, Apr 10, 2014 at 8:56 AM, Johan Tibell wrote: > On Thu, Apr 10, 2014 at 3:55 PM, Austin Seipp wrote: >> >> I don't necessarily propose we put it in the GHC repository (the LLVM >> folks do this, but I think it would make actually *updating* the >> website somewhat confusing), just somewhere more public. Does anyone >> have any inputs? My first inclination is to just put it on >> git.haskell.org, but perhaps the github.com/haskell organization is a >> better place (a bit more public). > > > I say put it on git.haskell.org and have our GitHub mirroring mirror it to > github.com/ghc/ > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Thu Apr 10 14:03:53 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 10 Apr 2014 16:03:53 +0200 Subject: Website repository In-Reply-To: References: Message-ID: On Thu, Apr 10, 2014 at 4:00 PM, Austin Seipp wrote: > I thought that too, but the reason I suggest GitHub is because it > might make people more inclined to submit patches. I still hear people > who want the GitHub mirrors to allow pull requests, but I think moving > it to the haskell organization would be easier and allow that anyway > in the short term without mirror complications.* > > * Note I'm not interested in having the debate about allowing PRs on > GitHub mirrors right now - it's just a recommendation as a result of > that. I'm fine with that too, although if this is really just the /ghc section of haskell.org, we could also put it under github.com/ghc/website (not as a mirror). If you want to use the haskell GitHub org, I can give you access. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Apr 10 15:43:29 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 10 Apr 2014 11:43:29 -0400 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: References: <532062AB.50108@cs.kuleuven.be> Message-ID: Yay! I have nothing else constructive to say, at the moment. What's the next step from your point of view? Are there unimplemented bits of this? Thanks for doing this! Richard On Apr 10, 2014, at 3:48 AM, Thomas Winant wrote: > Hi, > > I'm back with a status update. We implemented Austin's suggestion to > make wildcards in partial type signatures behave like holes. > > Let's demonstrate the new behaviour with an example. The example > program: > >> module Example where >> foo :: (Show _a, _) => _a -> _ >> foo x = show (succ x) > > Compiled with GHC master gives: > >> Example.hs:3:18: parse error on input ?_? > > When we compile it with our branch: > >> Example.hs:3:18: >> Instantiated extra-constraints wildcard ?_? to: >> (Enum _a) >> in the type signature for foo :: (Show _a, _) => _a -> _ >> at Example.hs:3:8-30 >> The complete inferred type is: >> foo :: forall _a. (Show _a, Enum _a) => _a -> String >> To use the inferred type, enable PartialTypeSignatures >> Example.hs:3:30: >> Instantiated wildcard ?_? to: String >> in the type signature for foo :: (Show _a, _) => _a -> _ >> at Example.hs:3:8-30 >> The complete inferred type is: >> foo :: forall _a. (Show _a, Enum _a) => _a -> String >> To use the inferred type, enable PartialTypeSignatures > > Now the types the wildcards were instantiated to are reported. Note that > `_a` is still treated as a type variable, as prescribed in Haskell 2010. > To treat it as a /named wildcard/, we pass the -XNamedWildcards flag and > get: > >> [..] >> Example.hs:3:24: >> Instantiated wildcard ?_a? to: tw_a >> in the type signature for foo :: (Show _a, _) => _a -> _ >> at Example.hs:3:8-30 >> The complete inferred type is: >> foo :: forall tw_a. (Show tw_a, Enum tw_a) => tw_a -> String >> To use the inferred type, enable PartialTypeSignatures >> [..] > > An extra error message appears, reporting that `_a` was instantiated to > a new type variable (`tw_a`). > > Finally, when passed the -XPartialTypeSignatures flag, the typechecker > will just use the inferred types for the wildcards and compile the > program without generating any error messages. > > We added this example and a section about the monomorphism restriction > to the wiki page [1]. > > Comments and feedback are still welcome. > > Cheers, > Thomas Winant > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures > > > > > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From ezyang at mit.edu Thu Apr 10 06:17:53 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 09 Apr 2014 23:17:53 -0700 Subject: Trac seems to think I'm a spambot...? In-Reply-To: References: Message-ID: <1397110531-sup-1739@sabre> Did the spamchecker get turned off? I just deleted a ticket (#8982; check your mail archives) which should have been caught by essentially any spamchecker worth its salt. Also, do we have any facilities for permanently banning spammers? Excerpts from Kyle Van Berendonck's message of 2014-04-07 02:43:23 -0700: > Hmm. > > I just got flagged as a spambot trying to reply to a ticket too. It did > give me a captcha option though. From ekmett at gmail.com Thu Apr 10 22:33:23 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 10 Apr 2014 18:33:23 -0400 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: References: <87fvll4l7w.fsf@gmail.com> <20140410111811.GA25090@sniper> Message-ID: +1 on the PATCHLEVEL variant. (for that matter, +1 on the other if it is all I can get!) I've wanted something like this for a long time. -Edward On Thu, Apr 10, 2014 at 9:57 AM, Austin Seipp wrote: > I agree with Roman. I think just adding a new PATCHLEVEL macro is the > way to go and complementary to the existing setup, without confusing > things. > > On Thu, Apr 10, 2014 at 6:18 AM, Roman Cheplyaka wrote: > > I've never needed this so far, but if this gets implemented, I'm in > favour of > > a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro. > > > > As you say, the existing scheme is somewhat non-intuitive. But having two > > schemes simultaneously carries an even bigger mental overhead. > > And it's too easy to forget that the scheme has changed when testing for > newer > > ghc versions. > > > > Roman > > > > * Herbert Valerio Riedel [2014-04-10 10:55:47+0200] > >> Hello, > >> > >> I know this has come up various times. So this is mostly an attempt to > >> see what the current position is on this topic: > >> > >> The current scheme is documented as > >> > >> ,---- > >> | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the > >> | integer xyy (if y is a single digit, then a leading zero is added, so > >> | for example in version 6.8.2 of GHC we would have > >> | __GLASGOW_HASKELL__==608). > >> `---- > >> > >> This has lead to confusion in the past, e.g. the following two values > >> > >> __GLASGOW_HASKELL__ == 702 > >> > >> __GLASGOW_HASKELL__ == 704 > >> > >> were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 > >> respectively. And sometimes when writing conditionals, it also happened > >> that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. > >> > >> Moreover, when GHC 7.2.2 came out, it would have been > >> useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some > >> SafeHaskell properties changed between 7.2.1 and 7.2.2. > >> > >> Therefore, I'd propose to extend this constant by a patch-level digit > >> for future GHC versions (starting with 7.10.1), i.e. > >> > >> __GLASGOW_HASKELL__ == 7090 -- 7.9 branch > >> > >> __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates > >> __GLASGOW_HASKELL__ == 7101 -- 7.10.1 > >> __GLASGOW_HASKELL__ == 7102 -- 7.10.2 > >> > >> __GLASGOW_HASKELL__ == 7121 -- 7.12.2 > >> > >> NB: this ensures that __GLASGOW_HASKELL__ retains its ordering > >> relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing > >> code using conditionals such as > >> > >> #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) > >> > >> for currently existing GHC versions will continue to work as expected. > >> > >> Alternative ideas: > >> > >> - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the > >> patch-level number. > >> > >> (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) > >> > >> This one might have the least impact, as its existence can be ignored > >> safely, and we could even use this starting with GHC 7.8.2 with low > >> risk of affecting users. > >> > >> - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of > >> Cabal's MIN_VERSION_() macros > >> > >> While this has the most structure, this has also the issue of > >> backward compatibility, as for earlier GHC versions you'd have to > >> check for the existence of the macro before using it to avoid > >> compile-time errors. > >> > >> > >> Cheers, > >> hvr > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Apr 10 22:39:49 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 10 Apr 2014 15:39:49 -0700 Subject: Validate failures (perf, ghc-7.8) Message-ID: <1397169467-sup-3632@sabre> I've got perf failures on Linux 64-bit on ghc-7.8 (and master too, I think). Please take a look. Unexpected results from: TEST="T4801 T3064 T5837 T6048" OVERALL SUMMARY for test run started at Thu Apr 10 15:33:27 2014 PDT 0:02:52 spent to go through 3920 total tests, which gave rise to 12853 test cases, of which 9274 were skipped 26 had missing libraries 3491 expected passes 58 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) From carter.schonwald at gmail.com Thu Apr 10 22:44:08 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 10 Apr 2014 18:44:08 -0400 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: References: <87fvll4l7w.fsf@gmail.com> <20140410111811.GA25090@sniper> Message-ID: +1 ! On Thu, Apr 10, 2014 at 6:33 PM, Edward Kmett wrote: > +1 on the PATCHLEVEL variant. (for that matter, +1 on the other if it is > all I can get!) > > I've wanted something like this for a long time. > > -Edward > > > On Thu, Apr 10, 2014 at 9:57 AM, Austin Seipp wrote: > >> I agree with Roman. I think just adding a new PATCHLEVEL macro is the >> way to go and complementary to the existing setup, without confusing >> things. >> >> On Thu, Apr 10, 2014 at 6:18 AM, Roman Cheplyaka >> wrote: >> > I've never needed this so far, but if this gets implemented, I'm in >> favour of >> > a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro. >> > >> > As you say, the existing scheme is somewhat non-intuitive. But having >> two >> > schemes simultaneously carries an even bigger mental overhead. >> > And it's too easy to forget that the scheme has changed when testing >> for newer >> > ghc versions. >> > >> > Roman >> > >> > * Herbert Valerio Riedel [2014-04-10 10:55:47+0200] >> >> Hello, >> >> >> >> I know this has come up various times. So this is mostly an attempt to >> >> see what the current position is on this topic: >> >> >> >> The current scheme is documented as >> >> >> >> ,---- >> >> | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the >> >> | integer xyy (if y is a single digit, then a leading zero is added, so >> >> | for example in version 6.8.2 of GHC we would have >> >> | __GLASGOW_HASKELL__==608). >> >> `---- >> >> >> >> This has lead to confusion in the past, e.g. the following two values >> >> >> >> __GLASGOW_HASKELL__ == 702 >> >> >> >> __GLASGOW_HASKELL__ == 704 >> >> >> >> were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 >> >> respectively. And sometimes when writing conditionals, it also happened >> >> that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. >> >> >> >> Moreover, when GHC 7.2.2 came out, it would have been >> >> useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some >> >> SafeHaskell properties changed between 7.2.1 and 7.2.2. >> >> >> >> Therefore, I'd propose to extend this constant by a patch-level digit >> >> for future GHC versions (starting with 7.10.1), i.e. >> >> >> >> __GLASGOW_HASKELL__ == 7090 -- 7.9 branch >> >> >> >> __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates >> >> __GLASGOW_HASKELL__ == 7101 -- 7.10.1 >> >> __GLASGOW_HASKELL__ == 7102 -- 7.10.2 >> >> >> >> __GLASGOW_HASKELL__ == 7121 -- 7.12.2 >> >> >> >> NB: this ensures that __GLASGOW_HASKELL__ retains its ordering >> >> relation. There's just a steeper jump from 7.8.1 to 7.10.1, but >> existing >> >> code using conditionals such as >> >> >> >> #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) >> >> >> >> for currently existing GHC versions will continue to work as expected. >> >> >> >> Alternative ideas: >> >> >> >> - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the >> >> patch-level number. >> >> >> >> (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) >> >> >> >> This one might have the least impact, as its existence can be >> ignored >> >> safely, and we could even use this starting with GHC 7.8.2 with low >> >> risk of affecting users. >> >> >> >> - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of >> >> Cabal's MIN_VERSION_() macros >> >> >> >> While this has the most structure, this has also the issue of >> >> backward compatibility, as for earlier GHC versions you'd have to >> >> check for the existence of the macro before using it to avoid >> >> compile-time errors. >> >> >> >> >> >> Cheers, >> >> hvr >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Thu Apr 10 23:45:31 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 10 Apr 2014 23:45:31 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <53464EDC.3080500@centrum.cz> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <91B817A3-3AE7-44AE-B52E-D38B66353AB3@gmail.com> <53445977.6000505@centrum.cz> <5344A545.8090906@gmail.com> <53450690.3000901@centrum.cz> <5A2B6C7F-0F01-40C7-844A-13FC93AF7645@gmail.com> <5345EB5B.5050505@gmail.com> <53464EDC.3080500@centrum.cz> Message-ID: <53472D1B.9000205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu 10 Apr 2014 07:57:16 AM UTC, Karel Gardas wrote: > On 04/10/14 02:52 AM, Alain O'Dea wrote: >>>> hmm, that's after GHC own platform processing is done, but what >>>> does >>>> >>>> sh config.guess >>>> >>>> tells you? E.g. on my two Solaris 11 I get: >>>> >>>> $ sh config.guess i386-pc-solaris2.11 >>>> >>>> $ sh config.guess sparc-sun-solaris2.11 >> >> Karel, I think I finally have what you were looking for: >> >> x86_64-pc-solaris2.11 >> i386-pc-solaris2.11 > > Great, so this means SmartOS is just another member of Solaris family. > I've installed it and verified that `ld' and `nm' are really what we > expect on real Solaris. Them's fightin' words ;) There are hard feelings (with good reason) between Illumos and Solaris. Oracle betrayed the OpenSolaris community and particularly their Open Source contributors when they closed Solaris. It was a very unethical thing to do. Bryan Cantrill spoke well on the reasons for and nature of the Illumos fork at LISA11: http://smartos.org/2011/12/15/fork-yeah-the-rise-and-development-of-illumos-2/ I am very happy that they remain binary compatible. I can immediately use Solaris 10 binaries on Illumos and in many cases Solaris 10 and 11 can run Illumos binaries. > In fact thanks for your advice I've been able > to use its packaged GHC on my Solaris 11 to compile some code and even > attempted the bootstrap of HEAD for Solaris/AMD64 platform. There are > some outstanding issues with bootstrap so this needs to wait till my > weekend ghc hobby time...(if someone does not solved it faster of > course...) > > Thanks! > Karel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRy0bAAoJEP0rIXJNjNSA4oUH/irlhd1xztoUA1yTDB/y5eDs jygqjp5cymU9jELfMGTJqTzuIyw/whvpDcqmiPqEaDrWdTgCUIHraZrxk0UTT/BF w6jtY1dBCqECUkQhT5Pdr/T/GtnRxVItiMGxn6fJ8c4yWb0HDcMFmXmCkyrwQQi6 ZwiLqpWu8P1zAHplbaOeEihusRaKtllOEm07eIajZdYcyjCoszgQrZyORaBVllkh Czwyk9WCkkh9u9GWhYZu7p1p8Z7ToJ/lrv/VgGWxbaCZcS1q+j4a7Z9r41L6HJ8v mgpEqBNtKgVZ1cRzVN8sapinXWt6PoNR38dHHUEGeW76z9TrqD5pPvOab9ROfGc= =5KpS -----END PGP SIGNATURE----- From petersen at fedoraproject.org Fri Apr 11 00:36:51 2014 From: petersen at fedoraproject.org (Jens Petersen) Date: Fri, 11 Apr 2014 09:36:51 +0900 Subject: 7.8.1 plan In-Reply-To: References: <53311BD4.3030008@mail.ru> <533DAACF.3050801@fuuzetsu.co.uk> <53450A96.50209@centrum.cz> Message-ID: Thanks Austin, On 10 April 2014 10:09, Austin Seipp wrote: > It's probably due to https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631abb86adf7f749b3d44887d28bc96b43c5a1e0631 > which was merged post RC2. I base this on the fact your build is failing > during the dynamic build. Do try a reverse patch and see if it helps. > Yes, that fixed the build with the standard bfd linker (http://koji.fedoraproject.org/koji/taskinfo?taskID=6722847). It seems to pass the dyn helloworld test at least. I believe Karel is right - you just need to use Gold. Ben actually had > patches to make the build fail if using binutils ld was detected, but > I believe I had reservations about the patch which I cannot recall off > the top of my head. In any case, a fix like that can certainly go in > 7.8.2. > If it doesn't then I think I can "bootstrap" to 7.8 with ld.bfd and then rebuild with ld.gold so hopefully it should work out anyway. Thanks, Jens > >>> dll-split: internal error: evacuate(static): strange closure type 0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Fri Apr 11 08:34:37 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 11 Apr 2014 10:34:37 +0200 Subject: Compiling GHC with Clang In-Reply-To: <87bnwki4ob.fsf@gnu.org> (Herbert Valerio Riedel's message of "Wed, 02 Apr 2014 09:14:28 +0200") References: <87bnwki4ob.fsf@gnu.org> Message-ID: <87zjjstgbm.fsf@gnu.org> On 2014-04-02 at 09:14:28 +0200, Herbert Valerio Riedel wrote: > Hello *, > > I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by > configuring the build with > > CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang > > but then, 'make' runs into [...] Just as follow-up, the problem was due to the 'clang-3.4' package included by Ubuntu Saucy[1] not being a proper 3.4 release but rather a pre-release snapshot of 3.4 which lacked an important fix[2]; After upgrading to Ubuntu Trusty which features proper clang-3.4 package, the problems went away. [1]: http://packages.ubuntu.com/saucy/clang-3.4 [2]: http://permalink.gmane.org/gmane.comp.compilers.clang.scm/76596 From marlowsd at gmail.com Fri Apr 11 08:38:00 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 11 Apr 2014 09:38:00 +0100 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: <87fvll4l7w.fsf@gmail.com> References: <87fvll4l7w.fsf@gmail.com> Message-ID: <5347A9E8.3020302@gmail.com> On 10/04/2014 09:55, Herbert Valerio Riedel wrote: > Hello, > > I know this has come up various times. So this is mostly an attempt to > see what the current position is on this topic: > > The current scheme is documented as > > ,---- > | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the > | integer xyy (if y is a single digit, then a leading zero is added, so > | for example in version 6.8.2 of GHC we would have > | __GLASGOW_HASKELL__==608). > `---- > > This has lead to confusion in the past, e.g. the following two values > > __GLASGOW_HASKELL__ == 702 > > __GLASGOW_HASKELL__ == 704 > > were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 > respectively. And sometimes when writing conditionals, it also happened > that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. > > Moreover, when GHC 7.2.2 came out, it would have been > useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some > SafeHaskell properties changed between 7.2.1 and 7.2.2. We omitted the patchlevel deliberately, because patchlevel releases of GHC are not supposed to change any APIs, so there should be no reason why you would want to distinguish them in the source code. If we changed something in SafeHaskell in a patchlevel release, then that was probably a mistake. We could add a __GLASGOW_HASKELL_PATCHLEVEL__ macro, but I'd like to understand more about why people need this, and whether we should be more careful about what we do in patchlevel releases. Cheers, Simon > > Therefore, I'd propose to extend this constant by a patch-level digit > for future GHC versions (starting with 7.10.1), i.e. > > __GLASGOW_HASKELL__ == 7090 -- 7.9 branch > > __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates > __GLASGOW_HASKELL__ == 7101 -- 7.10.1 > __GLASGOW_HASKELL__ == 7102 -- 7.10.2 > > __GLASGOW_HASKELL__ == 7121 -- 7.12.2 > > NB: this ensures that __GLASGOW_HASKELL__ retains its ordering > relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing > code using conditionals such as > > #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) > > for currently existing GHC versions will continue to work as expected. > > Alternative ideas: > > - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the > patch-level number. > > (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) > > This one might have the least impact, as its existence can be ignored > safely, and we could even use this starting with GHC 7.8.2 with low > risk of affecting users. > > - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of > Cabal's MIN_VERSION_() macros > > While this has the most structure, this has also the issue of > backward compatibility, as for earlier GHC versions you'd have to > check for the existence of the macro before using it to avoid > compile-time errors. > > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Fri Apr 11 08:40:20 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 11 Apr 2014 09:40:20 +0100 Subject: Offering GHC builder build slaves In-Reply-To: <1396945852.2514.17.camel@kirk> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> Message-ID: <5347AA74.2030005@gmail.com> On 08/04/2014 09:30, Joachim Breitner wrote: > we also need a culture of just doing stuff, and less asking for it. Where is the "like" button on this line? +1 Simon From hvriedel at gmail.com Fri Apr 11 08:47:11 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 11 Apr 2014 10:47:11 +0200 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: <5347A9E8.3020302@gmail.com> (Simon Marlow's message of "Fri, 11 Apr 2014 09:38:00 +0100") References: <87fvll4l7w.fsf@gmail.com> <5347A9E8.3020302@gmail.com> Message-ID: <87vbugtfqo.fsf@gmail.com> On 2014-04-11 at 10:38:00 +0200, Simon Marlow wrote: [...] > We could add a __GLASGOW_HASKELL_PATCHLEVEL__ macro, but I'd like to > understand more about why people need this, and whether we should be > more careful about what we do in patchlevel releases. What about the use-case when you want to workaround a compiler bug that existed for GHC==7.6.1 but which was fixed for GHC>=7.6.2 (and thus doesn't need the workaround anymore)? From marlowsd at gmail.com Fri Apr 11 09:28:45 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 11 Apr 2014 10:28:45 +0100 Subject: relocation R_X86_64_32 (Was: GHC HQ on Launchpad) In-Reply-To: <1396947491.2514.21.camel@kirk> References: <1396595015-sup-1148@sabre> <87y4zgql27.fsf@gmail.com> <1396947491.2514.21.camel@kirk> Message-ID: <5347B5CD.8020206@gmail.com> On 08/04/2014 09:58, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 08.04.2014, 10:31 +0200 schrieb Herbert Valerio Riedel: >> Just a reminder, as not everybody may be aware yet: >> >> There's already daily GHC HEAD packages for Debian at >> >> http://deb.haskell.org/ > > thanks for the reminder. I guess I need to set up something that > notifies me of failures... > > Since March 27 weeks, it seems, it is failing: > > [..] > configure: Building in-tree ghc-pwd > /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC > utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value > collect2: error: ld returned 1 exit status > configure: error: Building ghc-pwd failed > make: *** [configure-stamp] Error 1 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > http://deb.haskell.org/dailies/2014-04-07/ghc_7.9.20140407-0.daily_amd64.build > > Any ideas? I?m not an expert on linker issues. What LDFLAGS are being passed to the configure script? This change I made recently forwards LDFLAGS to GHC when building ghc-pwd: https://ghc.haskell.org/trac/ghc/changeset/2aa78106ae8f3c9b71d7b85c2a8a5558c4c35fb4/ghc Cheers, Simon From kyrab at mail.ru Fri Apr 11 09:47:04 2014 From: kyrab at mail.ru (kyra) Date: Fri, 11 Apr 2014 13:47:04 +0400 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 Message-ID: <5347BA18.3040309@mail.ru> Hi, I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to ~/data/Work/ghc-7.8.1-i386. Now I have the following: awson at awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure --prefix=/home/awson/data/ghc-7.8.1-i386 checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory configure: error: cannot determine current directory ghc-pwd is definitely there but it does not start it seems. Perhaps, the system lacks some shared libs or something. There absolutely no problems with 64-bit ghc. Regards, Kyra From karel.gardas at centrum.cz Fri Apr 11 09:57:23 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 11 Apr 2014 11:57:23 +0200 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347BA18.3040309@mail.ru> References: <5347BA18.3040309@mail.ru> Message-ID: <5347BC83.7090807@centrum.cz> On 04/11/14 11:47 AM, kyra wrote: > Hi, > > I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to > ~/data/Work/ghc-7.8.1-i386. > > Now I have the following: > > awson at awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure > --prefix=/home/awson/data/ghc-7.8.1-i386 > checking for path to top of build tree... > utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: > /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: > No such file or directory > configure: error: cannot determine current directory > > ghc-pwd is definitely there but it does not start it seems. Perhaps, the > system lacks some shared libs or something. > > There absolutely no problems with 64-bit ghc. Yes, you get the error like that when you try to execute different ABI or unsuppored ABI binary. Do that with ARM binary on x86 and you will get the same error for example. What you have forgotten is to install i386 libs on your purely amd64 xubuntu probably... Cheers, Karel From marlowsd at gmail.com Fri Apr 11 09:58:02 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 11 Apr 2014 10:58:02 +0100 Subject: GHC's performance In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5347BCAA.8040503@gmail.com> On 10/04/2014 08:58, Simon Peyton Jones wrote: > Friends > > The thread below concerns GHC's performance. I'm writing to ask for your help. > > In developing GHC we always run 'validate', which runs a lot of regression tests. A few of those are performance tests, but because we do so frequently, none of these performance tests run for long, and none depend on other packages. And they tend to test something very specific. > > What we lack is a sustained effort to track > a) The performance of GHC itself > b) The performance of GHC-compiled programs > > At GHC HQ we *aspire* to track this stuff, but in practice we simply don't. Bug-fixing, portability, etc etc always ends up taking priority. > > But it's a pity that we don't. For example, Michal's comment below (that his GHC-compiled program has run 10-20% faster with each release of GHC from 6.12) is fantastic -- but we have no data to back it up, or know whether it's just Michael, or more widely true. I also suspect that sometimes we regress and don't know it. People do report this (e.g. #8971), but it's a bit random. Again, it would be great to have a more systematic way to know. In many cases it might be easy to fix; but we can only fix if we know. > > We have the nofib suite, and we take that very seriously, but it is showing its age, uses no advanced features, and I'm not sure how representative it is any more. > > Johan Tibell and Bryan O'Sullivan agreed to become GHC's Performance Tsars a year or two ago, with a view to focusing on (b) at least, but they are both extremely busy. And I don't think they even attempt to focus on (a). > > So I'm wondering: would anyone like to help here? It would mean > * Soliciting and gathering together some more substantial benchmarks > * Gathering performance numbers > * Yelling quickly if the numbers go bad. > * Investigating why (e.g. no one has seriously profiled GHC itself for > a while, both space and time. I bet there are improvements to be had > there.) > > Maybe it could be part of the new buildbot team's work? Certainly it'd make sense to use the same nightly-build infrastructure. > > Anyway, I'm advertising that there's an un-met need, and I'd love some help. Let me second this. In particular, I think we regress on GHC performance regularly, because the perf tests just aren't a good way to prevent regressions. When we have a +/- 10% window, someone can commit a 9% regression without triggering a perf failure, but the next patch to come along with a 1% regression will be unfairly blamed. Furthermore, by the time we get to the perf tests we're nearly done and just want to push and go home, not go back and profile GHC. Yet the perf tests have an important purpose: the idea is to catch the problem when we have the crucial piece of information: the patch that caused the regression. Someone can try to optimise GHC later, but they have to start from scratch without the information about what caused the regressions. Having an automated system to track GHC performance would help a lot with this, I think. Cheers, Simon > > Thanks > > Simon > > | -----Original Message----- > | From: Michal J. Gajda [mailto:mjgajda at gmail.com] > | Sent: 10 April 2014 07:26 > | To: ghc-devs at haskell.org; Sergei Trofimovich; Manuel Chakravarty; Simon > | Peyton Jones > | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- > | ,citeproc / highlighting-kate > | > | Dear Devs, > | > | On 04/10/2014 09:09 AM, ghc-devs-request at haskell.org wrote: > | > Filed the reproducer as a new ticket: > | > https://ghc.haskell.org/trac/ghc/ticket/8980 > | > > | > [ Looks like highlighting-kate asks to be added to > | > compiler performance benchmarks (are there such ones?) > | > It tends to stress ghc all the time: > | > http://hackage.haskell.org/trac/ghc/ticket/3664 > | > ] > | Please consider adding hPDB too, if you want to stress the optimizer. > | It shows GHC optimizer at its best, with at least 10-20% improvement in > | every major version of > | the compiler since 6.12. Unfortunately at cost of very long compile > | times. > | Please let me know if I should submit a driver code for automatic > | benchmarks it (it is in hPDB-examples.) Thanks! > | >> > SpecConstr is too aggressive: it sometimes blows up the program > | badly and we have no good > | solution. See Trac #7898, #7068, #7944, #5550, #8836. > | And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy > | to reproduce by just `cabal install hPDB`. > | >> > I notice that the latter three are actually fixed in 7.8, so worth > | trying that. If it > | still fails, do add instructions to reproduce to one of the above open > | tickets, or make a new one. > | >> > > | >> > Meanwhile you can use -fno-spec-constr to simply switch it off for > | offending modules. That should get you going. > | -- > | Best regards > | Michal > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From christiaan.baaij at gmail.com Fri Apr 11 10:00:38 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 11 Apr 2014 12:00:38 +0200 Subject: Breaking bug in 7.8.1 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF151BCB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <6F78F35A-2CBC-474A-ADFC-2B413CC17994@gmail.com> It seems kinda to late to mention? but the release notes don't say that pattern splices are now supported in Template Haskell. A "big" new feature for Template Haskell I would say, and worthy of mentioning in the release notes. But perhaps for 7.8.3? -- Christiaan On Apr 10, 2014, at 3:42 PM, Austin Seipp wrote: > I'm now building the source distribution and sanity checking it before > I push the tags. Stay tuned. > > On Thu, Apr 10, 2014 at 7:54 AM, Austin Seipp wrote: >> This fix is now merged in the 7.8 branch and is ready to go. Unless >> someone speaks soon, I'm going to go ahead and start the builds... >> >> On Thu, Apr 10, 2014 at 7:28 AM, Austin Seipp wrote: >>> This seems good to me. I'll go ahead and prep the tree then and get >>> some things ready. >>> >>> To everyone: I'm going to carefully review the outstanding patches etc >>> besides #8979, but I'm not inclined to take very many - if any - >>> besides this one. So if you missed the 7.8.1 train, but you *really* >>> want something in 7.8.2, please talk to me soon... >>> >>> On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones >>> wrote: >>>> Austin, Simon (and others) >>>> >>>> As you?ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded >>>> in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it >>>> seems to matter. (Because of the windows seg-fault saga, RC2 was active for >>>> a long time, and none of our regression tests showed up this bug.) >>>> >>>> It looks to me that we have little choice but to push out 7.8.2, more or >>>> less immediately, and advise everyone to ignore 7.8.1. Do you agree? >>>> >>>> Sorry about this. >>>> >>>> Simon >>> >>> >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From kyrab at mail.ru Fri Apr 11 10:33:15 2014 From: kyrab at mail.ru (kyra) Date: Fri, 11 Apr 2014 14:33:15 +0400 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347BC83.7090807@centrum.cz> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> Message-ID: <5347C4EB.2020209@mail.ru> Yup, I've already guessed this. More specifically: which :i386 packages should I install to make it work? Regards, Kyra On 4/11/2014 13:57, Karel Gardas wrote: > On 04/11/14 11:47 AM, kyra wrote: >> Hi, >> >> I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to >> ~/data/Work/ghc-7.8.1-i386. >> >> Now I have the following: >> >> awson at awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure >> --prefix=/home/awson/data/ghc-7.8.1-i386 >> checking for path to top of build tree... >> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: >> /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: >> >> No such file or directory >> configure: error: cannot determine current directory >> >> ghc-pwd is definitely there but it does not start it seems. Perhaps, the >> system lacks some shared libs or something. >> > ... > What you have forgotten is to install i386 libs on your purely amd64 > xubuntu probably... > > Cheers, > Karel > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From alain.odea at gmail.com Fri Apr 11 10:43:19 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 11 Apr 2014 10:43:19 +0000 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347C4EB.2020209@mail.ru> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> <5347C4EB.2020209@mail.ru> Message-ID: <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> install ia32-libs: http://askubuntu.com/a/297155 YMMV. You are much better off using 64-bit software on 64-bit Ubuntu. > On Apr 11, 2014, at 10:33, kyra wrote: > > Yup, I've already guessed this. More specifically: which :i386 packages should I install to make it work? > > Regards, > Kyra > >> On 4/11/2014 13:57, Karel Gardas wrote: >>> On 04/11/14 11:47 AM, kyra wrote: >>> Hi, >>> >>> I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to >>> ~/data/Work/ghc-7.8.1-i386. >>> >>> Now I have the following: >>> >>> awson at awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure >>> --prefix=/home/awson/data/ghc-7.8.1-i386 >>> checking for path to top of build tree... >>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: >>> /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: >>> No such file or directory >>> configure: error: cannot determine current directory >>> >>> ghc-pwd is definitely there but it does not start it seems. Perhaps, the >>> system lacks some shared libs or something. >> ... >> What you have forgotten is to install i386 libs on your purely amd64 xubuntu probably... >> >> Cheers, >> Karel >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Fri Apr 11 10:55:13 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 11 Apr 2014 11:55:13 +0100 Subject: GHC's performance In-Reply-To: <5347BCAA.8040503@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> <5347BCAA.8040503@gmail.com> Message-ID: On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow wrote: > Let me second this. In particular, I think we regress on GHC performance > regularly, because the perf tests just aren't a good way to prevent > regressions. When we have a +/- 10% window, someone can commit a 9% > regression without triggering a perf failure, but the next patch to come > along with a 1% regression will be unfairly blamed. > Agreed. I think graphing results helps here. It's often easier to visualize identify which commit is the real culprit. Aside: I think moving completely to subrepos will generally help us track down regressions, both performance and correctness, faster. Being able to `git bisect` your way to the cause saves a lot of time. Furthermore, by the time we get to the perf tests we're nearly done and > just want to push and go home, not go back and profile GHC. Yet the perf > tests have an important purpose: the idea is to catch the problem when we > have the crucial piece of information: the patch that caused the > regression. Someone can try to optimise GHC later, but they have to start > from scratch without the information about what caused the regressions. > > Having an automated system to track GHC performance would help a lot with > this, I think. Agree a 100%. Automation is what's needed here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyrab at mail.ru Fri Apr 11 11:00:08 2014 From: kyrab at mail.ru (kyra) Date: Fri, 11 Apr 2014 15:00:08 +0400 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> <5347C4EB.2020209@mail.ru> <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> Message-ID: <5347CB38.10508@mail.ru> ia32-libs is absent on modern Ubuntus. But if anyone is interested installing lib32ncurses5 and libgmp10:i386 did the 'configure' trick. But now 'make install' fails with: "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc" "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc-pkg" "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1" '' '/home/awson/data/ghc-7.8.1-i386' '/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1' '/home/awson/data/ghc-7.8.1-i386/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) Kyra On 4/11/2014 14:43, Alain O'Dea wrote: > install ia32-libs: > http://askubuntu.com/a/297155 > > YMMV. You are much better off using 64-bit software on 64-bit Ubuntu. > >> On Apr 11, 2014, at 10:33, kyra wrote: >> >> Yup, I've already guessed this. More specifically: which :i386 packages should I install to make it work? >> >> Regards, >> Kyra >> >>> On 4/11/2014 13:57, Karel Gardas wrote: >>>> On 04/11/14 11:47 AM, kyra wrote: >>>> Hi, >>>> >>>> I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to >>>> ~/data/Work/ghc-7.8.1-i386. >>>> >>>> Now I have the following: >>>> >>>> awson at awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure >>>> --prefix=/home/awson/data/ghc-7.8.1-i386 >>>> checking for path to top of build tree... >>>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: >>>> /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: >>>> No such file or directory >>>> configure: error: cannot determine current directory >>>> >>>> ghc-pwd is definitely there but it does not start it seems. Perhaps, the >>>> system lacks some shared libs or something. >>> ... >>> What you have forgotten is to install i386 libs on your purely amd64 xubuntu probably... >>> >>> Cheers, >>> Karel >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Fri Apr 11 12:24:23 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 11 Apr 2014 13:24:23 +0100 Subject: GHC's performance In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> <5347BCAA.8040503@gmail.com> Message-ID: <5347DEF7.60504@gmail.com> On 11/04/2014 11:55, Johan Tibell wrote: > On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow > wrote: > > Let me second this. In particular, I think we regress on GHC > performance regularly, because the perf tests just aren't a good way > to prevent regressions. When we have a +/- 10% window, someone can > commit a 9% regression without triggering a perf failure, but the > next patch to come along with a 1% regression will be unfairly blamed. > > > Agreed. I think graphing results helps here. It's often easier to > visualize identify which commit is the real culprit. > > Aside: I think moving completely to subrepos will generally help us > track down regressions, both performance and correctness, faster. Being > able to `git bisect` your way to the cause saves a lot of time. > > Furthermore, by the time we get to the perf tests we're nearly done > and just want to push and go home, not go back and profile GHC. Yet > the perf tests have an important purpose: the idea is to catch the > problem when we have the crucial piece of information: the patch > that caused the regression. Someone can try to optimise GHC later, > but they have to start from scratch without the information about > what caused the regressions. > > Having an automated system to track GHC performance would help a lot > with this, I think. > > > Agree a 100%. Automation is what's needed here. Just to add one thing: when I wrote that above I was thinking primarily about the performance of GHC itself, but of course it all applies to both GHC and the code that GHC generates. Since the latter also affects the former, if we track both together we'll be able to see when we have changes in GHC performance that aren't related to changes in compiled code performance. I care a *lot* about the performance of GHC itself these days, the performance of GHC will directly impact how fast we can get code into production. Cheers, Simon From kyrab at mail.ru Fri Apr 11 12:50:01 2014 From: kyrab at mail.ru (kyra) Date: Fri, 11 Apr 2014 16:50:01 +0400 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347CB38.10508@mail.ru> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> <5347C4EB.2020209@mail.ru> <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> <5347CB38.10508@mail.ru> Message-ID: <5347E4F9.7080108@mail.ru> Don't bother. That was a usual 32/64-bit mess when installer picked up something from 64-bit ghc, which was in a path. Cheers, Kyra On 4/11/2014 15:00, kyra wrote: > ia32-libs is absent on modern Ubuntus. > > But if anyone is interested installing lib32ncurses5 and libgmp10:i386 > did the 'configure' trick. > > But now 'make install' fails with: > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register > libraries/ghc-prim dist-install > "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc" > "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc-pkg" > "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1" '' > '/home/awson/data/ghc-7.8.1-i386' > '/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1' > '/home/awson/data/ghc-7.8.1-i386/share/doc/ghc/html/libraries' NO > ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi > magic number mismatch: old/corrupt interface file? (wanted 33214052, > got 129742) > > Kyra From kyrab at mail.ru Fri Apr 11 13:17:05 2014 From: kyrab at mail.ru (kyra) Date: Fri, 11 Apr 2014 17:17:05 +0400 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347E4F9.7080108@mail.ru> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> <5347C4EB.2020209@mail.ru> <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> <5347CB38.10508@mail.ru> <5347E4F9.7080108@mail.ru> Message-ID: <5347EB51.6020208@mail.ru> Sorry for flood, but it turned out the problem remains. My previous message was a mistake. Now I've removed all GHC installations from paths but this does not help. Did anybody successfully install 32-bit ghc-7.8.1 on 64-bit linux? Regards, Kyra On 4/11/2014 16:50, kyra wrote: > Don't bother. That was a usual 32/64-bit mess when installer picked up > something from 64-bit ghc, which was in a path. > > Cheers, > Kyra > > On 4/11/2014 15:00, kyra wrote: >> ia32-libs is absent on modern Ubuntus. >> >> But if anyone is interested installing lib32ncurses5 and >> libgmp10:i386 did the 'configure' trick. >> >> But now 'make install' fails with: >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register >> libraries/ghc-prim dist-install >> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc" >> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc-pkg" >> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1" '' >> '/home/awson/data/ghc-7.8.1-i386' >> '/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1' >> '/home/awson/data/ghc-7.8.1-i386/share/doc/ghc/html/libraries' NO >> ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi >> magic number mismatch: old/corrupt interface file? (wanted 33214052, >> got 129742) >> >> Kyra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From austin at well-typed.com Fri Apr 11 13:58:51 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 11 Apr 2014 08:58:51 -0500 Subject: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04 In-Reply-To: <5347EB51.6020208@mail.ru> References: <5347BA18.3040309@mail.ru> <5347BC83.7090807@centrum.cz> <5347C4EB.2020209@mail.ru> <07B85024-5F9F-41EC-8E8F-4C2393CAE94F@gmail.com> <5347CB38.10508@mail.ru> <5347E4F9.7080108@mail.ru> <5347EB51.6020208@mail.ru> Message-ID: Kyrill, I think that at the moment, you can't really install a 32-bit GHC on a 64-bit platform. I've actually had a few reports 'in the wild' about there being problems with this, but I'm not sure if there's actually an official ticket regarding it. We should dig one up or file one if there isn't. In theory I see no reason why this should not be doable, but I can't imagine off the top of my head what might really be going wrong. Simon, do you perhaps have an idea? Or have you heard of this/tried it maybe? On Fri, Apr 11, 2014 at 8:17 AM, kyra wrote: > Sorry for flood, but it turned out the problem remains. My previous message > was a mistake. > Now I've removed all GHC installations from paths but this does not help. > Did anybody successfully install 32-bit ghc-7.8.1 on 64-bit linux? > > Regards, > Kyra > > > On 4/11/2014 16:50, kyra wrote: >> >> Don't bother. That was a usual 32/64-bit mess when installer picked up >> something from 64-bit ghc, which was in a path. >> >> Cheers, >> Kyra >> >> On 4/11/2014 15:00, kyra wrote: >>> >>> ia32-libs is absent on modern Ubuntus. >>> >>> But if anyone is interested installing lib32ncurses5 and libgmp10:i386 >>> did the 'configure' trick. >>> >>> But now 'make install' fails with: >>> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register >>> libraries/ghc-prim dist-install >>> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc" >>> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc-pkg" >>> "/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1" '' >>> '/home/awson/data/ghc-7.8.1-i386' >>> '/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1' >>> '/home/awson/data/ghc-7.8.1-i386/share/doc/ghc/html/libraries' NO >>> ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi >>> magic number mismatch: old/corrupt interface file? (wanted 33214052, got >>> 129742) >>> >>> Kyra >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Fri Apr 11 15:04:34 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 11 Apr 2014 11:04:34 -0400 Subject: RFC: provide patch-level information at __GLASGOW_HASKELL__ In-Reply-To: <87vbugtfqo.fsf@gmail.com> References: <87fvll4l7w.fsf@gmail.com> <5347A9E8.3020302@gmail.com> <87vbugtfqo.fsf@gmail.com> Message-ID: exactly, thats a use case I see for this in some of my own code. Eg, once 7.8.3 comes around, i'll be changing my code to use specialize more agreesively, but I'll still want to make sure that the code gets compiled decently with 7.6 and earlier 7.8 ghcs https://ghc.haskell.org/trac/ghc/ticket/8848 (basically in the mean time I have to do some overly agressive INLINING to get the same outcome I want) On Fri, Apr 11, 2014 at 4:47 AM, Herbert Valerio Riedel wrote: > On 2014-04-11 at 10:38:00 +0200, Simon Marlow wrote: > > [...] > > > We could add a __GLASGOW_HASKELL_PATCHLEVEL__ macro, but I'd like to > > understand more about why people need this, and whether we should be > > more careful about what we do in patchlevel releases. > > What about the use-case when you want to workaround a compiler bug that > existed for GHC==7.6.1 but which was fixed for GHC>=7.6.2 (and thus > doesn't need the workaround anymore)? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Apr 11 20:19:06 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 11 Apr 2014 22:19:06 +0200 Subject: Defined but not used in TcPatSyn Message-ID: <1397247546.29266.1.camel@kirk> Hi, someone introduced a validate error recently: compiler/typecheck/TcPatSyn.lhs:324:19: Warning: Defined but not used: `lit' compiler/typecheck/TcPatSyn.lhs:325:17: Warning: Defined but not used: `n' Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Fri Apr 11 23:51:09 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 11 Apr 2014 18:51:09 -0500 Subject: 7.8.2 bugs and beyond In-Reply-To: References: Message-ID: Hi all, The 7.8.2 source tarball is here. I actually have most of the binaries ready, but I forgot to send this in advance: http://www.haskell.org/ghc/dist/7.8.2/ Please build when you get a chance. I'll probably go ahead and announce shortly to get the bugfix into peoples hands, and we can incrementally add new tarballs. Thanks! On Thu, Apr 10, 2014 at 7:53 AM, Austin Seipp wrote: > Hello all, > > Misfortune has struck unfortunately - we shipped with a bit of an > awful bug in 7.8.1, see #8978. The good news is Simon already has a > fix! Yay! > > However, I'll probably be going ahead and releasing an immediate > today. For everyone, I don't think this changes much regarding my last > email - just substitute '7.8.2' with '7.8.3' where you might see it. > > Here's the list of 7.8.3 bugs for reference, I migrated the old 7.8.2 > tickets here: > > https://ghc.haskell.org/trac/ghc/query?milestone=7.8.3&group=status > > Thanks! > > On Wed, Apr 9, 2014 at 7:34 PM, Austin Seipp wrote: >> Hello all, >> >> 7.8.1 is out. Yay! Now, on to the next thing. >> >> Here's the very preliminary 7.8.2 buglist: >> >> - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 >> >> Note that this list has effectively received zero curation so far. I >> plan on fixing that soon, and in the process I am probably going to >> touch a lot of trac tickets (so I apologize in advance for the mail >> spam, because y'all are probably going to get a lot of it). This will >> include re-prioritizing these bugs, so take things with a grain of >> salt right now. >> >> Note that the bug tracker now has 7.8.1 as the default version - if >> you're filing bugs, please be sure to try it first of course. :) And >> don't forget to set the milestone to 7.8.2 if you think it qualifies >> for a fix. There are already a couple of things in the merge queue. >> >> There's currently no expected date for 7.8.2. Should it arrive >> quickly? Or slowly? Simon, Simon and I are inclined to just let things >> play out for a while of course, which is the traditional way things >> are done. But this release window has been especially awkward, so >> we'll see what happens. >> >> This of course leaves timeline questions for 7.10 open - but before we >> decide that, now's a time to just get some hacking done I suppose... >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ezyang at mit.edu Fri Apr 11 21:21:31 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 11 Apr 2014 14:21:31 -0700 Subject: Defined but not used in TcPatSyn In-Reply-To: <1397247546.29266.1.camel@kirk> References: <1397247546.29266.1.camel@kirk> Message-ID: <1397251277-sup-4382@sabre> Judging from affect files, probably commit c269b7e85524f4a8be3cd0f00e107207ab9197af Author: Dr. ERDI Gergo Date: Thu Apr 10 22:13:00 2014 +0800 Split off pattern synonym definition checking from pattern inversion Edward Excerpts from Joachim Breitner's message of 2014-04-11 13:19:06 -0700: > Hi, > > someone introduced a validate error recently: > > compiler/typecheck/TcPatSyn.lhs:324:19: > Warning: Defined but not used: `lit' > > compiler/typecheck/TcPatSyn.lhs:325:17: > Warning: Defined but not used: `n' > > > Greetings, > Joachim From pali.gabor at gmail.com Sat Apr 12 01:56:56 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Sat, 12 Apr 2014 03:56:56 +0200 Subject: 7.8.2 bugs and beyond In-Reply-To: References: Message-ID: 2014-04-12 1:51 GMT+02:00 Austin Seipp : > Please build when you get a chance. I'll probably go ahead and > announce shortly to get the bugfix into peoples hands, and we can > incrementally add new tarballs. All right, here are the FreeBSD builds, the corresponding checksums, and the updated install guide: http://haskell.inf.elte.hu/ghc/ghc-7.8.2-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.2-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html From kazu at iij.ad.jp Sat Apr 12 06:39:04 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Sat, 12 Apr 2014 15:39:04 +0900 (JST) Subject: 7.8.2 bugs and beyond In-Reply-To: References: Message-ID: <20140412.153904.1389713770369589947.kazu@iij.ad.jp> Helo, > The 7.8.2 source tarball is here. I actually have most of the binaries > ready, but I forgot to send this in advance: > > http://www.haskell.org/ghc/dist/7.8.2/ > > Please build when you get a chance. I'll probably go ahead and > announce shortly to get the bugfix into peoples hands, and we can > incrementally add new tarballs. Now I can build yesod with GHC 7.8.2 on my Mac. Thanks. --Kazu From mail at joachim-breitner.de Sat Apr 12 08:32:32 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 12 Apr 2014 10:32:32 +0200 Subject: Defined but not used in TcPatSyn In-Reply-To: <1397251277-sup-4382@sabre> References: <1397247546.29266.1.camel@kirk> <1397251277-sup-4382@sabre> Message-ID: <1397291552.11270.0.camel@kirk> Hi, Am Freitag, den 11.04.2014, 14:21 -0700 schrieb Edward Z.Yang: > Judging from affect files, probably > > commit c269b7e85524f4a8be3cd0f00e107207ab9197af > Author: Dr. ERDI Gergo > Date: Thu Apr 10 22:13:00 2014 +0800 > > Split off pattern synonym definition checking from pattern inversion quite likely; Gergo has fixed this now. It now fails with =====> as-pattern(normal) 3652 of 3950 [0, 0, 0] Actual stderr output differs from expected: --- /dev/null 2014-04-12 01:15:42.517232560 +0000 +++ ./patsyn/should_fail/as-pattern.comp.stderr 2014-04-12 01:45:41.904702080 +0000 @@ -0,0 +1 @@ +: does not exist: as-pattern.hs *** unexpected failure for as-pattern(normal) Gergo, did you forget to add a file to git? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gergo at erdi.hu Sat Apr 12 08:36:20 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Sat, 12 Apr 2014 16:36:20 +0800 (SGT) Subject: Defined but not used in TcPatSyn In-Reply-To: <1397291552.11270.0.camel@kirk> References: <1397247546.29266.1.camel@kirk> <1397251277-sup-4382@sabre> <1397291552.11270.0.camel@kirk> Message-ID: On Sat, 12 Apr 2014, Joachim Breitner wrote: > quite likely; Gergo has fixed this now. > > It now fails with > > =====> as-pattern(normal) 3652 of 3950 [0, 0, 0] > Actual stderr output differs from expected: > --- /dev/null 2014-04-12 01:15:42.517232560 +0000 > +++ ./patsyn/should_fail/as-pattern.comp.stderr 2014-04-12 01:45:41.904702080 +0000 > @@ -0,0 +1 @@ > +: does not exist: as-pattern.hs > *** unexpected failure for as-pattern(normal) > > Gergo, did you forget to add a file to git? Yes. Aargh. Fixed now. From mail at joachim-breitner.de Sat Apr 12 09:50:36 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 12 Apr 2014 11:50:36 +0200 Subject: Defined but not used in TcPatSyn In-Reply-To: References: <1397247546.29266.1.camel@kirk> <1397251277-sup-4382@sabre> <1397291552.11270.0.camel@kirk> Message-ID: <1397296236.11270.9.camel@kirk> Hi, Am Samstag, den 12.04.2014, 16:36 +0800 schrieb Dr. ERDI Gergo: > On Sat, 12 Apr 2014, Joachim Breitner wrote: > > > quite likely; Gergo has fixed this now. > > > > It now fails with > > > > =====> as-pattern(normal) 3652 of 3950 [0, 0, 0] > > Actual stderr output differs from expected: > > --- /dev/null 2014-04-12 01:15:42.517232560 +0000 > > +++ ./patsyn/should_fail/as-pattern.comp.stderr 2014-04-12 01:45:41.904702080 +0000 > > @@ -0,0 +1 @@ > > +: does not exist: as-pattern.hs > > *** unexpected failure for as-pattern(normal) > > > > Gergo, did you forget to add a file to git? > > Yes. Aargh. Fixed now. better. Not it seems that as-pattern.stderr is missing: Actual stderr output differs from expected: --- /dev/null 2014-04-12 08:45:45.769562505 +0000 +++ ./patsyn/should_fail/as-pattern.comp.stderr 2014-04-12 09:17:26.788082628 +0000 @@ -0,0 +1,4 @@ + +as-pattern.hs:4:18: + Pattern synonym definition cannot contain as-patterns (@): + x@(Just y) *** unexpected failure for as-pattern(normal) Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gergo at erdi.hu Sat Apr 12 14:32:15 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Sat, 12 Apr 2014 22:32:15 +0800 (SGT) Subject: Validation failures on master Message-ID: The ultimate case of 'the pot calling the kettle black'[*]: I'm seeing validation errors on 'master' 7233638: Unexpected passes: arrows/should_fail arrowfail001 (normal) lib/integer integerConstantFolding (normal) [*] just to be clear, I mean me being the pot in this case:) From hvr at gnu.org Sun Apr 13 07:58:50 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 13 Apr 2014 09:58:50 +0200 Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git Message-ID: <87ob05mzid.fsf@gmail.com> Hello *, Now that GHC 7.8.[12] is out of the door, the Git reorganization can be tackled further... After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago): - base - ghc-prim - integer-gmp - integer-simple - template-haskell IMO, the benefit/cost ratio of simplifying the workflow outweighs the benefit/cost ratio of turning those into proper Git submodules. This incremental step towards a fully git-bisect-able ghc.git does already allow bisecting to work on a larger time-range than it does now, as those wired-in packages are the most likely to break compilation if out-of-sync with ghc.git. If no objections are raised, I'm planning to implement this change next weekend (April 19th/20th). Any comments/questions/...? Cheers, hvr PS: After this step, the next remaining step would be to turn the remaining not-yet-submodule Git repos into proper submodule Repos (like haddock.git) and figure out how to get the sync-all convenience-tooling a bit more submodule friendly... From djsamperi at gmail.com Sun Apr 13 19:43:02 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 13 Apr 2014 15:43:02 -0400 Subject: Has the behavior of -fno-ghci-sandbox changed with ghc-7.8.2? Message-ID: I ticket #8371 I reported a problem using embedded R with ghci (no problem when application is compiled with ghc). The work-around was to use the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting a new thread (R is not thread-safe). This worked fine with pre-release ghci 7.7 (built from source using BuildFlavour = quick), but now I get a segfault on startup using ghci 7.8.2, suggesting that the behavior of -fno-ghci-sandbox may have changed, perhaps because of the way the Linux binary distribution was built. Has the behavior of -fno-ghci-sandbox changed, or could it have been changed because of the way the Linux binary distribution was built? BTW, I would have posted this as a follow-up to the ticket but I forgot my password. How does one reset the password on the ticket tracker site? Thanks, Dominick From djsamperi at gmail.com Sun Apr 13 20:18:55 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 13 Apr 2014 16:18:55 -0400 Subject: Has the behavior of -fno-ghci-sandbox changed with ghc-7.8.2? In-Reply-To: References: Message-ID: This was my error, sorry. The work-around is fine for 7.8.2. The last remark still applies: it is not apparent how to reset passwords on the issue tracker site. On Sun, Apr 13, 2014 at 3:43 PM, Dominick Samperi wrote: > I ticket #8371 I reported a problem using embedded R with ghci (no problem > when application is compiled with ghc). The work-around was to use > the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting > a new thread (R is not thread-safe). > > This worked fine with pre-release ghci 7.7 (built from source using > BuildFlavour = quick), but now I get a segfault on startup > using ghci 7.8.2, suggesting that the behavior of -fno-ghci-sandbox > may have changed, perhaps because of the way the Linux binary > distribution was built. > > Has the behavior of -fno-ghci-sandbox changed, or could it have been > changed because of the way the Linux binary distribution was built? > > BTW, I would have posted this as a follow-up to the ticket but I forgot > my password. How does one reset the password on the ticket > tracker site? > > Thanks, > Dominick From conal at conal.net Mon Apr 14 04:59:37 2014 From: conal at conal.net (Conal Elliott) Date: Sun, 13 Apr 2014 21:59:37 -0700 Subject: Help with coercion & roles? Message-ID: I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) "tpl"#) `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) ? LambdaCCC.Lambda.EP (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin _N (Sym (Simple.NTCo:HasIf[0] _N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Mon Apr 14 07:15:42 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Mon, 14 Apr 2014 09:15:42 +0200 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) Message-ID: The failing command: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140414 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Interface/Create.hs -o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/src/Haddock/Interface/Create.hs:367:44: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a1, Located (HsBind id))' Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) Actual type: TyClDecl Name -> LHsBinds Name Relevant bindings include defs :: [Located (HsDecl id)] (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) In the second argument of '(.)', namely 'tcdMeths' In the second argument of '(.)', namely 'bagToList . tcdMeths' utils/haddock/src/Haddock/Interface/Create.hs:393:22: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a0, Located (HsBind Name))' Expected type: HsValBindsLR Name Name -> [(a0, Located (HsBind Name))] Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] In the first argument of '(.)', namely 'valbinds' In the second argument of '(.)', namely 'valbinds . hs_valds' gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 gmake: *** [all] Error 2 Please consult the details at http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html From hvriedel at gmail.com Mon Apr 14 07:17:51 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 14 Apr 2014 09:17:51 +0200 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: (=?utf-8?Q?=22P=C3=A1li_G=C3=A1bor_J=C3=A1nos=22's?= message of "Mon, 14 Apr 2014 09:15:42 +0200") References: Message-ID: <87vbucidls.fsf@gmail.com> Hi, (probably) fixed by http://git.haskell.org/ghc.git/commitdiff/b4a820f97e48199a92f5ce7216731500f9a841c9 On 2014-04-14 at 09:15:42 +0200, P?li G?bor J?nos wrote: [...] > utils/haddock/src/Haddock/Interface/Create.hs:367:44: > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > with '(a1, Located (HsBind id))' > Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) > Actual type: TyClDecl Name -> LHsBinds Name > Relevant bindings include > defs :: [Located (HsDecl id)] > (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) > In the second argument of '(.)', namely 'tcdMeths' > In the second argument of '(.)', namely 'bagToList . tcdMeths' > utils/haddock/src/Haddock/Interface/Create.hs:393:22: > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > with '(a0, Located (HsBind Name))' > Expected type: HsValBindsLR Name Name > -> [(a0, Located (HsBind Name))] > Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] > In the first argument of '(.)', namely 'valbinds' > In the second argument of '(.)', namely 'valbinds . hs_valds' > gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 > gmake: *** [all] Error 2 > > Please consult the details at > > http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html From lukexipd at gmail.com Mon Apr 14 08:06:19 2014 From: lukexipd at gmail.com (Luke Iannini) Date: Mon, 14 Apr 2014 01:06:19 -0700 Subject: 7.8.2 bugs and beyond In-Reply-To: <20140412.153904.1389713770369589947.kazu@iij.ad.jp> References: <20140412.153904.1389713770369589947.kazu@iij.ad.jp> Message-ID: Hi Austin, Here are the iOS builds: https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-device/ghc-7.8.2-arm-apple-ios.tar.bz2 SHA1 2160c203ed641e38e1306a722727105db97ea7d7 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-simulator/ghc-7.8.2-i386-apple-ios.tar.bz2 SHA1 c855877d2b77a8c401da804373a3334e0dea43d4 & README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md On Fri, Apr 11, 2014 at 11:39 PM, Kazu Yamamoto wrote: > Helo, > > > The 7.8.2 source tarball is here. I actually have most of the binaries > > ready, but I forgot to send this in advance: > > > > http://www.haskell.org/ghc/dist/7.8.2/ > > > > Please build when you get a chance. I'll probably go ahead and > > announce shortly to get the bugfix into peoples hands, and we can > > incrementally add new tarballs. > > Now I can build yesod with GHC 7.8.2 on my Mac. Thanks. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Apr 14 08:23:16 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 14 Apr 2014 09:23:16 +0100 Subject: [commit: ghc] master: Fix linked list manipulation code (buggy on consecutive deletion) (e3938f3) In-Reply-To: <20140413063705.518392406B@ghc.haskell.org> References: <20140413063705.518392406B@ghc.haskell.org> Message-ID: <534B9AF4.9070304@gmail.com> Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please? Cheers, Simon On 13/04/2014 07:37, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244ce121478/ghc > >> --------------------------------------------------------------- > > commit e3938f3adac0093b23694fd347774244ce121478 > Author: Edward Z. Yang > Date: Sat Apr 12 23:02:13 2014 -0700 > > Fix linked list manipulation code (buggy on consecutive deletion) > > Signed-off-by: Edward Z. Yang > > >> --------------------------------------------------------------- > > e3938f3adac0093b23694fd347774244ce121478 > rts/CheckUnload.c | 3 ++- > rts/Linker.c | 6 ++++-- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c > index f1f454c..98f184b 100644 > --- a/rts/CheckUnload.c > +++ b/rts/CheckUnload.c > @@ -298,7 +298,7 @@ void checkUnload (StgClosure *static_objects) > // marked as unreferenced can be physically unloaded, because we > // have no references to it. > prev = NULL; > - for (oc = unloaded_objects; oc; prev = oc, oc = next) { > + for (oc = unloaded_objects; oc; oc = next) { > next = oc->next; > if (oc->referenced == 0) { > if (prev == NULL) { > @@ -312,6 +312,7 @@ void checkUnload (StgClosure *static_objects) > } else { > IF_DEBUG(linker, debugBelch("Object file still in use: %" > PATH_FMT "\n", oc->fileName)); > + prev = oc; > } > } > > diff --git a/rts/Linker.c b/rts/Linker.c > index af26d74..ab235e9 100644 > --- a/rts/Linker.c > +++ b/rts/Linker.c > @@ -3016,8 +3016,8 @@ unloadObj( pathchar *path ) > IF_DEBUG(linker, debugBelch("unloadObj: %" PATH_FMT "\n", path)); > > prev = NULL; > - for (oc = objects; oc; prev = oc, oc = next) { > - next = oc->next; > + for (oc = objects; oc; oc = next) { > + next = oc->next; // oc might be freed > > if (!pathcmp(oc->fileName,path)) { > > @@ -3075,6 +3075,8 @@ unloadObj( pathchar *path ) > /* This could be a member of an archive so continue > * unloading other members. */ > unloadedAnyObj = HS_BOOL_TRUE; > + } else { > + prev = oc; > } > } > > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From simonpj at microsoft.com Mon Apr 14 08:22:43 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 14 Apr 2014 08:22:43 +0000 Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <87ob05mzid.fsf@gmail.com> References: <87ob05mzid.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF155EFA@DB3PRD3001MB020.064d.mgd.msft.net> OK with me! Sounds simpler. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 13 April 2014 08:59 | To: ghc-devs | Cc: Austin Seipp | Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell- | template into ghc.git | | Hello *, | | Now that GHC 7.8.[12] is out of the door, the Git reorganization can be | tackled further... | | After a short conversion with Austin and Edward it appears that the | sensible course of action with respect towards moving to a proper Git | submodule set-up is to fold-in the 5 Git repos listed below (which btw | are all GHC wired-in packages) directly into ghc.git (the same way | testsuite.git was a few months ago): | | - base | - ghc-prim | - integer-gmp | - integer-simple | - template-haskell | | IMO, the benefit/cost ratio of simplifying the workflow outweighs the | benefit/cost ratio of turning those into proper Git submodules. | | This incremental step towards a fully git-bisect-able ghc.git does | already allow bisecting to work on a larger time-range than it does | now, as those wired-in packages are the most likely to break | compilation if out-of-sync with ghc.git. | | If no objections are raised, I'm planning to implement this change next | weekend (April 19th/20th). | | Any comments/questions/...? | | Cheers, | hvr | | | | PS: After this step, the next remaining step would be to turn the | remaining not-yet-submodule Git repos into proper submodule Repos | (like haddock.git) and figure out how to get the sync-all | convenience-tooling a bit more submodule friendly... | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Mon Apr 14 08:54:20 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 14 Apr 2014 10:54:20 +0200 Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF155EFA@DB3PRD3001MB020.064d.mgd.msft.net> References: <87ob05mzid.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF155EFA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Sounds good to me too. On Mon, Apr 14, 2014 at 10:22 AM, Simon Peyton Jones wrote: > OK with me! Sounds simpler. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Herbert Valerio Riedel > | Sent: 13 April 2014 08:59 > | To: ghc-devs > | Cc: Austin Seipp > | Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell- > | template into ghc.git > | > | Hello *, > | > | Now that GHC 7.8.[12] is out of the door, the Git reorganization can be > | tackled further... > | > | After a short conversion with Austin and Edward it appears that the > | sensible course of action with respect towards moving to a proper Git > | submodule set-up is to fold-in the 5 Git repos listed below (which btw > | are all GHC wired-in packages) directly into ghc.git (the same way > | testsuite.git was a few months ago): > | > | - base > | - ghc-prim > | - integer-gmp > | - integer-simple > | - template-haskell > | > | IMO, the benefit/cost ratio of simplifying the workflow outweighs the > | benefit/cost ratio of turning those into proper Git submodules. > | > | This incremental step towards a fully git-bisect-able ghc.git does > | already allow bisecting to work on a larger time-range than it does > | now, as those wired-in packages are the most likely to break > | compilation if out-of-sync with ghc.git. > | > | If no objections are raised, I'm planning to implement this change next > | weekend (April 19th/20th). > | > | Any comments/questions/...? > | > | Cheers, > | hvr > | > | > | > | PS: After this step, the next remaining step would be to turn the > | remaining not-yet-submodule Git repos into proper submodule Repos > | (like haddock.git) and figure out how to get the sync-all > | convenience-tooling a bit more submodule friendly... > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 14 09:13:02 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 14 Apr 2014 09:13:02 +0000 Subject: Git problem Message-ID: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> Friends I'm stuck with Git. Help please! Simon I tried to do a 'git stash pop', having just done a 'git pull' from the master repo. I got this: simonpj at cam-05-unx:~/code/HEAD-2$ git stash pop warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) Auto-merging utils/haddock CONFLICT (submodule): Merge conflict in utils/haddock Auto-merging compiler/typecheck/TcRnMonad.lhs Now git status says simonpj at cam-05-unx:~/code/HEAD-2$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: compiler/typecheck/TcMType.lhs # modified: compiler/typecheck/TcRnMonad.lhs # modified: compiler/typecheck/TcSimplify.lhs # modified: compiler/typecheck/TcUnify.lhs # # Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: utils/haddock The modified files are right. It's the "both modified utils/haddock" that is messing me up. I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying # modified: utils/haddock (new commits) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 14 09:45:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 14 Apr 2014 09:45:40 +0000 Subject: Help with coercion & roles? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> I think you need a ?Sub?. A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 14 April 2014 06:00 To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org Subject: Help with coercion & roles? I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) "tpl"#) `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) ? LambdaCCC.Lambda.EP (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representational in _N (Sym (Simple.NTCo:HasIf[0] _N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Apr 14 09:47:44 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 14 Apr 2014 11:47:44 +0200 Subject: Git problem In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Mon, 14 Apr 2014 09:13:02 +0000") References: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87mwfoi6nz.fsf@gmail.com> On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote: [...] > # both modified: utils/haddock > The modified files are right. It's the "both modified utils/haddock" that is messing me up. > I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying > > # modified: utils/haddock (new commits) Fyi, the git equivalent of saying "take the master haddock" (where 'master' refers to 'master' of 'haddock.git'): # checkout master of haddock.git: git submodule update --remote utils/haddock # register state (= submod commit-id) of utils/haddock for next commit git add utils/haddock HTH, hvr From eir at cis.upenn.edu Mon Apr 14 11:39:01 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 07:39:01 -0400 Subject: Help with coercion & roles? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I agree with Simon, but just `Sub` the `_N`, not the whole coercion. There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. In sum, here is the coercion I think you want: (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. Let me know if I can help further! Richard On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > I think you need a ?Sub?. > > A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. > > Simon > > From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott > Sent: 14 April 2014 06:00 > To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > Subject: Help with coercion & roles? > > I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > LambdaCCC.Lambda.lamvP# > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > @ (Simple.HasIf GHC.Types.Bool) > "tpl"# > ((LambdaCCC.Lambda.varP# > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > "tpl"#) > `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) > ? LambdaCCC.Lambda.EP > (GHC.Types.Bool > ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > ~# > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. > > Thanks, > > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 18:23:45 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 11:23:45 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: > class HasIf a where > ifThenElse :: Bool -> a -> a -> a > > instance HasIf Bool where > ifThenElse i t e = (i && t) || (not i && e) With `--dump-tc`, I see > TYPE SIGNATURES > TYPE CONSTRUCTORS > HasIf :: * -> Constraint > class HasIf a > Roles: [nominal] > RecFlag NonRecursive > ifThenElse :: Bool -> a -> a -> a > COERCION AXIOMS > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > INSTANCES > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R -- Conal On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the > whole coercion. > > There are actually two problems here. The one Simon identified, and also > the fact that Simple.NTCo:HasIf[0] produces a representational coercion. > How do I know? Because of the `NT` -- it's a newtype axiom and must produce > representational coercions. Furthermore, unless the newtype definition is > inferred to require a nominal parameter, the newtype would expect a > representational coercion, not the nominal one you are passing. Check the > dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on > `` would work, you would then be violating an invariant of GHC's > Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl > (TyConApp tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within > GHC, and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles > and may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones > wrote: > > I think you need a ?Sub?. > > A cast (e `cast` g) requires a representational coercion. I think you > have given it a (stronger) nominal one. Sub gets from one to t?other. > > Simon > > *From:* Glasgow-haskell-users [mailto:glasgow- > haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 14 April 2014 06:00 > *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > *Subject:* Help with coercion & roles? > > > I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and > running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > > > LambdaCCC.Lambda.lamvP# > > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > @ (Simple.HasIf GHC.Types.Bool) > > "tpl"# > > ((LambdaCCC.Lambda.varP# > > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > "tpl"#) > > `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) > > ? LambdaCCC.Lambda.EP > > (GHC.Types.Bool > > ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > ~# > > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > > Do you see anything inconsistent/incompatible in the coercions or roles > above? I constructed the nominal EP Refl coercion, and applied it (AppCo) > an existing coercion of a simpler type. > > Thanks, > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Apr 14 18:54:08 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 14:54:08 -0400 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Conal, In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the `HasIf` class indeed has a nominal parameter. So, it seems that this part, at least, is OK. What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what you're saying.) If that's the case, you won't be able to pass the result of NTCo:HasIf[0] to a coercion built from EP. Popping up a level, what are you trying to do here? If EP's role is indeed nominal, then I don't believe there's a fix here, as the coercion it seems you're trying to build may be unsound. (It looks to me like you want something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but if EP's role is nominal, then this is indeed bogus.) Richard On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the whole coercion. > > There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > >> I think you need a ?Sub?. >> >> A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. >> >> Simon >> >> From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott >> Sent: 14 April 2014 06:00 >> To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >> Subject: Help with coercion & roles? >> >> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: >> >> Warning: In the expression: >> >> >> LambdaCCC.Lambda.lamvP# >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> @ (Simple.HasIf GHC.Types.Bool) >> >> "tpl"# >> ((LambdaCCC.Lambda.varP# >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> "tpl"#) >> >> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> ? LambdaCCC.Lambda.EP >> (GHC.Types.Bool >> >> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> ~# >> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >> >> >> Role incompatibility: expected nominal, got representational >> >> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >> Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. >> >> Thanks, >> >> -- Conal >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 20:12:13 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 13:12:13 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Richard, I'm working on compiling Haskell to hardware, as outlined at https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a few recent blog posts). The first step is to convert Core into other Core that evaluates to a reified form, represented as a type-parametrized GADT. This GADT (in `LambdaCCC.Lambda`): > data E :: (* -> *) -> (* -> *) where ... The parameter is also type-parametrized, and is for the primitives. I have such a type designed for hardware generation (in `LambdaCCC.Prim`) > data Prim :: * -> * where ... and then the combination of the two: > type EP = E Prim So that's what `EP` is. With `-ddump-tc`, I get > TYPE CONSTRUCTORS > ... > E :: (* -> *) -> * -> * > data E ($a::* -> *) $b > No C type associated > Roles: [representational, nominal] > RecFlag NonRecursive, Not promotable > = ... > EP :: * -> * > type EP = E Prim The use of `EP` rather than the more general `E` is only temporary, while I'm learning more details of Core (and of HERMIT which I'm using to manipulate Core). I'm now working on reification in the presence of casts. The rule I'm trying to implement is > evalEP e |> co --> evalEP (e |> co'). Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. I'm trying to build `co'` from `co`, which led to these questions. So what do you think? Is there a sound coercion I can build for `co'`? -- Conal On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the > `HasIf` class indeed has a nominal parameter. So, it seems that this part, > at least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what > you're saying.) If that's the case, you won't be able to pass the result of > NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed > nominal, then I don't believe there's a fix here, as the coercion it seems > you're trying to build may be unsound. (It looks to me like you want > something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, > but if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > > Thanks for the pointers! I don't quite know how to get to the form you > recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] > _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from > the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC > (`Simple.NTCo:HasIf[0] _N` in this case) to a > representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to > apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which > then produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got > representational in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying > `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > >> I agree with Simon, but just `Sub` the `_N`, not the >> whole coercion. >> >> There are actually two problems here. The one Simon identified, and also >> the fact that Simple.NTCo:HasIf[0] produces a representational coercion. >> How do I know? Because of the `NT` -- it's a newtype axiom and must produce >> representational coercions. Furthermore, unless the newtype definition is >> inferred to require a nominal parameter, the newtype would expect a >> representational coercion, not the nominal one you are passing. Check the >> dump (using -ddump-tc) of the newtype axiom to be sure. >> >> Though putting a `Sub` on `` and changing the Refl constructor on >> `` would work, you would then be violating an invariant of GHC's >> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl >> (TyConApp tc [])) ...`. >> >> In sum, here is the coercion I think you want: >> >> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >> >> This is one of the problems with roles -- they are *very* fiddly within >> GHC, and it's hard for a non-expert in roles to get them right. >> >> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles >> and may be of help. >> >> Let me know if I can help further! >> Richard >> >> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones >> wrote: >> >> I think you need a ?Sub?. >> >> A cast (e `cast` g) requires a representational coercion. I think you >> have given it a (stronger) nominal one. Sub gets from one to t?other. >> >> Simon >> >> *From:* Glasgow-haskell-users [mailto:glasgow- >> haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott >> *Sent:* 14 April 2014 06:00 >> *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >> *Subject:* Help with coercion & roles? >> >> >> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and >> running into trouble with coercions & roles. Error message from Core Lint: >> >> Warning: In the expression: >> >> >> >> LambdaCCC.Lambda.lamvP# >> >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> @ (Simple.HasIf GHC.Types.Bool) >> >> "tpl"# >> >> ((LambdaCCC.Lambda.varP# >> >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> "tpl"#) >> >> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> ? LambdaCCC.Lambda.EP >> >> (GHC.Types.Bool >> >> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> ~# >> >> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >> >> Role incompatibility: expected nominal, got representational >> >> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> Do you see anything inconsistent/incompatible in the coercions or roles >> above? I constructed the nominal EP Refl coercion, and applied it (AppCo) >> an existing coercion of a simpler type. >> >> Thanks, >> -- Conal >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Apr 14 21:02:33 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 17:02:33 -0400 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > So what do you think? Is there a sound coercion I can build for `co'`? In a word, "no". The problem is that E, as you describe, is a GADT. Therefore, it cares exactly which types it is parameterized by. We can see this in evidence in the dump, which labels E's second parameter as nominal. To draw out the problem, let's look at a simpler example: > newtype Age = MkAge Int > data G a where > MkGInt :: G Int > MkGAge :: G Age Here, `G` would similarly get a nominal role, because we can't lift representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, which goes against our definition of G -- the only value inhabitant of G Int should be MkGInt. The best you can do here is to try to raise the inner coercion to be nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the ability of GHC's type system. Of course, I would like to help you with a way forward -- let me know if there's a way I can. Richard On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a few recent blog posts). The first step is to convert Core into other Core that evaluates to a reified form, represented as a type-parametrized GADT. This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while I'm learning more details of Core (and of HERMIT which I'm using to manipulate Core). > > I'm now working on reification in the presence of casts. The rule I'm trying to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the `HasIf` class indeed has a nominal parameter. So, it seems that this part, at least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what you're saying.) If that's the case, you won't be able to pass the result of NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed nominal, then I don't believe there's a fix here, as the coercion it seems you're trying to build may be unsound. (It looks to me like you want something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > >> Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". >> >> I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> -- Conal >> >> >> On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: >> I agree with Simon, but just `Sub` the `_N`, not the whole coercion. >> >> There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. >> >> Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. >> >> In sum, here is the coercion I think you want: >> >> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >> >> This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. >> >> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. >> >> Let me know if I can help further! >> Richard >> >> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: >> >>> I think you need a ?Sub?. >>> >>> A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. >>> >>> Simon >>> >>> From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott >>> Sent: 14 April 2014 06:00 >>> To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >>> Subject: Help with coercion & roles? >>> >>> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: >>> >>> Warning: In the expression: >>> >>> >>> LambdaCCC.Lambda.lamvP# >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> @ (Simple.HasIf GHC.Types.Bool) >>> >>> "tpl"# >>> ((LambdaCCC.Lambda.varP# >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> "tpl"#) >>> >>> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> ? LambdaCCC.Lambda.EP >>> (GHC.Types.Bool >>> >>> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> ~# >>> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >>> >>> >>> Role incompatibility: expected nominal, got representational >>> >>> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >>> Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. >>> >>> Thanks, >>> >>> -- Conal >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 22:04:10 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 15:04:10 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This explanation-with-example is very helpful. Thanks, Richard! I'll noodle some more. A fairly simple & robust solution may be to add `Cast` to my expression GADT. -- Conal On Mon, Apr 14, 2014 at 2:02 PM, Richard Eisenberg wrote: > So what do you think? Is there a sound coercion I can build for `co'`? > > > In a word, "no". The problem is that E, as you describe, is a GADT. > Therefore, it cares exactly which types it is parameterized by. We can see > this in evidence in the dump, which labels E's second parameter as nominal. > To draw out the problem, let's look at a simpler example: > > > newtype Age = MkAge Int > > data G a where > > MkGInt :: G Int > > MkGAge :: G Age > > Here, `G` would similarly get a nominal role, because we can't lift > representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` > type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, > which goes against our definition of G -- the only value inhabitant of G > Int should be MkGInt. > > The best you can do here is to try to raise the inner coercion to be > nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the > ability of GHC's type system. > > Of course, I would like to help you with a way forward -- let me know if > there's a way I can. > > Richard > > On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at > https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links > to a few recent blog posts). The first step is to convert Core into other > Core that evaluates to a reified form, represented as a type-parametrized > GADT. This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have > such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while > I'm learning more details of Core (and of HERMIT which I'm using to > manipulate Core). > > I'm now working on reification in the presence of casts. The rule I'm > trying to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > >> Hi Conal, >> >> In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the >> `HasIf` class indeed has a nominal parameter. So, it seems that this part, >> at least, is OK. >> >> What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what >> you're saying.) If that's the case, you won't be able to pass the result of >> NTCo:HasIf[0] to a coercion built from EP. >> >> Popping up a level, what are you trying to do here? If EP's role is >> indeed nominal, then I don't believe there's a fix here, as the coercion it >> seems you're trying to build may be unsound. (It looks to me like you want >> something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, >> but if EP's role is nominal, then this is indeed bogus.) >> >> Richard >> >> On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: >> >> Thanks for the pointers! I don't quite know how to get to the form you >> recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] >> _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from >> the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC >> (`Simple.NTCo:HasIf[0] _N` in this case) to a >> representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to >> apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which >> then produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected nominal, got >> representational in `Sym (Simple.NTCo:HasIf[0] _N)`". >> >> I also tried wrapping `mkSubCo` around the entire coercion (applying >> `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> -- Conal >> >> >> >> On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: >> >>> I agree with Simon, but just `Sub` the `_N`, not >>> the whole coercion. >>> >>> There are actually two problems here. The one Simon identified, and also >>> the fact that Simple.NTCo:HasIf[0] produces a representational coercion. >>> How do I know? Because of the `NT` -- it's a newtype axiom and must produce >>> representational coercions. Furthermore, unless the newtype definition is >>> inferred to require a nominal parameter, the newtype would expect a >>> representational coercion, not the nominal one you are passing. Check the >>> dump (using -ddump-tc) of the newtype axiom to be sure. >>> >>> Though putting a `Sub` on `` and changing the Refl constructor on >>> `` would work, you would then be violating an invariant of GHC's >>> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl >>> (TyConApp tc [])) ...`. >>> >>> In sum, here is the coercion I think you want: >>> >>> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >>> >>> This is one of the problems with roles -- they are *very* fiddly within >>> GHC, and it's hard for a non-expert in roles to get them right. >>> >>> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles >>> and may be of help. >>> >>> Let me know if I can help further! >>> Richard >>> >>> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones >>> wrote: >>> >>> I think you need a ?Sub?. >>> >>> A cast (e `cast` g) requires a representational coercion. I think you >>> have given it a (stronger) nominal one. Sub gets from one to t?other. >>> >>> Simon >>> >>> *From:* Glasgow-haskell-users [mailto:glasgow- >>> haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott >>> *Sent:* 14 April 2014 06:00 >>> *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >>> *Subject:* Help with coercion & roles? >>> >>> >>> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and >>> running into trouble with coercions & roles. Error message from Core Lint: >>> >>> Warning: In the expression: >>> >>> >>> >>> LambdaCCC.Lambda.lamvP# >>> >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> @ (Simple.HasIf GHC.Types.Bool) >>> >>> "tpl"# >>> >>> ((LambdaCCC.Lambda.varP# >>> >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> "tpl"#) >>> >>> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> ? LambdaCCC.Lambda.EP >>> >>> (GHC.Types.Bool >>> >>> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> ~# >>> >>> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >>> >>> Role incompatibility: expected nominal, got representational >>> >>> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> Do you see anything inconsistent/incompatible in the coercions or roles >>> above? I constructed the nominal EP Refl coercion, and applied it (AppCo) >>> an existing coercion of a simpler type. >>> >>> Thanks, >>> -- Conal >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Apr 14 07:27:22 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 14 Apr 2014 00:27:22 -0700 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: <87vbucidls.fsf@gmail.com> References: <87vbucidls.fsf@gmail.com> Message-ID: <1397460226-sup-5944@sabre> Hey Gergo, It looks like this failure came from one of your commits, which didn't include a submodule update. One trick that I find very useful for making sure that I haven't missed any files when submitting a patch is to always run 'git status' before I push, and carefully look at all the output, especially staged but not committed changes. I think Simon Marlow is even more conservative, and does his validate builds in a separate tree so he catches missing files. Edward Excerpts from Herbert Valerio Riedel's message of 2014-04-14 00:17:51 -0700: > Hi, > > (probably) fixed by > > http://git.haskell.org/ghc.git/commitdiff/b4a820f97e48199a92f5ce7216731500f9a841c9 > > > > On 2014-04-14 at 09:15:42 +0200, P?li G?bor J?nos wrote: > > [...] > > > utils/haddock/src/Haddock/Interface/Create.hs:367:44: > > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > > with '(a1, Located (HsBind id))' > > Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) > > Actual type: TyClDecl Name -> LHsBinds Name > > Relevant bindings include > > defs :: [Located (HsDecl id)] > > (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) > > In the second argument of '(.)', namely 'tcdMeths' > > In the second argument of '(.)', namely 'bagToList . tcdMeths' > > utils/haddock/src/Haddock/Interface/Create.hs:393:22: > > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > > with '(a0, Located (HsBind Name))' > > Expected type: HsValBindsLR Name Name > > -> [(a0, Located (HsBind Name))] > > Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] > > In the first argument of '(.)', namely 'valbinds' > > In the second argument of '(.)', namely 'valbinds . hs_valds' > > gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 > > gmake: *** [all] Error 2 > > > > Please consult the details at > > > > http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html > From ezyang at mit.edu Mon Apr 14 09:25:27 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 14 Apr 2014 02:25:27 -0700 Subject: Git problem In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1397467470-sup-3200@sabre> Hey Simon, If you have no Haddock changes, try cd'ing into the haddock directory and doing a hard reset to the remote origin (so something like git reset --hard origin/master *INSIDE HADDOCK*), and then changing back to the main directory and git add'ing the directory. Edward Excerpts from Simon Peyton Jones's message of 2014-04-14 02:13:02 -0700: > Friends > I'm stuck with Git. Help please! > Simon > > I tried to do a 'git stash pop', having just done a 'git pull' from the master repo. I got this: > > simonpj at cam-05-unx:~/code/HEAD-2$ git stash pop > > warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) > > Auto-merging utils/haddock > > CONFLICT (submodule): Merge conflict in utils/haddock > > Auto-merging compiler/typecheck/TcRnMonad.lhs > Now git status says > > simonpj at cam-05-unx:~/code/HEAD-2$ git status > > # On branch master > > # Your branch is ahead of 'origin/master' by 2 commits. > > # > > # Changes to be committed: > > # (use "git reset HEAD ..." to unstage) > > # > > # modified: compiler/typecheck/TcMType.lhs > > # modified: compiler/typecheck/TcRnMonad.lhs > > # modified: compiler/typecheck/TcSimplify.lhs > > # modified: compiler/typecheck/TcUnify.lhs > > # > > # Unmerged paths: > > # (use "git reset HEAD ..." to unstage) > > # (use "git add/rm ..." as appropriate to mark resolution) > > # > > # both modified: utils/haddock > The modified files are right. It's the "both modified utils/haddock" that is messing me up. > I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying > > # modified: utils/haddock (new commits) From kazu at iij.ad.jp Tue Apr 15 03:38:54 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 15 Apr 2014 12:38:54 +0900 (JST) Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <87ob05mzid.fsf@gmail.com> References: <87ob05mzid.fsf@gmail.com> Message-ID: <20140415.123854.1767044038178955750.kazu@iij.ad.jp> Hi Herbert, > After a short conversion with Austin and Edward it appears that the > sensible course of action with respect towards moving to a proper Git > submodule set-up is to fold-in the 5 Git repos listed below (which btw > are all GHC wired-in packages) directly into ghc.git (the same way > testsuite.git was a few months ago): This is just a confirmation. I have no opinion on this. Recalling the discussion in the last summer, I understood GHC project will start using git subtree, not git submodule. But it seems to me this is my misunderstanding. What was the conclusion of that discussion? And would you tell me why submodule was chosen? --Kazu From jan.stolarek at p.lodz.pl Tue Apr 15 04:52:42 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 15 Apr 2014 05:52:42 +0100 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: <1397460226-sup-5944@sabre> References: <87vbucidls.fsf@gmail.com> <1397460226-sup-5944@sabre> Message-ID: <201404150652.43183.jan.stolarek@p.lodz.pl> > I think Simon Marlow is even more conservative, and > does his validate builds in a separate tree so he catches missing files. I thought everyone is doing that. Janek From hvriedel at gmail.com Tue Apr 15 07:40:40 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 15 Apr 2014 09:40:40 +0200 Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <20140415.123854.1767044038178955750.kazu@iij.ad.jp> ("Kazu Yamamoto \=\?utf-8\?B\?KOWxseacrOWSjOW9pikiJ3M\=\?\= message of "Tue, 15 Apr 2014 12:38:54 +0900 (JST)") References: <87ob05mzid.fsf@gmail.com> <20140415.123854.1767044038178955750.kazu@iij.ad.jp> Message-ID: <87vbubavlz.fsf@gmail.com> On 2014-04-15 at 05:38:54 +0200, Kazu Yamamoto (????) wrote: > Hi Herbert, > >> After a short conversion with Austin and Edward it appears that the >> sensible course of action with respect towards moving to a proper Git >> submodule set-up is to fold-in the 5 Git repos listed below (which btw >> are all GHC wired-in packages) directly into ghc.git (the same way >> testsuite.git was a few months ago): > > This is just a confirmation. I have no opinion on this. > > Recalling the discussion in the last summer, I understood GHC project > will start using git subtree, not git submodule. But it seems to me > this is my misunderstanding. > > What was the conclusion of that discussion? And would you tell me why > submodule was chosen? I believe you refer to http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1179 and the spin-off thread http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1237 However, I couldn't find any conclusion while skimming through the threads stating that using 'git subtree' would have been the conclusion. Otoh, I can offer part of the motivation for using `git submodules` from my current point of view from the top of my head: - We already use Git submodules for half the sub-repos, using a mix of submodules and subtrees might become too confusing. - The remaining (after the wired-in packages are folded in) non-yet Git-submoduled repos at git.haskell.org are candidates for being moved to http://github.com/haskell/ (most are not specific to GHC (in theory at least) and are to become managed more actively by the core library committee, read "outsourced"), so they'd essentially become 3rd party tracked upstream repos, which is exactly the use-case that Git submodules are suited for. - Git subtrees embed the sub-repos' content into the super-repo, therefore once you don't need the subrepo anymore, you still have to carry around its content forever in the superproject. Git submodules only require to store the sub-repos commit-ids in the the super-repo (Git Submodules are basically what GHC fingerprints would provide if the GHC fingerprint would be checked into ghc.git and kept up-to-date with each ghc.git commit) - Git subtree is actually a Git contrib-script and may not be available in all Git installations. Submodules, otoh, have been an integral part of Git since version 1.5.3 Cheers, hvr From gergo at erdi.hu Tue Apr 15 13:19:30 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Tue, 15 Apr 2014 21:19:30 +0800 (SGT) Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: <1397460226-sup-5944@sabre> References: <87vbucidls.fsf@gmail.com> <1397460226-sup-5944@sabre> Message-ID: On Mon, 14 Apr 2014, Edward Z. Yang wrote: > Hey Gergo, > > It looks like this failure came from one of your commits, which didn't > include a submodule update. Noted, thanks. The git submodule voodoo is still a bit new to me. From kazu at iij.ad.jp Wed Apr 16 06:09:40 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 16 Apr 2014 15:09:40 +0900 (JST) Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <87vbubavlz.fsf@gmail.com> References: <87ob05mzid.fsf@gmail.com> <20140415.123854.1767044038178955750.kazu@iij.ad.jp> <87vbubavlz.fsf@gmail.com> Message-ID: <20140416.150940.1857560944419504019.kazu@iij.ad.jp> Hi Herbert, Thank you for your kind explanation! --Kazu > Otoh, I can offer part of the motivation for using `git submodules` from > my current point of view from the top of my head: > > - We already use Git submodules for half the sub-repos, using a mix of > submodules and subtrees might become too confusing. > > - The remaining (after the wired-in packages are folded in) non-yet > Git-submoduled repos at git.haskell.org are candidates for being > moved to http://github.com/haskell/ (most are not specific to GHC (in > theory at least) and are to become managed more actively by the core > library committee, read "outsourced"), so they'd essentially become > 3rd party tracked upstream repos, which is exactly the use-case that > Git submodules are suited for. > > - Git subtrees embed the sub-repos' content into the super-repo, > therefore once you don't need the subrepo anymore, you still have to > carry around its content forever in the superproject. Git submodules > only require to store the sub-repos commit-ids in the the super-repo > > (Git Submodules are basically what GHC fingerprints would provide if > the GHC fingerprint would be checked into ghc.git and kept up-to-date > with each ghc.git commit) > > - Git subtree is actually a Git contrib-script and may not be available > in all Git installations. Submodules, otoh, have been an integral > part of Git since version 1.5.3 > > Cheers, > hvr From pavel.ryzhov at gmail.com Wed Apr 16 13:21:22 2014 From: pavel.ryzhov at gmail.com (Pavel Ryzhov) Date: Wed, 16 Apr 2014 15:21:22 +0200 Subject: 7.8.2 bugs and beyond In-Reply-To: References: Message-ID: Hi Austin, Here is my build of 32-bit bindist and IPS package for Solaris 11.1: http://c1473.eu01.webzillafiles.com/ghc/ghc-7.8.2-i386-unknown-solaris2.tar.bz2 http://c1473.eu01.webzillafiles.com/ghc/ghc-7.8.2.i386.p5p http://c1473.eu01.webzillafiles.com/ghc/SHA256SUMS I hope I will have a free time next week to progress to 64-bit build of GHC for Solaris 11.1. Best regards, Pavel On 12 Apr 2014, at 01:51, Austin Seipp wrote: > Hi all, > > The 7.8.2 source tarball is here. I actually have most of the binaries > ready, but I forgot to send this in advance: > > http://www.haskell.org/ghc/dist/7.8.2/ > > Please build when you get a chance. I'll probably go ahead and > announce shortly to get the bugfix into peoples hands, and we can > incrementally add new tarballs. > > Thanks! > > On Thu, Apr 10, 2014 at 7:53 AM, Austin Seipp wrote: >> Hello all, >> >> Misfortune has struck unfortunately - we shipped with a bit of an >> awful bug in 7.8.1, see #8978. The good news is Simon already has a >> fix! Yay! >> >> However, I'll probably be going ahead and releasing an immediate >> today. For everyone, I don't think this changes much regarding my last >> email - just substitute '7.8.2' with '7.8.3' where you might see it. >> >> Here's the list of 7.8.3 bugs for reference, I migrated the old 7.8.2 >> tickets here: >> >> https://ghc.haskell.org/trac/ghc/query?milestone=7.8.3&group=status >> >> Thanks! >> >> On Wed, Apr 9, 2014 at 7:34 PM, Austin Seipp wrote: >>> Hello all, >>> >>> 7.8.1 is out. Yay! Now, on to the next thing. >>> >>> Here's the very preliminary 7.8.2 buglist: >>> >>> - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 >>> >>> Note that this list has effectively received zero curation so far. I >>> plan on fixing that soon, and in the process I am probably going to >>> touch a lot of trac tickets (so I apologize in advance for the mail >>> spam, because y'all are probably going to get a lot of it). This will >>> include re-prioritizing these bugs, so take things with a grain of >>> salt right now. >>> >>> Note that the bug tracker now has 7.8.1 as the default version - if >>> you're filing bugs, please be sure to try it first of course. :) And >>> don't forget to set the milestone to 7.8.2 if you think it qualifies >>> for a fix. There are already a couple of things in the merge queue. >>> >>> There's currently no expected date for 7.8.2. Should it arrive >>> quickly? Or slowly? Simon, Simon and I are inclined to just let things >>> play out for a while of course, which is the traditional way things >>> are done. But this release window has been especially awkward, so >>> we'll see what happens. >>> >>> This of course leaves timeline questions for 7.10 open - but before we >>> decide that, now's a time to just get some hacking done I suppose... >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From iavor.diatchki at gmail.com Wed Apr 16 15:44:00 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 16 Apr 2014 08:44:00 -0700 Subject: Git problem In-Reply-To: <87mwfoi6nz.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> <87mwfoi6nz.fsf@gmail.com> Message-ID: Hello, I think the commands Herbert suggested should help. I find it useful to have a mental model of what's going on with git, so here is a brief explanation, in case it is useful. The main observation is that Git not only keeps track of the state of all files in the repo, but also the states of all related repositories (aka, the sub-modules). So this is probably what happened: 1. `git stash`: Git remembered which files were modified, and the current commit for `haddock` (and other sub-modules) 2. `git pull`: Git got some changes for the remote server, and it happened that the current commit for `haddock` changed. 3. `git pop`: Git needs to apply the saved changes but in the new setting. It managed to automatically merge the modified files, but it does not know which is the correct current commit for haddock: do you want to use the newly downloaded version, or the one that was saved when you created the stash? So Herbert's commands tell it what to do: the first command tells it to set the current commit for haddock to the one in the remote repo (i.e., you are not interested in the stashed version); the second command tells it to remember this, so that the change will be committed later. Cheers, -Iavor On Mon, Apr 14, 2014 at 2:47 AM, Herbert Valerio Riedel wrote: > On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote: > > [...] > > > # both modified: utils/haddock > > > The modified files are right. It's the "both modified utils/haddock" > that is messing me up. > > I'm not modifying haddock! I just want to say "take the master > haddock", but I don't know how. I tried 'git checkout utils/haddock' but > that just led do `git status' saying > > > > # modified: utils/haddock (new commits) > > Fyi, the git equivalent of saying "take the master haddock" (where > 'master' refers to 'master' of 'haddock.git'): > > # checkout master of haddock.git: > git submodule update --remote utils/haddock > > # register state (= submod commit-id) of utils/haddock for next commit > git add utils/haddock > > HTH, hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Thu Apr 17 02:44:57 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 17 Apr 2014 02:44:57 +0000 Subject: ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) Message-ID: <534F4029.5020100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get the following error every time I run the ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) This appears to be the kernel returning EAGAIN (non-fatal) on an IO request. I'm not sure why it crashes the builder-client. I would expect hGetLine to retry in this case. I'm running this on SmartOS, which is an Illumos (OpenSolaris 10 compatible) distro. Here's a log of an entire run: https://gist.github.com/AlainODea/12a74a05b52c334614d9 Here's a snippet around the problem: Running "touching clean-check files" Running "setting version date" Running "booting" builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) [2014-04-17 02:21:08] [smartos-x86-head] Sending: "UPLOAD 14 1" Received: "202 Send name" Received: "202 Send subdir" Received: "202 Send program" Has anyone seen something like this before? Thanks, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTT0ApAAoJEP0rIXJNjNSAFbcH/29X7XvvMjGg/DWocap7D40f QOrVNTAipRcRSvEeCQh61hAAouabC2MkXts/8qM171xSghHArlYqe5XLkeKUDpo+ RiuyQER2t5fiZU1u8TywdMOm0NegxySiltEKooKpWzIzDzZHX7ggDUQlWTVzFgmR S50OsF8z9i3t8EF4N23J/Y78qca97iTn+Rw9qYl8Nc4vbhd+1Mqrsd25KDBK73Vk 5Hzy+HFy6yaJIEF3Rpda1Wr1CYKT4mwW6wAoTOeAK3obogwWX1mBzpV4MDt/5NBZ 9qet+2n59jkk0aaXJszXqNz4T0MTpMXgummjiLghyxtFJu71bvv3Xs6FXwgP23I= =6fKZ -----END PGP SIGNATURE----- From simonpj at microsoft.com Thu Apr 17 07:06:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 17 Apr 2014 07:06:40 +0000 Subject: Link failure Message-ID: <618BE556AADD624C9C918AA5D5911BEF15F4AC@DB3PRD3001MB020.064d.mgd.msft.net> On 64-bit Linux I'm getting this in the link step for the template-haskell library: /usr/bin/ld: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: relocation R_X86_64_PC32 against undefined symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so] Error 1 make[1]: *** [all_libraries/template-haskell] Error 2 make[1]: Leaving directory `/5playpen/simonpj/HEAD-1' My compiler is not vanilla HEAD, but I have changed only stuff in the Core simplifier, nothing in the back end. Does anyone have the faintest idea what is going on? It's extremely annoying because I can't make progress without working around it somehow. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 17 07:12:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 17 Apr 2014 07:12:03 +0000 Subject: Link failure In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF15F4AC@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF15F4AC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF15F4E3@DB3PRD3001MB020.064d.mgd.msft.net> sorry, ignore me - I assume it's #8696 and my tree is fairly old. I'll update. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones Sent: 17 April 2014 08:07 To: ghc-devs at haskell.org Subject: Link failure On 64-bit Linux I'm getting this in the link step for the template-haskell library: /usr/bin/ld: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: relocation R_X86_64_PC32 against undefined symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so] Error 1 make[1]: *** [all_libraries/template-haskell] Error 2 make[1]: Leaving directory `/5playpen/simonpj/HEAD-1' My compiler is not vanilla HEAD, but I have changed only stuff in the Core simplifier, nothing in the back end. Does anyone have the faintest idea what is going on? It's extremely annoying because I can't make progress without working around it somehow. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 17 07:37:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 17 Apr 2014 07:37:49 +0000 Subject: Git problem In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156093@DB3PRD3001MB020.064d.mgd.msft.net> <87mwfoi6nz.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF15F5B1@DB3PRD3001MB020.064d.mgd.msft.net> Thank you ? that?s helpful. It?s the mental model that I miss! Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 16 April 2014 16:44 To: Herbert Valerio Riedel Cc: Simon Peyton Jones; ghc-devs Subject: Re: Git problem Hello, I think the commands Herbert suggested should help. I find it useful to have a mental model of what's going on with git, so here is a brief explanation, in case it is useful. The main observation is that Git not only keeps track of the state of all files in the repo, but also the states of all related repositories (aka, the sub-modules). So this is probably what happened: 1. `git stash`: Git remembered which files were modified, and the current commit for `haddock` (and other sub-modules) 2. `git pull`: Git got some changes for the remote server, and it happened that the current commit for `haddock` changed. 3. `git pop`: Git needs to apply the saved changes but in the new setting. It managed to automatically merge the modified files, but it does not know which is the correct current commit for haddock: do you want to use the newly downloaded version, or the one that was saved when you created the stash? So Herbert's commands tell it what to do: the first command tells it to set the current commit for haddock to the one in the remote repo (i.e., you are not interested in the stashed version); the second command tells it to remember this, so that the change will be committed later. Cheers, -Iavor On Mon, Apr 14, 2014 at 2:47 AM, Herbert Valerio Riedel > wrote: On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote: [...] > # both modified: utils/haddock > The modified files are right. It's the "both modified utils/haddock" that is messing me up. > I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying > > # modified: utils/haddock (new commits) Fyi, the git equivalent of saying "take the master haddock" (where 'master' refers to 'master' of 'haddock.git'): # checkout master of haddock.git: git submodule update --remote utils/haddock # register state (= submod commit-id) of utils/haddock for next commit git add utils/haddock HTH, hvr _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Thu Apr 17 14:19:21 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Thu, 17 Apr 2014 16:19:21 +0200 Subject: Proposal - Foreign enum support Message-ID: Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support =============================== At the moment the FFI does not have a convenient way with interacting enums (whether proper enums or CPP defines) in C (like languages). Both enums and CPP defined enums are major parts of large C APIs and they are thus crucial to writing foreign bindings. A few examples: SDL_image defines the following enum: typedef enum { IMG_INIT_JPG = 0x00000001, IMG_INIT_PNG = 0x00000002, IMG_INIT_TIF = 0x00000004, IMG_INIT_WEBP = 0x00000008 } IMG_InitFlags; OpenCL specifies the following typedefs + CPP defined enum: typedef uint32_t cl_uint __attribute__((aligned(4))); typedef cl_uint cl_platform_info; /* cl_platform_info */ #define CL_PLATFORM_PROFILE 0x0900 #define CL_PLATFORM_VERSION 0x0901 #define CL_PLATFORM_NAME 0x0902 #define CL_PLATFORM_VENDOR 0x0903 #define CL_PLATFORM_EXTENSIONS 0x0904 OpenCL functions will return the above CPP defines as return values of type cl_platform_info. Current Solutions ----------------- In many cases someone wrapping such a C library would like to expose these enums as a simple sum type as this has several benefits: type safety, the ability to use haskell constructors for pattern matching, exhaustiveness checks. Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set of foreign types and newtypes with exposed constructors of these types. As such there seem two approaches to wrap these enums: 1. Implement an ADT representing the enum and write a manual conversion function between the ADT and the corresponding C type (e.g. CInt -> Foo and Foo -> CInt). 2. Use a tool like c2hs to automatically generate the ADT and conversion function. In both cases the foreign functions are imported using the corresponding C type in their signature (reducing type safety) and the user is forced write trivial wrappers for every imported function to convert the ADT to the relevant C type and back. This is both tedious to write and costly in terms of code produced, in case of c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every argument/result even though this could trivially be a no-op. Worse, since c2hs uses the Enum class for it's conversion to/from C types it generates Enum instances like: instance Enum Foo where fromEnum Bar = 1 fromEnum Baz = 1337 toEnum 1 = Bar toEnum 1337 = Baz toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) Since succ/pred and enumFromTo's default implementations assume enums convert to continuous sequence of Int this means the default generated enum instances crash. This problem could be overcome by making c2hs' code generation smarter, but this does not eliminate the tediousness of wrapping all foreign imported functions with marshalling wrappers, NOR does it eliminate the overhead of all this useless marshalling. Proposal -------- Add a new foreign construct for enums, the syntax I propose below is rather ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining based on a concrete example. foreign enum CInt as Foo where Bar = 1 Baz Quux = 1337 Xyzzy = _ This would introduce a new type 'Foo' with semantics approximately equivalent too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". Explicit listing of the value corresponding to a constructor should be optional, missing values should just increment by one from the previous (like C), if the initial value is missing, it should assume to start from 0. Values do not need to be contiguous. Users should be able to use these constructors as normal in pattern match (really, this mostly follows to semantics of the above pattern synonyms). The foreign import/export functionality should invisibly marshall Foo to the underlying foreign type (as is done for newtypes). I'm unsure about the support for a wildcard constructor like Xyzzy. If there is support for a wildcard, it should be optional. On the upside a wildcard means the marshalling is no longer a partial function. The downside is that it makes desugaring the use of enums in patterns harder. It seems clear that f Xyzzy = {- ... -} f Bar = {- ... -} f Baz = {- ... -} f Quux = {- ... -} Should not have the same semantics as: f (Foo _) = {- ... -} f (Foo 1) = {- ... -} f (Foo 2) = {- ... -} f (Foo 1337) = {- ... -} So in the presence of wildcards, the Foo enum can't trivially be desugared into pattern synonyms after checking exhaustiveness. Pros: 1. Foreign imports are slightly more type safe, as one can now write: foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () Preventing users from passing an arbitrary CInt to an argument expecting a specific enum. 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness checks and pattern matching 3. Cheaper as marshalling Foo to CInt is a no-op 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int mapping is no longer used for marshalling Cons: 1. Non-standard extension of the FFI 2. Someone has to implement it 3. Wildcards constructors would present difficulties desugaring pattern matches to a simple newtype. 4. ?? What Would Need to be Done? --------------------------- 1. Parser needs to be extended to deal with parsing of enum declarations. 2. Pattern matches of an enum type need to be checked for exhaustiveness and desugared to the underlying type's representation. 3. Extend foreign imports/exports to marshall enums properly. If there's no objections I'm willing to take a stab at implementing this, although I'd probably need some help with GHC's internals (although I could bug #ghc for that). Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From roma at ro-che.info Thu Apr 17 14:36:36 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 17 Apr 2014 17:36:36 +0300 Subject: Proposal - Foreign enum support In-Reply-To: References: Message-ID: <20140417143636.GA16407@sniper> I am reluctant about adding a new syntactic feature for such a niche problem. Can't this be achieved with a quaiquoter? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From carter.schonwald at gmail.com Thu Apr 17 15:25:19 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 17 Apr 2014 11:25:19 -0400 Subject: Proposal - Foreign enum support In-Reply-To: <20140417143636.GA16407@sniper> References: <20140417143636.GA16407@sniper> Message-ID: Agreed. A quasiquoter is the right approach here. On Thursday, April 17, 2014, Roman Cheplyaka wrote: > I am reluctant about adding a new syntactic feature for such a niche > problem. > > Can't this be achieved with a quaiquoter? > > Roman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Thu Apr 17 16:06:44 2014 From: jwlato at gmail.com (John Lato) Date: Thu, 17 Apr 2014 09:06:44 -0700 Subject: Proposal - Foreign enum support In-Reply-To: References: Message-ID: I wouldn't be keen on adding such a specific feature to the language either. Another concern is that this proposal doesn't seem to address a very common use case for C enums, bit vectors. IMHO any FFI proposal for working with C enums should take that idiom into account. On Apr 17, 2014 7:19 AM, "Merijn Verstraaten" wrote: > Cross-post to haskell-prime in case there's any interest for including > this into the report's FFI specification. > > Proposal - Foreign enum support > =============================== > > At the moment the FFI does not have a convenient way with interacting enums > (whether proper enums or CPP defines) in C (like languages). Both enums > and CPP > defined enums are major parts of large C APIs and they are thus crucial to > writing foreign bindings. A few examples: > > SDL_image defines the following enum: > > typedef enum { > IMG_INIT_JPG = 0x00000001, > IMG_INIT_PNG = 0x00000002, > IMG_INIT_TIF = 0x00000004, > IMG_INIT_WEBP = 0x00000008 > } IMG_InitFlags; > > OpenCL specifies the following typedefs + CPP defined enum: > > typedef uint32_t cl_uint __attribute__((aligned(4))); > typedef cl_uint cl_platform_info; > > /* cl_platform_info */ > #define CL_PLATFORM_PROFILE 0x0900 > #define CL_PLATFORM_VERSION 0x0901 > #define CL_PLATFORM_NAME 0x0902 > #define CL_PLATFORM_VENDOR 0x0903 > #define CL_PLATFORM_EXTENSIONS 0x0904 > > OpenCL functions will return the above CPP defines as return values of type > cl_platform_info. > > Current Solutions > ----------------- > > In many cases someone wrapping such a C library would like to expose these > enums as a simple sum type as this has several benefits: type safety, the > ability to use haskell constructors for pattern matching, exhaustiveness > checks. > > Currently the GHC FFI, as specified by Haskell2010, only marshalls a small > set > of foreign types and newtypes with exposed constructors of these types. As > such > there seem two approaches to wrap these enums: > > 1. Implement an ADT representing the enum and write a manual conversion > function between the ADT and the corresponding C type (e.g. CInt -> > Foo and > Foo -> CInt). > > 2. Use a tool like c2hs to automatically generate the ADT and conversion > function. > > In both cases the foreign functions are imported using the corresponding C > type > in their signature (reducing type safety) and the user is forced write > trivial > wrappers for every imported function to convert the ADT to the relevant C > type > and back. > > This is both tedious to write and costly in terms of code produced, in > case of > c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for > every > argument/result even though this could trivially be a no-op. > > Worse, since c2hs uses the Enum class for it's conversion to/from C types > it > generates Enum instances like: > > instance Enum Foo where > fromEnum Bar = 1 > fromEnum Baz = 1337 > > toEnum 1 = Bar > toEnum 1337 = Baz > toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ > show unmatched) > > Since succ/pred and enumFromTo's default implementations assume enums > convert > to continuous sequence of Int this means the default generated enum > instances > crash. This problem could be overcome by making c2hs' code generation > smarter, > but this does not eliminate the tediousness of wrapping all foreign > imported > functions with marshalling wrappers, NOR does it eliminate the overhead of > all > this useless marshalling. > > Proposal > -------- > > Add a new foreign construct for enums, the syntax I propose below is rather > ugly and ambiguous and thereforeopen to bikeshedding, but I prefer > explaining > based on a concrete example. > > foreign enum CInt as Foo where > Bar = 1 > Baz > Quux = 1337 > Xyzzy = _ > > This would introduce a new type 'Foo' with semantics approximately > equivalent > too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo > 1; > pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". > > Explicit listing of the value corresponding to a constructor should be > optional, missing values should just increment by one from the previous > (like > C), if the initial value is missing, it should assume to start from 0. > Values > do not need to be contiguous. > > Users should be able to use these constructors as normal in pattern match > (really, this mostly follows to semantics of the above pattern synonyms). > > The foreign import/export functionality should invisibly marshall Foo to > the > underlying foreign type (as is done for newtypes). > > I'm unsure about the support for a wildcard constructor like Xyzzy. If > there is > support for a wildcard, it should be optional. On the upside a wildcard > means > the marshalling is no longer a partial function. The downside is that it > makes > desugaring the use of enums in patterns harder. It seems clear that > > f Xyzzy = {- ... -} > f Bar = {- ... -} > f Baz = {- ... -} > f Quux = {- ... -} > > Should not have the same semantics as: > > f (Foo _) = {- ... -} > f (Foo 1) = {- ... -} > f (Foo 2) = {- ... -} > f (Foo 1337) = {- ... -} > > So in the presence of wildcards, the Foo enum can't trivially be desugared > into > pattern synonyms after checking exhaustiveness. > > Pros: > 1. Foreign imports are slightly more type safe, as one can now write: > > foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () > > Preventing users from passing an arbitrary CInt to an argument > expecting a > specific enum. > > 2. No need to write marshalling functions to/from ADT to obtain > exhaustiveness > checks and pattern matching > > 3. Cheaper as marshalling Foo to CInt is a no-op > > 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this > Int > mapping is no longer used for marshalling > > Cons: > 1. Non-standard extension of the FFI > > 2. Someone has to implement it > > 3. Wildcards constructors would present difficulties desugaring pattern > matches to a simple newtype. > > 4. ?? > > What Would Need to be Done? > --------------------------- > > 1. Parser needs to be extended to deal with parsing of enum declarations. > 2. Pattern matches of an enum type need to be checked for exhaustiveness > and > desugared to the underlying type's representation. > 3. Extend foreign imports/exports to marshall enums properly. > > If there's no objections I'm willing to take a stab at implementing this, > although I'd probably need some help with GHC's internals (although I > could bug > #ghc for that). > > Cheers, > Merijn > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjgajda at gmail.com Fri Apr 18 06:12:16 2014 From: mjgajda at gmail.com (=?UTF-8?Q?Micha=C5=82_J_Gajda?=) Date: Fri, 18 Apr 2014 14:12:16 +0800 Subject: GHC's performance In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Dear Friends, I have a few weeks free just now, and a keen interest in GHC performance, so please count me in as a person interested in developing the solution :-). On Thu, Apr 10, 2014 at 5:57 PM, Johan Tibell wrote: > There are a few "projects" in this area I think we should undertake: > > ## Set up a performance dashboard > > Example: http://goperfd.appspot.com/ (try clicking the "Perf" and > "Graphs" buttons.) > > I think the way to go here is: > > * Figure out how to build GHC and run the nofib suite in a repeatable > (i.e. scripted) manner. > Wouldn't it be faster to take GHC builds from the current builder? I understand that running GHC build for each commit may take some time... Where would be put the infrastructure? I could help to set it up, but I do not possess enough CPU power to hold it for a long time. I do not know how current builders are set up, and if it would be possible to indicate some of them as having exclusivity for their machine. If so, would it be better to add perf test and database submission as a last step for the test suite? As long as access is not anonymous (to prevent spam), such a database might provide a better coverage of performance data over tier-2 architectures. -- Best regards Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Apr 18 09:34:58 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 11:34:58 +0200 Subject: GHC's performance In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF15240F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Fri, Apr 18, 2014 at 8:12 AM, Micha? J Gajda wrote: > Dear Friends, > > I have a few weeks free just now, and a keen interest in GHC performance, > so please count me in as a person interested in developing the solution :-). > > On Thu, Apr 10, 2014 at 5:57 PM, Johan Tibell wrote: > >> There are a few "projects" in this area I think we should undertake: >> >> ## Set up a performance dashboard >> >> Example: http://goperfd.appspot.com/ (try clicking the "Perf" and >> "Graphs" buttons.) >> >> I think the way to go here is: >> >> * Figure out how to build GHC and run the nofib suite in a repeatable >> (i.e. scripted) manner. >> > > Wouldn't it be faster to take GHC builds from the current builder? > I understand that running GHC build for each commit may take some time... > Where would be put the infrastructure? > I could help to set it up, but I do not possess enough CPU power to hold > it for a long time. > Don't worry too much about how you build GHC. Any way that works is fine. The important part is that it's simple and works. If it can be written as a simple shell script + some tools to post-process the output, it would be easy to run on Jenkins. Also, don't worry about finding a machine that can run the benchmarks concurrently. If you get a dashboard and continuous build that works on your development machine, we can find a real server for it (e.g. I have an unused http://www.hetzner.de/en/hosting/produkte_rootserver/ex40) So here's what I'd suggest: 1. Write a script that builds and runs the benchmarks on your local machine. 2. Write something that massages the output into a format that can be pushed to whatever database the perf dashboard would user. 3. Get a dashboard up and running. 4. Tell us about the results. We'll find machines to run it on. Feel free to ask questions if you get stuck anywhere. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Apr 18 10:13:14 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 18 Apr 2014 12:13:14 +0200 Subject: strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure] In-Reply-To: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> References: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> Message-ID: <5350FABA.6000209@centrum.cz> Folks, last two/three builds on Solaris builder fails due to a reason that someone added (probably) stripping of installed libraries. My bet is on 8992d5269804b727fb77249511e89df678526907 -- hence ccing you Herbert, but I'm not sure... The problem is that invoked strip command line is incompatible with Solaris' strip which then fails with: strip: --strip-unneeded: cannot open file: No such file or directory the problem is usage of --strip-unneeded command-line argument? It looks like this argument is supported by just GNU strip. Do we really need to use it? If not, removing this may solve the issue. If yes, then I'll need to come with some workaround for Solaris... Detailed log of failure is at the bottom of http://haskell.inf.elte.hu/builders/solaris-x86-head/32/20.html Thanks! Karel On 04/18/14 05:03 AM, Builder wrote: > solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32 > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading tarball source | Success > testing bindist | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-builds From hvriedel at gmail.com Fri Apr 18 10:20:02 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 18 Apr 2014 12:20:02 +0200 Subject: strip related failure [ In-Reply-To: <5350FABA.6000209@centrum.cz> (Karel Gardas's message of "Fri, 18 Apr 2014 12:13:14 +0200") References: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> <5350FABA.6000209@centrum.cz> Message-ID: <87oazz2b3h.fsf@gmail.com> On 2014-04-18 at 12:13:14 +0200, Karel Gardas wrote: > Folks, > > last two/three builds on Solaris builder fails due to a reason that > someone added (probably) stripping of installed libraries. My bet is > on 8992d5269804b727fb77249511e89df678526907 -- hence ccing you > Herbert, but I'm not sure... > > The problem is that invoked strip command line is incompatible with > Solaris' strip which then fails with: > > strip: --strip-unneeded: cannot open file: No such file or directory > > the problem is usage of --strip-unneeded command-line argument? It > looks like this argument is supported by just GNU strip. Do we really > need to use it? If not, removing this may solve the issue. If yes, > then I'll need to come with some workaround for Solaris... This sounds as if you'd want to file an issue and/or pull-request ASAP for Cabal 1.20 before it gets released; see also https://github.com/haskell/cabal/pull/1691 https://github.com/haskell/cabal/issues/1630 which were similiar issues for other platforms not supporting '--strip-unneeded' Cheers, hvr From johan.tibell at gmail.com Fri Apr 18 10:26:41 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 12:26:41 +0200 Subject: strip related failure [ In-Reply-To: <87oazz2b3h.fsf@gmail.com> References: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> <5350FABA.6000209@centrum.cz> <87oazz2b3h.fsf@gmail.com> Message-ID: On Fri, Apr 18, 2014 at 12:20 PM, Herbert Valerio Riedel wrote: > > This sounds as if you'd want to file an issue and/or pull-request ASAP > for Cabal 1.20 before it gets released; Just fixed this on the 1.20 branch: https://github.com/haskell/cabal/commit/8af39a5f827dcf5b5ca68badc2955e4cccbb039d -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Apr 18 10:27:28 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 12:27:28 +0200 Subject: strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure] In-Reply-To: <5350FABA.6000209@centrum.cz> References: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> <5350FABA.6000209@centrum.cz> Message-ID: Fixed on the Cabal 1.20 branch: https://github.com/haskell/cabal/commit/8af39a5f827dcf5b5ca68badc2955e4cccbb039d I suggest we update the submodule to use that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Apr 18 10:30:57 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 18 Apr 2014 12:30:57 +0200 Subject: strip related failure [ In-Reply-To: References: <535095ec.c5630e0a.1bb2.ffffa61c@mx.google.com> <5350FABA.6000209@centrum.cz> <87oazz2b3h.fsf@gmail.com> Message-ID: <5350FEE1.40707@centrum.cz> Fantastic! This was less then minute for a fix after issue was created! Thanks a lot! Karel On 04/18/14 12:26 PM, Johan Tibell wrote: > On Fri, Apr 18, 2014 at 12:20 PM, Herbert Valerio Riedel > > wrote: > > This sounds as if you'd want to file an issue and/or pull-request ASAP > for Cabal 1.20 before it gets released; > > > Just fixed this on the 1.20 branch: > https://github.com/haskell/cabal/commit/8af39a5f827dcf5b5ca68badc2955e4cccbb039d > > -- Johan > > From marlowsd at gmail.com Fri Apr 18 15:39:10 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 18 Apr 2014 16:39:10 +0100 Subject: Heap usage of GHC increased in 7.8 vs. 7.6 Message-ID: <5351471E.7080602@gmail.com> I noticed that T1969 is failing again, and decided to do a little investigation. The maximum residency when compiling T1969 with HEAD compared with 7.6.3 looks like this: 7.6.3: 10,473,920 HEAD: 13,783,536 This is with +RTS -h -i0.01 to avoid sampling errors as much as possible. The figures are pretty accurate, and the heap profiles confirm it: we're using a lot more heap now. -ddump-if-trace shows that HEAD is reading more interface files: Renamer stats: 10 interfaces read 6 type/class/variable imported, out of 1361 read 0 instance decls imported, out of 105 read 0 rule decls imported, out of 53 read vs. with 7.6.3: Renamer stats: 8 interfaces read 2 type/class/variable imported, out of 828 read 0 instance decls imported, out of 40 read 0 rule decls imported, out of 45 read The extra interface files are Control.Applicative and Control.Monad. So the question is, why are we now reading these on *every* compilation? (T1969 imports only the Prelude). Presumably this is something to do with the AMP warnings, but can't we lazily load these interfaces when they're needed? Cheers, Simon From austin at well-typed.com Fri Apr 18 19:42:33 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 18 Apr 2014 14:42:33 -0500 Subject: Heap usage of GHC increased in 7.8 vs. 7.6 In-Reply-To: <5351471E.7080602@gmail.com> References: <5351471E.7080602@gmail.com> Message-ID: Yes, you're right regarding the AMP patches. Concerning this, I looked the patch back up to refresh my memory, and there reason we do this was because we need to check (and warn) if there are locally defined names in the current module which would clash with names from the Applicative-Monad proposal, among others - notably, naming functions like 'join' or whatnot in the current scope clashes. This means we wire in the 'Name's for join, <*>, etc from Control.Applicative and Control.Monad so we can check against them later, which implies loading the interfaces I believe. Perhaps we don't even need a wired Name for this particular step, which would sidestep that issue. But thinking about it - even fixing that, is this even avoidable, ultimately? The AMP warnings in 7.8 are actually temporary, and will be gone from HEAD soon. But once we do that and AMP is actually *implemented* in base, won't it essentially imply the loading of these same interfaces by default, and thus about the same amount of memory use? Or is there a planned module refactoring/shuffling too, since we're already breaking some user code this cycle? If there is, maybe this won't be problematic in the end or we should revisit it when the numbers are solid. I honestly don't know what all the expected intra-module changes might be (I've CC'd Edward in case he'd like to chime in about that.) On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow wrote: > I noticed that T1969 is failing again, and decided to do a little > investigation. The maximum residency when compiling T1969 with HEAD > compared with 7.6.3 looks like this: > > 7.6.3: 10,473,920 > HEAD: 13,783,536 > > This is with +RTS -h -i0.01 to avoid sampling errors as much as possible. > The figures are pretty accurate, and the heap profiles confirm it: we're > using a lot more heap now. > > -ddump-if-trace shows that HEAD is reading more interface files: > > Renamer stats: 10 interfaces read > 6 type/class/variable imported, out of 1361 read > 0 instance decls imported, out of 105 read > 0 rule decls imported, out of 53 read > > vs. with 7.6.3: > > Renamer stats: 8 interfaces read > 2 type/class/variable imported, out of 828 read > 0 instance decls imported, out of 40 read > 0 rule decls imported, out of 45 read > > The extra interface files are Control.Applicative and Control.Monad. So the > question is, why are we now reading these on *every* compilation? (T1969 > imports only the Prelude). Presumably this is something to do with the AMP > warnings, but can't we lazily load these interfaces when they're needed? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From marlowsd at gmail.com Fri Apr 18 20:31:49 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 18 Apr 2014 21:31:49 +0100 Subject: Heap usage of GHC increased in 7.8 vs. 7.6 In-Reply-To: References: <5351471E.7080602@gmail.com> Message-ID: <53518BB5.30108@gmail.com> On 18/04/14 20:42, Austin Seipp wrote: > Yes, you're right regarding the AMP patches. Concerning this, I looked > the patch back up to refresh my memory, and there reason we do this > was because we need to check (and warn) if there are locally defined > names in the current module which would clash with names from the > Applicative-Monad proposal, among others - notably, naming functions > like 'join' or whatnot in the current scope clashes. This means we > wire in the 'Name's for join, <*>, etc from Control.Applicative and > Control.Monad so we can check against them later, which implies > loading the interfaces I believe. > > Perhaps we don't even need a wired Name for this particular step, > which would sidestep that issue. > > But thinking about it - even fixing that, is this even avoidable, > ultimately? The AMP warnings in 7.8 are actually temporary, and will > be gone from HEAD soon. But once we do that and AMP is actually > *implemented* in base, won't it essentially imply the loading of these > same interfaces by default, and thus about the same amount of memory > use? I don't think it will. Except for orphan modules, interfaces are normally only loaded when we actually use something defined in that module. Perhaps this isn't a huge deal since it's a small fixed overhead, but it bugs me nonetheless. Cheers, Simon > Or is there a planned module refactoring/shuffling too, since we're > already breaking some user code this cycle? If there is, maybe this > won't be problematic in the end or we should revisit it when the > numbers are solid. I honestly don't know what all the expected > intra-module changes might be (I've CC'd Edward in case he'd like to > chime in about that.) > > > On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow wrote: >> I noticed that T1969 is failing again, and decided to do a little >> investigation. The maximum residency when compiling T1969 with HEAD >> compared with 7.6.3 looks like this: >> >> 7.6.3: 10,473,920 >> HEAD: 13,783,536 >> >> This is with +RTS -h -i0.01 to avoid sampling errors as much as possible. >> The figures are pretty accurate, and the heap profiles confirm it: we're >> using a lot more heap now. >> >> -ddump-if-trace shows that HEAD is reading more interface files: >> >> Renamer stats: 10 interfaces read >> 6 type/class/variable imported, out of 1361 read >> 0 instance decls imported, out of 105 read >> 0 rule decls imported, out of 53 read >> >> vs. with 7.6.3: >> >> Renamer stats: 8 interfaces read >> 2 type/class/variable imported, out of 828 read >> 0 instance decls imported, out of 40 read >> 0 rule decls imported, out of 45 read >> >> The extra interface files are Control.Applicative and Control.Monad. So the >> question is, why are we now reading these on *every* compilation? (T1969 >> imports only the Prelude). Presumably this is something to do with the AMP >> warnings, but can't we lazily load these interfaces when they're needed? >> >> Cheers, >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > From adam at well-typed.com Fri Apr 18 16:38:32 2014 From: adam at well-typed.com (Adam Gundry) Date: Fri, 18 Apr 2014 17:38:32 +0100 Subject: OverloadedRecordFields In-Reply-To: <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com> References: <52D9029C.7030500@well-typed.com> <59543203684B2244980D7E4057D5FBC1487194AB@DB3EX14MBXC306.europe.corp.microsoft.com> <530B04C1.1050408@well-typed.com> <59543203684B2244980D7E4057D5FBC1487B8AB5@DB3EX14MBXC312.europe.corp.microsoft.com> Message-ID: <53515508.5060800@well-typed.com> Hi folks, Apropos of nothing, I will be talking about OverloadedRecordFields in London on Monday 28th April at 6:30pm: https://skillsmatter.com/meetups/6345-overloaded-record-fields-for-haskell I've updated my OverloadedRecordFields branches to HEAD as of today. Validate on linux x86_64 is currently failing with a few perf failures, but several appear to be intermittently present on master (see below for details). How worried should I be about these? I'd like to get this reviewed/merged as soon as possible because the changes are quite wide-ranging so they tend to bitrot quickly. The code is in the following three repositories: https://github.com/adamgundry/ghc https://github.com/adamgundry/packages-base https://github.com/adamgundry/haddock The overloaded-record-fields branches have the history (rather messy, I'm afraid) and the orf-squashed branches have everything squashed into one commit per branch. More general information is on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields Cheers, Adam The perf failures on my branch are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) Those on master are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) Details of failures on my branch: =====> haddock.base(normal) 201 of 3977 [0, 0, 0] bytes allocated value is too high: Expected bytes allocated: 7128342344 +/-5% Lower bound bytes allocated: 6771925226 Upper bound bytes allocated: 7484759462 Actual bytes allocated: 7638726640 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 202 of 3977 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 95356616 +/-15% Lower bound max_bytes_used: 81053123 Upper bound max_bytes_used: 109660109 Actual max_bytes_used: 131046008 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 278 +/-10% Lower bound peak_megabytes_allocated: 250 Upper bound peak_megabytes_allocated: 306 Actual peak_megabytes_allocated: 326 bytes allocated value is too high: Expected bytes allocated: 3979151552 +/-5% Lower bound bytes allocated: 3780193974 Upper bound bytes allocated: 4178109130 Actual bytes allocated: 4752508984 *** unexpected failure for haddock.Cabal(normal) =====> haddock.compiler(normal) 203 of 3977 [0, 2, 0] bytes allocated value is too high: Expected bytes allocated: 28708374824 +/-10% Lower bound bytes allocated: 25837537341 Upper bound bytes allocated: 31579212307 Actual bytes allocated: 32010912664 *** unexpected failure for haddock.compiler(normal) =====> T1969(normal) 204 of 3977 [0, 3, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static >T1969.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 11000000 +/-20% Lower bound max_bytes_used: 8800000 Upper bound max_bytes_used: 13200000 Actual max_bytes_used: 13787248 *** unexpected failure for T1969(normal) =====> T3064(normal) 207 of 3977 [0, 4, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 308422280 +/-5% Lower bound bytes allocated: 293001166 Upper bound bytes allocated: 323843394 Actual bytes allocated: 351270952 *** unexpected failure for T3064(normal) =====> T5030(normal) 209 of 3977 [0, 5, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5030.hs -fcontext-stack=300 +RTS -V0 -tT5030.comp.stats --machine-readable -RTS >T5030.comp.stderr 2>&1 =====> T5631(normal) 210 of 3977 [0, 5, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5631.hs +RTS -V0 -tT5631.comp.stats --machine-readable -RTS >T5631.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 397672152 +/-10% Lower bound bytes allocated: 357904936 Upper bound bytes allocated: 437439368 Actual bytes allocated: 474229448 *** unexpected failure for T5030(normal) =====> T5837(normal) 216 of 3977 [0, 6, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 86795752 +/-10% Lower bound bytes allocated: 78116176 Upper bound bytes allocated: 95475328 Actual bytes allocated: 96210584 *** unexpected failure for T5837(normal) =====> T6048(optasm) 217 of 3977 [0, 7, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 110646312 +/-10% Lower bound bytes allocated: 99581680 Upper bound bytes allocated: 121710944 Actual bytes allocated: 125707864 *** unexpected failure for T6048(optasm) Details of failures on master: =====> haddock.Cabal(normal) 202 of 3954 [0, 0, 0] bytes allocated value is too high: Expected bytes allocated: 3979151552 +/-5% Lower bound bytes allocated: 3780193974 Upper bound bytes allocated: 4178109130 Actual bytes allocated: 4212057304 *** unexpected failure for haddock.Cabal(normal) =====> T1969(normal) 204 of 3954 [0, 1, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static >T1969.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 11000000 +/-20% Lower bound max_bytes_used: 8800000 Upper bound max_bytes_used: 13200000 Actual max_bytes_used: 13662736 *** unexpected failure for T1969(normal) =====> T3064(normal) 207 of 3954 [0, 2, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 =====> T4007(normal) 208 of 3954 [0, 2, 0] cd ./perf/compiler && $MAKE -s --no-print-directory T4007 T4007.run.stdout 2>T4007.run.stderr bytes allocated value is too high: Expected bytes allocated: 308422280 +/-5% Lower bound bytes allocated: 293001166 Upper bound bytes allocated: 323843394 Actual bytes allocated: 331042056 *** unexpected failure for T3064(normal) =====> T5837(normal) 216 of 3954 [0, 3, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 86795752 +/-10% Lower bound bytes allocated: 78116176 Upper bound bytes allocated: 95475328 Actual bytes allocated: 95994280 *** unexpected failure for T5837(normal) =====> T6048(optasm) 217 of 3954 [0, 4, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 110646312 +/-10% Lower bound bytes allocated: 99581680 Upper bound bytes allocated: 121710944 Actual bytes allocated: 124431616 *** unexpected failure for T6048(optasm) On 25/02/14 16:18, Simon Peyton Jones wrote: > Adam > > I'm very happy to hear that... good stuff. > > I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. > > So I suggest we plan to merge after 7.8 is out. > > Are the wiki pages up to date? > Records/OverloadedRecordFields > Records/OverloadedRecordFields/Implementation > Records/OverloadedRecordFields/Plan > > The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense > > Simon > > | -----Original Message----- > | From: Adam Gundry [mailto:adam at well-typed.com] > | Sent: 24 February 2014 08:37 > | To: Simon Peyton Jones > | Subject: Re: OverloadedRecordFields > | > | Hi Simon, > | > | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of > | last Saturday. Validate on linux x86_64 reports only one failure, the > | haddock.Cabal perf test, which might well be due to my Haddock changes, > | and I will investigate. I'm not sure how to run the Haddock test suite? > | > | I am keen to get the code reviewed and into HEAD as soon as is > | convenient, but I'm aware these are substantial changes, and don't want > | to rush things. In particular, I would understand if you'd rather hold > | them back until after the 7.8 final release. > | > | How would you like to proceed? > | > | Adam > | > | [1] https://github.com/adamgundry/ghc > | [2] https://github.com/adamgundry/packages-base > | [3] https://github.com/adamgundry/haddock -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Fri Apr 18 22:33:01 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Apr 2014 22:33:01 +0000 Subject: Heap usage of GHC increased in 7.8 vs. 7.6 In-Reply-To: <53518BB5.30108@gmail.com> References: <5351471E.7080602@gmail.com> <53518BB5.30108@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF162168@DB3PRD3001MB020.064d.mgd.msft.net> Now we have forked the tree - we can make Applicative a superclass of Monad - and remove all the AMP warning stuff That should resolve this particular issue, shouldn't it? Austin, would you like to go ahead and do that? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Marlow | Sent: 18 April 2014 21:32 | To: Austin Seipp | Cc: ghc-devs at haskell.org | Subject: Re: Heap usage of GHC increased in 7.8 vs. 7.6 | | On 18/04/14 20:42, Austin Seipp wrote: | > Yes, you're right regarding the AMP patches. Concerning this, I looked | > the patch back up to refresh my memory, and there reason we do this | > was because we need to check (and warn) if there are locally defined | > names in the current module which would clash with names from the | > Applicative-Monad proposal, among others - notably, naming functions | > like 'join' or whatnot in the current scope clashes. This means we | > wire in the 'Name's for join, <*>, etc from Control.Applicative and | > Control.Monad so we can check against them later, which implies | > loading the interfaces I believe. | > | > Perhaps we don't even need a wired Name for this particular step, | > which would sidestep that issue. | > | > But thinking about it - even fixing that, is this even avoidable, | > ultimately? The AMP warnings in 7.8 are actually temporary, and will | > be gone from HEAD soon. But once we do that and AMP is actually | > *implemented* in base, won't it essentially imply the loading of these | > same interfaces by default, and thus about the same amount of memory | > use? | | I don't think it will. Except for orphan modules, interfaces are | normally only loaded when we actually use something defined in that | module. | | Perhaps this isn't a huge deal since it's a small fixed overhead, but it | bugs me nonetheless. | | Cheers, | Simon | | | > Or is there a planned module refactoring/shuffling too, since we're | > already breaking some user code this cycle? If there is, maybe this | > won't be problematic in the end or we should revisit it when the | > numbers are solid. I honestly don't know what all the expected | > intra-module changes might be (I've CC'd Edward in case he'd like to | > chime in about that.) | > | > | > On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow | wrote: | >> I noticed that T1969 is failing again, and decided to do a little | >> investigation. The maximum residency when compiling T1969 with HEAD | >> compared with 7.6.3 looks like this: | >> | >> 7.6.3: 10,473,920 | >> HEAD: 13,783,536 | >> | >> This is with +RTS -h -i0.01 to avoid sampling errors as much as | possible. | >> The figures are pretty accurate, and the heap profiles confirm it: | we're | >> using a lot more heap now. | >> | >> -ddump-if-trace shows that HEAD is reading more interface files: | >> | >> Renamer stats: 10 interfaces read | >> 6 type/class/variable imported, out of 1361 read | >> 0 instance decls imported, out of 105 read | >> 0 rule decls imported, out of 53 read | >> | >> vs. with 7.6.3: | >> | >> Renamer stats: 8 interfaces read | >> 2 type/class/variable imported, out of 828 read | >> 0 instance decls imported, out of 40 read | >> 0 rule decls imported, out of 45 read | >> | >> The extra interface files are Control.Applicative and Control.Monad. | So the | >> question is, why are we now reading these on *every* compilation? | (T1969 | >> imports only the Prelude). Presumably this is something to do with | the AMP | >> warnings, but can't we lazily load these interfaces when they're | needed? | >> | >> Cheers, | >> Simon | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | >> | > | > | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Sat Apr 19 07:44:45 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 19 Apr 2014 08:44:45 +0100 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: <201404150652.43183.jan.stolarek@p.lodz.pl> References: <87vbucidls.fsf@gmail.com> <1397460226-sup-5944@sabre> <201404150652.43183.jan.stolarek@p.lodz.pl> Message-ID: <5352296D.8030604@gmail.com> On 15/04/14 05:52, Jan Stolarek wrote: >> I think Simon Marlow is even more conservative, and >> does his validate builds in a separate tree so he catches missing files. > I thought everyone is doing that. It's the recommended workflow, but I must admit it doesn't always work out, and nowadays I often just work in one tree. The problems arise when your patches don't validate, and you have to go and fix something - you don't want to go back to the working tree and test a new fix, you want to just fix it in the validate tree and validate again. So pretty soon you end up just working in the validate tree, especially when you're working on lots of small fixes. For larger branches a separate working tree works fine. The best way to solve this problem is going to be automation, where we submit the patch to a validate bot and get the results later. Wasn't Joachim working on this? Cheers, Simon From merijn at inconsistent.nl Sat Apr 19 11:00:18 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sat, 19 Apr 2014 13:00:18 +0200 Subject: Proposal - Foreign enum support In-Reply-To: References: Message-ID: <29089DE6-7F2A-424F-88AC-2FE10890CDB7@inconsistent.nl> After some thinking it'd be possible to implement this using a quasiquoter and pattern synonyms, however you'd lose the ability to get exhaustiveness checks for the pattern synonyms. Would people be equally opposed to the idea of defining a "closed" set of synonyms? That is a user defines a set of synonyms 'Foo', 'Bar', 'Baz' and a function defined on all three is considered exhaustive regardless of the underlying type. Otherwise using synonyms as abstract constructors for such enum types will result in rather confusing warning of functions not being exhaustively defined. Cheers, Merijn On Apr 17, 2014, at 18:06 , John Lato wrote: > I wouldn't be keen on adding such a specific feature to the language either. Another concern is that this proposal doesn't seem to address a very common use case for C enums, bit vectors. IMHO any FFI proposal for working with C enums should take that idiom into account. > > On Apr 17, 2014 7:19 AM, "Merijn Verstraaten" wrote: > Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. > > Proposal - Foreign enum support > =============================== > > At the moment the FFI does not have a convenient way with interacting enums > (whether proper enums or CPP defines) in C (like languages). Both enums and CPP > defined enums are major parts of large C APIs and they are thus crucial to > writing foreign bindings. A few examples: > > SDL_image defines the following enum: > > typedef enum { > IMG_INIT_JPG = 0x00000001, > IMG_INIT_PNG = 0x00000002, > IMG_INIT_TIF = 0x00000004, > IMG_INIT_WEBP = 0x00000008 > } IMG_InitFlags; > > OpenCL specifies the following typedefs + CPP defined enum: > > typedef uint32_t cl_uint __attribute__((aligned(4))); > typedef cl_uint cl_platform_info; > > /* cl_platform_info */ > #define CL_PLATFORM_PROFILE 0x0900 > #define CL_PLATFORM_VERSION 0x0901 > #define CL_PLATFORM_NAME 0x0902 > #define CL_PLATFORM_VENDOR 0x0903 > #define CL_PLATFORM_EXTENSIONS 0x0904 > > OpenCL functions will return the above CPP defines as return values of type > cl_platform_info. > > Current Solutions > ----------------- > > In many cases someone wrapping such a C library would like to expose these > enums as a simple sum type as this has several benefits: type safety, the > ability to use haskell constructors for pattern matching, exhaustiveness > checks. > > Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set > of foreign types and newtypes with exposed constructors of these types. As such > there seem two approaches to wrap these enums: > > 1. Implement an ADT representing the enum and write a manual conversion > function between the ADT and the corresponding C type (e.g. CInt -> Foo and > Foo -> CInt). > > 2. Use a tool like c2hs to automatically generate the ADT and conversion > function. > > In both cases the foreign functions are imported using the corresponding C type > in their signature (reducing type safety) and the user is forced write trivial > wrappers for every imported function to convert the ADT to the relevant C type > and back. > > This is both tedious to write and costly in terms of code produced, in case of > c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every > argument/result even though this could trivially be a no-op. > > Worse, since c2hs uses the Enum class for it's conversion to/from C types it > generates Enum instances like: > > instance Enum Foo where > fromEnum Bar = 1 > fromEnum Baz = 1337 > > toEnum 1 = Bar > toEnum 1337 = Baz > toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) > > Since succ/pred and enumFromTo's default implementations assume enums convert > to continuous sequence of Int this means the default generated enum instances > crash. This problem could be overcome by making c2hs' code generation smarter, > but this does not eliminate the tediousness of wrapping all foreign imported > functions with marshalling wrappers, NOR does it eliminate the overhead of all > this useless marshalling. > > Proposal > -------- > > Add a new foreign construct for enums, the syntax I propose below is rather > ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining > based on a concrete example. > > foreign enum CInt as Foo where > Bar = 1 > Baz > Quux = 1337 > Xyzzy = _ > > This would introduce a new type 'Foo' with semantics approximately equivalent > too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; > pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". > > Explicit listing of the value corresponding to a constructor should be > optional, missing values should just increment by one from the previous (like > C), if the initial value is missing, it should assume to start from 0. Values > do not need to be contiguous. > > Users should be able to use these constructors as normal in pattern match > (really, this mostly follows to semantics of the above pattern synonyms). > > The foreign import/export functionality should invisibly marshall Foo to the > underlying foreign type (as is done for newtypes). > > I'm unsure about the support for a wildcard constructor like Xyzzy. If there is > support for a wildcard, it should be optional. On the upside a wildcard means > the marshalling is no longer a partial function. The downside is that it makes > desugaring the use of enums in patterns harder. It seems clear that > > f Xyzzy = {- ... -} > f Bar = {- ... -} > f Baz = {- ... -} > f Quux = {- ... -} > > Should not have the same semantics as: > > f (Foo _) = {- ... -} > f (Foo 1) = {- ... -} > f (Foo 2) = {- ... -} > f (Foo 1337) = {- ... -} > > So in the presence of wildcards, the Foo enum can't trivially be desugared into > pattern synonyms after checking exhaustiveness. > > Pros: > 1. Foreign imports are slightly more type safe, as one can now write: > > foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () > > Preventing users from passing an arbitrary CInt to an argument expecting a > specific enum. > > 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness > checks and pattern matching > > 3. Cheaper as marshalling Foo to CInt is a no-op > > 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int > mapping is no longer used for marshalling > > Cons: > 1. Non-standard extension of the FFI > > 2. Someone has to implement it > > 3. Wildcards constructors would present difficulties desugaring pattern > matches to a simple newtype. > > 4. ?? > > What Would Need to be Done? > --------------------------- > > 1. Parser needs to be extended to deal with parsing of enum declarations. > 2. Pattern matches of an enum type need to be checked for exhaustiveness and > desugared to the underlying type's representation. > 3. Extend foreign imports/exports to marshall enums properly. > > If there's no objections I'm willing to take a stab at implementing this, > although I'd probably need some help with GHC's internals (although I could bug > #ghc for that). > > Cheers, > Merijn > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.is.fischer at googlemail.com Sat Apr 19 12:08:19 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sat, 19 Apr 2014 14:08:19 +0200 Subject: Cannot locally 'sync-all get' Message-ID: <1567077.gEPP8HsVsf@linux-hpeb.site> Like so often, ./sync-all pull failed today in my local clones, first with "... not on a branch", after sync-all checkout master, with "fatal: Reference ... not a tree". (Aside, that nonsense didn't happen before the introduction of submodules.) The usual remedy is rm -rf ./clone git clone ./ghc ./clone cd clone ./sync-all get but today it failed with > Klone nach 'libraries/xhtml'... > Fertig. > Unterprojekt-Pfad: 'libraries/xhtml': > 'fb9e0bbb69e15873682a9f25d39652099a3ccac1' ausgecheckt fatal: Projektarchiv > '/home/dafis/GHC/./haddock.git' existiert nicht. Klonen von > '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad 'utils/haddock' > fehlgeschlagen git failed: 256 at ./sync-all line 123. Any idea what's up? Cheers, Daniel From hvriedel at gmail.com Sat Apr 19 12:53:04 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 19 Apr 2014 14:53:04 +0200 Subject: Cannot locally 'sync-all get' In-Reply-To: <1567077.gEPP8HsVsf@linux-hpeb.site> (Daniel Fischer's message of "Sat, 19 Apr 2014 14:08:19 +0200") References: <1567077.gEPP8HsVsf@linux-hpeb.site> Message-ID: <87vbu5pjkf.fsf@gmail.com> On 2014-04-19 at 14:08:19 +0200, Daniel Fischer wrote: [...] >> Klone nach 'libraries/xhtml'... >> Fertig. >> Unterprojekt-Pfad: 'libraries/xhtml': >> 'fb9e0bbb69e15873682a9f25d39652099a3ccac1' ausgecheckt fatal: Projektarchiv >> '/home/dafis/GHC/./haddock.git' existiert nicht. Klonen von >> '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad 'utils/haddock' >> fehlgeschlagen git failed: 256 at ./sync-all line 123. > > Any idea what's up? utils/haddock was recently turned into a submodule, but sync-all isn't clever enough (yet) to fix it up automatically yet. Please try 'git submodule update --init' in the GHC source-tree top folder (that should be taken care of by sync-all, but sync-all wasn't adapted yet) From daniel.is.fischer at googlemail.com Sat Apr 19 13:09:58 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sat, 19 Apr 2014 15:09:58 +0200 Subject: Cannot locally 'sync-all get' In-Reply-To: <87vbu5pjkf.fsf@gmail.com> References: <1567077.gEPP8HsVsf@linux-hpeb.site> <87vbu5pjkf.fsf@gmail.com> Message-ID: <1555592.sHWQV4ooz0@linux-hpeb.site> On Saturday 19 April 2014, 14:53:04, Herbert Valerio Riedel wrote: > > Please try 'git submodule update --init' in the GHC source-tree top > folder (that should be taken care of by sync-all, but sync-all wasn't > adapted yet) Not sure if it's progress, running that before 'sync-all get' fails with > Unterprojekt 'utils/haddock' (/home/dafis/GHC/./haddock.git) ist f?r Pfad > 'utils/haddock' registriert > fatal: Projektarchiv '/home/dafis/GHC/./packages/Cabal.git' > existiert nicht. Klonen von > '/home/dafis/GHC/./packages/Cabal.git' in Unterprojekt-Pfad > 'libraries/Cabal' fehlgeschlagen and afterwards, 'synac-all get' again doesn't know about Cabal: > fatal: Projektarchiv '/home/dafis/GHC/./haddock.git' existiert nicht. > Klonen von '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad > 'utils/haddock' fehlgeschlagen > git failed: 256 at ./sync-all line 123. and then 'submodule update' doesn't know about Cabal anymore: > dafis at schwartz:~/GHC/build> git submodule update --init > fatal: Projektarchiv '/home/dafis/GHC/./haddock.git' existiert nicht. > Klonen von '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad > 'utils/haddock' fehlgeschlagen From hvr at gnu.org Sat Apr 19 13:44:41 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 19 Apr 2014 15:44:41 +0200 Subject: HEADS-UP: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <87ob05mzid.fsf@gmail.com> (Herbert Valerio Riedel's message of "Sun, 13 Apr 2014 09:58:50 +0200") References: <87ob05mzid.fsf@gmail.com> Message-ID: <87ioq5ph6e.fsf@gmail.com> On 2014-04-13 at 09:58:50 +0200, Herbert Valerio Riedel wrote: [...] > - base > - ghc-prim > - integer-gmp > - integer-simple > - template-haskell [...] > If no objections are raised, I'm planning to implement this change > next weekend (April 19th/20th). As there were no objections, I went on and implemented the change, so as of http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391d21d15a1 the repositories mentioned above are now part of ghc.git, and the same procedure applies as when we folded-in testsuite some time ago. Moreover, the 'master' branches of the five repositories have been made read-only, as GHC HEAD development is to continue inside ghc.git. See also http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/3453 as well as http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/3482 for the previous testsuite.git fold-in and related issues Cheers, hvr From carter.schonwald at gmail.com Sat Apr 19 14:04:42 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 19 Apr 2014 10:04:42 -0400 Subject: Proposal - Foreign enum support In-Reply-To: <29089DE6-7F2A-424F-88AC-2FE10890CDB7@inconsistent.nl> References: <29089DE6-7F2A-424F-88AC-2FE10890CDB7@inconsistent.nl> Message-ID: Have you considered a type class and new types ? :-) On Saturday, April 19, 2014, Merijn Verstraaten wrote: > After some thinking it'd be possible to implement this using a quasiquoter > and pattern synonyms, however you'd lose the ability to get exhaustiveness > checks for the pattern synonyms. Would people be equally opposed to the > idea of defining a "closed" set of synonyms? That is a user defines a set > of synonyms 'Foo', 'Bar', 'Baz' and a function defined on all three is > considered exhaustive regardless of the underlying type. Otherwise using > synonyms as abstract constructors for such enum types will result in rather > confusing warning of functions not being exhaustively defined. > > Cheers, > Merijn > > On Apr 17, 2014, at 18:06 , John Lato wrote: > > I wouldn't be keen on adding such a specific feature to the language > either. Another concern is that this proposal doesn't seem to address a > very common use case for C enums, bit vectors. IMHO any FFI proposal for > working with C enums should take that idiom into account. > On Apr 17, 2014 7:19 AM, "Merijn Verstraaten" > wrote: > > Cross-post to haskell-prime in case there's any interest for including > this into the report's FFI specification. > > Proposal - Foreign enum support > =============================== > > At the moment the FFI does not have a convenient way with interacting enums > (whether proper enums or CPP defines) in C (like languages). Both enums > and CPP > defined enums are major parts of large C APIs and they are thus crucial to > writing foreign bindings. A few examples: > > SDL_image defines the following enum: > > typedef enum { > IMG_INIT_JPG = 0x00000001, > IMG_INIT_PNG = 0x00000002, > IMG_INIT_TIF = 0x00000004, > IMG_INIT_WEBP = 0x00000008 > } IMG_InitFlags; > > OpenCL specifies the following typedefs + CPP defined enum: > > typedef uint32_t cl_uint __attribute__((aligned(4))); > typedef cl_uint cl_platform_info; > > /* cl_platform_info */ > #define CL_PLATFORM_PROFILE 0x0900 > #define CL_PLATFORM_VERSION 0x0901 > #define CL_PLATFORM_NAME 0x0902 > #define CL_PLATFORM_VENDOR 0x0903 > #define CL_PLATFORM_EXTENSIONS 0x0904 > > OpenCL functions will return the above CPP defines as return values of type > cl_platform_info. > > Current Solutions > ----------------- > > In many cases someone wrapping such a C library would like to expose these > enums as a simple sum type as this has several benefits: type safety, the > ability to use haskell constructors for pattern matching, exhaustiveness > checks. > > Currently the GHC FFI, as specified by Haskell2010, only marshalls a small > set > of foreign types and newtypes with exposed constructors of these types. As > such > there seem two approaches to wrap these enums: > > 1. Implement an ADT representing the enum and write a manual conversion > function between the ADT and the corresponding C type (e.g. CInt -> > Foo and > Foo -> CInt). > > 2. Use a tool like c2hs to automatically generate the ADT and conversion > function. > > In both cases the foreign functions are imported using the corresponding C > type > in their signature (reducing type safety) and the user is forced write > trivial > wrappers for every imported function to convert the ADT to the relevant C > type > and back. > > This is both tedious to write and costly in terms of code produced, in > case of > c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for > every > argument/result even though this could trivially be a no-op. > > Worse, since c2hs uses the Enum class for it's conversion to/from C types > it > generates Enum instances like: > > instance Enum Foo where > fromEnum Bar = 1 > fromEnum Baz = 1337 > > toEnum 1 = Bar > toEnum 1337 = Baz > toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ > show unmatched) > > Since succ/pred and enumFromTo's default implementations assume enums > convert > to continuous sequence of Int this means the default generated enum > instances > crash. This problem could be overcome by making c2hs' code generation > smarter, > but this does not eliminate the tediousness of wrapping all foreign > imported > functions with marshalling wrappers, NOR does it eliminate the overhead of > all > this useless marshalling. > > Proposal > -------- > > Add a new foreign construct for enums, the syntax I propose below is rather > ugly and ambiguous and thereforeopen to bikeshedding, but I prefer > explaining > based on a concrete example. > > foreign enum CInt as Foo where > Bar = 1 > Baz > Quux = 1337 > Xyzzy = _ > > This would introduce a new type 'Foo' with semantics approximately > equivalent > too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo > 1; > pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". > > Explicit listing of the value corresponding to a constructor should be > optional, missing values should just increment by one from the previous > (like > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Apr 19 14:13:00 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 19 Apr 2014 10:13:00 -0400 Subject: Proposal - Foreign enum support In-Reply-To: References: Message-ID: -1 from me. Your first example even provides a counter-example. typedef enum { > IMG_INIT_JPG = 0x00000001, > IMG_INIT_PNG = 0x00000002, > IMG_INIT_TIF = 0x00000004, > IMG_INIT_WEBP = 0x00000008 > } IMG_InitFlags; Those are defined as powers of two because they are a bit mask you have to be able to (.|.) together. This is the sort of thing people write .hsc files for, so they can include the appropriate header directly and resolve the constants. Maintaining a separate copy of an enum that goes out of date with the C version is a recipe for breaking on future versions of the dependency, and in my experience the majority of cases where the range is discontinuous arise from when the thing in question is a mask, like this very case. The remaining cases where you really want to incur all those obligations are few enough and far enough between that going through a quasiquoter seems to be the right solution. -Edward On Thu, Apr 17, 2014 at 10:19 AM, Merijn Verstraaten wrote: > Cross-post to haskell-prime in case there's any interest for including > this into the report's FFI specification. > > Proposal - Foreign enum support > =============================== > > At the moment the FFI does not have a convenient way with interacting enums > (whether proper enums or CPP defines) in C (like languages). Both enums > and CPP > defined enums are major parts of large C APIs and they are thus crucial to > writing foreign bindings. A few examples: > > SDL_image defines the following enum: > > typedef enum { > IMG_INIT_JPG = 0x00000001, > IMG_INIT_PNG = 0x00000002, > IMG_INIT_TIF = 0x00000004, > IMG_INIT_WEBP = 0x00000008 > } IMG_InitFlags; > > OpenCL specifies the following typedefs + CPP defined enum: > > typedef uint32_t cl_uint __attribute__((aligned(4))); > typedef cl_uint cl_platform_info; > > /* cl_platform_info */ > #define CL_PLATFORM_PROFILE 0x0900 > #define CL_PLATFORM_VERSION 0x0901 > #define CL_PLATFORM_NAME 0x0902 > #define CL_PLATFORM_VENDOR 0x0903 > #define CL_PLATFORM_EXTENSIONS 0x0904 > > OpenCL functions will return the above CPP defines as return values of type > cl_platform_info. > > Current Solutions > ----------------- > > In many cases someone wrapping such a C library would like to expose these > enums as a simple sum type as this has several benefits: type safety, the > ability to use haskell constructors for pattern matching, exhaustiveness > checks. > > Currently the GHC FFI, as specified by Haskell2010, only marshalls a small > set > of foreign types and newtypes with exposed constructors of these types. As > such > there seem two approaches to wrap these enums: > > 1. Implement an ADT representing the enum and write a manual conversion > function between the ADT and the corresponding C type (e.g. CInt -> > Foo and > Foo -> CInt). > > 2. Use a tool like c2hs to automatically generate the ADT and conversion > function. > > In both cases the foreign functions are imported using the corresponding C > type > in their signature (reducing type safety) and the user is forced write > trivial > wrappers for every imported function to convert the ADT to the relevant C > type > and back. > > This is both tedious to write and costly in terms of code produced, in > case of > c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for > every > argument/result even though this could trivially be a no-op. > > Worse, since c2hs uses the Enum class for it's conversion to/from C types > it > generates Enum instances like: > > instance Enum Foo where > fromEnum Bar = 1 > fromEnum Baz = 1337 > > toEnum 1 = Bar > toEnum 1337 = Baz > toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ > show unmatched) > > Since succ/pred and enumFromTo's default implementations assume enums > convert > to continuous sequence of Int this means the default generated enum > instances > crash. This problem could be overcome by making c2hs' code generation > smarter, > but this does not eliminate the tediousness of wrapping all foreign > imported > functions with marshalling wrappers, NOR does it eliminate the overhead of > all > this useless marshalling. > > Proposal > -------- > > Add a new foreign construct for enums, the syntax I propose below is rather > ugly and ambiguous and thereforeopen to bikeshedding, but I prefer > explaining > based on a concrete example. > > foreign enum CInt as Foo where > Bar = 1 > Baz > Quux = 1337 > Xyzzy = _ > > This would introduce a new type 'Foo' with semantics approximately > equivalent > too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo > 1; > pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". > > Explicit listing of the value corresponding to a constructor should be > optional, missing values should just increment by one from the previous > (like > C), if the initial value is missing, it should assume to start from 0. > Values > do not need to be contiguous. > > Users should be able to use these constructors as normal in pattern match > (really, this mostly follows to semantics of the above pattern synonyms). > > The foreign import/export functionality should invisibly marshall Foo to > the > underlying foreign type (as is done for newtypes). > > I'm unsure about the support for a wildcard constructor like Xyzzy. If > there is > support for a wildcard, it should be optional. On the upside a wildcard > means > the marshalling is no longer a partial function. The downside is that it > makes > desugaring the use of enums in patterns harder. It seems clear that > > f Xyzzy = {- ... -} > f Bar = {- ... -} > f Baz = {- ... -} > f Quux = {- ... -} > > Should not have the same semantics as: > > f (Foo _) = {- ... -} > f (Foo 1) = {- ... -} > f (Foo 2) = {- ... -} > f (Foo 1337) = {- ... -} > > So in the presence of wildcards, the Foo enum can't trivially be desugared > into > pattern synonyms after checking exhaustiveness. > > Pros: > 1. Foreign imports are slightly more type safe, as one can now write: > > foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () > > Preventing users from passing an arbitrary CInt to an argument > expecting a > specific enum. > > 2. No need to write marshalling functions to/from ADT to obtain > exhaustiveness > checks and pattern matching > > 3. Cheaper as marshalling Foo to CInt is a no-op > > 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this > Int > mapping is no longer used for marshalling > > Cons: > 1. Non-standard extension of the FFI > > 2. Someone has to implement it > > 3. Wildcards constructors would present difficulties desugaring pattern > matches to a simple newtype. > > 4. ?? > > What Would Need to be Done? > --------------------------- > > 1. Parser needs to be extended to deal with parsing of enum declarations. > 2. Pattern matches of an enum type need to be checked for exhaustiveness > and > desugared to the underlying type's representation. > 3. Extend foreign imports/exports to marshall enums properly. > > If there's no objections I'm willing to take a stab at implementing this, > although I'd probably need some help with GHC's internals (although I > could bug > #ghc for that). > > Cheers, > Merijn > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Sat Apr 19 18:02:24 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Sat, 19 Apr 2014 20:02:24 +0200 Subject: [PATCH 1/2] Make Prelude.abs handle -0.0 correctly (#7858) In-Reply-To: <1397930545-23329-1-git-send-email-alexander@plaimi.net> References: <1397930545-23329-1-git-send-email-alexander@plaimi.net> Message-ID: <1397930545-23329-2-git-send-email-alexander@plaimi.net> Make the `Float` and `Double` implementations of `abs` handle -0.0 correctly per IEEE-754. --- libraries/base/GHC/Float.lhs | 12 ++++++++---- libraries/base/changelog.md | 2 ++ 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/libraries/base/GHC/Float.lhs b/libraries/base/GHC/Float.lhs index e0c4f4a..442e13c 100644 --- a/libraries/base/GHC/Float.lhs +++ b/libraries/base/GHC/Float.lhs @@ -205,8 +205,10 @@ instance Num Float where (-) x y = minusFloat x y negate x = negateFloat x (*) x y = timesFloat x y - abs x | x >= 0.0 = x - | otherwise = negateFloat x + abs x + | isNegativeZero x = 0 + | x >= 0.0 = x + | otherwise = negateFloat x signum x | x == 0.0 = 0 | x > 0.0 = 1 | otherwise = negate 1 @@ -370,8 +372,10 @@ instance Num Double where (-) x y = minusDouble x y negate x = negateDouble x (*) x y = timesDouble x y - abs x | x >= 0.0 = x - | otherwise = negateDouble x + abs x + | isNegativeZero x = 0 + | x >= 0.0 = x + | otherwise = negateDouble x signum x | x == 0.0 = 0 | x > 0.0 = 1 | otherwise = negate 1 diff --git a/libraries/base/changelog.md b/libraries/base/changelog.md index a72e4e6..9eb279e 100644 --- a/libraries/base/changelog.md +++ b/libraries/base/changelog.md @@ -10,6 +10,8 @@ * Weaken RealFloat constraints on some `Data.Complex` functions + * Make `abs` handle -0.0 correctly for `Float` and `Double`. + ## 4.7.0.0 *Apr 2014* * Bundled with GHC 7.8.1 -- 1.8.3.2 From alexander at plaimi.net Sat Apr 19 18:02:23 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Sat, 19 Apr 2014 20:02:23 +0200 Subject: Strange behaviour in my signum Message-ID: <1397930545-23329-1-git-send-email-alexander@plaimi.net> I started preparing patches for #7858. My abs patch works well, my signum patch not at all. The gist of the bug is that abs and signum return erroneous values for for the input -0.0. abs (-0.0 :: Float) should return 0.0, not -0.0. My patch fixes this. For signum the situation is reverse. My patch does *not* fix this. It does not work using GHC nor GHCi (GHCi -ddump-simpl demonstrated below). The code for my signum is correct, as may be demonstrated by putting signumFix x | x == 0.0 = x | isNaN x = x | x > 0.0 = 1 | otherwise = negate 1 in a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 :: Float) should now return -0.0, where signum returns 0.0 with the same argument. Following this email come the patches. Please review the second patch. If you can spot what I am doing wrong, I would be grateful. Prelude> abs (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aqt :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aqt = GHC.Num.abs @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aqt `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Prelude> signum (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aKQ :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aKQ = GHC.Num.signum @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aKQ `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Alexander Berntsen (2): Make Prelude.abs handle -0.0 correctly (#7858) Make Prelude.signum handle -0.0 correctly (#7858) libraries/base/GHC/Float.lhs | 28 ++++++++++++++++++---------- libraries/base/changelog.md | 2 ++ 2 files changed, 20 insertions(+), 10 deletions(-) -- 1.8.3.2 From alexander at plaimi.net Sat Apr 19 18:02:25 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Sat, 19 Apr 2014 20:02:25 +0200 Subject: [PATCH 2/2] Make Prelude.signum handle -0.0 correctly (#7858) In-Reply-To: <1397930545-23329-1-git-send-email-alexander@plaimi.net> References: <1397930545-23329-1-git-send-email-alexander@plaimi.net> Message-ID: <1397930545-23329-3-git-send-email-alexander@plaimi.net> Make the `Float` and `Double` implementations of `signum` handle -0.0 correctly per IEEE-754. --- libraries/base/GHC/Float.lhs | 16 ++++++++++------ libraries/base/changelog.md | 2 +- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/libraries/base/GHC/Float.lhs b/libraries/base/GHC/Float.lhs index 442e13c..294ebd5 100644 --- a/libraries/base/GHC/Float.lhs +++ b/libraries/base/GHC/Float.lhs @@ -209,9 +209,11 @@ instance Num Float where | isNegativeZero x = 0 | x >= 0.0 = x | otherwise = negateFloat x - signum x | x == 0.0 = 0 - | x > 0.0 = 1 - | otherwise = negate 1 + signum x + | x == 0.0 = x + | isNaN x = x + | x > 0.0 = 1 + | otherwise = negate 1 {-# INLINE fromInteger #-} fromInteger i = F# (floatFromInteger i) @@ -376,9 +378,11 @@ instance Num Double where | isNegativeZero x = 0 | x >= 0.0 = x | otherwise = negateDouble x - signum x | x == 0.0 = 0 - | x > 0.0 = 1 - | otherwise = negate 1 + signum x + | x == 0.0 = x + | isNaN x = x + | x > 0.0 = 1 + | otherwise = negate 1 {-# INLINE fromInteger #-} fromInteger i = D# (doubleFromInteger i) diff --git a/libraries/base/changelog.md b/libraries/base/changelog.md index 9eb279e..bc52660 100644 --- a/libraries/base/changelog.md +++ b/libraries/base/changelog.md @@ -10,7 +10,7 @@ * Weaken RealFloat constraints on some `Data.Complex` functions - * Make `abs` handle -0.0 correctly for `Float` and `Double`. + * Make `abs` and `signum` handle -0.0 correctly for `Float` and `Double`. ## 4.7.0.0 *Apr 2014* -- 1.8.3.2 From marlowsd at gmail.com Sat Apr 19 18:52:23 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 19 Apr 2014 19:52:23 +0100 Subject: Heap usage of GHC increased in 7.8 vs. 7.6 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF162168@DB3PRD3001MB020.064d.mgd.msft.net> References: <5351471E.7080602@gmail.com> <53518BB5.30108@gmail.com> <618BE556AADD624C9C918AA5D5911BEF162168@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5352C5E7.9050302@gmail.com> That would fix it in HEAD, but not 7.8, of course. Cheers, Simon On 18/04/14 23:33, Simon Peyton Jones wrote: > Now we have forked the tree > - we can make Applicative a superclass of Monad > - and remove all the AMP warning stuff > That should resolve this particular issue, shouldn't it? > > Austin, would you like to go ahead and do that? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon > | Marlow > | Sent: 18 April 2014 21:32 > | To: Austin Seipp > | Cc: ghc-devs at haskell.org > | Subject: Re: Heap usage of GHC increased in 7.8 vs. 7.6 > | > | On 18/04/14 20:42, Austin Seipp wrote: > | > Yes, you're right regarding the AMP patches. Concerning this, I looked > | > the patch back up to refresh my memory, and there reason we do this > | > was because we need to check (and warn) if there are locally defined > | > names in the current module which would clash with names from the > | > Applicative-Monad proposal, among others - notably, naming functions > | > like 'join' or whatnot in the current scope clashes. This means we > | > wire in the 'Name's for join, <*>, etc from Control.Applicative and > | > Control.Monad so we can check against them later, which implies > | > loading the interfaces I believe. > | > > | > Perhaps we don't even need a wired Name for this particular step, > | > which would sidestep that issue. > | > > | > But thinking about it - even fixing that, is this even avoidable, > | > ultimately? The AMP warnings in 7.8 are actually temporary, and will > | > be gone from HEAD soon. But once we do that and AMP is actually > | > *implemented* in base, won't it essentially imply the loading of these > | > same interfaces by default, and thus about the same amount of memory > | > use? > | > | I don't think it will. Except for orphan modules, interfaces are > | normally only loaded when we actually use something defined in that > | module. > | > | Perhaps this isn't a huge deal since it's a small fixed overhead, but it > | bugs me nonetheless. > | > | Cheers, > | Simon > | > | > | > Or is there a planned module refactoring/shuffling too, since we're > | > already breaking some user code this cycle? If there is, maybe this > | > won't be problematic in the end or we should revisit it when the > | > numbers are solid. I honestly don't know what all the expected > | > intra-module changes might be (I've CC'd Edward in case he'd like to > | > chime in about that.) > | > > | > > | > On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow > | wrote: > | >> I noticed that T1969 is failing again, and decided to do a little > | >> investigation. The maximum residency when compiling T1969 with HEAD > | >> compared with 7.6.3 looks like this: > | >> > | >> 7.6.3: 10,473,920 > | >> HEAD: 13,783,536 > | >> > | >> This is with +RTS -h -i0.01 to avoid sampling errors as much as > | possible. > | >> The figures are pretty accurate, and the heap profiles confirm it: > | we're > | >> using a lot more heap now. > | >> > | >> -ddump-if-trace shows that HEAD is reading more interface files: > | >> > | >> Renamer stats: 10 interfaces read > | >> 6 type/class/variable imported, out of 1361 read > | >> 0 instance decls imported, out of 105 read > | >> 0 rule decls imported, out of 53 read > | >> > | >> vs. with 7.6.3: > | >> > | >> Renamer stats: 8 interfaces read > | >> 2 type/class/variable imported, out of 828 read > | >> 0 instance decls imported, out of 40 read > | >> 0 rule decls imported, out of 45 read > | >> > | >> The extra interface files are Control.Applicative and Control.Monad. > | So the > | >> question is, why are we now reading these on *every* compilation? > | (T1969 > | >> imports only the Prelude). Presumably this is something to do with > | the AMP > | >> warnings, but can't we lazily load these interfaces when they're > | needed? > | >> > | >> Cheers, > | >> Simon > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs at haskell.org > | >> http://www.haskell.org/mailman/listinfo/ghc-devs > | >> > | > > | > > | > > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > From daniel.is.fischer at googlemail.com Sat Apr 19 22:50:18 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sun, 20 Apr 2014 00:50:18 +0200 Subject: Validate Failures Message-ID: <3105610.mWPspcbopl@linux-hpeb.site> I'm getting three or four validate failures on 64-bit Linux (openSuSE 12.3): Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) simplCore/should_compile simpl015 [exit code non-0] (optasm) th T8333 [bad stdout] (normal) The perf tests allocate about 2% more than they are allowed to. > bytes allocated value is too high: > Expected bytes allocated: 308422280 +/-5% > Lower bound bytes allocated: 293001166 > Upper bound bytes allocated: 323843394 > Actual bytes allocated: 329638208 > *** unexpected failure for T3064(normal) > bytes allocated value is too high: > Expected bytes allocated: 110646312 +/-10% > Lower bound bytes allocated: 99581680 > Upper bound bytes allocated: 121710944 > Actual bytes allocated: 123103232 > *** unexpected failure for T6048(optasm) The T8333 failure is due to it reading my .ghci file, thus getting additional output. Is there a way to automatically check that all tests that use the "--interactive" flag also use "-ignore-dot-ghci" like the ghci tests do, or must one wait for validate failures due to that and add it then? Finally, simpl015 is a test that does only sometimes fail. It uses on my box an estimated 2GB of memory, and when I haven't anything else memory-hungry running, it passes, but when I have (as I do by default) SeaMonkey running (with tons of open tabs), my box quasi-freezes, the test times out, and the browser is OOM-killed. I am not happy with that behaviour. And looking at what the test is, I am somewhat irritated that it uses so much memory. Cheers, Daniel From simonpj at microsoft.com Mon Apr 21 07:47:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 07:47:03 +0000 Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d) In-Reply-To: <20140420060221.4CE822406B@ghc.haskell.org> References: <20140420060221.4CE822406B@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555C65@DB3PRD3001MB020.064d.mgd.msft.net> There is much more to change, right? * The code in the compiler that implements -fwarn-amp * Actually making Applicative a superclass of monad Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 20 April 2014 07:02 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for | validate (6074c5d) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e | c4955735931/ghc | | >--------------------------------------------------------------- | | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | Author: Austin Seipp | Date: Sun Apr 20 01:00:44 2014 -0500 | | Remove -fno-warn-amp sledgehammers for validate | | GHC should now fully compliant with respect to the Applicative | Monad | proposal (including all upstream libraries), and does not need to | suppress this warning anymore. | | Signed-off-by: Austin Seipp | | | >--------------------------------------------------------------- | | 6074c5da7f48f10e9b3b88d14607ec4955735931 | mk/validate-settings.mk | 2 -- | 1 file changed, 2 deletions(-) | | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index | 8797bf9..cac938d 100644 | --- a/mk/validate-settings.mk | +++ b/mk/validate-settings.mk | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | | GhcStage1HcOpts += -fwarn-tabs | GhcStage2HcOpts += -fwarn-tabs | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the | tests, and faster building of the utils to be installed | | GhcLibHcOpts += -O -dcore-lint | -GhcLibHcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | # We define DefaultFastGhcLibWays in this style so that the value is | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits From simonpj at microsoft.com Mon Apr 21 07:51:42 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 07:51:42 +0000 Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) In-Reply-To: <20140420215611.65A2A2406B@ghc.haskell.org> References: <20140420215611.65A2A2406B@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555E2F@DB3PRD3001MB020.064d.mgd.msft.net> I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 20 April 2014 22:56 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163/ghc | | >--------------------------------------------------------------- | | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 | Author: Austin Seipp | Date: Sun Apr 20 01:10:15 2014 -0500 | | Deprecate the AMP warnings. | | Now that we're in development mode, Applicative will soon be a | superclass of Monad in HEAD. So let's go ahead and deprecate the | -fno-warn-amp flag, remove the checks, and tweak a few tests | | Signed-off-by: Austin Seipp | | | >--------------------------------------------------------------- | | 3608f657d55b7ea7dd711556a4faf6a15c509163 | compiler/main/DynFlags.hs | 4 +- | compiler/typecheck/TcRnDriver.lhs | 215 +----------- | -------- | docs/users_guide/flags.xml | 2 +- | .../tests/ghci.debugger/scripts/break006.stderr | 4 +- | .../tests/ghci.debugger/scripts/print019.stderr | 2 +- | .../should_fail/overloadedlistsfail01.stderr | 2 +- | testsuite/tests/rename/should_compile/T7145b.hs | 3 - | .../tests/rename/should_compile/T7145b.stderr | 2 +- | .../tests/simplCore/should_compile/spec001.hs | 3 +- | .../tests/typecheck/should_compile/holes2.stderr | 2 +- | testsuite/tests/typecheck/should_fail/T5095.stderr | 2 - | .../tests/typecheck/should_fail/tcfail072.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail133.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail181.stderr | 1 - | 14 files changed, 14 insertions(+), 232 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 3608f657d55b7ea7dd711556a4faf6a15c509163 | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits From austin at well-typed.com Mon Apr 21 08:03:11 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Apr 2014 03:03:11 -0500 Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d) In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A555C65@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140420060221.4CE822406B@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A555C65@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yes the first part is done - see 3608f657d5 I removed the validate bandages first, so I could make sure that everything worked properly with -fno-warn-amp *legitimately* on and not deprecated. I then removed it afterwords in 3608f657d5 and replaced it with a deprecation notice. That means HEAD should now be 100% ready to actually make Applicative a superclass of Monad, the changes require shuffling around a bit of stuff in base though, I think. On Mon, Apr 21, 2014 at 2:47 AM, Simon Peyton Jones wrote: > There is much more to change, right? > > * The code in the compiler that implements -fwarn-amp > * Actually making Applicative a superclass of monad > > Simon > > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of > | git at git.haskell.org > | Sent: 20 April 2014 07:02 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for > | validate (6074c5d) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e > | c4955735931/ghc > | > | >--------------------------------------------------------------- > | > | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 > | Author: Austin Seipp > | Date: Sun Apr 20 01:00:44 2014 -0500 > | > | Remove -fno-warn-amp sledgehammers for validate > | > | GHC should now fully compliant with respect to the Applicative > | Monad > | proposal (including all upstream libraries), and does not need to > | suppress this warning anymore. > | > | Signed-off-by: Austin Seipp > | > | > | >--------------------------------------------------------------- > | > | 6074c5da7f48f10e9b3b88d14607ec4955735931 > | mk/validate-settings.mk | 2 -- > | 1 file changed, 2 deletions(-) > | > | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index > | 8797bf9..cac938d 100644 > | --- a/mk/validate-settings.mk > | +++ b/mk/validate-settings.mk > | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall > | > | GhcStage1HcOpts += -fwarn-tabs > | GhcStage2HcOpts += -fwarn-tabs > | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we > | sync upstream. > | > | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs > | > | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the > | tests, and faster building of the utils to be installed > | > | GhcLibHcOpts += -O -dcore-lint > | -GhcLibHcOpts += -fno-warn-amp # Temporary sledgehammer until we > | sync upstream. > | > | # We define DefaultFastGhcLibWays in this style so that the value is > | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. > | > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-commits > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Apr 21 08:03:44 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Apr 2014 03:03:44 -0500 Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A555E2F@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140420215611.65A2A2406B@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A555E2F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yep that's done, it's all removed from TcRnDriver. I think I missed some of the lingering wired-in-names in PrelNames though, now that I look at it... On Mon, Apr 21, 2014 at 2:51 AM, Simon Peyton Jones wrote: > I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. > > Simon > > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of > | git at git.haskell.org > | Sent: 20 April 2014 22:56 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf > | 6a15c509163/ghc > | > | >--------------------------------------------------------------- > | > | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 > | Author: Austin Seipp > | Date: Sun Apr 20 01:10:15 2014 -0500 > | > | Deprecate the AMP warnings. > | > | Now that we're in development mode, Applicative will soon be a > | superclass of Monad in HEAD. So let's go ahead and deprecate the > | -fno-warn-amp flag, remove the checks, and tweak a few tests > | > | Signed-off-by: Austin Seipp > | > | > | >--------------------------------------------------------------- > | > | 3608f657d55b7ea7dd711556a4faf6a15c509163 > | compiler/main/DynFlags.hs | 4 +- > | compiler/typecheck/TcRnDriver.lhs | 215 +----------- > | -------- > | docs/users_guide/flags.xml | 2 +- > | .../tests/ghci.debugger/scripts/break006.stderr | 4 +- > | .../tests/ghci.debugger/scripts/print019.stderr | 2 +- > | .../should_fail/overloadedlistsfail01.stderr | 2 +- > | testsuite/tests/rename/should_compile/T7145b.hs | 3 - > | .../tests/rename/should_compile/T7145b.stderr | 2 +- > | .../tests/simplCore/should_compile/spec001.hs | 3 +- > | .../tests/typecheck/should_compile/holes2.stderr | 2 +- > | testsuite/tests/typecheck/should_fail/T5095.stderr | 2 - > | .../tests/typecheck/should_fail/tcfail072.stderr | 2 +- > | .../tests/typecheck/should_fail/tcfail133.stderr | 2 +- > | .../tests/typecheck/should_fail/tcfail181.stderr | 1 - > | 14 files changed, 14 insertions(+), 232 deletions(-) > | > | Diff suppressed because of size. To see it, use: > | > | git diff-tree --root --patch-with-stat --no-color --find-copies- > | harder --ignore-space-at-eol --cc > | 3608f657d55b7ea7dd711556a4faf6a15c509163 > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-commits > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Mon Apr 21 08:21:39 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 08:21:39 +0000 Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d) In-Reply-To: References: <20140420060221.4CE822406B@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A555C65@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555F00@DB3PRD3001MB020.064d.mgd.msft.net> | with a deprecation notice. That means HEAD should now be 100% ready to | actually make Applicative a superclass of Monad, the changes require | shuffling around a bit of stuff in base though, I think. OK: will you do that, consulting the core libraries committee if necessary? Simon | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 21 April 2014 09:03 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Remove -fno-warn-amp sledgehammers | for validate (6074c5d) | | Yes the first part is done - see 3608f657d5 | | I removed the validate bandages first, so I could make sure that | everything worked properly with -fno-warn-amp *legitimately* on and not | deprecated. I then removed it afterwords in 3608f657d5 and replaced it | with a deprecation notice. That means HEAD should now be 100% ready to | actually make Applicative a superclass of Monad, the changes require | shuffling around a bit of stuff in base though, I think. | | On Mon, Apr 21, 2014 at 2:47 AM, Simon Peyton Jones | wrote: | > There is much more to change, right? | > | > * The code in the compiler that implements -fwarn-amp | > * Actually making Applicative a superclass of monad | > | > Simon | > | > | -----Original Message----- | > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On | Behalf | > | Of git at git.haskell.org | > | Sent: 20 April 2014 07:02 | > | To: ghc-commits at haskell.org | > | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers | > | for validate (6074c5d) | > | | > | Repository : ssh://git at git.haskell.org/ghc | > | | > | On branch : master | > | Link : | > | | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d146 | > | 07e | > | c4955735931/ghc | > | | > | >--------------------------------------------------------------- | > | | > | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | > | Author: Austin Seipp | > | Date: Sun Apr 20 01:00:44 2014 -0500 | > | | > | Remove -fno-warn-amp sledgehammers for validate | > | | > | GHC should now fully compliant with respect to the Applicative | > | Monad | > | proposal (including all upstream libraries), and does not need | to | > | suppress this warning anymore. | > | | > | Signed-off-by: Austin Seipp | > | | > | | > | >--------------------------------------------------------------- | > | | > | 6074c5da7f48f10e9b3b88d14607ec4955735931 | > | mk/validate-settings.mk | 2 -- | > | 1 file changed, 2 deletions(-) | > | | > | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk | index | > | 8797bf9..cac938d 100644 | > | --- a/mk/validate-settings.mk | > | +++ b/mk/validate-settings.mk | > | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | > | | > | GhcStage1HcOpts += -fwarn-tabs | > | GhcStage2HcOpts += -fwarn-tabs | > | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | > | sync upstream. | > | | > | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | > | | > | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of | > | the tests, and faster building of the utils to be installed | > | | > | GhcLibHcOpts += -O -dcore-lint | > | -GhcLibHcOpts += -fno-warn-amp # Temporary sledgehammer until we | > | sync upstream. | > | | > | # We define DefaultFastGhcLibWays in this style so that the value | > | is # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | > | | > | _______________________________________________ | > | ghc-commits mailing list | > | ghc-commits at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-commits | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Mon Apr 21 08:32:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 08:32:17 +0000 Subject: Strange behaviour in my signum In-Reply-To: <1397930545-23329-1-git-send-email-alexander@plaimi.net> References: <1397930545-23329-1-git-send-email-alexander@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555F40@DB3PRD3001MB020.064d.mgd.msft.net> Alexander Thanks for working on this. I suggest you add your draft patches and comments to the ticket #7858. Otherwise there is a terrible danger that they'll get lost. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Alexander Berntsen | Sent: 19 April 2014 19:02 | To: ghc-devs at haskell.org | Subject: Strange behaviour in my signum | | I started preparing patches for #7858. My abs patch works well, my | signum patch not at all. | | The gist of the bug is that abs and signum return erroneous values for | for the input -0.0. abs (-0.0 :: Float) should return 0.0, not -0.0. My | patch fixes this. For signum the situation is reverse. My patch does | *not* fix this. | | It does not work using GHC nor GHCi (GHCi -ddump-simpl demonstrated | below). The code for my signum is correct, as may be demonstrated by | putting | | signumFix x | | x == 0.0 = x | | isNaN x = x | | x > 0.0 = 1 | | otherwise = negate 1 | | in a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 | :: | Float) should now return -0.0, where signum returns 0.0 with the same | argument. | | Following this email come the patches. Please review the second patch. | If you can spot what I am doing wrong, I would be grateful. | | | | | Prelude> abs (-0.0 :: Float) | | ==================== Simplified expression ==================== let { | it_aqt :: GHC.Types.Float | [LclId, | Str=DmdType, | Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, | ConLike=False, WorkFree=False, Expandable=False, | Guidance=IF_ARGS [] 70 0}] | it_aqt = | GHC.Num.abs | @ GHC.Types.Float | GHC.Float.$fNumFloat | (GHC.Num.negate | @ GHC.Types.Float | GHC.Float.$fNumFloat | (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO | @ () | @ [()] | (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) | (GHC.Base.returnIO | @ [()] | (GHC.Types.: | @ () | (it_aqt | `cast` (UnivCo representational GHC.Types.Float () | :: GHC.Types.Float ~# ())) | (GHC.Types.[] @ ()))) | | | 0.0 | | | | | Prelude> signum (-0.0 :: Float) | | ==================== Simplified expression ==================== let { | it_aKQ :: GHC.Types.Float | [LclId, | Str=DmdType, | Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, | ConLike=False, WorkFree=False, Expandable=False, | Guidance=IF_ARGS [] 70 0}] | it_aKQ = | GHC.Num.signum | @ GHC.Types.Float | GHC.Float.$fNumFloat | (GHC.Num.negate | @ GHC.Types.Float | GHC.Float.$fNumFloat | (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO | @ () | @ [()] | (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) | (GHC.Base.returnIO | @ [()] | (GHC.Types.: | @ () | (it_aKQ | `cast` (UnivCo representational GHC.Types.Float () | :: GHC.Types.Float ~# ())) | (GHC.Types.[] @ ()))) | | | 0.0 | | Alexander Berntsen (2): | Make Prelude.abs handle -0.0 correctly (#7858) | Make Prelude.signum handle -0.0 correctly (#7858) | | libraries/base/GHC/Float.lhs | 28 ++++++++++++++++++---------- | libraries/base/changelog.md | 2 ++ | 2 files changed, 20 insertions(+), 10 deletions(-) | | -- | 1.8.3.2 | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 21 08:33:51 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 08:33:51 +0000 Subject: HEADS-UP: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git In-Reply-To: <87ioq5ph6e.fsf@gmail.com> References: <87ob05mzid.fsf@gmail.com> <87ioq5ph6e.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555F51@DB3PRD3001MB020.064d.mgd.msft.net> | As there were no objections, I went on and implemented the change, so | as of | | | http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391d | 21d15a1 | | the repositories mentioned above are now part of ghc.git, and the same | procedure applies as when we folded-in testsuite some time ago. Great! But what, specifically, is "the same procedure"? That is, if I have an existing tree, what steps do I take to upgrade? Never underestimate how stupid I am with git. Thanks Simon From simonpj at microsoft.com Mon Apr 21 08:40:41 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 08:40:41 +0000 Subject: Validate Failures In-Reply-To: <3105610.mWPspcbopl@linux-hpeb.site> References: <3105610.mWPspcbopl@linux-hpeb.site> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555F89@DB3PRD3001MB020.064d.mgd.msft.net> | The T8333 failure is due to it reading my .ghci file, thus getting | additional output. Is there a way to automatically check that all tests | that use the "--interactive" flag also use "-ignore-dot-ghci" like the | ghci tests do, or must one wait for validate failures due to that and | add it then? Could we not pass -ignore-dot-ghci to every test-invocation, whether in ghci tests or not? Maybe someone can make a patch to do that? Simon From austin at well-typed.com Mon Apr 21 13:12:14 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Apr 2014 08:12:14 -0500 Subject: OverloadedRecordFields merge Message-ID: Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From fuuzetsu at fuuzetsu.co.uk Mon Apr 21 13:53:11 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 21 Apr 2014 15:53:11 +0200 Subject: OverloadedRecordFields merge In-Reply-To: References: Message-ID: <535522C7.2080209@fuuzetsu.co.uk> On 04/21/2014 03:12 PM, Austin Seipp wrote: > Hello all, > > As some of you might have seen last week, my colleague Adam took the > time to get his OverloadedRecordFields back up to date with regards to > HEAD. > > I'm now wondering: when should we pull the trigger? I am inclined to > say 'soon'. In particular, the ORF changes are rather large, and Adam > has hinted to me it touches a lot of components of e.g. name > resolution. A large change with some fairly big impacts, in other > words. > > I think it is perhaps best to merge soon - so that it does not get out > of date and cause undue burden to Adam, but also so that we have > maximal amounts of time to sort out issues in the long haul that it > might expose. > > Simon - I believe you reviewed Adam's work in the past, yes? I am > wondering what you think we should do here. I am more than willing to > defer to you and let you do the merge after another review. On the > other hand, if you already did review it and feel confident after a > look or two, I'm more than willing to take over sometime this week. > > Adam - since you emailed us last week, Herbert went ahead and merged > 'base' into GHC's repository. This does not invalidate the changes you > gave us, it just means the two commits can be collapsed into one. > Also, the performance failures seem like minor anomalies, but I have > not yet directly built the ORF branch to confirm this. You're free to > rebase yourself, or I can likely handle it without much issue soon. > > If anyone else has opinions here - please speak up, I'm all ears. > > For those reading, Adam's implementation is available in current form here: > > - https://github.com/adamgundry/ghc > - https://github.com/adamgundry/packages-base > - https://github.com/adamgundry/haddock > I see a change to the Haddock interface file but the interface file version was not bumped (top of the file) which means that Haddock will try to read old interface file versions which will fail (I think). I would try myself but my system currently isn't really in appropriate state, perhaps I manage to do so later. It'd be great if we could default that to empty Map if we can't read it in but I don't think we can do that with existing binary (but we should be able to with the future CBOR stuff). Other than that, the Haddock patch looks good but again, I can not try it myself at the moment. I have to say I'm quite excited for overloaded records. -- Mateusz K. From eir at cis.upenn.edu Mon Apr 21 18:18:54 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 21 Apr 2014 14:18:54 -0400 Subject: update "latest" user manual Message-ID: Hi devs, I?m not sure who is responsible for this (Austin? Herbert?), but http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to v7.8.1, though 7.8.2 is available. We should update. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From metaniklas at gmail.com Tue Apr 22 01:03:49 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Tue, 22 Apr 2014 03:03:49 +0200 Subject: Automating Windows setup for development Message-ID: Hi! I have made a Powershell script that sets up a GHC build environment on Windows from scratch. It's at https://github.com/melted/getghc. It largely follows the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. It has no dependencies aside from Powershell 3.0. The reason I made it was to make it easier to set up a build bot on a clean machine. But it's probably generally useful for people who want to develop GHC on Windows. Usage: - Put the script in an empty directory - Run it - Hope for the best Potential problems: - If Python 2.7 is already installed and not on the path, the script wont install it, and msys wont pick up the path. Solution: Add the path to python in the control panel. - Powershell wont run unsigned scripts by default. The error message will give a hint how to disable that. I will add a signed version as soon as I can figure out how. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Apr 22 01:12:57 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Apr 2014 20:12:57 -0500 Subject: Automating Windows setup for development In-Reply-To: References: Message-ID: This is really cool, thanks! If you wouldn't mind, perhaps that page should be updated (the MSYS2 page) to point to your Powershell script. That would be really useful and make it much easier to find for people who don't follow the mailing list. On Mon, Apr 21, 2014 at 8:03 PM, Niklas Larsson wrote: > Hi! > > I have made a Powershell script that sets up a GHC build environment on > Windows from scratch. It's at https://github.com/melted/getghc. It largely > follows the instructions at > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. It > has no dependencies aside from Powershell 3.0. > > The reason I made it was to make it easier to set up a build bot on a clean > machine. But it's probably generally useful for people who want to develop > GHC on Windows. > > Usage: > - Put the script in an empty directory > - Run it > - Hope for the best > > Potential problems: > - If Python 2.7 is already installed and not on the path, the script wont > install it, and msys wont pick up the path. Solution: Add the path to python > in the control panel. > - Powershell wont run unsigned scripts by default. The error message will > give a hint how to disable that. I will add a signed version as soon as I > can figure out how. > > Niklas > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Apr 22 04:48:00 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Apr 2014 23:48:00 -0500 Subject: update "latest" user manual In-Reply-To: References: Message-ID: This is fixed, thanks Richard. I just forgot to update the symlink. On Mon, Apr 21, 2014 at 1:18 PM, Richard Eisenberg wrote: > Hi devs, > > I?m not sure who is responsible for this (Austin? Herbert?), but > http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to > v7.8.1, though 7.8.2 is available. We should update. > > Thanks, > Richard > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From afarmer at ittc.ku.edu Tue Apr 22 06:07:26 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Tue, 22 Apr 2014 01:07:26 -0500 Subject: update "latest" user manual In-Reply-To: References: Message-ID: Somewhat related: Using Hoogle with +ghc will give results which link into the ghc haddock docs. For instance: http://www.haskell.org/hoogle/?hoogle=%2Bghc+getOccName The link for 'getOccName' points to: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/Name.html#v:getOccName which gives a 404. But this link (adding the version number 7.8.2 in) does: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.8.2/Name.html#v:getOccName I'm not sure if this is Hoogle's fault or something someone on ghc-devs can fix, but can you symlink (or otherwise redirect) the 'ghc' to 'ghc-7.8.2'? On Mon, Apr 21, 2014 at 11:48 PM, Austin Seipp wrote: > This is fixed, thanks Richard. I just forgot to update the symlink. > > On Mon, Apr 21, 2014 at 1:18 PM, Richard Eisenberg wrote: >> Hi devs, >> >> I?m not sure who is responsible for this (Austin? Herbert?), but >> http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to >> v7.8.1, though 7.8.2 is available. We should update. >> >> Thanks, >> Richard >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Tue Apr 22 06:16:46 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 01:16:46 -0500 Subject: update "latest" user manual In-Reply-To: References: Message-ID: This is now fixed as well, including as other possible issues. Thanks! On Tue, Apr 22, 2014 at 1:07 AM, Andrew Farmer wrote: > Somewhat related: Using Hoogle with +ghc will give results which link > into the ghc haddock docs. > > For instance: http://www.haskell.org/hoogle/?hoogle=%2Bghc+getOccName > > The link for 'getOccName' points to: > > http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/Name.html#v:getOccName > > which gives a 404. But this link (adding the version number 7.8.2 in) does: > > http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.8.2/Name.html#v:getOccName > > I'm not sure if this is Hoogle's fault or something someone on > ghc-devs can fix, but can you symlink (or otherwise redirect) the > 'ghc' to 'ghc-7.8.2'? > > On Mon, Apr 21, 2014 at 11:48 PM, Austin Seipp wrote: >> This is fixed, thanks Richard. I just forgot to update the symlink. >> >> On Mon, Apr 21, 2014 at 1:18 PM, Richard Eisenberg wrote: >>> Hi devs, >>> >>> I?m not sure who is responsible for this (Austin? Herbert?), but >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to >>> v7.8.1, though 7.8.2 is available. We should update. >>> >>> Thanks, >>> Richard >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Tue Apr 22 07:49:22 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 22 Apr 2014 09:49:22 +0200 Subject: checking clean reporting a lot of non-deleted files. Message-ID: <53561F02.1070608@centrum.cz> Hello Herbert, I hope you are the right person to ask, but it looks like after folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to ghc tree the build's checking clean step reports a lot of non-deleted files. This makes our builder logs quite huge: http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html the situation just few days ago was quite different: http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html Do you think this is caused by your change? If not, do you have an idea what's going wrong here? Thanks! Karel From simonpj at microsoft.com Tue Apr 22 09:01:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Apr 2014 09:01:00 +0000 Subject: Validate Failures In-Reply-To: <3105610.mWPspcbopl@linux-hpeb.site> References: <3105610.mWPspcbopl@linux-hpeb.site> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A55BD54@DB3PRD3001MB020.064d.mgd.msft.net> | Finally, simpl015 is a test that does only sometimes fail. It uses on | my box an estimated 2GB of memory, and when I haven't anything else | memory-hungry running, it passes, but when I have (as I do by default) | SeaMonkey running (with tons of open tabs), my box quasi-freezes, the | test times out, and the browser is OOM-killed. Yes that's really a bug, thanks. I have opened #9020. Simon From austin at well-typed.com Tue Apr 22 09:03:48 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 04:03:48 -0500 Subject: OverloadedRecordFields merge In-Reply-To: <535522C7.2080209@fuuzetsu.co.uk> References: <535522C7.2080209@fuuzetsu.co.uk> Message-ID: I rebased the ORF work (fixing a minor merge by hand) and it is now available in GHC and Haddock under the 'orf' branches. Do feel free to give them a try. On Mon, Apr 21, 2014 at 8:53 AM, Mateusz Kowalczyk wrote: > On 04/21/2014 03:12 PM, Austin Seipp wrote: >> Hello all, >> >> As some of you might have seen last week, my colleague Adam took the >> time to get his OverloadedRecordFields back up to date with regards to >> HEAD. >> >> I'm now wondering: when should we pull the trigger? I am inclined to >> say 'soon'. In particular, the ORF changes are rather large, and Adam >> has hinted to me it touches a lot of components of e.g. name >> resolution. A large change with some fairly big impacts, in other >> words. >> >> I think it is perhaps best to merge soon - so that it does not get out >> of date and cause undue burden to Adam, but also so that we have >> maximal amounts of time to sort out issues in the long haul that it >> might expose. >> >> Simon - I believe you reviewed Adam's work in the past, yes? I am >> wondering what you think we should do here. I am more than willing to >> defer to you and let you do the merge after another review. On the >> other hand, if you already did review it and feel confident after a >> look or two, I'm more than willing to take over sometime this week. >> >> Adam - since you emailed us last week, Herbert went ahead and merged >> 'base' into GHC's repository. This does not invalidate the changes you >> gave us, it just means the two commits can be collapsed into one. >> Also, the performance failures seem like minor anomalies, but I have >> not yet directly built the ORF branch to confirm this. You're free to >> rebase yourself, or I can likely handle it without much issue soon. >> >> If anyone else has opinions here - please speak up, I'm all ears. >> >> For those reading, Adam's implementation is available in current form here: >> >> - https://github.com/adamgundry/ghc >> - https://github.com/adamgundry/packages-base >> - https://github.com/adamgundry/haddock >> > > I see a change to the Haddock interface file but the interface file > version was not bumped (top of the file) which means that Haddock will > try to read old interface file versions which will fail (I think). I > would try myself but my system currently isn't really in appropriate > state, perhaps I manage to do so later. It'd be great if we could > default that to empty Map if we can't read it in but I don't think we > can do that with existing binary (but we should be able to with the > future CBOR stuff). > > Other than that, the Haddock patch looks good but again, I can not try > it myself at the moment. > > I have to say I'm quite excited for overloaded records. > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Apr 22 09:32:55 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Apr 2014 09:32:55 +0000 Subject: HEADS-UP: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git References: <87ob05mzid.fsf@gmail.com> <87ioq5ph6e.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A55BDD3@DB3PRD3001MB020.064d.mgd.msft.net> I would love a reply to this query. Currently I don't dare do 'git pull' into my active working trees. Specifically: what steps, if any, beyond 'git pull --rebase' do I need to do, to update my working trees. Thanks Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 21 April 2014 09:34 | To: 'Herbert Valerio Riedel'; ghc-devs | Subject: RE: HEADS-UP: Folding in base, integer-{gmp, single}, ghc- | prim, and haskell-template into ghc.git | | | | As there were no objections, I went on and implemented the change, so | | as of | | | | | | | http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391 | | d | | 21d15a1 | | | | the repositories mentioned above are now part of ghc.git, and the | same | | procedure applies as when we folded-in testsuite some time ago. | | Great! But what, specifically, is "the same procedure"? That is, if I | have an existing tree, what steps do I take to upgrade? | | Never underestimate how stupid I am with git. | | Thanks | | Simon From austin at well-typed.com Tue Apr 22 11:18:59 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 06:18:59 -0500 Subject: OverloadedRecordFields merge In-Reply-To: References: <535522C7.2080209@fuuzetsu.co.uk> Message-ID: Hello all, The work is now instead on the 'wip/orf' branch. In particular this is more in-line with what we traditionally do now. The new branch fixes an error - I forgot to add a file! It should now all build correctly. Finally, the Haddock changes are now correctly attributed to Adam (not me), and the interface file version was bumped to v26. Hopefully that should do it! On Tue, Apr 22, 2014 at 4:03 AM, Austin Seipp wrote: > I rebased the ORF work (fixing a minor merge by hand) and it is now > available in GHC and Haddock under the 'orf' branches. Do feel free to > give them a try. > > On Mon, Apr 21, 2014 at 8:53 AM, Mateusz Kowalczyk > wrote: >> On 04/21/2014 03:12 PM, Austin Seipp wrote: >>> Hello all, >>> >>> As some of you might have seen last week, my colleague Adam took the >>> time to get his OverloadedRecordFields back up to date with regards to >>> HEAD. >>> >>> I'm now wondering: when should we pull the trigger? I am inclined to >>> say 'soon'. In particular, the ORF changes are rather large, and Adam >>> has hinted to me it touches a lot of components of e.g. name >>> resolution. A large change with some fairly big impacts, in other >>> words. >>> >>> I think it is perhaps best to merge soon - so that it does not get out >>> of date and cause undue burden to Adam, but also so that we have >>> maximal amounts of time to sort out issues in the long haul that it >>> might expose. >>> >>> Simon - I believe you reviewed Adam's work in the past, yes? I am >>> wondering what you think we should do here. I am more than willing to >>> defer to you and let you do the merge after another review. On the >>> other hand, if you already did review it and feel confident after a >>> look or two, I'm more than willing to take over sometime this week. >>> >>> Adam - since you emailed us last week, Herbert went ahead and merged >>> 'base' into GHC's repository. This does not invalidate the changes you >>> gave us, it just means the two commits can be collapsed into one. >>> Also, the performance failures seem like minor anomalies, but I have >>> not yet directly built the ORF branch to confirm this. You're free to >>> rebase yourself, or I can likely handle it without much issue soon. >>> >>> If anyone else has opinions here - please speak up, I'm all ears. >>> >>> For those reading, Adam's implementation is available in current form here: >>> >>> - https://github.com/adamgundry/ghc >>> - https://github.com/adamgundry/packages-base >>> - https://github.com/adamgundry/haddock >>> >> >> I see a change to the Haddock interface file but the interface file >> version was not bumped (top of the file) which means that Haddock will >> try to read old interface file versions which will fail (I think). I >> would try myself but my system currently isn't really in appropriate >> state, perhaps I manage to do so later. It'd be great if we could >> default that to empty Map if we can't read it in but I don't think we >> can do that with existing binary (but we should be able to with the >> future CBOR stuff). >> >> Other than that, the Haddock patch looks good but again, I can not try >> it myself at the moment. >> >> I have to say I'm quite excited for overloaded records. >> >> -- >> Mateusz K. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Apr 22 12:42:46 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 07:42:46 -0500 Subject: Status updates Message-ID: Hello all, At the behast of Simon&Simon, we're going to start doing weekly summary updates. We generally meet every week, but lots of times people may not be privvy to our plans. Here's to fixing that! (I would have started last week actually - but I got cut off by a hardware failure last week due to a lightning storm that fried some stuff! Nothing ultra critical, and after a little time and some replacements, though, everything seems OK.) So here's a status summary of what I've been up to, and what the plans are: - Last week, I was cut short on time due to hardware failure, but I spent time this past weekend playing catch-up a bit. - The new OverloadedRecordFields extension is Ready To Go, as I hinted on the list earlier. You can find the work on 'wip/orf' branches in GHC and Haddock. Thanks to Adam, catching this back up to HEAD did not take very long. I would like to merge it within the next week before it bitrots any further. If you're working on a branch dealing with the renamer, name resolution, desugaring, be warned! Big patch incoming! - The Applicative/Monad changes are on their way. After some minor fiddling this morning, the patches are about 95% complete I'd say - they just require a few minor touchups to some upstream libraries. I'd like to merge the AMP patches within the week if possible. They're pending review from the Core Libraries committee now. This patch should not negatively impact anyone working on base right now, I imagine. Or at least not very much. - I spent some time on a new optimization for low-level memory copies, and support for -march/-mcpu in GHC as a side project, so we can take advantage of CPU-specific features more easily. After some fumbling on Saturday and wanting to merge them, I got stalled by a problem, but I think I see my (horrific, stupid, stupid) error now upon review. Hopefully I can get this in soon. - I also spent time this week trying something else fun: I spent a few hours dealing with the Coverity static analyzer tool, attempting to run it over the GHC Runtime system. I succeeded! According to their statistics, it has a total of 124,074 LOC analyzed (this includes header files), with 44 detected possible defects throughout, with a defect ratio of 0.35. If their claims are to be believed, they typically hit within a 5-20% false positive rate. That would mean 30 of these bugs could be real, in fact. At the moment, Scan results are not public, and I do not (yet) have access to the defects. If you'd like access, don't worry - I'll be sending out another email soon about this, and who wants access to the reports... If you'd like to know more, see https://scan.coverity.com - I made some merges to the GHC branch, and all outstanding merges are now done, minus one from Carter, which I will take care of soon (I made it fall out of date, totally my fault). So far, the 7.8.3 branch contains about 7 bug fixes, but more are surely going to be on the way. - There's a new 7.8 FAQ page - https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ - over the past few weeks, I've spent time talking to users and collecting some pitfalls they've run into, since a lot of things changed this cycle. This page is preliminary, but *many* people have been tripped up by the few things in there! If you've encountered some stumbling block with 7.8, please add it to the page. Also, if the wording is confusing, please re-word it if you can, or tell me! I will advertise this FAQ more widely to glasgow-haskell-users soon. ------------------------------------------------------------------------------------------ But what about this week? Well: - Like I said above, I'll be merging some things, hopefully including: my optimization, ORF, and the AMP changes. Watch this space. - I will be triaging bugs. I've been putting this off because it's a bit tedious, but I'm likely going to start after this email and Just Do It. Prepare your inbox, depending on how well I can wield the 'bulk edit' feature. By the end of it, we should have an accurate depiction of what we want in 7.8.3. - On that note, we'll be using a new milestoning policy. Things filed at 7.4 stage will now be demoted in priority, since the 7.8 branch is done. The 7.6 tickets will NOT be re-milestoned at all - they could be young, and their priority shouldn't be touched unfairly and preemptively. Most people don't need to care about this, except possibly me and Herbert. But if you do want to move something around, please let me know, and I'll fill you in on the details. - I've been looking into our CI setup for GHC, and evaluating things. Right now though, I am directly working on getting Windows build bots set up on Gabor's infrastructure. He gave me the credentials, and hopefully this should not take long, it just slipped my mind. But mostly I've been looking at CI systems for Hackage, so that we can try to continuously integrate a subset of important packages against GHC over time. Right now, we have Travis-CI thanks to Herbert, but not quite everyone uses this (or doesn't properly configure it to e.g. test HEAD). This would really help find things in the future, I think, especially closer to release. It would also really help find nasty bugs in the RCs, like the dreaded #8978 Right now, after some thought, I'm looking into Michael's Stackage as a starting point for this, as he's done some awesome work. But I haven't yet done so in anger, and there are some other things I want to try too. ------------------------------------------------------------------------------------------ I think that's all for now. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From chris at chrisdornan.com Tue Apr 22 13:22:48 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 22 Apr 2014 14:22:48 +0100 Subject: [commit: ghc] wip/orf: ghc: implement OverloadedRecordFields (fe77cbf) In-Reply-To: <20140422111722.143EA2406B@ghc.haskell.org> References: <20140422111722.143EA2406B@ghc.haskell.org> Message-ID: Marvellous On 22/04/2014 12:17, "git at git.haskell.org" wrote: >Repository : ssh://git at git.haskell.org/ghc > >On branch : wip/orf >Link : >http://ghc.haskell.org/trac/ghc/changeset/fe77cbf15dd44bb72943357d65bd8adf >9f4deee5/ghc > >>--------------------------------------------------------------- > >commit fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >Author: Adam Gundry >Date: Tue Apr 22 02:12:03 2014 -0500 > > ghc: implement OverloadedRecordFields > > This fully implements the new ORF extension, developed during the >Google > Summer of Code 2013, and as described on the wiki: > > https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields > > This also updates the Haddock submodule. > > Reviewed-by: Simon Peyton Jones > Signed-off-by: Austin Seipp > > >>--------------------------------------------------------------- > >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 > compiler/basicTypes/Avail.hs | 149 ++++++- > compiler/basicTypes/DataCon.lhs | 21 +- > compiler/basicTypes/DataCon.lhs-boot | 2 + > compiler/basicTypes/FieldLabel.lhs | 128 ++++++ > compiler/basicTypes/Id.lhs | 12 +- > compiler/basicTypes/MkId.lhs | 2 +- > compiler/basicTypes/OccName.lhs | 8 + > compiler/basicTypes/RdrName.lhs | 123 +++-- > compiler/deSugar/Check.lhs | 4 +- > compiler/deSugar/Coverage.lhs | 4 +- > compiler/deSugar/Desugar.lhs | 2 + > compiler/deSugar/DsExpr.lhs | 18 +- > compiler/deSugar/DsMeta.hs | 4 +- > compiler/deSugar/DsMonad.lhs | 1 + > compiler/deSugar/MatchCon.lhs | 6 +- > compiler/ghc.cabal.in | 3 + > compiler/ghc.mk | 7 + > compiler/hsSyn/Convert.lhs | 23 +- > compiler/hsSyn/HsDecls.lhs | 6 + > compiler/hsSyn/HsExpr.lhs | 5 +- > compiler/hsSyn/HsImpExp.lhs | 33 +- > compiler/hsSyn/HsPat.lhs | 39 +- > compiler/hsSyn/HsTypes.lhs | 51 ++- > compiler/hsSyn/HsUtils.lhs | 80 ++-- > compiler/iface/BuildTyCl.lhs | 2 +- > compiler/iface/IfaceSyn.lhs | 52 +-- > compiler/iface/LoadIface.lhs | 19 +- > compiler/iface/MkIface.lhs | 27 +- > compiler/iface/TcIface.lhs | 36 +- > compiler/main/DynFlags.hs | 9 + > compiler/main/GHC.hs | 19 +- > compiler/main/HscMain.hs | 16 +- > compiler/main/HscTypes.lhs | 27 +- > compiler/main/InteractiveEval.hs | 2 +- > compiler/main/PprTyThing.hs | 12 +- > compiler/main/TidyPgm.lhs | 12 +- > compiler/parser/Parser.y.pp | 6 +- > compiler/parser/RdrHsSyn.lhs | 6 +- > compiler/prelude/PrelInfo.lhs | 2 +- > compiler/prelude/PrelNames.lhs | 43 +- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 321 ++++++++++--- > compiler/rename/RnExpr.lhs | 20 +- > compiler/rename/RnNames.lhs | 470 >+++++++++++++++----- > compiler/rename/RnPat.lhs | 75 ++-- > compiler/rename/RnSource.lhs | 90 ++-- > compiler/rename/RnTypes.lhs | 53 ++- > compiler/typecheck/FamInst.lhs | 53 ++- > compiler/typecheck/Inst.lhs | 3 +- > compiler/typecheck/TcEnv.lhs | 57 +-- > compiler/typecheck/TcErrors.lhs | 54 ++- > compiler/typecheck/TcEvidence.lhs | 1 + > compiler/typecheck/TcExpr.lhs | 320 ++++++++++--- > compiler/typecheck/TcFldInsts.lhs | 468 >+++++++++++++++++++ > compiler/typecheck/TcGenDeriv.lhs | 11 +- > compiler/typecheck/TcGenGenerics.lhs | 16 +- > compiler/typecheck/TcHsSyn.lhs | 4 +- > compiler/typecheck/TcHsType.lhs | 16 +- > compiler/typecheck/TcInstDcls.lhs | 4 +- > compiler/typecheck/TcInteract.lhs | 65 ++- > compiler/typecheck/TcPat.lhs | 24 +- > compiler/typecheck/TcRnDriver.lhs | 25 +- > compiler/typecheck/TcRnMonad.lhs | 5 +- > compiler/typecheck/TcRnTypes.lhs | 31 +- > compiler/typecheck/TcSMonad.lhs | 18 +- > compiler/typecheck/TcSplice.lhs | 2 +- > compiler/typecheck/TcTyClsDecls.lhs | 79 ++-- > compiler/typecheck/TcType.lhs | 9 + > compiler/typecheck/TcValidity.lhs | 19 +- > compiler/types/TyCon.lhs | 54 ++- > compiler/types/Type.lhs | 29 +- > compiler/types/Type.lhs-boot | 2 + > compiler/types/TypeRep.lhs | 43 +- > compiler/utils/Binary.hs | 1 - > compiler/utils/FastStringEnv.lhs | 77 ++++ > docs/users_guide/glasgow_exts.xml | 307 +++++++++++++ > libraries/base/GHC/Base.lhs | 3 + > libraries/base/GHC/Records.hs | 249 +++++++++++ > libraries/base/GHC/TypeLits.hs | 8 +- > libraries/base/base.cabal | 1 + > testsuite/tests/driver/T4437.hs | 1 + > testsuite/tests/ghci/scripts/ghci042.stdout | 2 +- > testsuite/tests/module/mod176.stderr | 2 +- > .../{annotations => overloadedrecflds}/Makefile | 0 > .../ghci}/Makefile | 0 > testsuite/tests/overloadedrecflds/ghci/all.T | 3 + > .../ghci/overloadedrecfldsghci01.script | 13 + > .../ghci/overloadedrecfldsghci01.stdout | 11 + > .../should_fail}/Makefile | 0 > .../should_fail/OverloadedRecFldsFail04_A.hs | 9 + > .../should_fail/OverloadedRecFldsFail06_A.hs | 16 + > .../should_fail/OverloadedRecFldsFail08_A.hs | 14 + > .../tests/overloadedrecflds/should_fail/all.T | 16 + > .../should_fail/overloadedrecfldsfail01.hs | 17 + > .../should_fail/overloadedrecfldsfail01.stderr | 16 + > .../should_fail/overloadedrecfldsfail02.hs | 19 + > .../should_fail/overloadedrecfldsfail02.stderr | 50 +++ > .../should_fail/overloadedrecfldsfail03.hs | 7 + > .../should_fail/overloadedrecfldsfail03.stderr | 5 + > .../should_fail/overloadedrecfldsfail04.hs | 9 + > .../should_fail/overloadedrecfldsfail04.stderr | 5 + > .../should_fail/overloadedrecfldsfail05.hs | 10 + > .../should_fail/overloadedrecfldsfail05.stderr | 10 + > .../should_fail/overloadedrecfldsfail06.hs | 10 + > .../should_fail/overloadedrecfldsfail06.stderr | 15 + > .../should_fail/overloadedrecfldsfail07.hs | 11 + > .../should_fail/overloadedrecfldsfail07.stderr | 6 + > .../should_fail/overloadedrecfldsfail08.hs | 13 + > .../should_fail/overloadedrecfldsfail08.stderr | 47 ++ > .../should_fail/overloadedrecfldsfail09.hs | 9 + > .../should_fail/overloadedrecfldsfail09.stderr | 20 + > .../should_fail/overloadedrecfldsfail10.hs | 11 + > .../should_fail/overloadedrecfldsfail10.stderr | 9 + > .../should_run}/Makefile | 0 > .../should_run/OverloadedRecFldsRun01_A.hs | 9 + > .../should_run/OverloadedRecFldsRun02_A.hs | 9 + > .../should_run/OverloadedRecFldsRun07_A.hs | 11 + > .../should_run/OverloadedRecFldsRun07_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_A.hs | 11 + > .../should_run/OverloadedRecFldsRun08_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_C.hs | 7 + > .../should_run/OverloadedRecFldsRun11_A.hs | 9 + > .../should_run/OverloadedRecFldsRun11_A.hs-boot | 5 + > .../should_run/OverloadedRecFldsRun11_B.hs | 7 + > .../should_run/OverloadedRecFldsRun12_A.hs | 11 + > .../should_run/OverloadedRecFldsRun12_B.hs | 7 + > testsuite/tests/overloadedrecflds/should_run/all.T | 26 ++ > .../should_run/overloadedrecfldsrun01.hs | 70 +++ > .../should_run/overloadedrecfldsrun01.stdout | 13 + > .../should_run/overloadedrecfldsrun02.hs | 6 + > .../should_run/overloadedrecfldsrun02.stdout | 0 > .../should_run/overloadedrecfldsrun03.hs | 18 + > .../should_run/overloadedrecfldsrun03.stdout | 4 + > .../should_run/overloadedrecfldsrun04.hs | 18 + > .../should_run/overloadedrecfldsrun04.stdout | 3 + > .../should_run/overloadedrecfldsrun05.hs | 34 ++ > .../should_run/overloadedrecfldsrun05.stdout | 2 + > .../should_run/overloadedrecfldsrun06.hs | 28 ++ > .../should_run/overloadedrecfldsrun06.stdout | 1 + > .../should_run/overloadedrecfldsrun07.hs | 7 + > .../should_run/overloadedrecfldsrun07.stdout} | 0 > .../should_run/overloadedrecfldsrun08.hs | 7 + > .../should_run/overloadedrecfldsrun08.stdout | 2 + > .../should_run/overloadedrecfldsrun09.hs | 8 + > .../should_run/overloadedrecfldsrun09.stdout | 2 + > .../should_run/overloadedrecfldsrun10.hs | 12 + > .../should_run/overloadedrecfldsrun10.stderr | 2 + > .../should_run/overloadedrecfldsrun11.hs | 5 + > .../should_run/overloadedrecfldsrun11.stdout} | 0 > .../should_run/overloadedrecfldsrun12.hs | 6 + > .../should_run/overloadedrecfldsrun12.stdout | 2 + > .../should_run/overloadedrecfldsrun13.hs | 9 + > .../should_run/overloadedrecfldsrun13.stdout} | 0 > testsuite/tests/rename/should_fail/T5892a.stderr | 2 +- > .../tests/typecheck/should_fail/tcfail102.stderr | 3 +- > utils/ghctags/Main.hs | 2 +- > utils/haddock | 2 +- > 157 files changed, 4131 insertions(+), 759 deletions(-) > >Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color >--find-copies-harder --ignore-space-at-eol --cc >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >_______________________________________________ >ghc-commits mailing list >ghc-commits at haskell.org >http://www.haskell.org/mailman/listinfo/ghc-commits From marlowsd at gmail.com Tue Apr 22 14:08:06 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 22 Apr 2014 15:08:06 +0100 Subject: Automating Windows setup for development In-Reply-To: References: Message-ID: <535677C6.8010309@gmail.com> This reminds me: the instructions shouldn't be recommending that people add GHC's own mingw tools to their PATH. The build should work without that, and indeed we want to know if the build is using gcc from PATH because that's a bug (and could cause real problems). Cheers, Simon On 22/04/2014 02:12, Austin Seipp wrote: > This is really cool, thanks! > > If you wouldn't mind, perhaps that page should be updated (the MSYS2 > page) to point to your Powershell script. That would be really useful > and make it much easier to find for people who don't follow the > mailing list. > > On Mon, Apr 21, 2014 at 8:03 PM, Niklas Larsson wrote: >> Hi! >> >> I have made a Powershell script that sets up a GHC build environment on >> Windows from scratch. It's at https://github.com/melted/getghc. It largely >> follows the instructions at >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. It >> has no dependencies aside from Powershell 3.0. >> >> The reason I made it was to make it easier to set up a build bot on a clean >> machine. But it's probably generally useful for people who want to develop >> GHC on Windows. >> >> Usage: >> - Put the script in an empty directory >> - Run it >> - Hope for the best >> >> Potential problems: >> - If Python 2.7 is already installed and not on the path, the script wont >> install it, and msys wont pick up the path. Solution: Add the path to python >> in the control panel. >> - Powershell wont run unsigned scripts by default. The error message will >> give a hint how to disable that. I will add a signed version as soon as I >> can figure out how. >> >> Niklas >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > From Thomas.Winant at cs.kuleuven.be Tue Apr 22 14:17:54 2014 From: Thomas.Winant at cs.kuleuven.be (Thomas Winant) Date: Tue, 22 Apr 2014 16:17:54 +0200 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: References: <532062AB.50108@cs.kuleuven.be> Message-ID: <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> Hi, My apologies for the late reply. On 2014-04-10 17:43, Richard Eisenberg wrote: > What's the next step from your point of view? Are there unimplemented > bits of this? We do see some bits left to implement: * Partial pattern and expression signatures (see [1] for our view on this issue). * Partial type signatures for local bindings. What with 'let should not be generalised' (see [2])? The implementation also needs a thorough code review (and probably some refactoring as well) from a GHC dev. We'll be talking to SPJ via Skype on Thursday to discuss further details. I'll post another status update in due course. Cheers, Thomas Winant [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#PartialExpressionandPatternSignatures [2]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#LocalDefinitions > On Apr 10, 2014, at 3:48 AM, Thomas Winant > wrote: > >> Hi, >> >> I'm back with a status update. We implemented Austin's suggestion to >> make wildcards in partial type signatures behave like holes. >> >> Let's demonstrate the new behaviour with an example. The example >> program: >> >>> module Example where >>> foo :: (Show _a, _) => _a -> _ >>> foo x = show (succ x) >> >> Compiled with GHC master gives: >> >>> Example.hs:3:18: parse error on input ?_? >> >> When we compile it with our branch: >> >>> Example.hs:3:18: >>> Instantiated extra-constraints wildcard ?_? to: >>> (Enum _a) >>> in the type signature for foo :: (Show _a, _) => _a -> _ >>> at Example.hs:3:8-30 >>> The complete inferred type is: >>> foo :: forall _a. (Show _a, Enum _a) => _a -> String >>> To use the inferred type, enable PartialTypeSignatures >>> Example.hs:3:30: >>> Instantiated wildcard ?_? to: String >>> in the type signature for foo :: (Show _a, _) => _a -> _ >>> at Example.hs:3:8-30 >>> The complete inferred type is: >>> foo :: forall _a. (Show _a, Enum _a) => _a -> String >>> To use the inferred type, enable PartialTypeSignatures >> >> Now the types the wildcards were instantiated to are reported. Note >> that >> `_a` is still treated as a type variable, as prescribed in Haskell >> 2010. >> To treat it as a /named wildcard/, we pass the -XNamedWildcards flag >> and >> get: >> >>> [..] >>> Example.hs:3:24: >>> Instantiated wildcard ?_a? to: tw_a >>> in the type signature for foo :: (Show _a, _) => _a -> _ >>> at Example.hs:3:8-30 >>> The complete inferred type is: >>> foo :: forall tw_a. (Show tw_a, Enum tw_a) => tw_a -> String >>> To use the inferred type, enable PartialTypeSignatures >>> [..] >> >> An extra error message appears, reporting that `_a` was instantiated >> to >> a new type variable (`tw_a`). >> >> Finally, when passed the -XPartialTypeSignatures flag, the typechecker >> will just use the inferred types for the wildcards and compile the >> program without generating any error messages. >> >> We added this example and a section about the monomorphism restriction >> to the wiki page [1]. >> >> Comments and feedback are still welcome. >> >> Cheers, >> Thomas Winant >> >> >> [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures >> >> >> >> >> >> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From metaniklas at gmail.com Tue Apr 22 17:00:31 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Tue, 22 Apr 2014 19:00:31 +0200 Subject: Automating Windows setup for development In-Reply-To: References: Message-ID: I'll put it on the trac page as soon as I have updated it a bit. I found out how to rewrite the downloading so windows 7 don't have to have an upgraded powershell, I'll do that tomorrow. 2014-04-22 3:12 GMT+02:00 Austin Seipp : > This is really cool, thanks! > > If you wouldn't mind, perhaps that page should be updated (the MSYS2 > page) to point to your Powershell script. That would be really useful > and make it much easier to find for people who don't follow the > mailing list. > > On Mon, Apr 21, 2014 at 8:03 PM, Niklas Larsson > wrote: > > Hi! > > > > I have made a Powershell script that sets up a GHC build environment on > > Windows from scratch. It's at https://github.com/melted/getghc. It > largely > > follows the instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. > It > > has no dependencies aside from Powershell 3.0. > > > > The reason I made it was to make it easier to set up a build bot on a > clean > > machine. But it's probably generally useful for people who want to > develop > > GHC on Windows. > > > > Usage: > > - Put the script in an empty directory > > - Run it > > - Hope for the best > > > > Potential problems: > > - If Python 2.7 is already installed and not on the path, the script wont > > install it, and msys wont pick up the path. Solution: Add the path to > python > > in the control panel. > > - Powershell wont run unsigned scripts by default. The error message will > > give a hint how to disable that. I will add a signed version as soon as I > > can figure out how. > > > > Niklas > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Apr 22 17:02:06 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 12:02:06 -0500 Subject: Coverity Scan Message-ID: Hello all, As of this morning, GHC has been accepted into the Coverity Scan project! The results are in and a few of us are combing over them now. Some of you I'm sure would like to play around and see what it says. Please feel free to ask me for access. In general, Coverity is restrictive of access because of the security implications, but I think this is much less of a problem for us in general. That said, I won't give literally everyone in the world access, but there's no harm in having some eyes. The project is available here, and you can request access by giving your email address: https://scan.coverity.com/projects/1919 Currently me and Herbert are the owners, and so we can submit builds. I plan on inviting at least Simon M and Edward Yang as well. You two can also just apply via the UI and I will add you as well. Note that I think a few of these issues are quite real, but I do think we'll have to mitigate some by writing a Coverity model and tuning things to reduce the false impact rate. Luckily this shouldn't be too hard. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From greg at gregorycollins.net Tue Apr 22 17:17:44 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 22 Apr 2014 19:17:44 +0200 Subject: Coverity Scan In-Reply-To: References: Message-ID: I signed up (and you or someone else approved) but I still can't see the results of the scan :( On Tue, Apr 22, 2014 at 7:02 PM, Austin Seipp wrote: > Hello all, > > As of this morning, GHC has been accepted into the Coverity Scan > project! The results are in and a few of us are combing over them now. > Some of you I'm sure would like to play around and see what it says. > > Please feel free to ask me for access. In general, Coverity is > restrictive of access because of the security implications, but I > think this is much less of a problem for us in general. That said, I > won't give literally everyone in the world access, but there's no harm > in having some eyes. > > The project is available here, and you can request access by giving > your email address: https://scan.coverity.com/projects/1919 > > Currently me and Herbert are the owners, and so we can submit builds. > > I plan on inviting at least Simon M and Edward Yang as well. You two > can also just apply via the UI and I will add you as well. > > Note that I think a few of these issues are quite real, but I do think > we'll have to mitigate some by writing a Coverity model and tuning > things to reduce the false impact rate. Luckily this shouldn't be too > hard. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Apr 22 17:19:41 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 22 Apr 2014 12:19:41 -0500 Subject: Coverity Scan In-Reply-To: References: Message-ID: Hi Gregory, Please try again now. On Tue, Apr 22, 2014 at 12:17 PM, Gregory Collins wrote: > I signed up (and you or someone else approved) but I still can't see the > results of the scan :( > > > On Tue, Apr 22, 2014 at 7:02 PM, Austin Seipp wrote: >> >> Hello all, >> >> As of this morning, GHC has been accepted into the Coverity Scan >> project! The results are in and a few of us are combing over them now. >> Some of you I'm sure would like to play around and see what it says. >> >> Please feel free to ask me for access. In general, Coverity is >> restrictive of access because of the security implications, but I >> think this is much less of a problem for us in general. That said, I >> won't give literally everyone in the world access, but there's no harm >> in having some eyes. >> >> The project is available here, and you can request access by giving >> your email address: https://scan.coverity.com/projects/1919 >> >> Currently me and Herbert are the owners, and so we can submit builds. >> >> I plan on inviting at least Simon M and Edward Yang as well. You two >> can also just apply via the UI and I will add you as well. >> >> Note that I think a few of these issues are quite real, but I do think >> we'll have to mitigate some by writing a Coverity model and tuning >> things to reduce the false impact rate. Luckily this shouldn't be too >> hard. >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > -- > Gregory Collins -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From greg at gregorycollins.net Tue Apr 22 17:23:54 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 22 Apr 2014 19:23:54 +0200 Subject: Coverity Scan In-Reply-To: References: Message-ID: OK, that works, thanks! On Tue, Apr 22, 2014 at 7:19 PM, Austin Seipp wrote: > Hi Gregory, > > Please try again now. > > On Tue, Apr 22, 2014 at 12:17 PM, Gregory Collins > wrote: > > I signed up (and you or someone else approved) but I still can't see the > > results of the scan :( > > > > > > On Tue, Apr 22, 2014 at 7:02 PM, Austin Seipp > wrote: > >> > >> Hello all, > >> > >> As of this morning, GHC has been accepted into the Coverity Scan > >> project! The results are in and a few of us are combing over them now. > >> Some of you I'm sure would like to play around and see what it says. > >> > >> Please feel free to ask me for access. In general, Coverity is > >> restrictive of access because of the security implications, but I > >> think this is much less of a problem for us in general. That said, I > >> won't give literally everyone in the world access, but there's no harm > >> in having some eyes. > >> > >> The project is available here, and you can request access by giving > >> your email address: https://scan.coverity.com/projects/1919 > >> > >> Currently me and Herbert are the owners, and so we can submit builds. > >> > >> I plan on inviting at least Simon M and Edward Yang as well. You two > >> can also just apply via the UI and I will add you as well. > >> > >> Note that I think a few of these issues are quite real, but I do think > >> we'll have to mitigate some by writing a Coverity model and tuning > >> things to reduce the false impact rate. Luckily this shouldn't be too > >> hard. > >> > >> -- > >> Regards, > >> > >> Austin Seipp, Haskell Consultant > >> Well-Typed LLP, http://www.well-typed.com/ > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > > > > > -- > > Gregory Collins > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Tue Apr 22 20:37:25 2014 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Tue, 22 Apr 2014 13:37:25 -0700 (PDT) Subject: Coverity CID 43168 Message-ID: <1398199045.61793.YahooMailNeo@web164003.mail.gq1.yahoo.com> Hi, This is code I wrote for Trac ticket #2615. I will study it to see if it needs to be fixed. If so, I will submit a patch. I tried to put this into the triage section in Coverity, but I guess I don't have write access to update that. This is a minor memory leak (if at all). The semantics of the POSIX dlopen error isn't fully specified, so I'm unsure of whether I need to fix this or not. Howard B. Golden Northridge, CA, USA From jjaredsimpson at gmail.com Wed Apr 23 00:11:17 2014 From: jjaredsimpson at gmail.com (jared simpson) Date: Tue, 22 Apr 2014 20:11:17 -0400 Subject: Automating Windows setup for development In-Reply-To: References: Message-ID: Looking forward to trying this. Last time I tried to build on Windows I couldn't make it work and just gave up. On Tue, Apr 22, 2014 at 1:00 PM, Niklas Larsson wrote: > I'll put it on the trac page as soon as I have updated it a bit. I found > out how to rewrite the downloading so windows 7 don't have to have an > upgraded powershell, I'll do that tomorrow. > > > 2014-04-22 3:12 GMT+02:00 Austin Seipp : > > This is really cool, thanks! >> >> If you wouldn't mind, perhaps that page should be updated (the MSYS2 >> page) to point to your Powershell script. That would be really useful >> and make it much easier to find for people who don't follow the >> mailing list. >> >> On Mon, Apr 21, 2014 at 8:03 PM, Niklas Larsson >> wrote: >> > Hi! >> > >> > I have made a Powershell script that sets up a GHC build environment on >> > Windows from scratch. It's at https://github.com/melted/getghc. It >> largely >> > follows the instructions at >> > >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. >> It >> > has no dependencies aside from Powershell 3.0. >> > >> > The reason I made it was to make it easier to set up a build bot on a >> clean >> > machine. But it's probably generally useful for people who want to >> develop >> > GHC on Windows. >> > >> > Usage: >> > - Put the script in an empty directory >> > - Run it >> > - Hope for the best >> > >> > Potential problems: >> > - If Python 2.7 is already installed and not on the path, the script >> wont >> > install it, and msys wont pick up the path. Solution: Add the path to >> python >> > in the control panel. >> > - Powershell wont run unsigned scripts by default. The error message >> will >> > give a hint how to disable that. I will add a signed version as soon as >> I >> > can figure out how. >> > >> > Niklas >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Apr 23 07:35:14 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 23 Apr 2014 08:35:14 +0100 Subject: [commit: ghc] master: Be less untruthful about the prototypes of external functions (5a31f23) In-Reply-To: <20140422044030.322F22406B@ghc.haskell.org> References: <20140422044030.322F22406B@ghc.haskell.org> Message-ID: <53576D32.7070400@gmail.com> Could we have a comment with the ticket number next to the prototype please? Otherwise some well-meaning developer will "fix" it again in the future :-) Cheers, Simon On 22/04/2014 05:40, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/5a31f231eebfb8140f9b519b166094d9d4fc2d79/ghc > >> --------------------------------------------------------------- > > commit 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > Author: Colin Watson > Date: Sat Apr 12 01:55:07 2014 +0100 > > Be less untruthful about the prototypes of external functions > > GHC's generated C code uses dummy prototypes for foreign imports. At the > moment these all claim to be (void), i.e. functions of zero arguments. On > most platforms this doesn't matter very much: calls to these functions put > the parameters in the usual places anyway, and (with the exception of > varargs) things just work. > > However, the ELFv2 ABI on ppc64 optimises stack allocation > (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html): a call to a > function that has a prototype, is not varargs, and receives all parameters > in registers rather than on the stack does not require the caller to > allocate an argument save area. The incorrect prototypes cause GCC to > believe that all functions declared this way can be called without an > argument save area, but if the callee has sufficiently many arguments then > it will expect that area to be present, and will thus corrupt the caller's > stack. This happens in particular with calls to runInteractiveProcess in > libraries/process/cbits/runProcess.c. > > The simplest fix appears to be to declare these external functions with an > unspecified argument list rather than a void argument list. This is no > worse for platforms that don't care either way, and allows a successful > bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2 > ABI). > > Fixes #8965 > > Signed-off-by: Colin Watson > Signed-off-by: Austin Seipp > > >> --------------------------------------------------------------- > > 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > includes/Stg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/includes/Stg.h b/includes/Stg.h > index be966aa..1707c9b 100644 > --- a/includes/Stg.h > +++ b/includes/Stg.h > @@ -213,7 +213,7 @@ typedef StgFunPtr F_; > #define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) > #define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void) > #define FN_(f) StgFunPtr f(void) > -#define EF_(f) extern StgFunPtr f(void) > +#define EF_(f) extern StgFunPtr f() > > /* ----------------------------------------------------------------------------- > Tail calls > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From mail at joachim-breitner.de Wed Apr 23 09:09:35 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 23 Apr 2014 11:09:35 +0200 Subject: Status updates In-Reply-To: References: Message-ID: <1398244175.2515.32.camel@kirk> Hi, Am Dienstag, den 22.04.2014, 07:42 -0500 schrieb Austin Seipp: > - I've been looking into our CI setup for GHC, and evaluating things. > Right now though, I am directly working on getting Windows build bots > set up on Gabor's infrastructure. He gave me the credentials, and > hopefully this should not take long, it just slipped my mind. > > But mostly I've been looking at CI systems for Hackage, so that we > can try to continuously integrate a subset of important packages > against GHC over time. Right now, we have Travis-CI thanks to Herbert, > but not quite everyone uses this (or doesn't properly configure it to > e.g. test HEAD). > > This would really help find things in the future, I think, especially > closer to release. It would also really help find nasty bugs in the > RCs, like the dreaded #8978 > > Right now, after some thought, I'm looking into Michael's Stackage as > a starting point for this, as he's done some awesome work. But I > haven't yet done so in anger, and there are some other things I want > to try too. having GHC HQ monitor breakage in (a subset) of hackage for HEAD would be great! I can imagine a daily (or weekly, depending on resources) build of all of hackage or stackage using HEAD, and when there is a breakage, then git bisect on our soon bisectable repo and a tool that would allow the common git hacker to easily built and test the one breaking package will let us know about problems quickly and with little friction. (The sole purpose of this message is to convey motivation :-)) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Wed Apr 23 12:55:15 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 23 Apr 2014 14:55:15 +0200 Subject: checking clean reporting a lot of non-deleted files. In-Reply-To: <53561F02.1070608@centrum.cz> (Karel Gardas's message of "Tue, 22 Apr 2014 09:49:22 +0200") References: <53561F02.1070608@centrum.cz> Message-ID: <878uqwryrw.fsf@gmail.com> On 2014-04-22 at 09:49:22 +0200, Karel Gardas wrote: > I hope you are the right person to ask, but it looks like after > folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to > ghc tree the build's checking clean step reports a lot of non-deleted > files. This makes our builder logs quite huge: > > http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html > > the situation just few days ago was quite different: > > http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html > > Do you think this is caused by your change? If not, do you have an > idea what's going wrong here? Just to follow-up to ghc-devs, after a short off-list conversation, and a couple of fixes to the build-system, the builder logs seem to have been muted, judging from http://haskell.inf.elte.hu/builders/solaris-x86-head/37/14.html Cheers, hvr From conal at conal.net Thu Apr 24 00:29:06 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 23 Apr 2014 17:29:06 -0700 Subject: Help with cast error Message-ID: I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 07:01:46 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 07:01:46 +0000 Subject: Porting GHC Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A561817@DB3PRD3001MB020.064d.mgd.msft.net> Colin I saw your porting-ghc blog post (via the Haskell Weekly News) today. What a great post! Porting GHC to new architectures is way beyond the slender resources of GHC HQ, so depends utterly on volunteers. And you see to be a particularly skilled and knowledgeable one. Thank you! Simon PS: where you have offered patches to the main sources (e.g the function-prototype thing), did you elaborately comment the "technically wrong" prototype? I have this fear that in three year's time someone is going to say "oh, we could do better with that prototype" and re-introduce the bug! Aha. I've just checked #8965, and there's no comment at all. I'll add the commit message as a comment. Other ghc-devs, nb! Adding the ticket number to the comment is also fantastically helpful, because it often points to examples and discussion that are too long to include in the code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Apr 24 07:43:20 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 24 Apr 2014 09:43:20 +0200 Subject: RFC: template-haskell & Data.Map vs. Prelude.lookup use Message-ID: <87y4yvb2av.fsf@gmail.com> Hello *, In order to address https://github.com/haskell/cabal/issues/1811 I've prepared a commit for review at https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-dep-from-th However, I'm wondering if we really need Data.Map, or if would be equally ok to simply use O(n) Prelude.lookup-style dictionary Does anyone here happen to have an estimate for how large the dictionary in https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Language/Haskell/TH/PprLib.hs#l120 (which is the only use of Data.Map in TH) typically gets? Cheers, hvr From simonpj at microsoft.com Thu Apr 24 07:50:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 07:50:18 +0000 Subject: Strange checkout message Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A561905@DB3PRD3001MB020.064d.mgd.msft.net> Herbert or others, What does this mean (in a clean tree) git checkout wip/orf Checking out files: 100% (159/159), done. M utils/haddock Branch wip/orf set up to track remote branch wip/orf from origin. Switched to a new branch 'wip/orf' simonpj at cam-05-unx:~/code/HEAD-3$ What's all this about haddock being modified? I've just checked out a branch, which is supposed to make everything line up, isn't it? Do you need to say "git submodule update" as well? Could this be documented in the (upcoming?) workflows page? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 07:58:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 07:58:00 +0000 Subject: Help with cast error In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> (a ~ b) is a boxed, nominal equality. (a ~R# b) is an unboxed, representational equality So it is rightly rejected. For the boxed/unboxed thing, the paper ?practical aspects?? gives more detail. http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ I think you already know about the nominal/representational distinction. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 24 April 2014 01:29 To: glasgow-haskell-users at haskell.org; ghc-devs at haskell.org; Richard Eisenberg; Simon Peyton Jones Subject: Help with cast error I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 08:22:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 08:22:59 +0000 Subject: Cloning ghc-7.8 Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> How would I get a GHC 7.8 branch repo? Something like git clone http://git.haskell.org/ghc.git ghc-7.8-branch cd ghc-7.8-branch ./sync-all get git checkout ghc-7.8 git submodule update Is that enough? What about the non-submodule libraries? Do I need to do any more pull/get stuff? This would be another great entry on the workflow page. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 08:29:15 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 08:29:15 +0000 Subject: Status updates In-Reply-To: <1398244175.2515.32.camel@kirk> References: <1398244175.2515.32.camel@kirk> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A561986@DB3PRD3001MB020.064d.mgd.msft.net> | having GHC HQ monitor breakage in (a subset) of hackage for HEAD would | be great! I can imagine a daily (or weekly, depending on resources) | build of all of hackage or stackage using HEAD, and when there is a | breakage, then git bisect on our soon bisectable repo and a tool that | would allow the common git hacker to easily built and test the one | breaking package will let us know about problems quickly and with | little friction. | | (The sole purpose of this message is to convey motivation :-)) Please remember that "ghc hq" = Austin and me. And I have another job. Relying on GHC for anything means that you may wait a long time. So we increasingly rely on the army of GHC volunteers to do the heavy lifting. I'm increasingly encouraging Austin to see his role as supporting, encouraging, helping, coordinating, removing road-blocks from, keeping well-informed, and thanking volunteers, rather than doing the work himself. So Yay for motivation, but it's the ghc-devs community that you are addressing, not "ghc hq". And THANK YOU ghc-devs. We love you. Simon From johan.tibell at gmail.com Thu Apr 24 08:36:31 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 24 Apr 2014 10:36:31 +0200 Subject: Strange checkout message In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A561905@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A561905@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I believe you need to run `git submodule update`. The orf branch was likely set to use a different commit from the haddock repo than your current repo. Git doesn't automatically assume that you want to switch your submodule to use the same commit as the orf branch was using, hence you now have a "change" in your checkout relative to the orf branch (i.e. you changed to using a different commit from the haddock repo.) On Thu, Apr 24, 2014 at 9:50 AM, Simon Peyton Jones wrote: > Herbert or others, > > What does this mean (in a clean tree) > > git checkout wip/orf > > Checking out files: 100% (159/159), done. > > *M utils/haddock* > > Branch wip/orf set up to track remote branch wip/orf from origin. > > Switched to a new branch 'wip/orf' > > simonpj at cam-05-unx:~/code/HEAD-3$ > > What?s all this about haddock being modified? I?ve just checked out a > branch, which is supposed to make everything line up, isn?t it? > > Do you need to say ?git submodule update? as well? > > Could this be documented in the (upcoming?) workflows page? > > Thanks > > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Apr 24 08:45:34 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 24 Apr 2014 10:45:34 +0200 Subject: Status updates In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A561986@DB3PRD3001MB020.064d.mgd.msft.net> References: <1398244175.2515.32.camel@kirk> <618BE556AADD624C9C918AA5D5911BEF0A561986@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1398329134.2536.10.camel@kirk> Hi, Am Donnerstag, den 24.04.2014, 08:29 +0000 schrieb Simon Peyton Jones: > Please remember that "ghc hq" = Austin and me. sorry, I meant and should have said, more generally, GHC developers. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Thu Apr 24 10:14:16 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 10:14:16 +0000 Subject: Cloning ghc-7.8 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A562800@DB3PRD3001MB020.064d.mgd.msft.net> I tried the sequence below and got this: simonpj at cam-05-unx:~/code/ghc-7.8-branch$ git checkout ghc-7.8 warning: unable to rmdir utils/haddock: Directory not empty M libraries/Cabal M libraries/binary M libraries/vector Branch ghc-7.8 set up to track remote branch ghc-7.8 from origin. Switched to a new branch 'ghc-7.8' simonpj at cam-05-unx:~/code/ghc-7.8-branch$ ls utils/haddock/ ANNOUNCE doc/ haddock.cabal haskell.vim latex-test/ make-sdist.sh Setup.lhs* test/ build-windows-dist.sh driver/ haddock.spec hcar.tex LICENSE README src/ vendor/ CHANGES ghc.mk haddock.wrapper html-test/ Makefile resources/ STYLE simonpj at cam-05-unx:~/code/ghc-7.8-branch$ git submodule update Submodule path 'libraries/Cabal': checked out 'c226c0de042999bbe4c5c339c6c28a9be7f0c6d1' Submodule path 'libraries/binary': checked out '2799c25d85b4627200f2e4dcb30d2128488780c3' Submodule path 'libraries/vector': checked out '9baab444a57c4a225ee247fea27187d1892d90bf' simonpj at cam-05-unx:~/code/ghc-7.8-branch$ Notice the bit in red, and the lack of a submodule update message with I did "git submodule update". This is a completely fresh tree, newly cloned from the main repo. Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones Sent: 24 April 2014 09:23 To: ghc-devs at haskell.org Subject: Cloning ghc-7.8 How would I get a GHC 7.8 branch repo? Something like git clone http://git.haskell.org/ghc.git ghc-7.8-branch cd ghc-7.8-branch ./sync-all get git checkout ghc-7.8 git submodule update Is that enough? What about the non-submodule libraries? Do I need to do any more pull/get stuff? This would be another great entry on the workflow page. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Thu Apr 24 10:33:25 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 24 Apr 2014 17:33:25 +0700 Subject: Status updates In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A561986@DB3PRD3001MB020.064d.mgd.msft.net> References: <1398244175.2515.32.camel@kirk> <618BE556AADD624C9C918AA5D5911BEF0A561986@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Apr 24, 2014 at 3:29 PM, Simon Peyton Jones wrote: > So we increasingly rely on the army of GHC volunteers to do the heavy > lifting. I'm increasingly encouraging Austin to see his role as > supporting, > encouraging, > helping, > coordinating, > removing road-blocks from, > keeping well-informed, > and thanking > volunteers, rather than doing the work himself. > To that end, I have one or two book recommendations for Austin if he would like them (ping me off-list). Organizing volunteers isn't easy but specialists have worked hard on this problem and shared their results. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 10:38:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 10:38:40 +0000 Subject: Cloning ghc-7.8 In-Reply-To: <87tx9jaukj.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF0A562800@DB3PRD3001MB020.064d.mgd.msft.net> <87tx9jaukj.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A562DCA@DB3PRD3001MB020.064d.mgd.msft.net> OK. So are you saying that you can't reliably change to a different branch in an existing tree, but rather must freshly clone from the source each time you want to check out a different branch? That seems a bit extreme. I thought switching branches is precisely what git is good at. Still I'll blow away my tree and try what you say. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 24 April 2014 11:30 | To: Simon Peyton Jones | Cc: Austin Seipp | Subject: Re: Cloning ghc-7.8 | | On 2014-04-24 at 12:14:16 +0200, Simon Peyton Jones wrote: | > I tried the sequence below and got this: | | maybe try this sequence that was suggested by Austin on #ghc a couple | of | days ago: | | (sync-all has a little difficulty with the submodules | here, and you'll end up needing to always clean anyway due to interface | changes, etc) | 'git clone -b ghc-7.8 git://git.haskell.org && cd ghc | && ./sync-all get -b ghc-7.8' should do it | From hvriedel at gmail.com Thu Apr 24 11:00:01 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 24 Apr 2014 13:00:01 +0200 Subject: Cloning ghc-7.8 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A562DCA@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Thu, 24 Apr 2014 10:38:40 +0000") References: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF0A562800@DB3PRD3001MB020.064d.mgd.msft.net> <87tx9jaukj.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0A562DCA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87eh0nat72.fsf@gmail.com> On 2014-04-24 at 12:38:40 +0200, Simon Peyton Jones wrote: > OK. So are you saying that you can't reliably change to a different > branch in an existing tree, but rather must freshly clone from the > source each time you want to check out a different branch? > > That seems a bit extreme. I thought switching branches is precisely > what git is good at. In all fairness, you made it sound (e.g. Subject-line) as if you wanted to know how to *clone* a GHC 7.8 branch rather than switching to the ghc-7.8 branch... :-) That said, however: Yes, switching between the 'ghc-7.8' branch and 'master' is currently problematic, because 'ghc-7.8' has a different mix of submodules and loose subrepos than 'master', and the issue being that Git isn't aware of that, so Git gets confused here and there, as it doesn't have all information it needs. This will get better however, once everything is put under Git's control. Then switching between 'ghc-7.10' and GHC HEAD should work much smoother than now between 'ghc-7.8' and GHC HEAD Hope this makes some sense... From johan.tibell at gmail.com Thu Apr 24 11:05:10 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 24 Apr 2014 13:05:10 +0200 Subject: Cloning ghc-7.8 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A562DCA@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A56195B@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF0A562800@DB3PRD3001MB020.064d.mgd.msft.net> <87tx9jaukj.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0A562DCA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Apr 24, 2014 at 12:38 PM, Simon Peyton Jones wrote: > That seems a bit extreme. I thought switching branches is precisely what > git is good at. > It was made not so great in the past (i.e. 7.8) by us having the homegrown sync-all pull system instead of submodules. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Apr 24 13:04:55 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 24 Apr 2014 09:04:55 -0400 Subject: RFC: template-haskell & Data.Map vs. Prelude.lookup use In-Reply-To: <87y4yvb2av.fsf@gmail.com> References: <87y4yvb2av.fsf@gmail.com> Message-ID: <10970AFB-3008-4567-81FA-0CD54497BCF4@cis.upenn.edu> That map seems to store the set of variables during printing TH, for the purposes of disambiguating identifiers with the same name but different uniques. If blatting out a whole lot of program text, I could imagine the Map getting somewhat sizeable. But, it seems to only need the lookup and insert operations... is there a simpler data structure that has only these operations efficiently? Richard On Apr 24, 2014, at 3:43 AM, Herbert Valerio Riedel wrote: > Hello *, > > In order to address > > https://github.com/haskell/cabal/issues/1811 > > I've prepared a commit for review at > > https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-dep-from-th > > > However, I'm wondering if we really need Data.Map, or if would be > equally ok to simply use O(n) Prelude.lookup-style dictionary > > Does anyone here happen to have an estimate for how large the dictionary > in > > https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Language/Haskell/TH/PprLib.hs#l120 > > (which is the only use of Data.Map in TH) typically gets? > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From daniel.is.fischer at googlemail.com Thu Apr 24 15:54:22 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 24 Apr 2014 17:54:22 +0200 Subject: More validate failures Message-ID: <2886204.LBvCxqc7Mj@linux-hpeb.site> Running the full testsuite (sh validate --testsuite-only --slow), I get a lot of unexpected failures (45 on this run). typecheck/should_run/tcrun045 fails due to Compile failed (status 256) errors were: [1 of 1] Compiling Main ( tcrun045.hs, tcrun045.o ) tcrun045.hs:24:1: Illegal implict parameter ??imp::Int? In the context: (?imp::Int) While checking the super-classes of class ?D? In the class declaration for ?D? and 6.12, 7.0, 7.2 and 7.8 refuse the file with the same error, only 7.4 and 7.6 accept it. Is that a regression or are 7.4 and 7.6 wrong and it shouldn't have compiled? Then I get a lot of optllvm failures, like =====> GMapAssoc(optllvm) 891 of 3955 [0, 8, 0] cd ./indexed-types/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o GMapAssoc GMapAssoc.hs -O -fllvm -package containers >GMapAssoc.comp.stderr 2>&1 cd ./indexed-types/should_run && ./GMapAssoc GMapAssoc.run.stdout 2>GMapAssoc.run.stderr /bin/sh: Zeile 1: 21331 Speicherzugriffsfehler ./GMapAssoc < /dev/null > GMapAssoc.run.stdout 2> GMapAssoc.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for GMapAssoc(optllvm) or =====> qq007(optllvm) 1161 of 3955 [0, 10, 0] cd ./quasiquotation/qq007 && $MAKE -s --no-print-directory TH_QQ cd ./quasiquotation/qq007 && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 >qq007.comp.stderr 2>&1 /bin/sh: Zeile 1: 25528 Speicherzugriffsfehler '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp - dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -ignore- dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 > qq007.comp.stderr 2>&1 Compile failed (status 35584) errors were: *** unexpected failure for qq007(optllvm) which I don't know what to make of, other optllvm tests work fine. Has anybody an idea what might cause those? T6145 fails to compile with a type error and a missing argument to the `MG` constructor. Apparently the API changed but the test was not updated. T8639_api has unexpected stdout, the type is printed as `Bool` instead of the expected `GHC.Types.Bool`, I guess one should update the expected output, but maybe the type should be printed qualified? =====> T4891(normal) 1610 of 3955 [0, 14, 0] cd ./ghc-api/T4891 && $MAKE -s --no-print-directory T4891 T4891.run.stdout 2>T4891.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: T4891.hs:23:19: Module ?PrelNames? does not export ?iNTERACTIVE? gmake[2]: *** [T4891] Fehler 1 *** unexpected failure for T4891(normal) T3064 and T6048 allocate slightly more than they are allowed to (about 1% resp. 0.15% too much). Generally, I have the impression that whoever decides the 64-bit Linux allocation numbers has a system where the figures aresystematically lower than on mine, maybe the expected numbers should be given a bit higher. joao-circular fails the optllvm way with unexpected stdout: Actual stdout output differs from expected: --- ./programs/joao-circular/joao-circular.stdout 2014-04-24 11:18:07.363987627 +0200 +++ ./programs/joao-circular/joao-circular.run.stdout 2014-04-24 14:27:38.927486429 +0200 @@ -68,13 +68,6 @@ PUSHa "recfact" 2 PUSHa "x" 2 LOAD -PUSHa "x" 1 -PUSHa "x" 2 -LOAD -PUSHi 1 -SUB -STORE -CALL "recfact" MUL STORE C_Ident_1 "end_if_1": @@ -83,4 +76,4 @@ Detected Semantic Errors: [C_E_Name_AD_1 (C_Ident_1 "a")] -[] +[C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_while_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_if_t_e_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1] *** unexpected failure for joao-circular(optllvm) which I have no idea how to interpret. T7919 (optllvm) fails to compile. The ghci way, although it passed, uses a lot of memory (~ 2.5 G), temporarily froze my box, and got my browser OOM- killed. The other ways also use a lot of memory (~1.1 G - 1.7 G). While it looks as though it is to be expected that the test uses a fair bit of memory, perhaps it should not use quite as much. If somebody more knowledgeable looks at it that might be good. simplCore/should_compile/spec001 fails due to unexpected stdout, the `-fno- warn-amp` flag is deprecated, the pragma should be removed probably. arr016 (optllvm) failed with what looks serious: =====> arr016(optllvm) 3092 of 3955 [0, 32, 0] cd ./array/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o arr016 arr016.hs -O -fllvm >arr016.comp.stderr 2>&1 cd ./array/should_run && ./arr016 arr016.run.stdout 2>arr016.run.stderr /bin/sh: Zeile 1: 23929 Abgebrochen ./arr016 < /dev/null > arr016.run.stdout 2> arr016.run.stderr Wrong exit code (expected 0 , actual 134 ) Stdout: Stderr: arr016: internal error: MUT_ARR_PTRS_DIRTY object entered! (GHC version 7.9.20140424 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for arr016(optllvm) T7653(ghci) managed to get my browser OOM-killed again (yes, I was naive enough to restart it), using ~2.7 G of memory. And the test timed out - also when running only T7653 without the browser to compete for the memory. The threaded1 way uses even more memory (~2.9 G), other ways much, but not that much. posix002(threaded2) failed with +posix002: failed to create OS thread: Resource temporarily unavailable *** unexpected failure for posix002(threaded2) but that isn't replicable running the test alone. From conal at conal.net Thu Apr 24 16:13:14 2014 From: conal at conal.net (Conal Elliott) Date: Thu, 24 Apr 2014 09:13:14 -0700 Subject: Help with cast error In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks for the summary and paper pointer! I'll study up. -- Conal On Thu, Apr 24, 2014 at 12:58 AM, Simon Peyton Jones wrote: > (a ~ b) is a *boxed*, *nominal* equality. > > (a ~R# b) is an *unboxed, representational* equality > > > > So it is rightly rejected. > > > For the boxed/unboxed thing, the paper ?practical aspects?? gives more > detail. > http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ > > > > I think you already know about the nominal/representational distinction. > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 24 April 2014 01:29 > *To:* glasgow-haskell-users at haskell.org; ghc-devs at haskell.org; Richard > Eisenberg; Simon Peyton Jones > *Subject:* Help with cast error > > > > I'd appreciate help with a cast-related Core Lint error I'm getting with a > GHC plugin I'm working on: > > Argument value doesn't match argument type: > Fun type: > Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => > EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) > Arg type: > ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) > Arg: > CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) > ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R > > (I omitted the module prefixes for brevity.) Do I have a role wrong here, > or maybe something more fundamental? > > I can easily supply more info if it'd help. > > Thanks, -- Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Thu Apr 24 16:45:01 2014 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Thu, 24 Apr 2014 09:45:01 -0700 (PDT) Subject: Adding Doxygen (or other documentation tool) comments to GHC patches? Message-ID: <1398357901.35183.YahooMailNeo@web164006.mail.gq1.yahoo.com> Hi, I am working on a patch for GHC Trac ticket #9021. I wonder whether it would be welcome or unwelcome to include Doxygen (or other documentation tool) comments in the patch? If another tool is preferred, please recommend it. Thanks. Howard B. Golden Northridge, CA From daniel.is.fischer at googlemail.com Thu Apr 24 18:36:24 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 24 Apr 2014 20:36:24 +0200 Subject: optllvm failures Message-ID: <6994821.NuLaD01UEA@linux-hpeb.site> I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis at schwartz:~/JNthPrime> llc --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm - ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis at schwartz:~/JNthPrime> opt --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause? From carter.schonwald at gmail.com Thu Apr 24 18:49:18 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 24 Apr 2014 14:49:18 -0400 Subject: optllvm failures In-Reply-To: <6994821.NuLaD01UEA@linux-hpeb.site> References: <6994821.NuLaD01UEA@linux-hpeb.site> Message-ID: What OS? Is this on a vm? I7-avx is the instruction family. I5 will be ok. Certain vms break handling avx register saves. On Thursday, April 24, 2014, Daniel Fischer < daniel.is.fischer at googlemail.com> wrote: > I have done a bit of testing with regards to my optllvm failures in the > testsuite. > > Some tests compile but segfault when they are run, others fail to compile, > both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although > 7.6 > gives the warning: > > You are using a new version of LLVM that hasn't been tested yet! > We will try though... > > I suspect that the LLVM backend thinks I have a different version than I > actually have, or maybe the LLVM tools think I have a different CPU than I > have: > > dafis at schwartz:~/JNthPrime> llc --version > LLVM (http://llvm.org/): > LLVM version 3.2svn > Optimized build. > Default target: x86_64-unknown-linux-gnu > Host CPU: corei7-avx > > Registered Targets: > arm - ARM > ppc32 - PowerPC 32 > ppc64 - PowerPC 64 > thumb - Thumb > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > dafis at schwartz:~/JNthPrime> opt --version > LLVM (http://llvm.org/): > LLVM version 3.2svn > Optimized build. > Default target: x86_64-unknown-linux-gnu > Host CPU: corei7-avx > > But my CPU is a Core i5, not i7. > > Can somebody confirm or deny that that may be the cause? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Apr 24 18:55:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 24 Apr 2014 13:55:20 -0500 Subject: More validate failures In-Reply-To: <2886204.LBvCxqc7Mj@linux-hpeb.site> References: <2886204.LBvCxqc7Mj@linux-hpeb.site> Message-ID: The fact GHC 7.4 and GHC 7.6 accepted tcrun045 was a bug that we didn't catch (implicit parameters in superclass constraints should have been rejected). I don't have a reference off hand for this, but I do know Simon discussed it and this was the conclusion. As for the others, it's entirely possible that the LLVM version you are running is buggy and produces incorrect code. It wouldn't be the first time this has happened. Can you try with any other version of LLVM, perhaps? On Thu, Apr 24, 2014 at 10:54 AM, Daniel Fischer wrote: > Running the full testsuite (sh validate --testsuite-only --slow), I get a lot > of unexpected failures (45 on this run). > > typecheck/should_run/tcrun045 > > fails due to > > Compile failed (status 256) errors were: > [1 of 1] Compiling Main ( tcrun045.hs, tcrun045.o ) > > tcrun045.hs:24:1: > Illegal implict parameter ??imp::Int? > In the context: (?imp::Int) > While checking the super-classes of class ?D? > In the class declaration for ?D? > > and 6.12, 7.0, 7.2 and 7.8 refuse the file with the same error, only 7.4 and > 7.6 accept it. Is that a regression or are 7.4 and 7.6 wrong and it shouldn't > have compiled? > > Then I get a lot of optllvm failures, like > > =====> GMapAssoc(optllvm) 891 of 3955 [0, 8, 0] > cd ./indexed-types/should_run && '/home/dafis/GHC/virgo/bindisttest/install > dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- > package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o GMapAssoc > GMapAssoc.hs -O -fllvm -package containers >GMapAssoc.comp.stderr 2>&1 > cd ./indexed-types/should_run && ./GMapAssoc >GMapAssoc.run.stdout 2>GMapAssoc.run.stderr > /bin/sh: Zeile 1: 21331 Speicherzugriffsfehler ./GMapAssoc < /dev/null > > GMapAssoc.run.stdout 2> GMapAssoc.run.stderr > Wrong exit code (expected 0 , actual 139 ) > Stdout: > > Stderr: > > *** unexpected failure for GMapAssoc(optllvm) > > or > > =====> qq007(optllvm) 1161 of 3955 [0, 10, 0] > cd ./quasiquotation/qq007 && $MAKE -s --no-print-directory TH_QQ > cd ./quasiquotation/qq007 && '/home/dafis/GHC/virgo/bindisttest/install > dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- > package-db -rtsopts -ignore-dot-ghci -fno-ghci-history --make Test -O -fllvm > -v0 >qq007.comp.stderr 2>&1 > /bin/sh: Zeile 1: 25528 Speicherzugriffsfehler > '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp - > dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -ignore- > dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 > qq007.comp.stderr 2>&1 > Compile failed (status 35584) errors were: > > *** unexpected failure for qq007(optllvm) > > which I don't know what to make of, other optllvm tests work fine. Has anybody > an idea what might cause those? > > T6145 fails to compile with a type error and a missing argument to the `MG` > constructor. Apparently the API changed but the test was not updated. > > T8639_api has unexpected stdout, the type is printed as `Bool` instead of the > expected `GHC.Types.Bool`, I guess one should update the expected output, but > maybe the type should be printed qualified? > > =====> T4891(normal) 1610 of 3955 [0, 14, 0] > cd ./ghc-api/T4891 && $MAKE -s --no-print-directory T4891 >T4891.run.stdout 2>T4891.run.stderr > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > > T4891.hs:23:19: Module ?PrelNames? does not export ?iNTERACTIVE? > gmake[2]: *** [T4891] Fehler 1 > > *** unexpected failure for T4891(normal) > > T3064 and T6048 allocate slightly more than they are allowed to (about 1% > resp. 0.15% too much). Generally, I have the impression that whoever decides > the 64-bit Linux allocation numbers has a system where the figures > aresystematically lower than on mine, maybe the expected numbers should be > given a bit higher. > > joao-circular fails the optllvm way with unexpected stdout: > > Actual stdout output differs from expected: > --- ./programs/joao-circular/joao-circular.stdout 2014-04-24 > 11:18:07.363987627 +0200 > +++ ./programs/joao-circular/joao-circular.run.stdout 2014-04-24 > 14:27:38.927486429 +0200 > @@ -68,13 +68,6 @@ > PUSHa "recfact" 2 > PUSHa "x" 2 > LOAD > -PUSHa "x" 1 > -PUSHa "x" 2 > -LOAD > -PUSHi 1 > -SUB > -STORE > -CALL "recfact" > MUL > STORE > C_Ident_1 "end_if_1": > @@ -83,4 +76,4 @@ > > Detected Semantic Errors: > [C_E_Name_AD_1 (C_Ident_1 "a")] > -[] > +[C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_while_1,C_E_T_BOP_1,C_E_T_NC_1 > C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 > C_Errortype_1,C_E_T_BOP_1,C_E_T_if_t_e_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 > C_Inttype_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1] > *** unexpected failure for joao-circular(optllvm) > > which I have no idea how to interpret. > > T7919 (optllvm) fails to compile. The ghci way, although it passed, uses a > lot of memory (~ 2.5 G), temporarily froze my box, and got my browser OOM- > killed. The other ways also use a lot of memory (~1.1 G - 1.7 G). While it > looks as though it is to be expected that the test uses a fair bit of memory, > perhaps it should not use quite as much. If somebody more knowledgeable looks > at it that might be good. > > simplCore/should_compile/spec001 fails due to unexpected stdout, the `-fno- > warn-amp` flag is deprecated, the pragma should be removed probably. > > arr016 (optllvm) failed with what looks serious: > > =====> arr016(optllvm) 3092 of 3955 [0, 32, 0] > cd ./array/should_run && '/home/dafis/GHC/virgo/bindisttest/install > dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- > package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o arr016 arr016.hs -O > -fllvm >arr016.comp.stderr 2>&1 > cd ./array/should_run && ./arr016 arr016.run.stdout > 2>arr016.run.stderr > /bin/sh: Zeile 1: 23929 Abgebrochen ./arr016 < /dev/null > > arr016.run.stdout 2> arr016.run.stderr > Wrong exit code (expected 0 , actual 134 ) > Stdout: > > Stderr: > arr016: internal error: MUT_ARR_PTRS_DIRTY object entered! > (GHC version 7.9.20140424 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *** unexpected failure for arr016(optllvm) > > T7653(ghci) managed to get my browser OOM-killed again (yes, I was naive > enough to restart it), using ~2.7 G of memory. And the test timed out - also > when running only T7653 without the browser to compete for the memory. The > threaded1 way uses even more memory (~2.9 G), other ways much, but not that > much. > > posix002(threaded2) failed with > > +posix002: failed to create OS thread: Resource temporarily unavailable > *** unexpected failure for posix002(threaded2) > > but that isn't replicable running the test alone. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From daniel.is.fischer at googlemail.com Thu Apr 24 18:57:33 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 24 Apr 2014 20:57:33 +0200 Subject: optllvm failures In-Reply-To: References: <6994821.NuLaD01UEA@linux-hpeb.site> Message-ID: <1615877.bZPc2HsqiZ@linux-hpeb.site> On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: > What OS? Is this on a vm? Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. > I7-avx is the instruction family. I5 will be ok. Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is. From austin at well-typed.com Thu Apr 24 19:04:13 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 24 Apr 2014 14:04:13 -0500 Subject: optllvm failures In-Reply-To: <1615877.bZPc2HsqiZ@linux-hpeb.site> References: <6994821.NuLaD01UEA@linux-hpeb.site> <1615877.bZPc2HsqiZ@linux-hpeb.site> Message-ID: GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1. The odd version number for LLVM 3.2 was a known problem with their tarball, they forgot to remove the 'svn' suffix. This shouldn't be a problem for GHC, it should correctly parse the right thing anyway. Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this. On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer wrote: > On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: >> What OS? Is this on a vm? > > Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. > >> I7-avx is the instruction family. I5 will be ok. > > Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks > 3.2 is. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Apr 24 19:05:39 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 24 Apr 2014 14:05:39 -0500 Subject: optllvm failures In-Reply-To: References: <6994821.NuLaD01UEA@linux-hpeb.site> <1615877.bZPc2HsqiZ@linux-hpeb.site> Message-ID: (And note I base this assumption on the principle that e.g. ARM is currently working relatively well with the latest versions of LLVM, where that's the only option for the code generator. But we've had other bugs exposed here before, or exposed LLVM bugs, so it may just be whack-a-mole...) On Thu, Apr 24, 2014 at 2:04 PM, Austin Seipp wrote: > GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1. > > The odd version number for LLVM 3.2 was a known problem with their > tarball, they forgot to remove the 'svn' suffix. This shouldn't be a > problem for GHC, it should correctly parse the right thing anyway. > > Can you try another LLVM version? LLVM 3.2 has been known to be > particularly problematic - I believe me and David looked into this a > while back, and we couldn't get even get the compiler to bootstrap > with it at one point, let alone figure out what the hell was going on > (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM > 3.4 should work just fine, and you can put them on the front of your > $PATH before running the testsuite to check this. > > On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer > wrote: >> On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: >>> What OS? Is this on a vm? >> >> Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. >> >>> I7-avx is the instruction family. I5 will be ok. >> >> Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks >> 3.2 is. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Thu Apr 24 19:06:13 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 24 Apr 2014 15:06:13 -0400 Subject: optllvm failures In-Reply-To: <1615877.bZPc2HsqiZ@linux-hpeb.site> References: <6994821.NuLaD01UEA@linux-hpeb.site> <1615877.bZPc2HsqiZ@linux-hpeb.site> Message-ID: Look at the output of ghc --info It will tell you what opt /LLC ghc will invoke by default. ghc 7.8 should work with llvm 3.3/3.4 On Thursday, April 24, 2014, Daniel Fischer < daniel.is.fischer at googlemail.com> wrote: > On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: > > What OS? Is this on a vm? > > Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. > > > I7-avx is the instruction family. I5 will be ok. > > Okay, then it's probably that what openSuSE calls 3.2 is not what GHC > thinks > 3.2 is. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.is.fischer at googlemail.com Thu Apr 24 19:22:48 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 24 Apr 2014 21:22:48 +0200 Subject: optllvm failures In-Reply-To: References: <6994821.NuLaD01UEA@linux-hpeb.site> <1615877.bZPc2HsqiZ@linux-hpeb.site> Message-ID: <2469255.g84p1pa59l@linux-hpeb.site> On Thursday 24 April 2014, 14:04:13, Austin Seipp wrote: > Can you try another LLVM version? LLVM 3.2 has been known to be > particularly problematic - I believe me and David looked into this a > while back, and we couldn't get even get the compiler to bootstrap > with it at one point, let alone figure out what the hell was going on > (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM > 3.4 should work just fine, and you can put them on the front of your > $PATH before running the testsuite to check this. Okay, I got myself a 3.4, and it seems to work. I'll re-run the testsuite and see what failures remain. From daniel.is.fischer at googlemail.com Thu Apr 24 23:39:24 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Fri, 25 Apr 2014 01:39:24 +0200 Subject: Patches fixing a few test failures Message-ID: <9515806.jTimy73IC2@linux-hpeb.site> I've prepared two patches fixing some test failures. The first passes '-ignore-dot-ghci' to all tests, not only the ghci way, which deals with forgetting to pass the flag when the test is invoked with '-- interactive' from a makefile, as was the case with T8333. The second removes the now-obsolete pragma setting '-fno-warn-amp' from spec001. I didn't notice the trailing whitespace that was also removed in time, sorry, but I hope the clutter from that is not too bad. Kindly revise the patches, please. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Pass-ignore-dot-ghci-to-all-tests-as-suggested-by-SP.patch Type: text/x-patch Size: 2909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-pragma-setting-fno-warn-amp.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: From carter.schonwald at gmail.com Thu Apr 24 23:41:02 2014 From: carter.schonwald at gmail.com (Carter Tazio Schonwald) Date: Thu, 24 Apr 2014 19:41:02 -0400 Subject: Adding Doxygen (or other documentation tool) comments to GHC patches? In-Reply-To: <1398357901.35183.YahooMailNeo@web164006.mail.gq1.yahoo.com> References: <1398357901.35183.YahooMailNeo@web164006.mail.gq1.yahoo.com> Message-ID: hey howard, somehow your emails keep on going to my spam folder! https://ghc.haskell.org/trac/ghc/ticket/9021 right? Im not sure if theres any docs convention for the C code in ghc, perhaps simon marlow or austin can chime in? On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden wrote: > Hi, I am working on a patch for GHC Trac ticket #9021. I wonder whether it would be welcome or unwelcome to include Doxygen (or other documentation tool) comments in the patch? If another tool is preferred, please recommend it. Thanks. > > Howard B. Golden > Northridge, CA > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org (mailto:ghc-devs at haskell.org) > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Apr 25 08:16:13 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 25 Apr 2014 10:16:13 +0200 Subject: RFC: template-haskell & Data.Map vs. Prelude.lookup use In-Reply-To: <10970AFB-3008-4567-81FA-0CD54497BCF4@cis.upenn.edu> (Richard Eisenberg's message of "Thu, 24 Apr 2014 09:04:55 -0400") References: <87y4yvb2av.fsf@gmail.com> <10970AFB-3008-4567-81FA-0CD54497BCF4@cis.upenn.edu> Message-ID: <87ha5h9642.fsf@gmail.com> Hello Richard, On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote: > That map seems to store the set of variables during printing TH, for > the purposes of disambiguating identifiers with the same name but > different uniques. If blatting out a whole lot of program text, I > could imagine the Map getting somewhat sizeable. When does printing TH actually occur? If it doesn't occur during regular compilation, do we ever need to pretty print large amounts of TH? > But, it seems to only need the lookup and insert operations... actually, it uses a specific combination of lookup+insert, so that it would suffice to have the single operation in the style of Python's dict.setdefault(), i.e. findWithDefaultInsert :: Ord k => k -> v -> Map k v -> (v, Map k v) findWithDefaultInsert k default m | Just v <- Map.lookup k m = (v, m) | otherwise = default `seq` (default, Map.insert k default m) > is there a simpler data structure that has only these operations > efficiently? From simonpj at microsoft.com Fri Apr 25 09:43:47 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 25 Apr 2014 09:43:47 +0000 Subject: make 2 FAST=YES Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A564865@DB3PRD3001MB020.064d.mgd.msft.net> When I say "make 2 FAST=YES" in compiler/, the make system is supposed to recompile the stage-2 compiler, but ignoring the fact that the stage-1 compiler has changed. It used to do that. But now it doesn't. It recompiles every module in GHC, and every module in the base libraries on which GHC depends. The recompilation checker then spots that nothing has changed, but it still takes several unnecessary minutes. Would it be possible to restore the old behaviour? It saves quite a lot of time when rebuilding stage2 after a minor change. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Apr 25 13:23:47 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 25 Apr 2014 14:23:47 +0100 Subject: Adding Doxygen (or other documentation tool) comments to GHC patches? In-Reply-To: References: <1398357901.35183.YahooMailNeo@web164006.mail.gq1.yahoo.com> Message-ID: <535A61E3.1030805@gmail.com> We don't use Doxygen or anything else, so I don't think it would be helpful to add annotations. Cheers, Simon On 25/04/2014 00:41, Carter Tazio Schonwald wrote: > hey howard, somehow your emails keep on going to my spam folder! > > https://ghc.haskell.org/trac/ghc/ticket/9021 right? Im not sure if > theres any docs convention for the C code in ghc, > perhaps simon marlow or austin can chime in? > > > On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden > > wrote: >> Hi, I am working on a patch for GHC Trac ticket #9021. I wonder >> whether it would be welcome or unwelcome to include Doxygen (or other >> documentation tool) comments in the patch? If another tool is >> preferred, please recommend it. Thanks. >> >> Howard B. Golden >> Northridge, CA >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Fri Apr 25 13:33:45 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 25 Apr 2014 09:33:45 -0400 Subject: RFC: template-haskell & Data.Map vs. Prelude.lookup use In-Reply-To: <87ha5h9642.fsf@gmail.com> References: <87y4yvb2av.fsf@gmail.com> <10970AFB-3008-4567-81FA-0CD54497BCF4@cis.upenn.edu> <87ha5h9642.fsf@gmail.com> Message-ID: <496F128C-E87A-42E6-B35E-CC2090B83759@cis.upenn.edu> On Apr 25, 2014, at 4:16 AM, Herbert Valerio Riedel wrote: > Hello Richard, > > On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote: >> That map seems to store the set of variables during printing TH, for >> the purposes of disambiguating identifiers with the same name but >> different uniques. If blatting out a whole lot of program text, I >> could imagine the Map getting somewhat sizeable. > > When does printing TH actually occur? If it doesn't occur during regular > compilation, do we ever need to pretty print large amounts of TH? I guess it depends on who ?we? are. In the process of routine TH hackery, I would say that printing is uncommon -- normally the TH is processed and then just spliced, without user interaction. But, I can conceive of a library that does some processing and then prints. > >> But, it seems to only need the lookup and insert operations... Good observation. > > actually, it uses a specific combination of lookup+insert, so that it > would suffice to have the single operation in the style of Python's > dict.setdefault(), i.e. > > findWithDefaultInsert :: Ord k => k -> v -> Map k v -> (v, Map k v) > findWithDefaultInsert k default m > | Just v <- Map.lookup k m = (v, m) > | otherwise = default `seq` (default, Map.insert k default m) > >> is there a simpler data structure that has only these operations >> efficiently? > From austin at well-typed.com Fri Apr 25 13:52:07 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 25 Apr 2014 08:52:07 -0500 Subject: RFC: template-haskell & Data.Map vs. Prelude.lookup use In-Reply-To: <496F128C-E87A-42E6-B35E-CC2090B83759@cis.upenn.edu> References: <87y4yvb2av.fsf@gmail.com> <10970AFB-3008-4567-81FA-0CD54497BCF4@cis.upenn.edu> <87ha5h9642.fsf@gmail.com> <496F128C-E87A-42E6-B35E-CC2090B83759@cis.upenn.edu> Message-ID: Really, the patch is fine just as it is probably. Earlier me and Herbert were wondering if anyone would actually be affected by the O(n) lookup, but the only reason *I* really cared to know that is just so we don't have to inline part of `containers` if we don't have to. But at the end of the day it's barely 100 lines of extra code. So maybe not that big a deal (but kinda lame). To be on the conservative side and not regress (and this could easily be considered a regression from a performance POV) we can certainly just commit this and see if we can make the code smaller later, I'd say. On Fri, Apr 25, 2014 at 8:33 AM, Richard Eisenberg wrote: > > On Apr 25, 2014, at 4:16 AM, Herbert Valerio Riedel wrote: > >> Hello Richard, >> >> On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote: >>> That map seems to store the set of variables during printing TH, for >>> the purposes of disambiguating identifiers with the same name but >>> different uniques. If blatting out a whole lot of program text, I >>> could imagine the Map getting somewhat sizeable. >> >> When does printing TH actually occur? If it doesn't occur during regular >> compilation, do we ever need to pretty print large amounts of TH? > > I guess it depends on who ?we? are. In the process of routine TH hackery, I would say that printing is uncommon -- normally the TH is processed and then just spliced, without user interaction. But, I can conceive of a library that does some processing and then prints. > >> >>> But, it seems to only need the lookup and insert operations... > > Good observation. > >> >> actually, it uses a specific combination of lookup+insert, so that it >> would suffice to have the single operation in the style of Python's >> dict.setdefault(), i.e. >> >> findWithDefaultInsert :: Ord k => k -> v -> Map k v -> (v, Map k v) >> findWithDefaultInsert k default m >> | Just v <- Map.lookup k m = (v, m) >> | otherwise = default `seq` (default, Map.insert k default m) >> >>> is there a simpler data structure that has only these operations >>> efficiently? >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jessica.l.hamilton at gmail.com Sat Apr 26 07:41:52 2014 From: jessica.l.hamilton at gmail.com (Jessica Hamilton) Date: Sat, 26 Apr 2014 19:41:52 +1200 Subject: Cross-compiling to Haiku Message-ID: Hi, I seem to have managed to build a cross-compiler for Haiku, but am having trouble installing it. Possibly I'm missing something during the build, which didn't get pointed out to me at the time. On the Linux host, the build was basically: export PATH=$PATH:/path/to/haiku/gcc4/cross-compiler ./configure --target=i586-pc-haiku --enable-unregisterised --prefix=/opt make make binary-dist In Haiku, after editing configure to set GHC_PWD=pwd (the bundled ghc_pwd is built for the host, not the target...), that part seems to go well. But in make install I get the following errors/output: > ./configure --prefix=/boot/home/config/non-packaged .... Configuration done, ready to 'make install' > make install make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:680: libraries/old-time/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell98/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell2010/ghc.mk: No such file or directory make[1]: *** No rule to make target `libraries/haskell2010/ghc.mk'. Stop. make: *** [install] Error 2 I presume those are the standard libraries it's trying to install? Jessica -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Sat Apr 26 21:41:26 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Sat, 26 Apr 2014 21:41:26 +0000 Subject: Cross-compiling to Haiku In-Reply-To: References: Message-ID: <984D5A0E-D557-4320-95E0-64FE29629685@gmail.com> > On Apr 26, 2014, at 7:41, Jessica Hamilton wrote: > > Hi, > > I seem to have managed to build a cross-compiler for Haiku, but am having trouble installing it. Possibly I'm missing something during the build, which didn't get pointed out to me at the time. > > On the Linux host, the build was basically: > export PATH=$PATH:/path/to/haiku/gcc4/cross-compiler > ./configure --target=i586-pc-haiku --enable-unregisterised --prefix=/opt > make > make binary-dist > > In Haiku, after editing configure to set GHC_PWD=pwd (the bundled ghc_pwd is built for the host, not the target...), that part seems to go well. But in make install I get the following errors/output: > > > ./configure --prefix=/boot/home/config/non-packaged > .... > Configuration done, ready to 'make install' > > > make install > make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES > ghc.mk:680: libraries/old-time/ghc.mk: No such file or directory > ghc.mk:680: libraries/haskell98/ghc.mk: No such file or directory > ghc.mk:680: libraries/haskell2010/ghc.mk: No such file or directory > make[1]: *** No rule to make target `libraries/haskell2010/ghc.mk'. Stop. > make: *** [install] Error 2 > > I presume those are the standard libraries it's trying to install? > > Jessica Hi Jessica: I think that can happen if the source tree isn't "booted". Did you run `./sync-all --no-dph get && perl boot` on the Haiku target system? (this might not be necessary with bindist, so I'm guessing) It would be really cool to have GHC for Haiku. Best, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sun Apr 27 08:18:02 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 27 Apr 2014 10:18:02 +0200 Subject: Status updates In-Reply-To: (Austin Seipp's message of "Tue, 22 Apr 2014 07:42:46 -0500") References: Message-ID: <87siozp4n9.fsf@gmail.com> On 2014-04-22 at 14:42:46 +0200, Austin Seipp wrote: [...] > - I've been looking into our CI setup for GHC, and evaluating things. > Right now though, I am directly working on getting Windows build bots > set up on Gabor's infrastructure. He gave me the credentials, and > hopefully this should not take long, it just slipped my mind. > > But mostly I've been looking at CI systems for Hackage, so that we > can try to continuously integrate a subset of important packages > against GHC over time. Right now, we have Travis-CI thanks to Herbert, > but not quite everyone uses this (or doesn't properly configure it to > e.g. test HEAD). > > This would really help find things in the future, I think, especially > closer to release. It would also really help find nasty bugs in the > RCs, like the dreaded #8978 > > Right now, after some thought, I'm looking into Michael's Stackage as > a starting point for this, as he's done some awesome work. But I > haven't yet done so in anger, and there are some other things I want > to try too. I want to add that a GitHub-integrated CI like Travis-CI and a "Hackage-CI" are two different CI-systems that complement each other, in case there may be the impression that one renders the other one redundant. Something like Travis-CI helps a package maintainer keep the HEAD branch from breaking early during development even before the package is actually uploaded to Hackage (furthermore, it helps pre-validating patches in pull-requests so might save the package maintainer time with patches that don't pass the test-suite). Whereas a build-the-world Hackage-CI would (the way I understand it) help detecting that the Hackage *released* package-set is in a working state for a given compiler configuration (including GHC HEAD[1]), w/o any active cooperation from the package maintainer. And more importantly, it may trigger rebuilds of depending packages, when new packages is added to the Hackage index to help detect problems due to inter-package interactions. [1]: However, I wonder how to keep Hackage buildable with GHC HEAD w/o having to patch up every package that will likely break sooner or later due to API (e.g. the AMP-refactoring will likely break stuff) and compiler changes[2], as I don't think cabal-install's --allow-newer will help in all cases. [2]: This already happened due to #8883 with the HTTP package, see also haskell/HTTP#58 Cheers, hvr From hvr at gnu.org Sun Apr 27 09:14:41 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 27 Apr 2014 11:14:41 +0200 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell Message-ID: <87lhurp20u.fsf@gnu.org> Hi GHC devs, In accordance with Edward and Austin, I want to move the primary home of the non-GHC specific core-library packages to the http://github.com/haskell/ organization. Specifically, I plan to move the following package Git repositories to the github.com/haskell organization: - array - directory - filepath - old-locale - old-time - process - stm - unix (N.B.: the 'Win32' package already lives at github.com/haskell) I'm not sure yet about the following packages, those are not officially maintained by the committee (@Simon, maybe you can state your preference where you want your packages to be hosted/issue-tracked in the future?) - parallel - deepseq - hpc - hoopl - haskell2010 - haskell98 The practical effects to GHC developers of this switch would be that: - Issue tracking for those packages moves over to GitHub. (the official maintaing entity is the core-library committee) - In ghc.git those packages will be *turned into Git submodules* (i.e. they will be handled just like the other existing 3rd party upstream packages such as 'Win32' or 'Cabal' are already handled[1], see also next item) - Using pull-requests on GitHub is highly recommended for submitting changes which are not urgent (instead of diverging the respective git.haskell.org lagged mirror repo) -- note also that pull-requests will be validated by Travis-CI for multiple GHC versions to help detect compat-breaking changes. However, GHC developers can easily be given push-rights to the respective repos in the github.com/haskell/ organization should this turn out to be a more appropriate workflow. [1]: https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream#Modifiyinglibrariesforwhichthereisanupstreamrepository PS: 'haddock.git' is planned to move its issue tracking over to GitHub as well, however it's going to be handled slightly different (mostly because haddock is tightly coupled to the GHC API) and will be explained in more detail in a future separate email. Cheers, hvr From austin at well-typed.com Sun Apr 27 13:14:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 27 Apr 2014 08:14:20 -0500 Subject: Removing -fext-core Message-ID: Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Sun Apr 27 16:10:32 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 27 Apr 2014 12:10:32 -0400 Subject: Removing -fext-core In-Reply-To: References: Message-ID: <42DE22FA-F1D7-4709-A4FF-2952EF3768E1@cis.upenn.edu> +1 from me I?ve been meaning to say essentially the same thing as you just did. We all seem to concentrate on *adding* things to GHC; it?s a bit refreshing to consider *removing* something. Echoing Austin somewhat: - Anyone using external core is either working with an old GHC or is kludging quite a bit, as it?s horribly rotten compared to ?internal? core. (For what it?s worth, I?m responsible for much of the rot. When I started working on Core, external core was just enough rotten already that I didn?t feel compelled to keep it up to date... but now it?s in a sorry state, indeed.) - With the GHC API, the ability for plugins, and HERMIT[1], I think external core?s utility has been eclipsed. - GHC actually contains a parser for external core, which is type-checked during compilation, but its functions are never actually called anywhere! This is a sure sign of Something Wrong. Richard [1]: http://www.ittc.ku.edu/csdl/fpg/software/hermit.html On Apr 27, 2014, at 9:14 AM, Austin Seipp wrote: > Hello all, > > Recently I was wondering something: is there any reason to keep > -fext-core around? In particular, it's been broken for a while at this > point, see GHC bug #5630[1] > > As far as I'm aware there really aren't any users of it still around > these days, at least none working with a modern GHC. And it seems like > if people were to need access to Core, they could use a plugin or some > such to get direct access to what they want. > > Simon mentioned removing ExtCore in face of replacing it with IfaceSyn > in the compiler. I'm not entirely sure how much work that would be to > bring it all up to scratch if people needed it, but maybe it's worth > thinking about. > > One other issue is a notion of semantics which is present in External > Core, but we also now have a documented semantics for GHC's core > language as well (which has evolved quite a bit), so I don't know how > much that matters. > > So long story short: I don't think anyone is using it, maintaining it, > and it seems subsumed by more recent events. > > Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, > unless someone is willing to step up and really maintain it. If you're > using it, you should probably speak up soon I'd imagine... > > [1] https://ghc.haskell.org/trac/ghc/ticket/5630 > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Mon Apr 28 08:16:39 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 09:16:39 +0100 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <87lhurp20u.fsf@gnu.org> References: <87lhurp20u.fsf@gnu.org> Message-ID: <535E0E67.9090508@gmail.com> So let me check that I'm understanding correctly. Right now the source of truth for these repos is under git.haskell.org/ghc, and you're proposing that we move the source of truth to github. In addition we would still need the git.haskell.org/ghc repos, but they would become lagging repos tracking the github upstream? So the situation for pushing to these repos becomes more complex, becuase we have to push to upstream first, then the lagging repo, and finally update the submodule link. I've no objection to hosting issue trackers on github, but I'm concerned about the repo structure and the workflow for pushing becoming more complex. Cheers, Simon On 27/04/2014 10:14, Herbert Valerio Riedel wrote: > Hi GHC devs, > > In accordance with Edward and Austin, I want to move the primary home of > the non-GHC specific core-library packages to the > http://github.com/haskell/ organization. > > Specifically, I plan to move the following package Git repositories to > the github.com/haskell organization: > > - array > - directory > - filepath > - old-locale > - old-time > - process > - stm > - unix (N.B.: the 'Win32' package already lives at github.com/haskell) > > I'm not sure yet about the following packages, those are not officially > maintained by the committee (@Simon, maybe you can state your preference > where you want your packages to be hosted/issue-tracked in the future?) > > - parallel > - deepseq > - hpc > - hoopl > - haskell2010 > - haskell98 > > The practical effects to GHC developers of this switch would be that: > > - Issue tracking for those packages moves over to GitHub. > (the official maintaing entity is the core-library committee) > > - In ghc.git those packages will be *turned into Git submodules* > (i.e. they will be handled just like the other existing 3rd party > upstream packages such as 'Win32' or 'Cabal' are already handled[1], > see also next item) > > - Using pull-requests on GitHub is highly recommended for submitting > changes which are not urgent (instead of diverging the respective > git.haskell.org lagged mirror repo) -- note also that pull-requests > will be validated by Travis-CI for multiple GHC versions to help > detect compat-breaking changes. > > However, GHC developers can easily be given push-rights to the > respective repos in the github.com/haskell/ organization should this > turn out to be a more appropriate workflow. > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream#Modifiyinglibrariesforwhichthereisanupstreamrepository > > PS: 'haddock.git' is planned to move its issue tracking over to GitHub > as well, however it's going to be handled slightly different (mostly > because haddock is tightly coupled to the GHC API) and will be > explained in more detail in a future separate email. > > > Cheers, > hvr > From hvriedel at gmail.com Mon Apr 28 08:32:48 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 28 Apr 2014 10:32:48 +0200 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <535E0E67.9090508@gmail.com> (Simon Marlow's message of "Mon, 28 Apr 2014 09:16:39 +0100") References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> Message-ID: <878uqpg8gf.fsf@gmail.com> Hello Simon, On 2014-04-28 at 10:16:39 +0200, Simon Marlow wrote: > So let me check that I'm understanding correctly. Right now the > source of truth for these repos is under git.haskell.org/ghc, and > you're proposing that we move the source of truth to github. In > addition we would still need the git.haskell.org/ghc repos, but they > would become lagging repos tracking the github upstream? > So the situation for pushing to these repos becomes more complex, > becuase we have to push to upstream first, then the lagging repo, and > finally update the submodule link. Yes, that'd be the extreme case (and we have that kind of complexity already for packages such as transformers/time, where we even have to bridge the darcs/git gap) However, we can configure the lagged mirror such that we'd automatically mirror github's 'master' branch into our lagged mirror (we'd still be free to create local wip/* or ghc-7.10 branches at git.haskell.org if needed) Then you'd only have to do the 2-step workflow, i.e. updating github's master branch (or for more experimental stuff, a git.haskell.org-local wip/ branch), and update the gitlink in ghc.git > I've no objection to hosting issue trackers on github, but I'm > concerned about the repo structure and the workflow for pushing > becoming more complex. I'd like to point out, that while it will become more complex in one way or another (if we want to get away from the current loosely-coupled sub-repo setup), breaking changes in GHC HEAD requiring immediate action happen rather infrequently (after all, we tend to avoid such breakages in the first place, as they'd usually affect a larger portion of Hackage then as well) From simonpj at microsoft.com Mon Apr 28 08:40:15 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Apr 2014 08:40:15 +0000 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <535E0E67.9090508@gmail.com> References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A5755C7@DBXPRD3001MB024.064d.mgd.msft.net> In general I'd like to make the infrastructure reflect the story of who is managing these packages. Moreover, those who are maintaining a package, in this case the core-libraries committee, should have the final word on where their infrastructure lives. Putting issue-tracking in a clearly-defined place (not mixed up with the GHC Trac) is a good idea. (But please can it be clear, somehow, where each issue tracker is?) But I agree with Simon that complicating the workflow ought to have a benefit. What is the benefit in this case? We could instead * Leave the repos where they are * Move the repos but have GHC builds pull directly from the mother repo Both seem simpler than adding a new lagging repo. Having a lagging repo doesn't add anything, does it? Indeed, does it *ever* help to have a lagging repo? The SHA hash for a submodule uniquely determines that build depends on, so we don't need a whole repo for that! (I'm hazy about how and when to make GHC's repo point to newer versions of the sub-module.) Regardless of the decision here, can I appeal, once more, for clear documentation of the workflows that a GHC developer will encounter? Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Marlow | Sent: 28 April 2014 09:17 | To: Herbert Valerio Riedel; ghc-devs | Cc: Austin Seipp | Subject: Re: Relocating (some of) GHC's core-libraries to | github.com/haskell | | So let me check that I'm understanding correctly. Right now the source | of truth for these repos is under git.haskell.org/ghc, and you're | proposing that we move the source of truth to github. In addition we | would still need the git.haskell.org/ghc repos, but they would become | lagging repos tracking the github upstream? | | So the situation for pushing to these repos becomes more complex, | becuase we have to push to upstream first, then the lagging repo, and | finally update the submodule link. | | I've no objection to hosting issue trackers on github, but I'm | concerned about the repo structure and the workflow for pushing | becoming more complex. | | Cheers, | Simon | | On 27/04/2014 10:14, Herbert Valerio Riedel wrote: | > Hi GHC devs, | > | > In accordance with Edward and Austin, I want to move the primary home | > of the non-GHC specific core-library packages to the | > http://github.com/haskell/ organization. | > | > Specifically, I plan to move the following package Git repositories | to | > the github.com/haskell organization: | > | > - array | > - directory | > - filepath | > - old-locale | > - old-time | > - process | > - stm | > - unix (N.B.: the 'Win32' package already lives at | github.com/haskell) | > | > I'm not sure yet about the following packages, those are not | > officially maintained by the committee (@Simon, maybe you can state | > your preference where you want your packages to be | > hosted/issue-tracked in the future?) | > | > - parallel | > - deepseq | > - hpc | > - hoopl | > - haskell2010 | > - haskell98 | > | > The practical effects to GHC developers of this switch would be that: | > | > - Issue tracking for those packages moves over to GitHub. | > (the official maintaing entity is the core-library committee) | > | > - In ghc.git those packages will be *turned into Git submodules* | > (i.e. they will be handled just like the other existing 3rd party | > upstream packages such as 'Win32' or 'Cabal' are already | handled[1], | > see also next item) | > | > - Using pull-requests on GitHub is highly recommended for | submitting | > changes which are not urgent (instead of diverging the respective | > git.haskell.org lagged mirror repo) -- note also that pull- | requests | > will be validated by Travis-CI for multiple GHC versions to help | > detect compat-breaking changes. | > | > However, GHC developers can easily be given push-rights to the | > respective repos in the github.com/haskell/ organization should | this | > turn out to be a more appropriate workflow. | > | > [1]: | > | https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream#Modifiying | > librariesforwhichthereisanupstreamrepository | > | > PS: 'haddock.git' is planned to move its issue tracking over to | GitHub | > as well, however it's going to be handled slightly different | (mostly | > because haddock is tightly coupled to the GHC API) and will be | > explained in more detail in a future separate email. | > | > | > Cheers, | > hvr | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Mon Apr 28 08:41:30 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 09:41:30 +0100 Subject: Strange checkout message In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A561905@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <535E143A.1080704@gmail.com> I believe sync-all pull is supposed to automatically do a submodule update. If it doesn't then that's a bug - Simon please create a ticket. Cheers, Simon On 24/04/2014 09:36, Johan Tibell wrote: > I believe you need to run `git submodule update`. The orf branch was > likely set to use a different commit from the haddock repo than your > current repo. Git doesn't automatically assume that you want to switch > your submodule to use the same commit as the orf branch was using, hence > you now have a "change" in your checkout relative to the orf branch > (i.e. you changed to using a different commit from the haddock repo.) > > > On Thu, Apr 24, 2014 at 9:50 AM, Simon Peyton Jones > > wrote: > > Herbert or others,____ > > What does this mean (in a clean tree)____ > > git checkout wip/orf____ > > Checking out files: 100% (159/159), done.____ > > *M utils/haddock____* > > Branch wip/orf set up to track remote branch wip/orf from origin.____ > > Switched to a new branch 'wip/orf'____ > > simonpj at cam-05-unx:~/code/HEAD-3$____ > > What?s all this about haddock being modified? I?ve just checked out > a branch, which is supposed to make everything line up, isn?t it? ____ > > Do you need to say ?git submodule update? as well?____ > > Could this be documented in the (upcoming?) workflows page?____ > > Thanks____ > > Simon____ > > __ __ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From hvriedel at gmail.com Mon Apr 28 09:05:01 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 28 Apr 2014 11:05:01 +0200 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A5755C7@DBXPRD3001MB024.064d.mgd.msft.net> (Simon Peyton Jones's message of "Mon, 28 Apr 2014 08:40:15 +0000") References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0A5755C7@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: <874n1dg6yq.fsf@gmail.com> On 2014-04-28 at 10:40:15 +0200, Simon Peyton Jones wrote: > In general I'd like to make the infrastructure reflect the story of > who is managing these packages. Moreover, those who are maintaining a > package, in this case the core-libraries committee, should have the > final word on where their infrastructure lives. I've CC'ed Edward, in case he wants to chime in... > Putting issue-tracking in a clearly-defined place (not mixed up with > the GHC Trac) is a good idea. (But please can it be clear, somehow, > where each issue tracker is?) For one, I plan to have the cabal 'bug-reports' & 'homepage' URL fields reflect the new location as soon as possible (I need to check with duncan, if there's a working way to manually edit the cabal meta-data shown on Hackage other than uploading a patchlevel release of the affected packages), when this relocation is done. > But I agree with Simon that complicating the workflow ought to have a benefit. What is the benefit in this case? We could instead > * Leave the repos where they are That's btw what's planned for haddock.git: have GitHub be merely a mirror of the mother repo at git.haskell.org; however, the workflow for merging pull-requests filed at GitHub requires being more careful (i.e. not use the "merge"-button in the GitHub web-gui, or any other GitHub feature modifying the Git repo), as any changes made to the GitHub copy of the git.haskell.org mother Git repo would get overwritten by the next automatic git.haskell.org->github.com mirroring. So the only downside I can think of is that you'd have to educate everyone working the GitHub mirrors how to modify the repository. > * Move the repos but have GHC builds pull directly from > the mother repo You'd still want to have an automatic mirror of that repo at git.haskell.org, as we need to traverse the sub-repo in order to validate submodule gitlink refs in ghc.git Also, you need to ensure that the upstream repo never loses the commits you reference from ghc.git (afaik there's a way to ask the GitHub admins to disable non-fast-forward updates for certain repos -- but that would mean, that you should refrain from creating topic-branches in the mother-repo, as those would not be allowed to be deleted -- GitHub doesn't support branch-based ACLs) > Both seem simpler than adding a new lagging repo. > Having a lagging repo doesn't add anything, does it? It adds the ability to add temporary local changes if you don't have full control over the upstream repo, or if you plan on re-basing your work-in-progress patchsets (which would be disallowed inside the GitHub upstream repo) > Indeed, does it *ever* help to have a lagging repo? The SHA hash for > a submodule uniquely determines that build depends on, so we don't > need a whole repo for that! That's right, but as pointed out above, we need a local copy for having ghc.git's validation-script be able to verify the "foreign-key constraint" property on the referenced SHA hash. > (I'm hazy about how and when to make GHC's repo point to newer versions of the sub-module.) > > > Regardless of the decision here, can I appeal, once more, for clear documentation of the workflows that a GHC developer will encounter? From simonpj at microsoft.com Mon Apr 28 09:09:04 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Apr 2014 09:09:04 +0000 Subject: Removing -fext-core In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> In principle I think it's a pity to lose External Core. It provides an interface to GHC that is based on the simplest possibly connector (a text file), and allows GHC's front end or back end to be used by other systems written in different languages. However, as you say, it has received no love for many years. I have repeatedly sought someone to support and maintain External Core, but no one has stepped forward. That doesn't mean that no one is using it! But the absence of bug reports, given how much it has bit-rotted, is a strong indicator that no one is. So I'd like hear from our users, but I won't stand in the way of removing it. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Austin Seipp | Sent: 27 April 2014 14:14 | To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org | Subject: Removing -fext-core | | Hello all, | | Recently I was wondering something: is there any reason to keep -fext- | core around? In particular, it's been broken for a while at this point, | see GHC bug #5630[1] | | As far as I'm aware there really aren't any users of it still around | these days, at least none working with a modern GHC. And it seems like | if people were to need access to Core, they could use a plugin or some | such to get direct access to what they want. | | Simon mentioned removing ExtCore in face of replacing it with IfaceSyn | in the compiler. I'm not entirely sure how much work that would be to | bring it all up to scratch if people needed it, but maybe it's worth | thinking about. | | One other issue is a notion of semantics which is present in External | Core, but we also now have a documented semantics for GHC's core | language as well (which has evolved quite a bit), so I don't know how | much that matters. | | So long story short: I don't think anyone is using it, maintaining it, | and it seems subsumed by more recent events. | | Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, | unless someone is willing to step up and really maintain it. If you're | using it, you should probably speak up soon I'd imagine... | | [1] https://ghc.haskell.org/trac/ghc/ticket/5630 | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Mon Apr 28 09:28:35 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 10:28:35 +0100 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <878uqpg8gf.fsf@gmail.com> References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <878uqpg8gf.fsf@gmail.com> Message-ID: <535E1F43.6000106@gmail.com> On 28/04/2014 09:32, Herbert Valerio Riedel wrote: > Hello Simon, > > On 2014-04-28 at 10:16:39 +0200, Simon Marlow wrote: >> So let me check that I'm understanding correctly. Right now the >> source of truth for these repos is under git.haskell.org/ghc, and >> you're proposing that we move the source of truth to github. In >> addition we would still need the git.haskell.org/ghc repos, but they >> would become lagging repos tracking the github upstream? > >> So the situation for pushing to these repos becomes more complex, >> becuase we have to push to upstream first, then the lagging repo, and >> finally update the submodule link. > > Yes, that'd be the extreme case (and we have that kind of complexity > already for packages such as transformers/time, where we even have to > bridge the darcs/git gap) > > However, we can configure the lagged mirror such that we'd automatically > mirror github's 'master' branch into our lagged mirror (we'd still be > free to create local wip/* or ghc-7.10 branches at git.haskell.org if > needed) I think that's fine. As Simon points out, we already have lagging repo functionality in the form of the submodule links, so the repo on git.haskell.org can be a pure mirror. Let me make one suggestion: have a sync-all command that automatically checks out a submodule onto a branch and sets the push-url to the appropriate upstream. Something like $ ./sync-all checkout-submodule array so you would do this before modifying 'array', and then a git push inside that submodule would do the right thing. Cheers, Simon > Then you'd only have to do the 2-step workflow, i.e. updating github's > master branch (or for more experimental stuff, a git.haskell.org-local > wip/ branch), and update the gitlink in ghc.git > > > >> I've no objection to hosting issue trackers on github, but I'm >> concerned about the repo structure and the workflow for pushing >> becoming more complex. > > I'd like to point out, that while it will become more complex in one way > or another (if we want to get away from the current loosely-coupled > sub-repo setup), breaking changes in GHC HEAD requiring immediate action > happen rather infrequently (after all, we tend to avoid such breakages > in the first place, as they'd usually affect a larger portion of Hackage > then as well) > > From austin at well-typed.com Mon Apr 28 11:21:15 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 28 Apr 2014 06:21:15 -0500 Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! Message-ID: Hello all, I hate to pester so late, but this completely slipped my mind *twice* so I'm afraid I have to! The HCAR entry deadling is rapidly approaching (~May 1st), and before I send off what we have to Mihai, I'd like everyone to pitch in as much as possible. I've already gone ahead and filled out the skeleton. Now I need y'all to fill in details. To that end, I've directly CC'd interested parties, and replicating the message here - if your name is below, please take a quick look over, it shouldn't take you long. * Richard - I copied over the note about the old Explicit Type Application work - do you have any update on what its current status is? I also was under the impression the new kind equalities work *may* go into 7.10, but I haven't heard anything yet. Do please confirm and edit as you see fit. * Iavor - I know you, Eric, and Trevor had worked on Kinds without Data before. Do you know of its current status? I copied the current notes into the page - I also believe you have some recent work involving using an SMT solver in the type-checker, which is quite interesting! If you feel like it, please do mention it, I'm sure people would like to hear. * Thomas - everyone is excited about PartialTypeSignatures I think. Please edit the page and write what you'd like - there's a tiny stub there already. * Edward, Simon, Johan - I'm not sure what you're working on, but I imagine you may have some runtime system or optimization changes up your sleeve. Do feel free to add in things you feel you should mention. * SimonM - I've added a small note for ApplicativeDo. Please feel free to expand or tweak it as you see fit. * Herbert - Do please make the new repository changes clear, and be sure to mention anything else you might be working on (perhaps more integer-gmp improvements?) Please spread the word (by mouth somehow or IRC) - I'll be monitoring the page closely for the next few days and send it to Mihail once it's been expanded upon. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Mon Apr 28 11:27:29 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Apr 2014 11:27:29 +0000 Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A5776FB@DBXPRD3001MB024.064d.mgd.msft.net> Austin omitted the all-important URL: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 It's on the wiki so you can fill in yourselves. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 28 April 2014 12:21 | To: ghc-devs at haskell.org | Cc: Simon Marlow; Herbert Valerio Riedel | Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! | | Hello all, | | I hate to pester so late, but this completely slipped my mind *twice* | so I'm afraid I have to! | | The HCAR entry deadling is rapidly approaching (~May 1st), and before | I send off what we have to Mihai, I'd like everyone to pitch in as | much as possible. | | I've already gone ahead and filled out the skeleton. Now I need y'all | to fill in details. To that end, I've directly CC'd interested | parties, and replicating the message here - if your name is below, | please take a quick look over, it shouldn't take you long. | | * Richard - I copied over the note about the old Explicit Type | Application work - do you have any update on what its current status | is? I also was under the impression the new kind equalities work *may* | go into 7.10, but I haven't heard anything yet. Do please confirm and | edit as you see fit. | | * Iavor - I know you, Eric, and Trevor had worked on Kinds without | Data before. Do you know of its current status? I copied the current | notes into the page - | | I also believe you have some recent work involving using an SMT | solver in the type-checker, which is quite interesting! If you feel | like it, please do mention it, I'm sure people would like to hear. | | * Thomas - everyone is excited about PartialTypeSignatures I think. | Please edit the page and write what you'd like - there's a tiny stub | there already. | | * Edward, Simon, Johan - I'm not sure what you're working on, but I | imagine you may have some runtime system or optimization changes up | your sleeve. Do feel free to add in things you feel you should | mention. | | * SimonM - I've added a small note for ApplicativeDo. Please feel | free to expand or tweak it as you see fit. | | * Herbert - Do please make the new repository changes clear, and be | sure to mention anything else you might be working on (perhaps more | integer-gmp improvements?) | | Please spread the word (by mouth somehow or IRC) - I'll be monitoring | the page closely for the next few days and send it to Mihail once it's | been expanded upon. | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Mon Apr 28 11:28:47 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 28 Apr 2014 06:28:47 -0500 Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A5776FB@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A5776FB@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: Yes, major blunder. Sorry about that! On Mon, Apr 28, 2014 at 6:27 AM, Simon Peyton Jones wrote: > Austin omitted the all-important URL: > https://ghc.haskell.org/trac/ghc/wiki/Status/May14 > > It's on the wiki so you can fill in yourselves. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin > | Seipp > | Sent: 28 April 2014 12:21 > | To: ghc-devs at haskell.org > | Cc: Simon Marlow; Herbert Valerio Riedel > | Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! > | > | Hello all, > | > | I hate to pester so late, but this completely slipped my mind *twice* > | so I'm afraid I have to! > | > | The HCAR entry deadling is rapidly approaching (~May 1st), and before > | I send off what we have to Mihai, I'd like everyone to pitch in as > | much as possible. > | > | I've already gone ahead and filled out the skeleton. Now I need y'all > | to fill in details. To that end, I've directly CC'd interested > | parties, and replicating the message here - if your name is below, > | please take a quick look over, it shouldn't take you long. > | > | * Richard - I copied over the note about the old Explicit Type > | Application work - do you have any update on what its current status > | is? I also was under the impression the new kind equalities work *may* > | go into 7.10, but I haven't heard anything yet. Do please confirm and > | edit as you see fit. > | > | * Iavor - I know you, Eric, and Trevor had worked on Kinds without > | Data before. Do you know of its current status? I copied the current > | notes into the page - > | > | I also believe you have some recent work involving using an SMT > | solver in the type-checker, which is quite interesting! If you feel > | like it, please do mention it, I'm sure people would like to hear. > | > | * Thomas - everyone is excited about PartialTypeSignatures I think. > | Please edit the page and write what you'd like - there's a tiny stub > | there already. > | > | * Edward, Simon, Johan - I'm not sure what you're working on, but I > | imagine you may have some runtime system or optimization changes up > | your sleeve. Do feel free to add in things you feel you should > | mention. > | > | * SimonM - I've added a small note for ApplicativeDo. Please feel > | free to expand or tweak it as you see fit. > | > | * Herbert - Do please make the new repository changes clear, and be > | sure to mention anything else you might be working on (perhaps more > | integer-gmp improvements?) > | > | Please spread the word (by mouth somehow or IRC) - I'll be monitoring > | the page closely for the next few days and send it to Mihail once it's > | been expanded upon. > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Apr 28 13:57:45 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 28 Apr 2014 08:57:45 -0500 Subject: Status updates Message-ID: Hello all, Here's what's gone on this week: - The HCAR is happening! I sent an email about this earlier, but PLEASE, if you're working on something, add it to the page for the May 2014 report! I won't forget the link this time: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 - ORF is still waiting for a merge. I believe Simon was looking over it this past week - I'm sure we'll talk about it later today. - AMP is still waiting for merge, I think we'll have to coordinate a Happy release as well to match (the fix I have is slightly unsatisfactory). I'll talk to Simon about this today. - My extended-rep-movsb patch is on wip/ermsb, but it needs to be benchmarked and tested before I merge it. Unordered-containers will be my baseline, since Johan tells me it's sensitive to copies like this (it may also need alignment tweaking, on this note). - Many of the Coverity bugs have been fixed, hooray! We will probably fix some more of them - all of the current fixes have gone into 7.8 as well. - I triaged the bug tracker a lot this morning as I'm sure you can all see. I went through a bunch of them, closed tickets, punted, lowered priority, etc. - I've proposed to remove External Core - if you need it, you should speak up *soon*, otherwise I will probably nuke it sometime this week: http://www.haskell.org/pipermail/ghc-devs/2014-April/004791.html The work to do this is on wip/kill-extcore, so again, speak soon or forever hold your peace. - The 7.8.3 milestone has been shaped up. Please take a look at the outstanding tickets: https://ghc.haskell.org/trac/ghc/milestone/7.8.3 https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&group=status&milestone=7.8.3 Note that *not* all of these will be fixed - but these are the ones we will pay attention to for the 7.8.3 release. So do have a look over and if you think you can fix something, please do so! ------------- Some things I've been thinking about: - One really annoying thing about the way we generate source-distributions is that we must do a build first, but this practically negates the need for a sdist! Joachim in particular finds this annoying too for the Debian builds. Ideally we could build a source dist immediately from the repository, and then build from that. This has the benefit the CI system is always testing something that a user can build and make themselves. The problem here is that we need to run Happy and Alex on the parser, which is part of the stage1/stage2 build. Although it's kind of a hack, I think we can do this differently, but I haven't tried it. In particular, they do not depend on any CPP, so we could just immediately generate them up front in the build process. This is kind of a gross hack from the build-system's point of view, but it would make this task much easier. - For right now, I'd like to go with Stackage for building a subset of packages against HEAD I think. Herbert recently uploaded fresh PPAs for GHC HEAD recently, so I think we can already begin the process of testing things and seeing how/why they break. Of course, not everyone will always need to pay attention to this, and sometimes it *will* be broken (c.f. upcoming AMP changes). But in the long run I think this will be very useful, and we can also set it up for the 7.8 branch. I'll be spinning up some new machines today and reply with some updates on this later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From iavor.diatchki at gmail.com Mon Apr 28 14:40:39 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 28 Apr 2014 07:40:39 -0700 Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A5776FB@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: Hello, I added a paragraph about my work to integrate an SMT solver with the constraint solver. As far as I know, the work on 'data kinds' is stalled at the moment in part due to lack of time, but also because we got a prototype working, but then there were doubts if we'd taken the right approach. -Iavor On Mon, Apr 28, 2014 at 4:28 AM, Austin Seipp wrote: > Yes, major blunder. Sorry about that! > > On Mon, Apr 28, 2014 at 6:27 AM, Simon Peyton Jones > wrote: > > Austin omitted the all-important URL: > > https://ghc.haskell.org/trac/ghc/wiki/Status/May14 > > > > It's on the wiki so you can fill in yourselves. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > Austin > > | Seipp > > | Sent: 28 April 2014 12:21 > > | To: ghc-devs at haskell.org > > | Cc: Simon Marlow; Herbert Valerio Riedel > > | Subject: [Urgent] Please fill out the 2014 HCAR entry for GHC! > > | > > | Hello all, > > | > > | I hate to pester so late, but this completely slipped my mind *twice* > > | so I'm afraid I have to! > > | > > | The HCAR entry deadling is rapidly approaching (~May 1st), and before > > | I send off what we have to Mihai, I'd like everyone to pitch in as > > | much as possible. > > | > > | I've already gone ahead and filled out the skeleton. Now I need y'all > > | to fill in details. To that end, I've directly CC'd interested > > | parties, and replicating the message here - if your name is below, > > | please take a quick look over, it shouldn't take you long. > > | > > | * Richard - I copied over the note about the old Explicit Type > > | Application work - do you have any update on what its current status > > | is? I also was under the impression the new kind equalities work *may* > > | go into 7.10, but I haven't heard anything yet. Do please confirm and > > | edit as you see fit. > > | > > | * Iavor - I know you, Eric, and Trevor had worked on Kinds without > > | Data before. Do you know of its current status? I copied the current > > | notes into the page - > > | > > | I also believe you have some recent work involving using an SMT > > | solver in the type-checker, which is quite interesting! If you feel > > | like it, please do mention it, I'm sure people would like to hear. > > | > > | * Thomas - everyone is excited about PartialTypeSignatures I think. > > | Please edit the page and write what you'd like - there's a tiny stub > > | there already. > > | > > | * Edward, Simon, Johan - I'm not sure what you're working on, but I > > | imagine you may have some runtime system or optimization changes up > > | your sleeve. Do feel free to add in things you feel you should > > | mention. > > | > > | * SimonM - I've added a small note for ApplicativeDo. Please feel > > | free to expand or tweak it as you see fit. > > | > > | * Herbert - Do please make the new repository changes clear, and be > > | sure to mention anything else you might be working on (perhaps more > > | integer-gmp improvements?) > > | > > | Please spread the word (by mouth somehow or IRC) - I'll be monitoring > > | the page closely for the next few days and send it to Mihail once it's > > | been expanded upon. > > | > > | -- > > | Regards, > > | > > | Austin Seipp, Haskell Consultant > > | Well-Typed LLP, http://www.well-typed.com/ > > | _______________________________________________ > > | ghc-devs mailing list > > | ghc-devs at haskell.org > > | http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Tue Apr 29 05:59:02 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 29 Apr 2014 05:59:02 +0000 Subject: GHC builder: out of memory from ghc during make Message-ID: I am trying to get GHC builder-clients running for x86 and x86_64 GHC on SmartOS. I have been trying to get to the bottom of this memory issue and have had no luck. I've set it aside for the past couple of days to try to get a clear head to attack it afresh tonight. The three latest builds die with the following message: ghc: out of memory (requested 2097152 bytes) compiler/ghc.mk:641: recipe for target 'compiler/stage1/build/DynFlags.o' failed http://haskell.inf.elte.hu/builders/smartos-x86_64-head/16/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/17/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/18/10.html All of these were run interactively from the builder directory: builder-client --do-build Here's my zone setup: image: SmartOS base64 13.4.2 max_physical_memory: 4GB max_swap: 8GB disk_quota: 200GB # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 12261 virtual memory (kbytes, -v) unlimited It doesn't use anywhere near the 4GB of memory or 8GB of swap allocated to the zone. Total zone RSS (physical memory usage) stays under 200MB for the entire builder-client run. I took regular snaps of memory during the build run and saw no evidence of memory saturation or errors. It's nowhere near hitting swap limits either. I think I've done all I can do to remove system imposed resource limits. This doesn't happen when I run make directly from a shell myself. It looks like a defect in the GHC builder-client itself. If POSIX resources are available on the host (which they are on SmartOS) builder-client sets a 1GB ResourceTotalMemory limit using System.Posix.Resource.setResourceLimit: https://github.com/haskell/ghc-builder/blob/master/client/client.hs#L54 I'm trying a build with the resource limit code commented out. Hopefully that will finally put this to bed. Speaking of bed, I should probably sleep too. If anyone has any other ideas I'd be very happy for the help. Best, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 29 06:17:43 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Tue, 29 Apr 2014 08:17:43 +0200 Subject: GHC builder: out of memory from ghc during make In-Reply-To: References: Message-ID: 2014-04-29 7:59 GMT+02:00 Alain O'Dea : > This doesn't happen when I run make directly from a shell myself. It looks > like a defect in the GHC builder-client itself. I would rather call it (yet) an undocumented feature :-) > If POSIX resources are available on the host (which they are on SmartOS) > builder-client sets a 1GB ResourceTotalMemory limit using > System.Posix.Resource.setResourceLimit: > https://github.com/haskell/ghc-builder/blob/master/client/client.hs#L54 Yes, I think your diagnosis is right. The builder-client sets that memory limit for each launched process so it could avoid uncontrolled consumption. But the original 1-GB limit may be too strict these days, as the build phase could easily exceed this (legally), especially on 64-bit architectures. Probably this should be factored out to a configuration file or increased to 2 or 4 GB. From simonpj at microsoft.com Tue Apr 29 07:56:42 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Apr 2014 07:56:42 +0000 Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab) In-Reply-To: <20140428235122.E84F12406D@ghc.haskell.org> References: <20140428235122.E84F12406D@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> Richard, Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal needed it, and the new optimsations it enables, are also non-obvious and deserve examples! Evernyone: my obsession with Notes is born of the hours I have spent staring at code that has cases I don't understand; or "fixing" something turned out to be there for a good but undocumented reason. Going back to unSubCo, I think the start of the documentation could be if g :: t1 ~R t2 then unSubCo g :: t ~N t2 (if it succeeds at all). But why do we need it? And what optimisations do we get? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 29 April 2014 00:51 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. | (a3896ab) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 | e25e327da5/ghc | | >--------------------------------------------------------------- | | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 | Author: Richard Eisenberg | Date: Mon Apr 28 13:33:13 2014 -0400 | | Improve implementation of unSubCo_maybe. | | This is the result of an email conversation (off list) with | Conal Elliott, who needed a stronger unSubCo_maybe. This | commit adds cases to upgrade the role of a coercion when | recursion is necessary to do say (for example, for a use of | TransCo). As a side effect, more coercion optimizations are | now possible. | | This was not done previously because unSubCo_maybe was used | only during coercion optimization, and the recursive cases | looked to be unlikely. However, adding them can cause no harm. | | unSubCo_maybe is now also exported from Coercion, for use | cases like Conal's. | | | >--------------------------------------------------------------- | | a3896ab5d2dc88160f710705bf23e6e25e327da5 | compiler/types/Coercion.lhs | 20 +++++++++++++++----- | 1 file changed, 15 insertions(+), 5 deletions(-) | | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs | index af2b2fa..f60fcbd 100644 | --- a/compiler/types/Coercion.lhs | +++ b/compiler/types/Coercion.lhs | @@ -38,7 +38,7 @@ module Coercion ( | splitAppCo_maybe, | splitForAllCo_maybe, | nthRole, tyConRolesX, | - nextRole, | + nextRole, unSubCo_maybe, | | -- ** Coercion variables | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co | | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; otherwise, | fails unSubCo_maybe :: Coercion -> Maybe Coercion | +unSubCo_maybe co | + | Nominal <- coercionRole co = Just co | unSubCo_maybe (SubCo co) = Just co | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe | (TyConAppCo Representational tc cos) | - = do { cos' <- mapM unSubCo_maybe cos | +unSubCo_maybe (TyConAppCo Representational tc coes) | + = do { cos' <- mapM unSubCo_maybe coes | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 | -- We do *not* promote UnivCo Phantom, as that's unsafe. | -- UnivCo Nominal is no more unsafe than UnivCo Representational - | unSubCo_maybe co | - | Nominal <- coercionRole co = Just co | +unSubCo_maybe (TransCo co1 co2) | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe | +(AppCo co1 co2) | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo tv | +co) | + = ForAllCo tv <$> unSubCo_maybe co | +unSubCo_maybe (NthCo n co) | + = NthCo n <$> unSubCo_maybe co | +unSubCo_maybe (InstCo co ty) | + = InstCo <$> unSubCo_maybe co <*> pure ty | unSubCo_maybe _ = Nothing | | -- takes any coercion and turns it into a Phantom coercion | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits From hvriedel at gmail.com Tue Apr 29 09:58:14 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 29 Apr 2014 11:58:14 +0200 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <535E1F43.6000106@gmail.com> (Simon Marlow's message of "Mon, 28 Apr 2014 10:28:35 +0100") References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <878uqpg8gf.fsf@gmail.com> <535E1F43.6000106@gmail.com> Message-ID: <87bnvk8nk9.fsf@gmail.com> Hello Simon, On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote: [...] >> However, we can configure the lagged mirror such that we'd automatically >> mirror github's 'master' branch into our lagged mirror (we'd still be >> free to create local wip/* or ghc-7.10 branches at git.haskell.org if >> needed) > > I think that's fine. As Simon points out, we already have lagging > repo functionality in the form of the submodule links, so the repo on > git.haskell.org can be a pure mirror. Just so I get this right, does "pure mirror" here mean that we don't want users to be able to push to the automatically mirrored repo on git.haskell.org at all, but rather the only way to get any commits into the git.haskell.org mirrored repo would be push it via the GitHub repo? (I'd like that, as it would make the set-up easier and hopefully less confusing, as there'd be only a single data-flow path) Cheers, hvr From marlowsd at gmail.com Tue Apr 29 10:27:38 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 29 Apr 2014 11:27:38 +0100 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <87bnvk8nk9.fsf@gmail.com> References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <878uqpg8gf.fsf@gmail.com> <535E1F43.6000106@gmail.com> <87bnvk8nk9.fsf@gmail.com> Message-ID: <535F7E9A.90905@gmail.com> On 29/04/2014 10:58, Herbert Valerio Riedel wrote: > Hello Simon, > > On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote: > > [...] > >>> However, we can configure the lagged mirror such that we'd automatically >>> mirror github's 'master' branch into our lagged mirror (we'd still be >>> free to create local wip/* or ghc-7.10 branches at git.haskell.org if >>> needed) >> >> I think that's fine. As Simon points out, we already have lagging >> repo functionality in the form of the submodule links, so the repo on >> git.haskell.org can be a pure mirror. > > Just so I get this right, does "pure mirror" here mean that we don't > want users to be able to push to the automatically mirrored repo on > git.haskell.org at all, but rather the only way to get any commits into > the git.haskell.org mirrored repo would be push it via the GitHub repo? > > (I'd like that, as it would make the set-up easier and hopefully less > confusing, as there'd be only a single data-flow path) Makes sense to me, but how does that interact with your post-commit hook that checks for validity of the submodule updates? Cheers, Simon From ekmett at gmail.com Tue Apr 29 14:46:45 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 29 Apr 2014 10:46:45 -0400 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: <87bnvk8nk9.fsf@gmail.com> References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <878uqpg8gf.fsf@gmail.com> <535E1F43.6000106@gmail.com> <87bnvk8nk9.fsf@gmail.com> Message-ID: I would really like that as well. My experience is it is rather easy to get users to put together a pull request through github. It is rather more like pulling teeth to get them to use git properly and put together a traditional patch. This would greatly open up the workflow for end users contributing things like small documentation fixes and the like. -Edward On Tue, Apr 29, 2014 at 5:58 AM, Herbert Valerio Riedel wrote: > Hello Simon, > > On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote: > > [...] > > >> However, we can configure the lagged mirror such that we'd automatically > >> mirror github's 'master' branch into our lagged mirror (we'd still be > >> free to create local wip/* or ghc-7.10 branches at git.haskell.org if > >> needed) > > > > I think that's fine. As Simon points out, we already have lagging > > repo functionality in the form of the submodule links, so the repo on > > git.haskell.org can be a pure mirror. > > Just so I get this right, does "pure mirror" here mean that we don't > want users to be able to push to the automatically mirrored repo on > git.haskell.org at all, but rather the only way to get any commits into > the git.haskell.org mirrored repo would be push it via the GitHub repo? > > (I'd like that, as it would make the set-up easier and hopefully less > confusing, as there'd be only a single data-flow path) > > Cheers, > hvr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Apr 29 17:08:41 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 29 Apr 2014 18:08:41 +0100 Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab) In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140428235122.E84F12406D@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <535FDC99.7060303@gmail.com> On 29/04/2014 08:56, Simon Peyton Jones wrote: > Richard, > > Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal needed it, and the new optimsations it enables, are also non-obvious and deserve examples! And let's not forget a test too :-) Cheers, Simon > Evernyone: my obsession with Notes is born of the hours I have spent staring at code that has cases I don't understand; or "fixing" something turned out to be there for a good but undocumented reason. > > Going back to unSubCo, I think the start of the documentation could be > if g :: t1 ~R t2 > then unSubCo g :: t ~N t2 > (if it succeeds at all). > > But why do we need it? And what optimisations do we get? > > Thanks > > Simon > > > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of > | git at git.haskell.org > | Sent: 29 April 2014 00:51 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. > | (a3896ab) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 > | e25e327da5/ghc > | > | >--------------------------------------------------------------- > | > | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 > | Author: Richard Eisenberg > | Date: Mon Apr 28 13:33:13 2014 -0400 > | > | Improve implementation of unSubCo_maybe. > | > | This is the result of an email conversation (off list) with > | Conal Elliott, who needed a stronger unSubCo_maybe. This > | commit adds cases to upgrade the role of a coercion when > | recursion is necessary to do say (for example, for a use of > | TransCo). As a side effect, more coercion optimizations are > | now possible. > | > | This was not done previously because unSubCo_maybe was used > | only during coercion optimization, and the recursive cases > | looked to be unlikely. However, adding them can cause no harm. > | > | unSubCo_maybe is now also exported from Coercion, for use > | cases like Conal's. > | > | > | >--------------------------------------------------------------- > | > | a3896ab5d2dc88160f710705bf23e6e25e327da5 > | compiler/types/Coercion.lhs | 20 +++++++++++++++----- > | 1 file changed, 15 insertions(+), 5 deletions(-) > | > | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs > | index af2b2fa..f60fcbd 100644 > | --- a/compiler/types/Coercion.lhs > | +++ b/compiler/types/Coercion.lhs > | @@ -38,7 +38,7 @@ module Coercion ( > | splitAppCo_maybe, > | splitForAllCo_maybe, > | nthRole, tyConRolesX, > | - nextRole, > | + nextRole, unSubCo_maybe, > | > | -- ** Coercion variables > | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, > | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co > | > | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; otherwise, > | fails unSubCo_maybe :: Coercion -> Maybe Coercion > | +unSubCo_maybe co > | + | Nominal <- coercionRole co = Just co > | unSubCo_maybe (SubCo co) = Just co > | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe > | (TyConAppCo Representational tc cos) > | - = do { cos' <- mapM unSubCo_maybe cos > | +unSubCo_maybe (TyConAppCo Representational tc coes) > | + = do { cos' <- mapM unSubCo_maybe coes > | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo > | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 > | -- We do *not* promote UnivCo Phantom, as that's unsafe. > | -- UnivCo Nominal is no more unsafe than UnivCo Representational - > | unSubCo_maybe co > | - | Nominal <- coercionRole co = Just co > | +unSubCo_maybe (TransCo co1 co2) > | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe > | +(AppCo co1 co2) > | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo tv > | +co) > | + = ForAllCo tv <$> unSubCo_maybe co > | +unSubCo_maybe (NthCo n co) > | + = NthCo n <$> unSubCo_maybe co > | +unSubCo_maybe (InstCo co ty) > | + = InstCo <$> unSubCo_maybe co <*> pure ty > | unSubCo_maybe _ = Nothing > | > | -- takes any coercion and turns it into a Phantom coercion > | > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-commits > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Tue Apr 29 17:22:52 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 29 Apr 2014 18:22:52 +0100 Subject: optllvm failures In-Reply-To: References: <6994821.NuLaD01UEA@linux-hpeb.site> <1615877.bZPc2HsqiZ@linux-hpeb.site> Message-ID: <535FDFEC.2040802@gmail.com> We should reject LLVM 3.2 if it's known to be bad - I remember running into this on the RPi too. LlvmCodeGen already checks the version number and emits warnings if it's too old or too new. On 24/04/2014 20:04, Austin Seipp wrote: > GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1. > > The odd version number for LLVM 3.2 was a known problem with their > tarball, they forgot to remove the 'svn' suffix. This shouldn't be a > problem for GHC, it should correctly parse the right thing anyway. > > Can you try another LLVM version? LLVM 3.2 has been known to be > particularly problematic - I believe me and David looked into this a > while back, and we couldn't get even get the compiler to bootstrap > with it at one point, let alone figure out what the hell was going on > (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM > 3.4 should work just fine, and you can put them on the front of your > $PATH before running the testsuite to check this. > > On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer > wrote: >> On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: >>> What OS? Is this on a vm? >> >> Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. >> >>> I7-avx is the instruction family. I5 will be ok. >> >> Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks >> 3.2 is. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > From eir at cis.upenn.edu Tue Apr 29 18:36:20 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 29 Apr 2014 14:36:20 -0400 Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab) In-Reply-To: <535FDC99.7060303@gmail.com> References: <20140428235122.E84F12406D@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> <535FDC99.7060303@gmail.com> Message-ID: <127E90A6-B135-4994-84B9-45233AD727BE@cis.upenn.edu> I?m surely agreed about the Note -- I also did some helpful name-changing of related functions and am validating my work as I write. About a test case: this seems like a challenging thing to test. The new code affects only coercion optimizations. The only time the extra code would be triggered is when we, say, have a coercion built with transitivity buried inside of a TyConAppCo that needs to be split up in order to interact with the use of an axiom. (The obscurity of the case is one reason I believe I didn?t implement it this way to begin with!) So, I think I?m going to leave off the test case for now. Richard On Apr 29, 2014, at 1:08 PM, Simon Marlow wrote: > On 29/04/2014 08:56, Simon Peyton Jones wrote: >> Richard, >> >> Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal needed it, and the new optimsations it enables, are also non-obvious and deserve examples! > > And let's not forget a test too :-) > > Cheers, > Simon > > >> Evernyone: my obsession with Notes is born of the hours I have spent staring at code that has cases I don't understand; or "fixing" something turned out to be there for a good but undocumented reason. >> >> Going back to unSubCo, I think the start of the documentation could be >> if g :: t1 ~R t2 >> then unSubCo g :: t ~N t2 >> (if it succeeds at all). >> >> But why do we need it? And what optimisations do we get? >> >> Thanks >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of >> | git at git.haskell.org >> | Sent: 29 April 2014 00:51 >> | To: ghc-commits at haskell.org >> | Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. >> | (a3896ab) >> | >> | Repository : ssh://git at git.haskell.org/ghc >> | >> | On branch : master >> | Link : >> | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 >> | e25e327da5/ghc >> | >> | >--------------------------------------------------------------- >> | >> | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 >> | Author: Richard Eisenberg >> | Date: Mon Apr 28 13:33:13 2014 -0400 >> | >> | Improve implementation of unSubCo_maybe. >> | >> | This is the result of an email conversation (off list) with >> | Conal Elliott, who needed a stronger unSubCo_maybe. This >> | commit adds cases to upgrade the role of a coercion when >> | recursion is necessary to do say (for example, for a use of >> | TransCo). As a side effect, more coercion optimizations are >> | now possible. >> | >> | This was not done previously because unSubCo_maybe was used >> | only during coercion optimization, and the recursive cases >> | looked to be unlikely. However, adding them can cause no harm. >> | >> | unSubCo_maybe is now also exported from Coercion, for use >> | cases like Conal's. >> | >> | >> | >--------------------------------------------------------------- >> | >> | a3896ab5d2dc88160f710705bf23e6e25e327da5 >> | compiler/types/Coercion.lhs | 20 +++++++++++++++----- >> | 1 file changed, 15 insertions(+), 5 deletions(-) >> | >> | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs >> | index af2b2fa..f60fcbd 100644 >> | --- a/compiler/types/Coercion.lhs >> | +++ b/compiler/types/Coercion.lhs >> | @@ -38,7 +38,7 @@ module Coercion ( >> | splitAppCo_maybe, >> | splitForAllCo_maybe, >> | nthRole, tyConRolesX, >> | - nextRole, >> | + nextRole, unSubCo_maybe, >> | >> | -- ** Coercion variables >> | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, >> | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co >> | >> | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; otherwise, >> | fails unSubCo_maybe :: Coercion -> Maybe Coercion >> | +unSubCo_maybe co >> | + | Nominal <- coercionRole co = Just co >> | unSubCo_maybe (SubCo co) = Just co >> | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe >> | (TyConAppCo Representational tc cos) >> | - = do { cos' <- mapM unSubCo_maybe cos >> | +unSubCo_maybe (TyConAppCo Representational tc coes) >> | + = do { cos' <- mapM unSubCo_maybe coes >> | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo >> | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 >> | -- We do *not* promote UnivCo Phantom, as that's unsafe. >> | -- UnivCo Nominal is no more unsafe than UnivCo Representational - >> | unSubCo_maybe co >> | - | Nominal <- coercionRole co = Just co >> | +unSubCo_maybe (TransCo co1 co2) >> | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe >> | +(AppCo co1 co2) >> | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo tv >> | +co) >> | + = ForAllCo tv <$> unSubCo_maybe co >> | +unSubCo_maybe (NthCo n co) >> | + = NthCo n <$> unSubCo_maybe co >> | +unSubCo_maybe (InstCo co ty) >> | + = InstCo <$> unSubCo_maybe co <*> pure ty >> | unSubCo_maybe _ = Nothing >> | >> | -- takes any coercion and turns it into a Phantom coercion >> | >> | _______________________________________________ >> | ghc-commits mailing list >> | ghc-commits at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-commits >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Apr 29 18:39:36 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Apr 2014 18:39:36 +0000 Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab) In-Reply-To: <127E90A6-B135-4994-84B9-45233AD727BE@cis.upenn.edu> References: <20140428235122.E84F12406D@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> <535FDC99.7060303@gmail.com> <127E90A6-B135-4994-84B9-45233AD727BE@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A58F159@DB3PRD3001MB020.064d.mgd.msft.net> I'm sympathetic about not having a test for this kind of thing. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] | Sent: 29 April 2014 19:36 | To: Simon Marlow | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Improve implementation of | unSubCo_maybe. (a3896ab) | | I'm surely agreed about the Note -- I also did some helpful name-changing | of related functions and am validating my work as I write. | | About a test case: this seems like a challenging thing to test. The new | code affects only coercion optimizations. The only time the extra code | would be triggered is when we, say, have a coercion built with | transitivity buried inside of a TyConAppCo that needs to be split up in | order to interact with the use of an axiom. (The obscurity of the case is | one reason I believe I didn't implement it this way to begin with!) So, I | think I'm going to leave off the test case for now. | | Richard | | On Apr 29, 2014, at 1:08 PM, Simon Marlow wrote: | | > On 29/04/2014 08:56, Simon Peyton Jones wrote: | >> Richard, | >> | >> Looks good, but *surely* worth a Note [unSubCo] in the file? It's | manifestly non-obvious or you'd have done this from day 1. Moreover, the | *reason* Conal needed it, and the new optimsations it enables, are also | non-obvious and deserve examples! | > | > And let's not forget a test too :-) | > | > Cheers, | > Simon | > | > | >> Evernyone: my obsession with Notes is born of the hours I have spent | staring at code that has cases I don't understand; or "fixing" something | turned out to be there for a good but undocumented reason. | >> | >> Going back to unSubCo, I think the start of the documentation could be | >> if g :: t1 ~R t2 | >> then unSubCo g :: t ~N t2 | >> (if it succeeds at all). | >> | >> But why do we need it? And what optimisations do we get? | >> | >> Thanks | >> | >> Simon | >> | >> | >> | -----Original Message----- | >> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of | >> | git at git.haskell.org | >> | Sent: 29 April 2014 00:51 | >> | To: ghc-commits at haskell.org | >> | Subject: [commit: ghc] master: Improve implementation of | unSubCo_maybe. | >> | (a3896ab) | >> | | >> | Repository : ssh://git at git.haskell.org/ghc | >> | | >> | On branch : master | >> | Link : | >> | | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 | >> | e25e327da5/ghc | >> | | >> | >--------------------------------------------------------------- | >> | | >> | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 | >> | Author: Richard Eisenberg | >> | Date: Mon Apr 28 13:33:13 2014 -0400 | >> | | >> | Improve implementation of unSubCo_maybe. | >> | | >> | This is the result of an email conversation (off list) with | >> | Conal Elliott, who needed a stronger unSubCo_maybe. This | >> | commit adds cases to upgrade the role of a coercion when | >> | recursion is necessary to do say (for example, for a use of | >> | TransCo). As a side effect, more coercion optimizations are | >> | now possible. | >> | | >> | This was not done previously because unSubCo_maybe was used | >> | only during coercion optimization, and the recursive cases | >> | looked to be unlikely. However, adding them can cause no harm. | >> | | >> | unSubCo_maybe is now also exported from Coercion, for use | >> | cases like Conal's. | >> | | >> | | >> | >--------------------------------------------------------------- | >> | | >> | a3896ab5d2dc88160f710705bf23e6e25e327da5 | >> | compiler/types/Coercion.lhs | 20 +++++++++++++++----- | >> | 1 file changed, 15 insertions(+), 5 deletions(-) | >> | | >> | diff --git a/compiler/types/Coercion.lhs | b/compiler/types/Coercion.lhs | >> | index af2b2fa..f60fcbd 100644 | >> | --- a/compiler/types/Coercion.lhs | >> | +++ b/compiler/types/Coercion.lhs | >> | @@ -38,7 +38,7 @@ module Coercion ( | >> | splitAppCo_maybe, | >> | splitForAllCo_maybe, | >> | nthRole, tyConRolesX, | >> | - nextRole, | >> | + nextRole, unSubCo_maybe, | >> | | >> | -- ** Coercion variables | >> | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, | >> | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co | >> | | >> | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; | otherwise, | >> | fails unSubCo_maybe :: Coercion -> Maybe Coercion | >> | +unSubCo_maybe co | >> | + | Nominal <- coercionRole co = Just co | >> | unSubCo_maybe (SubCo co) = Just co | >> | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe | >> | (TyConAppCo Representational tc cos) | >> | - = do { cos' <- mapM unSubCo_maybe cos | >> | +unSubCo_maybe (TyConAppCo Representational tc coes) | >> | + = do { cos' <- mapM unSubCo_maybe coes | >> | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe | (UnivCo | >> | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 | >> | -- We do *not* promote UnivCo Phantom, as that's unsafe. | >> | -- UnivCo Nominal is no more unsafe than UnivCo Representational | - | >> | unSubCo_maybe co | >> | - | Nominal <- coercionRole co = Just co | >> | +unSubCo_maybe (TransCo co1 co2) | >> | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 | unSubCo_maybe | >> | +(AppCo co1 co2) | >> | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe | (ForAllCo tv | >> | +co) | >> | + = ForAllCo tv <$> unSubCo_maybe co | >> | +unSubCo_maybe (NthCo n co) | >> | + = NthCo n <$> unSubCo_maybe co | >> | +unSubCo_maybe (InstCo co ty) | >> | + = InstCo <$> unSubCo_maybe co <*> pure ty | >> | unSubCo_maybe _ = Nothing | >> | | >> | -- takes any coercion and turns it into a Phantom coercion | >> | | >> | _______________________________________________ | >> | ghc-commits mailing list | >> | ghc-commits at haskell.org | >> | http://www.haskell.org/mailman/listinfo/ghc-commits | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | >> | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Tue Apr 29 19:03:41 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 29 Apr 2014 20:03:41 +0100 Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab) In-Reply-To: <127E90A6-B135-4994-84B9-45233AD727BE@cis.upenn.edu> References: <20140428235122.E84F12406D@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF0A583DB3@DB3PRD3001MB020.064d.mgd.msft.net> <535FDC99.7060303@gmail.com> <127E90A6-B135-4994-84B9-45233AD727BE@cis.upenn.edu> Message-ID: No problem - I assumed that Conal had some code that demonstrated the difference. On 29 Apr 2014 19:36, "Richard Eisenberg" wrote: > I?m surely agreed about the Note -- I also did some helpful name-changing > of related functions and am validating my work as I write. > > About a test case: this seems like a challenging thing to test. The new > code affects only coercion optimizations. The only time the extra code > would be triggered is when we, say, have a coercion built with transitivity > buried inside of a TyConAppCo that needs to be split up in order to > interact with the use of an axiom. (The obscurity of the case is one reason > I believe I didn?t implement it this way to begin with!) So, I think I?m > going to leave off the test case for now. > > Richard > > On Apr 29, 2014, at 1:08 PM, Simon Marlow wrote: > > > On 29/04/2014 08:56, Simon Peyton Jones wrote: > >> Richard, > >> > >> Looks good, but *surely* worth a Note [unSubCo] in the file? It's > manifestly non-obvious or you'd have done this from day 1. Moreover, the > *reason* Conal needed it, and the new optimsations it enables, are also > non-obvious and deserve examples! > > > > And let's not forget a test too :-) > > > > Cheers, > > Simon > > > > > >> Evernyone: my obsession with Notes is born of the hours I have spent > staring at code that has cases I don't understand; or "fixing" something > turned out to be there for a good but undocumented reason. > >> > >> Going back to unSubCo, I think the start of the documentation could be > >> if g :: t1 ~R t2 > >> then unSubCo g :: t ~N t2 > >> (if it succeeds at all). > >> > >> But why do we need it? And what optimisations do we get? > >> > >> Thanks > >> > >> Simon > >> > >> > >> | -----Original Message----- > >> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf > Of > >> | git at git.haskell.org > >> | Sent: 29 April 2014 00:51 > >> | To: ghc-commits at haskell.org > >> | Subject: [commit: ghc] master: Improve implementation of > unSubCo_maybe. > >> | (a3896ab) > >> | > >> | Repository : ssh://git at git.haskell.org/ghc > >> | > >> | On branch : master > >> | Link : > >> | > http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 > >> | e25e327da5/ghc > >> | > >> | >--------------------------------------------------------------- > >> | > >> | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 > >> | Author: Richard Eisenberg > >> | Date: Mon Apr 28 13:33:13 2014 -0400 > >> | > >> | Improve implementation of unSubCo_maybe. > >> | > >> | This is the result of an email conversation (off list) with > >> | Conal Elliott, who needed a stronger unSubCo_maybe. This > >> | commit adds cases to upgrade the role of a coercion when > >> | recursion is necessary to do say (for example, for a use of > >> | TransCo). As a side effect, more coercion optimizations are > >> | now possible. > >> | > >> | This was not done previously because unSubCo_maybe was used > >> | only during coercion optimization, and the recursive cases > >> | looked to be unlikely. However, adding them can cause no harm. > >> | > >> | unSubCo_maybe is now also exported from Coercion, for use > >> | cases like Conal's. > >> | > >> | > >> | >--------------------------------------------------------------- > >> | > >> | a3896ab5d2dc88160f710705bf23e6e25e327da5 > >> | compiler/types/Coercion.lhs | 20 +++++++++++++++----- > >> | 1 file changed, 15 insertions(+), 5 deletions(-) > >> | > >> | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs > >> | index af2b2fa..f60fcbd 100644 > >> | --- a/compiler/types/Coercion.lhs > >> | +++ b/compiler/types/Coercion.lhs > >> | @@ -38,7 +38,7 @@ module Coercion ( > >> | splitAppCo_maybe, > >> | splitForAllCo_maybe, > >> | nthRole, tyConRolesX, > >> | - nextRole, > >> | + nextRole, unSubCo_maybe, > >> | > >> | -- ** Coercion variables > >> | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, > >> | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co > >> | > >> | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; > otherwise, > >> | fails unSubCo_maybe :: Coercion -> Maybe Coercion > >> | +unSubCo_maybe co > >> | + | Nominal <- coercionRole co = Just co > >> | unSubCo_maybe (SubCo co) = Just co > >> | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe > >> | (TyConAppCo Representational tc cos) > >> | - = do { cos' <- mapM unSubCo_maybe cos > >> | +unSubCo_maybe (TyConAppCo Representational tc coes) > >> | + = do { cos' <- mapM unSubCo_maybe coes > >> | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo > >> | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 > >> | -- We do *not* promote UnivCo Phantom, as that's unsafe. > >> | -- UnivCo Nominal is no more unsafe than UnivCo Representational - > >> | unSubCo_maybe co > >> | - | Nominal <- coercionRole co = Just co > >> | +unSubCo_maybe (TransCo co1 co2) > >> | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe > >> | +(AppCo co1 co2) > >> | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo > tv > >> | +co) > >> | + = ForAllCo tv <$> unSubCo_maybe co > >> | +unSubCo_maybe (NthCo n co) > >> | + = NthCo n <$> unSubCo_maybe co > >> | +unSubCo_maybe (InstCo co ty) > >> | + = InstCo <$> unSubCo_maybe co <*> pure ty > >> | unSubCo_maybe _ = Nothing > >> | > >> | -- takes any coercion and turns it into a Phantom coercion > >> | > >> | _______________________________________________ > >> | ghc-commits mailing list > >> | ghc-commits at haskell.org > >> | http://www.haskell.org/mailman/listinfo/ghc-commits > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 29 21:13:29 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Apr 2014 21:13:29 +0000 Subject: GHC status report Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> As Austin has told us, there's a draft of the GHC Status Report for the HCAR, here: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 Have we missed out something you have been working hard on? Do take a moment to add a bullet in an appropriate place (it's a wiki). I'd like to be sure that we are giving credit to all the appropriate people, so please help us fix that too. GHC is a team effort. Deadline is 1 May I think. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From afarmer at ittc.ku.edu Tue Apr 29 21:41:45 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Tue, 29 Apr 2014 16:41:45 -0500 Subject: Relocating (some of) GHC's core-libraries to github.com/haskell In-Reply-To: References: <87lhurp20u.fsf@gnu.org> <535E0E67.9090508@gmail.com> <878uqpg8gf.fsf@gmail.com> <535E1F43.6000106@gmail.com> <87bnvk8nk9.fsf@gmail.com> Message-ID: +1 On Tue, Apr 29, 2014 at 9:46 AM, Edward Kmett wrote: > I would really like that as well. > > My experience is it is rather easy to get users to put together a pull > request through github. > > It is rather more like pulling teeth to get them to use git properly and put > together a traditional patch. > > This would greatly open up the workflow for end users contributing things > like small documentation fixes and the like. > > -Edward > > > On Tue, Apr 29, 2014 at 5:58 AM, Herbert Valerio Riedel > wrote: >> >> Hello Simon, >> >> On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote: >> >> [...] >> >> >> However, we can configure the lagged mirror such that we'd >> >> automatically >> >> mirror github's 'master' branch into our lagged mirror (we'd still be >> >> free to create local wip/* or ghc-7.10 branches at git.haskell.org if >> >> needed) >> > >> > I think that's fine. As Simon points out, we already have lagging >> > repo functionality in the form of the submodule links, so the repo on >> > git.haskell.org can be a pure mirror. >> >> Just so I get this right, does "pure mirror" here mean that we don't >> want users to be able to push to the automatically mirrored repo on >> git.haskell.org at all, but rather the only way to get any commits into >> the git.haskell.org mirrored repo would be push it via the GitHub repo? >> >> (I'd like that, as it would make the set-up easier and hopefully less >> confusing, as there'd be only a single data-flow path) >> >> Cheers, >> hvr > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From conal at conal.net Tue Apr 29 22:02:53 2014 From: conal at conal.net (Conal Elliott) Date: Tue, 29 Apr 2014 15:02:53 -0700 Subject: GHC rewrite rules and constructor wrappers? Message-ID: I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like > "reify/(:<)" reifyEP (:<) = kPrim VecSP This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire. Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Apr 30 00:35:29 2014 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 29 Apr 2014 21:35:29 -0300 Subject: GHC status report In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: It doesn't have anything about the dynamic linking changes made for 7.8. I think it's worth mentioning the improvements we expect to get from that. The highlights of the release notes do mention it, so maybe that suffices. In particular, I'm hoping that it is going to fix a lot of problems with using foreign libraries such as OpenGL from ghci. I could be wrong about that though. On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones wrote: > As Austin has told us, there?s a draft of the *GHC Status Report for the > HCAR*, here: > > https://ghc.haskell.org/trac/ghc/wiki/Status/May14 > > Have we missed out something you have been working hard on? Do take a > moment to add a bullet in an appropriate place (it?s a wiki). I?d like to > be sure that we are giving credit to all the appropriate people, so please > help us fix that too. GHC is a team effort. > > Deadline is 1 May I think. > > Thanks > > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Apr 30 00:46:15 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 29 Apr 2014 19:46:15 -0500 Subject: GHC status report In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Good idea! Definitely one of the biggest changes. On Tue, Apr 29, 2014 at 7:35 PM, George Colpitts wrote: > It doesn't have anything about the dynamic linking changes made for 7.8. I > think it's worth mentioning the improvements we expect to get from that. The > highlights of the release notes do mention it, so maybe that suffices. > > In particular, I'm hoping that it is going to fix a lot of problems with > using foreign libraries such as OpenGL from ghci. I could be wrong about > that though. > > > On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones > wrote: >> >> As Austin has told us, there?s a draft of the GHC Status Report for the >> HCAR, here: >> >> https://ghc.haskell.org/trac/ghc/wiki/Status/May14 >> >> Have we missed out something you have been working hard on? Do take a >> moment to add a bullet in an appropriate place (it?s a wiki). I?d like to >> be sure that we are giving credit to all the appropriate people, so please >> help us fix that too. GHC is a team effort. >> >> Deadline is 1 May I think. >> >> Thanks >> >> Simon >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Wed Apr 30 08:33:01 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 30 Apr 2014 10:33:01 +0200 Subject: Overloaded record fields: we ought to change the name of FldTy Message-ID: Hi, I'm currently watching the Skills Matter talks you gave (great!) and I'm slightly worried that we're going to expose beginners (and intermediate users!) to a name called FldTy, which might be OK for a GHC-internal name, but is not very readable. If this is going to be exposed to users, could we name is something readable, like FieldType, Field, or something similar? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Apr 30 13:29:05 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 30 Apr 2014 08:29:05 -0500 Subject: GHC status report In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Done now. OK, unless anyone has anything else major going in, I'll look for typos closely and send it to Mihail later today. It filled up pretty fast - thanks for the haste everyone! On Tue, Apr 29, 2014 at 7:46 PM, Austin Seipp wrote: > Good idea! Definitely one of the biggest changes. > > On Tue, Apr 29, 2014 at 7:35 PM, George Colpitts > wrote: >> It doesn't have anything about the dynamic linking changes made for 7.8. I >> think it's worth mentioning the improvements we expect to get from that. The >> highlights of the release notes do mention it, so maybe that suffices. >> >> In particular, I'm hoping that it is going to fix a lot of problems with >> using foreign libraries such as OpenGL from ghci. I could be wrong about >> that though. >> >> >> On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones >> wrote: >>> >>> As Austin has told us, there?s a draft of the GHC Status Report for the >>> HCAR, here: >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Status/May14 >>> >>> Have we missed out something you have been working hard on? Do take a >>> moment to add a bullet in an appropriate place (it?s a wiki). I?d like to >>> be sure that we are giving credit to all the appropriate people, so please >>> help us fix that too. GHC is a team effort. >>> >>> Deadline is 1 May I think. >>> >>> Thanks >>> >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From scpmw at leeds.ac.uk Wed Apr 30 13:29:16 2014 From: scpmw at leeds.ac.uk (Peter Wortmann) Date: Wed, 30 Apr 2014 14:29:16 +0100 Subject: GHC status report In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1398864556.5508.4.camel@cslin101.csunix.comp.leeds.ac.uk> Added a few sentences about DWARF support - we should really aim to get this done for 7.10. Greetings, Peter Wortmann From austin at well-typed.com Wed Apr 30 13:30:22 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 30 Apr 2014 08:30:22 -0500 Subject: GHC status report In-Reply-To: <1398864556.5508.4.camel@cslin101.csunix.comp.leeds.ac.uk> References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> <1398864556.5508.4.camel@cslin101.csunix.comp.leeds.ac.uk> Message-ID: Great, thanks Peter! On Wed, Apr 30, 2014 at 8:29 AM, Peter Wortmann wrote: > > > Added a few sentences about DWARF support - we should really aim to get > this done for 7.10. > > Greetings, > Peter Wortmann > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Wed Apr 30 13:33:52 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 30 Apr 2014 08:33:52 -0500 Subject: Branch cleanup coming soon - please take inventory Message-ID: Hello all, I was talking about this on IRC the other day, and it reminded me I wanted to do this a while back. At the moment, we have a *lot* of branches hanging out in the GHC tree: $ git branch -r | grep origin | wc -l 89 $ So I'd like to start deleting all the old ones that are merged and don't need to hang around. A while back I kept a list that was curated of what branches were dead and could be removed. Here it is: https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches This page is a bit out of date, but still many of the comments are accurate, particularly what can already be deleted. I will likely be *deleting* these merged branches soon unless someone speaks up. Note that: - Anything I cannot be 100% certain is merged will stay. - Anything which is effectively 'in-limbo' (like local-gc, or supercompiler) will stay. We also have a lot of WIP branches here too. If you all would all take inventory of your branches and make sure they're catalogued on that page, it would be really nice. Just add it for now - I'll get rid of the old entries once I delete them later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Wed Apr 30 13:36:06 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 30 Apr 2014 08:36:06 -0500 Subject: Removing -fext-core In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: For people keeping score, I created a branch with this already done the other day: https://github.com/ghc/ghc/tree/wip/kill-extcore Again, unless someone speaks up *real* soon, I'm probably going to get rid of it before the end of the week - so your timeframe is something like 72 hours to make a peep before it goes away.... On Mon, Apr 28, 2014 at 4:09 AM, Simon Peyton Jones wrote: > In principle I think it's a pity to lose External Core. It provides an interface to GHC that is based on the simplest possibly connector (a text file), and allows GHC's front end or back end to be used by other systems written in different languages. > > However, as you say, it has received no love for many years. I have repeatedly sought someone to support and maintain External Core, but no one has stepped forward. That doesn't mean that no one is using it! But the absence of bug reports, given how much it has bit-rotted, is a strong indicator that no one is. > > So I'd like hear from our users, but I won't stand in the way of removing it. > > Simon > > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Austin Seipp > | Sent: 27 April 2014 14:14 > | To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > | Subject: Removing -fext-core > | > | Hello all, > | > | Recently I was wondering something: is there any reason to keep -fext- > | core around? In particular, it's been broken for a while at this point, > | see GHC bug #5630[1] > | > | As far as I'm aware there really aren't any users of it still around > | these days, at least none working with a modern GHC. And it seems like > | if people were to need access to Core, they could use a plugin or some > | such to get direct access to what they want. > | > | Simon mentioned removing ExtCore in face of replacing it with IfaceSyn > | in the compiler. I'm not entirely sure how much work that would be to > | bring it all up to scratch if people needed it, but maybe it's worth > | thinking about. > | > | One other issue is a notion of semantics which is present in External > | Core, but we also now have a documented semantics for GHC's core > | language as well (which has evolved quite a bit), so I don't know how > | much that matters. > | > | So long story short: I don't think anyone is using it, maintaining it, > | and it seems subsumed by more recent events. > | > | Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, > | unless someone is willing to step up and really maintain it. If you're > | using it, you should probably speak up soon I'd imagine... > | > | [1] https://ghc.haskell.org/trac/ghc/ticket/5630 > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Wed Apr 30 13:39:29 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 30 Apr 2014 15:39:29 +0200 Subject: Removing -fext-core In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Wed Apr 30 15:22:46 2014 From: adam at well-typed.com (Adam Gundry) Date: Wed, 30 Apr 2014 16:22:46 +0100 Subject: Overloaded record fields: we ought to change the name of FldTy In-Reply-To: References: Message-ID: <53611546.4030106@well-typed.com> Thanks Johan, On 30/04/14 09:33, Johan Tibell wrote: > I'm currently watching the Skills Matter talks you gave (great!) and I'm > slightly worried that we're going to expose beginners (and intermediate > users!) to a name called FldTy, which might be OK for a GHC-internal > name, but is not very readable. > > If this is going to be exposed to users, could we name is something > readable, like FieldType, Field, or something similar? While I'm hoping to avoid exposing these names to most users more than at present, I think you're right: we should pick slightly more informative names. (Various others have also made this suggestion!) Perhaps: Has |-> HasField FldTy |-> FieldType Upd |-> UpdatedField UpdTy |-> UpdatedType If possible, I'd prefer to merge the existing patches more or less as is, then I can work on the library design without continually needing to fix merge conflicts. Apart from naming, I'd like to tweak the design to improve the presentation of inferred types that result from ORF code. Since I originally implemented it, the constraint solver seems to have changed in a way that makes the "functional dependencies via type families" approach used lead to less pretty types. Obviously we need something a little less brittle. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From marlowsd at gmail.com Wed Apr 30 16:45:35 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 30 Apr 2014 17:45:35 +0100 Subject: GHC status report In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <536128AF.7080209@gmail.com> On 30/04/2014 01:35, George Colpitts wrote: > It doesn't have anything about the dynamic linking changes made for 7.8. > I think it's worth mentioning the improvements we expect to get from > that. The highlights of the release notes do mention it, so maybe that > suffices. > > In particular, I'm hoping that it is going to fix a lot of problems with > using foreign libraries such as OpenGL from ghci. I could be wrong about > that though. I'd like to understand more about what those problems are. As a data point, at Facebook we're using static linking (I compiled GHC with DYNAMIC_GHC_PROGRAMS=NO), we're loading upwards of 50 3rd-party C++ libraries and one gigantic shared library consisting of a ton of in-house C++ code, together with all our Haskell code into GHCi, and it works perfectly. The key to using the static linker is to not use it for C++ code - you want all your external C++ code in shared libraries and load those using the system linker. Dynamic linking has been a huge headache in GHC, and it's not clear that it's an overall improvement compared with the static linker. Now that 7.8 is out of the way, it's time to have a conversation about whether we want to do dynamic linking again for 7.10, or revert to static linking. I think Austin is going to update https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms, and then we'll see where we stand. Cheers, Simon > > On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones > > wrote: > > As Austin has told us, there?s a draft of the *GHC Status Report for > the HCAR*, here:____ > > https://ghc.haskell.org/trac/ghc/wiki/Status/May14____ > > Have we missed out something you have been working hard on? Do > take a moment to add a bullet in an appropriate place (it?s a > wiki). I?d like to be sure that we are giving credit to all the > appropriate people, so please help us fix that too. GHC is a team > effort.____ > > Deadline is 1 May I think.____ > > Thanks____ > > Simon____ > > __ __ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From johan.tibell at gmail.com Wed Apr 30 18:14:06 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 30 Apr 2014 20:14:06 +0200 Subject: Overloaded record fields: we ought to change the name of FldTy In-Reply-To: <53611546.4030106@well-typed.com> References: <53611546.4030106@well-typed.com> Message-ID: On Wed, Apr 30, 2014 at 5:22 PM, Adam Gundry wrote: > If possible, I'd prefer to merge the existing patches more or less as > is, then I can work on the library design without continually needing to > fix merge conflicts. > Agreed. We should try to get the patches in sooner rather than later to avoid extra work for you and allow people to try the feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely at risko.hu Wed Apr 30 20:22:42 2014 From: gergely at risko.hu (Gergely Risko) Date: Wed, 30 Apr 2014 22:22:42 +0200 Subject: GHC status report References: <618BE556AADD624C9C918AA5D5911BEF0A58F2FC@DB3PRD3001MB020.064d.mgd.msft.net> <536128AF.7080209@gmail.com> Message-ID: <877g66must.fsf@gergely.risko.hu> Hi, On Wed, 30 Apr 2014 17:45:35 +0100, Simon Marlow writes: > Dynamic linking has been a huge headache in GHC, and it's not clear > that it's an overall improvement compared with the static linker. Now > that 7.8 is out of the way, it's time to have a conversation about > whether we want to do dynamic linking again for 7.10, or revert to > static linking. I think Austin is going to update > https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms, and then > we'll see where we stand. Apart from the bugs, which are steadily being fixed (hooray), I have a little concern about -dynamic-too. The whole thing is kind of a mess, that if you forget to use it, then ghci doesn't work and TH doesn't work. And cabal used it wrong (maybe now it's getting better). It also increases the compilation times. And of course I get used to it, but I wanted to ask: would it be possible to change the default compilation method to be only dynamic? If we have only dynamic objects, can we still build a static executable (I mean haskelly half static: libc and libgmp is dynamic, but the haskell libs are not shared, so as of now)? If I remember correctly when I do gcc + ld for a simple C project, it's enough to decide ld time if I'm building a shared or a static executable. But maybe I'm oversimplifying something... Gergely From hvr at gnu.org Tue Apr 15 07:48:32 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 15 Apr 2014 07:48:32 -0000 Subject: The build is broken (Solaris/x86, FreeBSD/{i386,amd64}) In-Reply-To: <201404150652.43183.jan.stolarek@p.lodz.pl> (Jan Stolarek's message of "Tue, 15 Apr 2014 05:52:42 +0100") References: <87vbucidls.fsf@gmail.com> <1397460226-sup-5944@sabre> <201404150652.43183.jan.stolarek@p.lodz.pl> Message-ID: <87r44zav97.fsf@gnu.org> On 2014-04-15 at 06:52:42 +0200, Jan Stolarek wrote: >> I think Simon Marlow is even more conservative, and >> does his validate builds in a separate tree so he catches missing >> files. > I thought everyone is doing that. Btw, using such a workflow[1] is actually almost a necessity if you want to continue working on GHC while a longish validate is running in the background... otherwise you're blocked till validate completes. Cheers, hvr [1]: like e.g. https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Workflowwithvalidate (fwiw, I meant to write up a variant not relying on sync-all)