From mark.lentczner at gmail.com Sat May 2 00:57:27 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 1 May 2015 17:57:27 -0700 Subject: release timing Message-ID: I'm wondering if ghc 7.10.2 has a rough time table yet? This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off.... But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' "heads up" would be good. Thoughts? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sat May 2 13:21:01 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sat, 02 May 2015 13:21:01 +0000 Subject: Hoopl question Message-ID: Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Sun May 3 17:39:42 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 3 May 2015 19:39:42 +0200 Subject: Hoopl question In-Reply-To: References: Message-ID: <201505031939.42195.jan.stolarek@p.lodz.pl> Micha?, one of my students is currently working on this: https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup as his BSc thesis (see #8315). It might turn out that he will also have enough time to focus on performance issues in Hoopl but at this point it is hard to tell. Janek Dnia sobota, 2 maja 2015, Michal Terepeta napisa?: > Hi, > > I've just read through the Hoopl paper and then noticed > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance > which is really interesting. But it seems that there were no updates to the > page > in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone > know > what is the current status of this? > > Thanks, > Michal --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From michal.terepeta at gmail.com Sun May 3 18:22:00 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 03 May 2015 18:22:00 +0000 Subject: Hoopl question In-Reply-To: <201505031939.42195.jan.stolarek@p.lodz.pl> References: <201505031939.42195.jan.stolarek@p.lodz.pl> Message-ID: > > > On Sun, May 3, 2015 at 7:39 PM Jan Stolarek > wrote: > > Micha?, > > > > one of my students is currently working on this: > > > > https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup > > > > as his BSc thesis (see #8315). It might turn out that he will also have > enough time to focus on > > performance issues in Hoopl but at this point it is hard to tell. > > > > Janek > Sounds great! :-) Which reminds me about another question I had -- the main reason to have the specialized module in GHC (instead of relying on the Hoopl one) is performance, right? (as in, the module is specialized for the UniqSM, but otherwise pretty close to Hoopl.Dataflow?) Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Sun May 3 19:31:58 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 3 May 2015 21:31:58 +0200 Subject: Hoopl question In-Reply-To: References: <201505031939.42195.jan.stolarek@p.lodz.pl> Message-ID: <201505032131.58725.jan.stolarek@p.lodz.pl> > Which reminds me about another question I had -- the main reason to have > the specialized module in GHC (instead of relying on the Hoopl one) is > performance, > right? Yes. If you're interested you might look at ghc-devs archives from July and August 2013 - I was doing MSR internship at that time and I had some questions about Hoopl. You might find these helpful or interesting (well, answers, not questions :-) ). Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From mkscrg at gmail.com Mon May 4 17:12:19 2015 From: mkscrg at gmail.com (Mike Craig) Date: Mon, 4 May 2015 10:12:19 -0700 Subject: Help with GHC 7.10 on Homebrew? Message-ID: Hey all, I'm trying to help improve the GHC-via-Homebrew situation. It's been busted for a while now. Someone opened a reasonable-looking PR to update the ghc formula. It removes a few bad hacks added over the years: https://github.com/Homebrew/homebrew/pull/39134 However, the build fails on CI when setting up HPC: > cat utils/hpc/hpc.wrapper >> inplace/bin/hpc > cat: utils/hpc/hpc.wrapper: No such file or directory The full log is here, with that error near the bottom: http://bot.brew.sh/job/Homebrew%20Pull%20Requests/25284/version=yosemite/testReport/junit/brew-test-bot/yosemite/install_ghc/ Is this problem familiar to anyone? That formula builds on my laptop (also Yosemite), and I'm not familiar enough with the GHC build to know what to try next. Any help is much-appreciated! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From magesh85 at gmail.com Tue May 5 08:21:33 2015 From: magesh85 at gmail.com (magesh b) Date: Tue, 5 May 2015 13:51:33 +0530 Subject: Annotation restriction is not respected while generating Annotation via TH Message-ID: As per user guide one of the restriction in annotating value is . The binder being annotated must be declared in the current module But when I use TH to generate the annotation above restriction is not respected. Below is the minimal test case to reproduce the issue ---- Ann.hs {-# LANGUAGE TemplateHaskell #-} module Ann where import Language.Haskell.TH -- {-# Ann id "Orphan Ann for id" #-} -- *Rightly produces error "Not in scope: ?id?"* $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . return) --* Ideally this should have produced same error as above* ---- End of Ann.hs ---- Main.hs {-# LANGUAGE TemplateHaskell #-} module Main where import Ann () import Language.Haskell.TH ann :: [String] ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> [|anns|])) --err = 'a' && True -- Uncomment to introduce compile error main :: IO () main = print ann ---- End of Main.hs Also there is another bug in reifying the Orphan Annotations. In the above example Main.hs depends on Ann.hs which defines Annotation for `id` When Main.hs compiles fine in the first go, its is able to retrieve the annotation for `id` Instead, if Ann.hs compiled successfully and Main.hs failed to compile and when you later fix the Main.hs error, it is not able to retrieve that annotation without recompiling Ann.hs Regards, Magesh B -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 5 10:08:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2015 10:08:15 +0000 Subject: release timing In-Reply-To: References: Message-ID: This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off.... Good plan! In Austin?s last GHC Weekly News we asked if anyone had any constraints on the release of GHC 7.10.2. So far as I know, no one replied. So the current status is that we?ll hold it until someone says ?getting 7.10.2 out really matters to me?. Other things being equal, the longer we wait, the more fixes will be in. But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 02 May 2015 01:57 To: ghc-devs at haskell.org Subject: release timing I'm wondering if ghc 7.10.2 has a rough time table yet? This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off.... But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' "heads up" would be good. Thoughts? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 5 10:12:42 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2015 10:12:42 +0000 Subject: Hoopl question In-Reply-To: References: Message-ID: <297d7bf161d24020b386e79cc8fd8cb1@DB4PR30MB030.064d.mgd.msft.net> Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl, so they would be good people to talk to. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michal Terepeta Sent: 02 May 2015 14:21 To: ghc-devs at haskell.org Subject: Hoopl question Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue May 5 10:16:24 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 05 May 2015 13:16:24 +0300 Subject: release timing In-Reply-To: References: Message-ID: <55489878.5060602@ro-che.info> I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385 On 05/05/15 13:08, Simon Peyton Jones wrote: > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! > Crazy, I know, and who knows if we can pull it off.... > > > > Good plan! > > > > In Austin?s last GHC Weekly News we asked if anyone had any constraints > on the release of GHC 7.10.2. So far as I know, no one replied. *So > the current status is that we?ll hold it until someone says ?getting > 7.10.2 out really matters to me?.* Other things being equal, the longer > we wait, the more fixes will be in. > > > > But does anything stand in the way of pressing the button on the HP > build, so that you have a HP 7.10.2 ready to go? You can always press > the button again if/when further fixes go in. > > > > Simon > > > > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of > *Mark Lentczner > *Sent:* 02 May 2015 01:57 > *To:* ghc-devs at haskell.org > *Subject:* release timing > > > > I'm wondering if ghc 7.10.2 has a rough time table yet? > > > > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! > Crazy, I know, and who knows if we can pull it off.... > > > > But I imagine it is about 3 or 4 week cycle for HP at this point > (still)... so a few weeks' "heads up" would be good. Thoughts? > > > > - Mark > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alan.zimm at gmail.com Tue May 5 10:26:18 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 5 May 2015 12:26:18 +0200 Subject: release timing In-Reply-To: <55489878.5060602@ro-che.info> References: <55489878.5060602@ro-che.info> Message-ID: I'd love to see the various queued API Annotations diffs go in. Alan On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka wrote: > I'd love to see GHC 7.10.2 once this haddock issue is fixed: > https://github.com/haskell/haddock/issues/385 > > On 05/05/15 13:08, Simon Peyton Jones wrote: > > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! > > Crazy, I know, and who knows if we can pull it off.... > > > > > > > > Good plan! > > > > > > > > In Austin?s last GHC Weekly News we asked if anyone had any constraints > > on the release of GHC 7.10.2. So far as I know, no one replied. *So > > the current status is that we?ll hold it until someone says ?getting > > 7.10.2 out really matters to me?.* Other things being equal, the longer > > we wait, the more fixes will be in. > > > > > > > > But does anything stand in the way of pressing the button on the HP > > build, so that you have a HP 7.10.2 ready to go? You can always press > > the button again if/when further fixes go in. > > > > > > > > Simon > > > > > > > > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of > > *Mark Lentczner > > *Sent:* 02 May 2015 01:57 > > *To:* ghc-devs at haskell.org > > *Subject:* release timing > > > > > > > > I'm wondering if ghc 7.10.2 has a rough time table yet? > > > > > > > > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! > > Crazy, I know, and who knows if we can pull it off.... > > > > > > > > But I imagine it is about 3 or 4 week cycle for HP at this point > > (still)... so a few weeks' "heads up" would be good. Thoughts? > > > > > > > > - Mark > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Tue May 5 11:04:10 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 5 May 2015 13:04:10 +0200 Subject: Hoopl question In-Reply-To: <297d7bf161d24020b386e79cc8fd8cb1@DB4PR30MB030.064d.mgd.msft.net> References: <297d7bf161d24020b386e79cc8fd8cb1@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <201505051304.11164.jan.stolarek@p.lodz.pl> > Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl Sadly, this is not what Hackage says. Janek > , > so they would be good people to talk to. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michal > Terepeta Sent: 02 May 2015 14:21 > To: ghc-devs at haskell.org > Subject: Hoopl question > > Hi, > > I've just read through the Hoopl paper and then noticed > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance > which is really interesting. But it seems that there were no updates to the > page in like 3 years, yet the new codegen seems to be using Hoopl... Does > anyone know what is the current status of this? > > Thanks, > Michal --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From matthewtpickering at gmail.com Tue May 5 11:09:06 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 5 May 2015 12:09:06 +0100 Subject: release timing In-Reply-To: References: <55489878.5060602@ro-che.info> Message-ID: +1 for the API Annotations patches. On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman wrote: > I'd love to see the various queued API Annotations diffs go in. > > Alan > > On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka wrote: >> >> I'd love to see GHC 7.10.2 once this haddock issue is fixed: >> https://github.com/haskell/haddock/issues/385 >> >> On 05/05/15 13:08, Simon Peyton Jones wrote: >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! >> > Crazy, I know, and who knows if we can pull it off.... >> > >> > >> > >> > Good plan! >> > >> > >> > >> > In Austin?s last GHC Weekly News we asked if anyone had any constraints >> > on the release of GHC 7.10.2. So far as I know, no one replied. *So >> > the current status is that we?ll hold it until someone says ?getting >> > 7.10.2 out really matters to me?.* Other things being equal, the longer >> > we wait, the more fixes will be in. >> > >> > >> > >> > But does anything stand in the way of pressing the button on the HP >> > build, so that you have a HP 7.10.2 ready to go? You can always press >> > the button again if/when further fixes go in. >> > >> > >> > >> > Simon >> > >> > >> > >> > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of >> > *Mark Lentczner >> > *Sent:* 02 May 2015 01:57 >> > *To:* ghc-devs at haskell.org >> > *Subject:* release timing >> > >> > >> > >> > I'm wondering if ghc 7.10.2 has a rough time table yet? >> > >> > >> > >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! >> > Crazy, I know, and who knows if we can pull it off.... >> > >> > >> > >> > But I imagine it is about 3 or 4 week cycle for HP at this point >> > (still)... so a few weeks' "heads up" would be good. Thoughts? >> > >> > >> > >> > - Mark >> > >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Tue May 5 11:09:21 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2015 11:09:21 +0000 Subject: Hoopl question In-Reply-To: <201505051304.11164.jan.stolarek@p.lodz.pl> References: <297d7bf161d24020b386e79cc8fd8cb1@DB4PR30MB030.064d.mgd.msft.net> <201505051304.11164.jan.stolarek@p.lodz.pl> Message-ID: well perhaps they have not yet uploaded a new version. But I believe it's as agreed with all parties. Simon | -----Original Message----- | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl] | Sent: 05 May 2015 12:04 | To: ghc-devs at haskell.org | Cc: Simon Peyton Jones; Michal Terepeta; Ning Wang | Subject: Re: Hoopl question | | > Also Ning Wang and Andreas Voellmy have taken over maintainership of | > Hoopl | Sadly, this is not what Hackage says. | | Janek | | > , | > so they would be good people to talk to. | > | > Simon | > | > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > Michal Terepeta Sent: 02 May 2015 14:21 | > To: ghc-devs at haskell.org | > Subject: Hoopl question | > | > Hi, | > | > I've just read through the Hoopl paper and then noticed | > | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerform | > ance which is really interesting. But it seems that there were no | > updates to the page in like 3 years, yet the new codegen seems to be | > using Hoopl... Does anyone know what is the current status of this? | > | > Thanks, | > Michal | | | | --- | Politechnika ??dzka | Lodz University of Technology | | Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla | adresata. | Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez | pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej | usuni?cie. | | This email contains information intended solely for the use of the | individual to whom it is addressed. | If you are not the intended recipient or if you have received this | message in error, please notify the sender and delete it from your | system. From simonpj at microsoft.com Tue May 5 11:16:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2015 11:16:05 +0000 Subject: release timing In-Reply-To: References: <55489878.5060602@ro-che.info> Message-ID: <114f7cc39f5746479c3856c281fc27fd@DB4PR30MB030.064d.mgd.msft.net> Just to be clear, the issue is this * For whom is 7.10.2 mission-critical? * And with what patches? (give specific tickets) * And by what date? The only reason to make a release is because someone is stalled, or seriously inconvenienced, unit it happens. Otherwise we should wait. So: "+1" doesn't give enough information. Of course, the sooner the better, the more bugs fixed the better. You might say "I'm waiting for API Annotations; but I'm under no time pressure". Or "My whole business is stalled pending a fix to Trac #xxx" or whatever. The whole API annotations thing is a special case. We usually make NO api changes in a patch-level release. But the API annotations stuff is brand new, and apparently most of the fixes depend on API changes. So I think we are going to let them sneak in. Do we have a comprehensive list, in Trac tickets of all the patches that are sought? The canonical list is https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 Only patches that are listed as "merge" or "patch" are even being considered. If you have something you care about that is not in that state, can you cause it to be in that state? Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Matthew Pickering | Sent: 05 May 2015 12:09 | To: Alan & Kim Zimmerman | Cc: ghc-devs at haskell.org | Subject: Re: release timing | | +1 for the API Annotations patches. | | On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman | wrote: | > I'd love to see the various queued API Annotations diffs go in. | > | > Alan | > | > On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka | wrote: | >> | >> I'd love to see GHC 7.10.2 once this haddock issue is fixed: | >> https://github.com/haskell/haddock/issues/385 | >> | >> On 05/05/15 13:08, Simon Peyton Jones wrote: | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC | 7.10.2! | >> > Crazy, I know, and who knows if we can pull it off.... | >> > | >> > | >> > | >> > Good plan! | >> > | >> > | >> > | >> > In Austin?s last GHC Weekly News we asked if anyone had any | >> > constraints on the release of GHC 7.10.2. So far as I know, no | one | >> > replied. *So the current status is that we?ll hold it until | >> > someone says ?getting | >> > 7.10.2 out really matters to me?.* Other things being equal, the | >> > longer we wait, the more fixes will be in. | >> > | >> > | >> > | >> > But does anything stand in the way of pressing the button on the | HP | >> > build, so that you have a HP 7.10.2 ready to go? You can always | >> > press the button again if/when further fixes go in. | >> > | >> > | >> > | >> > Simon | >> > | >> > | >> > | >> > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf | Of | >> > *Mark Lentczner | >> > *Sent:* 02 May 2015 01:57 | >> > *To:* ghc-devs at haskell.org | >> > *Subject:* release timing | >> > | >> > | >> > | >> > I'm wondering if ghc 7.10.2 has a rough time table yet? | >> > | >> > | >> > | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC | 7.10.2! | >> > Crazy, I know, and who knows if we can pull it off.... | >> > | >> > | >> > | >> > But I imagine it is about 3 or 4 week cycle for HP at this point | >> > (still)... so a few weeks' "heads up" would be good. Thoughts? | >> > | >> > | >> > | >> > - Mark | >> > | >> > | >> > | >> > _______________________________________________ | >> > ghc-devs mailing list | >> > ghc-devs at haskell.org | >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> > | >> | >> | >> | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue May 5 11:30:07 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 5 May 2015 13:30:07 +0200 Subject: Tracking bugs for libraries Message-ID: <201505051330.07579.jan.stolarek@p.lodz.pl> I just noticed that bugs for several of our libraries can either be tracked on Trac (there is a corresponding entry in the "Component" field) or on github (issue tracking for that library is enabled in the repo). These libraries are: directory, hoopl, old-time, pretty, process, random and unix. I don't like the idea of spreading bug reports in two separate places, unless there is a good reason for doing this (eg. because we actually use our own copies of these libraries). So, is this duplication intended or accidental? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From andreas.voellmy at gmail.com Tue May 5 13:45:45 2015 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Tue, 5 May 2015 09:45:45 -0400 Subject: Hoopl question In-Reply-To: References: <297d7bf161d24020b386e79cc8fd8cb1@DB4PR30MB030.064d.mgd.msft.net> <201505051304.11164.jan.stolarek@p.lodz.pl> Message-ID: There was some delay in pushing the latest hoopl to hackage, but it is done now and Ning and I are also listed as maintainers now. -Andi On Tue, May 5, 2015 at 7:09 AM, Simon Peyton Jones wrote: > well perhaps they have not yet uploaded a new version. But I believe it's > as agreed with all parties. > > Simon > > | -----Original Message----- > | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl] > | Sent: 05 May 2015 12:04 > | To: ghc-devs at haskell.org > | Cc: Simon Peyton Jones; Michal Terepeta; Ning Wang > | Subject: Re: Hoopl question > | > | > Also Ning Wang and Andreas Voellmy have taken over maintainership of > | > Hoopl > | Sadly, this is not what Hackage says. > | > | Janek > | > | > , > | > so they would be good people to talk to. > | > > | > Simon > | > > | > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > Michal Terepeta Sent: 02 May 2015 14:21 > | > To: ghc-devs at haskell.org > | > Subject: Hoopl question > | > > | > Hi, > | > > | > I've just read through the Hoopl paper and then noticed > | > > | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerform > | > ance which is really interesting. But it seems that there were no > | > updates to the page in like 3 years, yet the new codegen seems to be > | > using Hoopl... Does anyone know what is the current status of this? > | > > | > Thanks, > | > Michal > | > | > | > | --- > | Politechnika ??dzka > | Lodz University of Technology > | > | Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > | adresata. > | Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > | pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej > | usuni?cie. > | > | This email contains information intended solely for the use of the > | individual to whom it is addressed. > | If you are not the intended recipient or if you have received this > | message in error, please notify the sender and delete it from your > | system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue May 5 14:48:33 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 May 2015 07:48:33 -0700 Subject: Annotation restriction is not respected while generating Annotation via TH In-Reply-To: References: Message-ID: <1430837233-sup-160@sabre> Hello magesh, Sounds like a bug. Could you file a ticket in the GHC Trac, and CC alanz who had been most closely associated with annotations. Thanks, Edward Excerpts from magesh b's message of 2015-05-05 01:21:33 -0700: > As per user guide one of the restriction in annotating value is > . The binder being annotated must be declared in the current module > > But when I use TH to generate the annotation above restriction is not > respected. > Below is the minimal test case to reproduce the issue > > ---- Ann.hs > > {-# LANGUAGE TemplateHaskell #-} > module Ann where > > import Language.Haskell.TH > > -- {-# Ann id "Orphan Ann for id" #-} -- *Rightly produces error "Not in > scope: ?id?"* > > $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . > return) --* Ideally this should have produced same error as above* > ---- End of Ann.hs > > ---- Main.hs > > {-# LANGUAGE TemplateHaskell #-} > module Main where > > import Ann () > import Language.Haskell.TH > > ann :: [String] > ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> > [|anns|])) > --err = 'a' && True -- Uncomment to introduce compile error > main :: IO () > main = print ann > > ---- End of Main.hs > > Also there is another bug in reifying the Orphan Annotations. > In the above example Main.hs depends on Ann.hs which defines Annotation for > `id` > When Main.hs compiles fine in the first go, its is able to retrieve the > annotation for `id` > Instead, if Ann.hs compiled successfully and Main.hs failed to compile and > when you later fix the Main.hs error, it is not able to retrieve that > annotation without recompiling Ann.hs > > Regards, > Magesh B From ezyang at mit.edu Tue May 5 14:53:20 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 May 2015 07:53:20 -0700 Subject: Annotation restriction is not respected while generating Annotation via TH In-Reply-To: References: Message-ID: <1430837584-sup-891@sabre> Whoops, it looks like simonpj already went ahead and filed the ticket: https://ghc.haskell.org/trac/ghc/ticket/10385 Cheers, Edward Excerpts from magesh b's message of 2015-05-05 01:21:33 -0700: > As per user guide one of the restriction in annotating value is > . The binder being annotated must be declared in the current module > > But when I use TH to generate the annotation above restriction is not > respected. > Below is the minimal test case to reproduce the issue > > ---- Ann.hs > > {-# LANGUAGE TemplateHaskell #-} > module Ann where > > import Language.Haskell.TH > > -- {-# Ann id "Orphan Ann for id" #-} -- *Rightly produces error "Not in > scope: ?id?"* > > $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . > return) --* Ideally this should have produced same error as above* > ---- End of Ann.hs > > ---- Main.hs > > {-# LANGUAGE TemplateHaskell #-} > module Main where > > import Ann () > import Language.Haskell.TH > > ann :: [String] > ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> > [|anns|])) > --err = 'a' && True -- Uncomment to introduce compile error > main :: IO () > main = print ann > > ---- End of Main.hs > > Also there is another bug in reifying the Orphan Annotations. > In the above example Main.hs depends on Ann.hs which defines Annotation for > `id` > When Main.hs compiles fine in the first go, its is able to retrieve the > annotation for `id` > Instead, if Ann.hs compiled successfully and Main.hs failed to compile and > when you later fix the Main.hs error, it is not able to retrieve that > annotation without recompiling Ann.hs > > Regards, > Magesh B From simonpj at microsoft.com Tue May 5 15:01:16 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2015 15:01:16 +0000 Subject: FW: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: References: Message-ID: <2f61e2ac632746fa81601d2d16b70506@DB4PR30MB030.064d.mgd.msft.net> GHC devs, I wasn?t aware that we?d changed these. Anyone know why? Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Omari Norman Sent: 05 May 2015 15:55 To: haskell Cafe Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: -fwarn-type-defaults -fwarn-name-shadowing -fwarn-missing-signatures -fwarn-hi-shadowing -fwarn-orphans -fwarn-unused-do-bind -fwarn-trustworthy-safe I can't find any mention in the release notes of this change in behavior. I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From ezyang at mit.edu Tue May 5 15:44:26 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 May 2015 08:44:26 -0700 Subject: FW: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: <2f61e2ac632746fa81601d2d16b70506@DB4PR30MB030.064d.mgd.msft.net> References: <2f61e2ac632746fa81601d2d16b70506@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1430840643-sup-1961@sabre> There were a few refactorings of DynFlags from the 7.8-7.10 cycle, I bet one of them broke -Wall. I'm bisecting. Edward Excerpts from Simon Peyton Jones's message of 2015-05-05 08:01:16 -0700: > GHC devs, > > I wasn?t aware that we?d changed these. Anyone know why? > > Simon > > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Omari Norman > Sent: 05 May 2015 15:55 > To: haskell Cafe > Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 > > I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > I can't find any mention in the release notes of this change in behavior. > I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alan.zimm at gmail.com Tue May 5 19:23:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 5 May 2015 21:23:52 +0200 Subject: release timing In-Reply-To: <114f7cc39f5746479c3856c281fc27fd@DB4PR30MB030.064d.mgd.msft.net> References: <55489878.5060602@ro-che.info> <114f7cc39f5746479c3856c281fc27fd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I aplogise for the following long post on Api Annotations. They are a new feature, and allow a whole class of tools to become much simpler. The interest in this technology can be seen in the strong support Matt Pickering's proposal for GSOC achieved, and that it was accepted. This project is a good showcase for the annotations, as it should allow the hints from HLint to be directly applied to the source code. This technology can only be useful when it is generally available, which means being baked in to the compiler. We came really close to getting it all together for 7.10.1, but unfortunately some issues slipped through. These were picked up when Matt Pickering ran the ghc-exactrpint utliity over most of hackage, and found the remaining ones. The fixes for these are now all queued up in trac/phab with patches. If they do not go in to 7.10.2 it means waiting for 7.12 to be in general use before the tooling built from this can be used widely. The patches themselves do not change the operation of the compiler, merely re-arrange things slightly in the parsing stage, to make sure all the annotations make it through to the final ParsedSource. The two most intrusive ones are D840, which introduces new parser productions to correct a pre-existing error where `'[]` was parsed as a `HsTyVar` rather than a `HsExplicitListTy`. These have different annotations so it is a problem; and D836, which preserves the parsed `HsForAllTy` structure, including any nested `HsParTy` wrappers. This results in the original flattening code being moved out of `RdrHsSyn` into the renamer and typechecker, but does not change any of the operations. I know this places a huge burden on Austin in particular, because it requires a lot of merge operations from the number of patches. The only way I can propose to ease this is to submit a mega-patch with all the changes, which can be applied at once, once the individual ones are reviewed and found acceptable (with whatever fixes are required). The full list of Trac tickers / Phab patches follows below. Regards Alan --------------------------------------------------------- 10207 - parser: ParStmt has incorrect SrcSpan D803 (landed 7.10.2) 10214 - parser: TransStmt has incorrect SrcSpan D806 (landed 7.10.2) --- 10209 - parser: opt_kind_sig has incorrect SrcSpan D813 (landed master, scheduled 7.10.2) 10255 - API Annotations : ExprWithTySig processing discards annotated spans D823 (landed master, scheduled 7.10.2) --- 10357 - ApiAnnotations : pquals production adds AnnVbar in the wrong place D869 10358 - ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. D873 10254 - parser : the API annotation on opt_sig is being discarded D822 (landed master) 10256 - parser: API Annotations : guardquals1 does not annotate commas properly D818 (landed master) 10268 - ApiAnnotations : quoted type variables missing leading quote D825. (Accepted Austin) Depends D840/#10299 10269 - ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses D832 (Accepted Austin) Note: Potentially keep HsPar as an alternate? 10277 - ApiAnnotations : lexer discards comment close in nested comment D829 (landed master) 10280 - ApiAnnotations : AnnComma missing in TupleSection D834 (Accepted Austin) 10287 - ApiAnnotations : BooleanFormula construction discards original D837. Partial fix. Full fix by locating BooleanFormula properly. 10307 - Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected D842 10309 - ApiAnnotations : mkGadtDecl discards annotations for HsFunTy D848 10312 - ApiAnnotations: misplaced AnnComma for squals production D846 (accepted Austin) 10299 - D840: Correct parsing of lifted empty list constructor D840 --- The next four are all addressed by D836 10315 - ApiAnnotations : Empty context loses annotations D855 retired, fixed by 10354/D836 10354 - ApiAnnotations : parens around a context with wildcard loses annotations D868 - no, superseded by D836 10363 - ApiAnnotations : HsForAllTy discards parens D836 10278 - ApiAnnotations : Nested forall loses forall annotation D836 (old/alternate D833) --------------------------------------------------------- On Tue, May 5, 2015 at 1:16 PM, Simon Peyton Jones wrote: > Just to be clear, the issue is this > > * For whom is 7.10.2 mission-critical? > * And with what patches? (give specific tickets) > * And by what date? > > The only reason to make a release is because someone is stalled, or > seriously inconvenienced, unit it happens. Otherwise we should wait. So: > "+1" doesn't give enough information. Of course, the sooner the better, > the more bugs fixed the better. > > You might say "I'm waiting for API Annotations; but I'm under no time > pressure". Or "My whole business is stalled pending a fix to Trac #xxx" or > whatever. > > The whole API annotations thing is a special case. We usually make NO api > changes in a patch-level release. But the API annotations stuff is brand > new, and apparently most of the fixes depend on API changes. So I think we > are going to let them sneak in. Do we have a comprehensive list, in Trac > tickets of all the patches that are sought? > > The canonical list is > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 > Only patches that are listed as "merge" or "patch" are even being > considered. If you have something you care about that is not in that > state, can you cause it to be in that state? > > Thanks > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Matthew Pickering > | Sent: 05 May 2015 12:09 > | To: Alan & Kim Zimmerman > | Cc: ghc-devs at haskell.org > | Subject: Re: release timing > | > | +1 for the API Annotations patches. > | > | On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman > | wrote: > | > I'd love to see the various queued API Annotations diffs go in. > | > > | > Alan > | > > | > On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka > | wrote: > | >> > | >> I'd love to see GHC 7.10.2 once this haddock issue is fixed: > | >> https://github.com/haskell/haddock/issues/385 > | >> > | >> On 05/05/15 13:08, Simon Peyton Jones wrote: > | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC > | 7.10.2! > | >> > Crazy, I know, and who knows if we can pull it off.... > | >> > > | >> > > | >> > > | >> > Good plan! > | >> > > | >> > > | >> > > | >> > In Austin?s last GHC Weekly News we asked if anyone had any > | >> > constraints on the release of GHC 7.10.2. So far as I know, no > | one > | >> > replied. *So the current status is that we?ll hold it until > | >> > someone says ?getting > | >> > 7.10.2 out really matters to me?.* Other things being equal, the > | >> > longer we wait, the more fixes will be in. > | >> > > | >> > > | >> > > | >> > But does anything stand in the way of pressing the button on the > | HP > | >> > build, so that you have a HP 7.10.2 ready to go? You can always > | >> > press the button again if/when further fixes go in. > | >> > > | >> > > | >> > > | >> > Simon > | >> > > | >> > > | >> > > | >> > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf > | Of > | >> > *Mark Lentczner > | >> > *Sent:* 02 May 2015 01:57 > | >> > *To:* ghc-devs at haskell.org > | >> > *Subject:* release timing > | >> > > | >> > > | >> > > | >> > I'm wondering if ghc 7.10.2 has a rough time table yet? > | >> > > | >> > > | >> > > | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC > | 7.10.2! > | >> > Crazy, I know, and who knows if we can pull it off.... > | >> > > | >> > > | >> > > | >> > But I imagine it is about 3 or 4 week cycle for HP at this point > | >> > (still)... so a few weeks' "heads up" would be good. Thoughts? > | >> > > | >> > > | >> > > | >> > - Mark > | >> > > | >> > > | >> > > | >> > _______________________________________________ > | >> > ghc-devs mailing list > | >> > ghc-devs at haskell.org > | >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> > > | >> > | >> > | >> > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs at haskell.org > | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> > | > > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue May 5 19:44:23 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 5 May 2015 15:44:23 -0400 Subject: Tracking bugs for libraries In-Reply-To: <201505051330.07579.jan.stolarek@p.lodz.pl> References: <201505051330.07579.jan.stolarek@p.lodz.pl> Message-ID: <7D545A8B-7B51-452B-8E13-65D59090B685@gmail.com> > On May 5, 2015, at 7:30 AM, Jan Stolarek wrote: > > I just noticed that bugs for several of our libraries can either be tracked on Trac (there is a > corresponding entry in the "Component" field) or on github (issue tracking for that library is > enabled in the repo). These libraries are: directory, hoopl, old-time, pretty, process, random > and unix. I don't like the idea of spreading bug reports in two separate places, unless there is > a good reason for doing this (eg. because we actually use our own copies of these libraries). So, > is this duplication intended or accidental? > As of a couple of months ago, we updated https://wiki.haskell.org/Library_submissions to include the definitive source for where issues should be tracked on a package by package basis for all of the core libraries. As we spread maintainership of these packages around, we found more and more people preferred using github issue tracking to the legacy trac. There may well wind up with parallel trac items for some items in a separate project issue tracker, but the primary reason for such would be when ghc has to respond to an external change. Most (if not all) of the remaining duplicate issues were pushed out to the corresponding external trackers. As we clear out the remaining issues, we might look at removing these as component selections in the trac. -Edward > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mark.lentczner at gmail.com Wed May 6 03:47:02 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 5 May 2015 20:47:02 -0700 Subject: release timing In-Reply-To: References: Message-ID: On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones wrote: > *So the current status is that we?ll hold it until someone says ?getting > 7.10.2 out really matters to me?.* Other things being equal, the longer > we wait, the more fixes will be in. > This seems like a pretty ad hoc way to release a mature project. While it may be fine for GHC central to be happy living on tip-o-master until such time as someone decides to stamp a tag on it, for anyone with anything that is based on "official releases", this sort of "radioactive decay" model of releasing makes any planning and work scheduling neigh impossible. But does anything stand in the way of pressing the button on the HP build, > so that you have a HP 7.10.2 ready to go? You can always press the button > again if/when further fixes go in. > > There is a tremendous amount of contingent work that goes into the libraries that make up the HP. In order for us to beat the bushes and ensure that everything is in shape to ship with the GHC release, we need some sense of when the release is, and preferably a few weeks before hand notice. Asking all the library authors to keep their libraries up-to-date, with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is asking too much. Ideally, development would follow a schedule like this: - T -8 weeks - GHC Central announces the date of the next release (T) - T -7 weeks - HP assembles library list, puts maintainers on notice of impending release - T -4 weeks - GHC releases alpha builds, HP team does test builds, notifies library maintainers of needed updates - T -3 weeks - HP releases alpha build - T -2 weeks - GHC releases beta builds - T -1 week - HP releases beta build - T -2 days - GHC releases release candidate - T -1 day - HP releases release candidate - T - GHC & HP release at same time I can't imagine mobilizing the volunteer army any faster than that. I, for one, have to plan for weekends "off from the family" so that I can put out the final release - and these things have to be scheduled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed May 6 05:53:00 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 6 May 2015 07:53:00 +0200 Subject: Tracking bugs for libraries In-Reply-To: <7D545A8B-7B51-452B-8E13-65D59090B685@gmail.com> References: <201505051330.07579.jan.stolarek@p.lodz.pl> <7D545A8B-7B51-452B-8E13-65D59090B685@gmail.com> Message-ID: <201505060753.00900.jan.stolarek@p.lodz.pl> > As of a couple of months ago, we updated > > https://wiki.haskell.org/Library_submissions > > to include the definitive source for where issues should be tracked on a > package by package basis for all of the core libraries. As we spread > maintainership of these packages around, we found more and more people > preferred using github issue tracking to the legacy trac. That makes perfect sense. Thanks for clarifying. However, Hoopl is not included on the wiki page. Is that accidental or intentional omission? Janek > > There may well wind up with parallel trac items for some items in a > separate project issue tracker, but the primary reason for such would be > when ghc has to respond to an external change. Most (if not all) of the > remaining duplicate issues were pushed out to the corresponding external > trackers. > > As we clear out the remaining issues, we might look at removing these as > component selections in the trac. > > -Edward > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From ekmett at gmail.com Wed May 6 06:47:46 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 6 May 2015 02:47:46 -0400 Subject: Tracking bugs for libraries In-Reply-To: <201505060753.00900.jan.stolarek@p.lodz.pl> References: <201505051330.07579.jan.stolarek@p.lodz.pl> <7D545A8B-7B51-452B-8E13-65D59090B685@gmail.com> <201505060753.00900.jan.stolarek@p.lodz.pl> Message-ID: Hoopl didn't exist when the page was first created. I'm not sure if it should be considered a "core library" or not, honestly. If so, then it probably belongs on that page. If not, then it is probably worth documenting more clearly somewhere where its issues are tracked. -Edward On Wed, May 6, 2015 at 1:53 AM, Jan Stolarek wrote: > > As of a couple of months ago, we updated > > > > https://wiki.haskell.org/Library_submissions > > > > to include the definitive source for where issues should be tracked on a > > package by package basis for all of the core libraries. As we spread > > maintainership of these packages around, we found more and more people > > preferred using github issue tracking to the legacy trac. > That makes perfect sense. Thanks for clarifying. However, Hoopl is not > included on the wiki page. > Is that accidental or intentional omission? > > Janek > > > > > > There may well wind up with parallel trac items for some items in a > > separate project issue tracker, but the primary reason for such would be > > when ghc has to respond to an external change. Most (if not all) of the > > remaining duplicate issues were pushed out to the corresponding external > > trackers. > > > > As we clear out the remaining issues, we might look at removing these as > > component selections in the trac. > > > > -Edward > > > > > Janek > > > > > > --- > > > Politechnika ??dzka > > > Lodz University of Technology > > > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > adresata. > > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej > usuni?cie. > > > > > > This email contains information intended solely for the use of the > > > individual to whom it is addressed. If you are not the intended > recipient > > > or if you have received this message in error, please notify the sender > > > and delete it from your system. > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. > If you are not the intended recipient or if you have received this message > in error, > please notify the sender and delete it from your system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed May 6 08:22:32 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 06 May 2015 10:22:32 +0200 Subject: RFC re #10196 & GHC 7.10.2: Allow Unicode Lm category for 2nd+ character on in identifiers Message-ID: <87egmu6rp3.fsf@gnu.org> Hello *, As you may be aware, GHC 7.10.1 updated its Unicode catalog to version 7.0, thereby causing some subscript symbols to change character properties, thereby causing GHC 7.10.1 to reject some Unicode-subscript characters that GHC 7.8.4 accepted. See https://ghc.haskell.org/trac/ghc/ticket/10196 for specific examples. In order to address this regression, one suggestion is to allow characters in the 'Letter, Modifier' category[1] from the 2nd position on in an identifier. This however may do more than just fix the regression, as it looks from [1] that it would allow many more new identifiers than were previously possible. So, is allowing 'Lm'-chars the the 2nd+ characters in an identifier a sensible change for addressing #10196 or not. If it's a bad idea, are there other suggestions worth considering? [1]: http://www.fileformat.info/info/unicode/category/Lm/list.htm Cheers, hvr From simonpj at microsoft.com Wed May 6 09:45:02 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 May 2015 09:45:02 +0000 Subject: Tracking bugs for libraries In-Reply-To: References: <201505051330.07579.jan.stolarek@p.lodz.pl> <7D545A8B-7B51-452B-8E13-65D59090B685@gmail.com> <201505060753.00900.jan.stolarek@p.lodz.pl> Message-ID: well, according to the page, Hoopl would come under clause (3) of what a ?core library? is; GHC depends on it. So yes, it should be in the table. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett Sent: 06 May 2015 07:48 To: Jan Stolarek Cc: ghc-devs at haskell.org Subject: Re: Tracking bugs for libraries Hoopl didn't exist when the page was first created. I'm not sure if it should be considered a "core library" or not, honestly. If so, then it probably belongs on that page. If not, then it is probably worth documenting more clearly somewhere where its issues are tracked. -Edward On Wed, May 6, 2015 at 1:53 AM, Jan Stolarek > wrote: > As of a couple of months ago, we updated > > https://wiki.haskell.org/Library_submissions > > to include the definitive source for where issues should be tracked on a > package by package basis for all of the core libraries. As we spread > maintainership of these packages around, we found more and more people > preferred using github issue tracking to the legacy trac. That makes perfect sense. Thanks for clarifying. However, Hoopl is not included on the wiki page. Is that accidental or intentional omission? Janek > > There may well wind up with parallel trac items for some items in a > separate project issue tracker, but the primary reason for such would be > when ghc has to respond to an external change. Most (if not all) of the > remaining duplicate issues were pushed out to the corresponding external > trackers. > > As we clear out the remaining issues, we might look at removing these as > component selections in the trac. > > -Edward > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 6 09:58:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 May 2015 09:58:10 +0000 Subject: release timing In-Reply-To: References: Message-ID: <1193432dbd5a48ffaeb703103aea2ebc@DB4PR30MB030.064d.mgd.msft.net> Mark Good points but: ? If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it?s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release. ? The tremendous amount of contingent work for HP should be orders of magnitude less for a patch-level release. Remember, there are supposed to be no API changes, just bug fixes. So if it worked with 7.10.1, it should work with 7.10.2. That?s why I said ?press the button?. Suppose you did just do the automated build with exact same libraries as you currently have for 7.10.1. If that doesn?t work, that?s interesting? it?s not supposed to happen. And it would be good to know if it does. So I think there should be precisely zero work for library authors to stay abreast of 7.10.2 Does that help? I?m sure I?m misunderstanding something important ? apologies if so. Simon From: Mark Lentczner [mailto:mark.lentczner at gmail.com] Sent: 06 May 2015 04:47 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: release timing On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones > wrote: So the current status is that we?ll hold it until someone says ?getting 7.10.2 out really matters to me?. Other things being equal, the longer we wait, the more fixes will be in. This seems like a pretty ad hoc way to release a mature project. While it may be fine for GHC central to be happy living on tip-o-master until such time as someone decides to stamp a tag on it, for anyone with anything that is based on "official releases", this sort of "radioactive decay" model of releasing makes any planning and work scheduling neigh impossible. But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in. There is a tremendous amount of contingent work that goes into the libraries that make up the HP. In order for us to beat the bushes and ensure that everything is in shape to ship with the GHC release, we need some sense of when the release is, and preferably a few weeks before hand notice. Asking all the library authors to keep their libraries up-to-date, with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is asking too much. Ideally, development would follow a schedule like this: * T -8 weeks - GHC Central announces the date of the next release (T) * T -7 weeks - HP assembles library list, puts maintainers on notice of impending release * T -4 weeks - GHC releases alpha builds, HP team does test builds, notifies library maintainers of needed updates * T -3 weeks - HP releases alpha build * T -2 weeks - GHC releases beta builds * T -1 week - HP releases beta build * T -2 days - GHC releases release candidate * T -1 day - HP releases release candidate * T - GHC & HP release at same time I can't imagine mobilizing the volunteer army any faster than that. I, for one, have to plan for weekends "off from the family" so that I can put out the final release - and these things have to be scheduled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed May 6 10:08:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 6 May 2015 12:08:52 +0200 Subject: release timing In-Reply-To: <1193432dbd5a48ffaeb703103aea2ebc@DB4PR30MB030.064d.mgd.msft.net> References: <1193432dbd5a48ffaeb703103aea2ebc@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On the automated build front, there are now nightly builds for 7.10.1 on stackage [1]. Running a stackage instance with 7.10.2 could serve as a good confirmation test prior to release. Alan [1] https://www.stackage.org/nightly/2015-05-05 On Wed, May 6, 2015 at 11:58 AM, Simon Peyton Jones wrote: > Mark > > > > Good points but: > > ? If literally no one actually finds the absence of 7.10.2 a > problem, we could save a lot of work (for you) by not releasing it! I > think it?s reasonable to have some evidence of need before investing the > effort (for both GHC and HP) needed for a release. > > ? The tremendous amount of contingent work for HP should be > orders of magnitude less for a patch-level release. Remember, there are > supposed to be *no API changes*, just bug fixes. So if it worked with > 7.10.1, it should work with 7.10.2. That?s why I said ?press the button?. > Suppose you did just do the automated build with exact same libraries as > you currently have for 7.10.1. If that *doesn?t* work, that?s > interesting? it?s not supposed to happen. And it would be good to know if > it does. > > So I think there should be precisely zero work for library authors to stay > abreast of 7.10.2 > > Does that help? I?m sure I?m misunderstanding something important ? > apologies if so. > > Simon > > > > *From:* Mark Lentczner [mailto:mark.lentczner at gmail.com] > *Sent:* 06 May 2015 04:47 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: release timing > > > > > > On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones > wrote: > > *So the current status is that we?ll hold it until someone says ?getting > 7.10.2 out really matters to me?.* Other things being equal, the longer > we wait, the more fixes will be in. > > > > This seems like a pretty ad hoc way to release a mature project. While it > may be fine for GHC central to be happy living on tip-o-master until such > time as someone decides to stamp a tag on it, for anyone with anything that > is based on "official releases", this sort of "radioactive decay" model of > releasing makes any planning and work scheduling neigh impossible. > > > > But does anything stand in the way of pressing the button on the HP build, > so that you have a HP 7.10.2 ready to go? You can always press the button > again if/when further fixes go in. > > > > There is a tremendous amount of contingent work that goes into the > libraries that make up the HP. In order for us to beat the bushes and > ensure that everything is in shape to ship with the GHC release, we need > some sense of when the release is, and preferably a few weeks before hand > notice. Asking all the library authors to keep their libraries up-to-date, > with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is > asking too much. > > > > Ideally, development would follow a schedule like this: > > - T -8 weeks - GHC Central announces the date of the next release (T) > - T -7 weeks - HP assembles library list, puts maintainers on notice > of impending release > - T -4 weeks - GHC releases alpha builds, HP team does test builds, > notifies library maintainers of needed updates > - T -3 weeks - HP releases alpha build > - T -2 weeks - GHC releases beta builds > - T -1 week - HP releases beta build > - T -2 days - GHC releases release candidate > - T -1 day - HP releases release candidate > - T - GHC & HP release at same time > > I can't imagine mobilizing the volunteer army any faster than that. I, > for one, have to plan for weekends "off from the family" so that I can put > out the final release - and these things have to be scheduled. > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed May 6 11:08:03 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 06 May 2015 13:08:03 +0200 Subject: RFC: "Native -XCPP" Proposal Message-ID: <87zj5i55gs.fsf@gmail.com> Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics? From jan.stolarek at p.lodz.pl Wed May 6 11:38:16 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 6 May 2015 13:38:16 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: <201505061338.16090.jan.stolarek@p.lodz.pl> One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here: https://lists.chalmers.se/pipermail/agda/2014/006975.html and twice as more on my private inbox. We've reached no conclusion about the cause and the only solution was to use system-cpp. Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Janek [1] http://projects.haskell.org/cpphs/ Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: > Hello *, > > As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > currently relies on the system's C-compiler bundled `cpp` program to > provide a "traditional mode" c-preprocessor. > > This has caused several problems in the past, since parsing Haskell code > with a preprocessor mode designed for use with C's tokenizer has caused > already quite some problems[1] in the past. I'd like to see GHC 7.12 > adopt an implemntation of `-XCPP` that does not rely on the shaky > system-`cpp` foundation. To this end I've created a wiki page > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > to describe the actual problems in more detail, and a couple of possible > ways forward. Ideally, we'd simply integrate `cpphs` into GHC > (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > discussed and debated since affects the overall-license of the GHC > code-base, which may or may not be a problem to GHC's user-base (and > that's what I hope this discussion will help to find out). > > So please go ahead and read the Wiki page... and then speak your mind! > > > Thanks, > HVR > > > [1]: ...does anybody remember the issues Haskell packages (& GHC) > encountered when Apple switched to the Clang tool-chain, thereby > causing code using `-XCPP` to suddenly break due to subtly > different `cpp`-semantics? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From austin at well-typed.com Wed May 6 12:25:54 2015 From: austin at well-typed.com (Austin Seipp) Date: Wed, 6 May 2015 07:25:54 -0500 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel wrote: > Hello *, > > As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > currently relies on the system's C-compiler bundled `cpp` program to > provide a "traditional mode" c-preprocessor. > > This has caused several problems in the past, since parsing Haskell code > with a preprocessor mode designed for use with C's tokenizer has caused > already quite some problems[1] in the past. I'd like to see GHC 7.12 > adopt an implemntation of `-XCPP` that does not rely on the shaky > system-`cpp` foundation. To this end I've created a wiki page > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > to describe the actual problems in more detail, and a couple of possible > ways forward. Ideally, we'd simply integrate `cpphs` into GHC > (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > discussed and debated since affects the overall-license of the GHC > code-base, which may or may not be a problem to GHC's user-base (and > that's what I hope this discussion will help to find out). > > So please go ahead and read the Wiki page... and then speak your mind! Thanks for writing this up, btw! It's nice to put the mumblings we've had for a while down 'on paper'. > > Thanks, > HVR > > > [1]: ...does anybody remember the issues Haskell packages (& GHC) > encountered when Apple switched to the Clang tool-chain, thereby > causing code using `-XCPP` to suddenly break due to subtly > different `cpp`-semantics? There are two (major) differences I can list, although I can only provide some specific examples OTTOMH: 1) Clang is more strict wrt language specifications. For example, GCC is lenient and allows a space between a macro identifier and the parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid with GCC (where FOO is a macro), but not with Clang. Sometimes this trips up existing code, but I've mostly seen it in GHC itself. 2) The lexing rules for C and Haskell simply are not the same in general. For example, what should "FOO(a' + b')" parse to? Well, in Haskell, 'prime' is a valid component from an identifier and in this case the parse should be "a prime + b prime", but in C the ' character is identified as beginning the start of a single-character literal, and a strict preprocessor like Clang's will reject that. In practice, I think people have mostly just avoided arcane lexer behaviors that don't work, and the only reason this was never a problem was because GCC or some variant was always the 'standard' C compiler GHC could rely on. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From the.dead.shall.rise at gmail.com Wed May 6 13:03:38 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 6 May 2015 15:03:38 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On 6 May 2015 at 14:25, Austin Seipp wrote: > 2) The lexing rules for C and Haskell simply are not the same in > general. One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP. From alan.zimm at gmail.com Wed May 6 13:05:01 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 6 May 2015 15:05:01 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: Perhaps it makes sense to scan hackage to find all the different CPP idioms that are actually used in Haskell code, if it is a small/well-defined set it may be worth writing a simple custom preprocessor. Alan On Wed, May 6, 2015 at 3:03 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > On 6 May 2015 at 14:25, Austin Seipp wrote: > > 2) The lexing rules for C and Haskell simply are not the same in > > general. > > One area where this is irritating is that it makes it impossible to > use Haskell multiline strings together with CPP. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed May 6 13:27:29 2015 From: austin at well-typed.com (Austin Seipp) Date: Wed, 6 May 2015 08:27:29 -0500 Subject: HCAR DUE SOON: Please help edit! Message-ID: Hi *, (Apologies for the caps lock cruise-control in the title.) After sitting on it for a bit, it dawned on me today that the may HCAR report is due soon - in about two weeks! So, it's that time of the year again, and I'd like you all to take a quick glance at the page and edit some stuff in about what you're all working on, because I can't possibly keep up with it all. :) https://ghc.haskell.org/trac/ghc/wiki/Status/May15 Note that I've already put some boilerplate on the page, but some of it is old, from the last report - but some other things slipped, so maybe it's not old! The best case is you will read this page in 5 minutes and it will look OK. At worst, you may need to tweak a paragraph or write a new one - so please read and contribute! Note: I'll continue editing this page as time goes on, to prepare it for submission. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From asr at eafit.edu.co Wed May 6 13:43:03 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 6 May 2015 08:43:03 -0500 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <201505061338.16090.jan.stolarek@p.lodz.pl> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: I want to emphasize that cpphs is actively maintained as it's pointed out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The Agda team has found some cpphs bugs which have been *quickly* fixed by cpphs's author, Malcolm Wallace. Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. On 6 May 2015 at 06:38, Jan Stolarek wrote: > One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also > bring problems of its own. I, for one, have run into problems with it when installing Agda. There > is a very long thread here: > > https://lists.chalmers.se/pipermail/agda/2014/006975.html > > and twice as more on my private inbox. We've reached no conclusion about the cause and the only > solution was to use system-cpp. > > Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider > changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to > the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me > to make other arrangements." > > Janek > > [1] http://projects.haskell.org/cpphs/ > > Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: >> Hello *, >> >> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >> currently relies on the system's C-compiler bundled `cpp` program to >> provide a "traditional mode" c-preprocessor. >> >> This has caused several problems in the past, since parsing Haskell code >> with a preprocessor mode designed for use with C's tokenizer has caused >> already quite some problems[1] in the past. I'd like to see GHC 7.12 >> adopt an implemntation of `-XCPP` that does not rely on the shaky >> system-`cpp` foundation. To this end I've created a wiki page >> >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp >> >> to describe the actual problems in more detail, and a couple of possible >> ways forward. Ideally, we'd simply integrate `cpphs` into GHC >> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be >> discussed and debated since affects the overall-license of the GHC >> code-base, which may or may not be a problem to GHC's user-base (and >> that's what I hope this discussion will help to find out). >> >> So please go ahead and read the Wiki page... and then speak your mind! >> >> >> Thanks, >> HVR >> >> >> [1]: ...does anybody remember the issues Haskell packages (& GHC) >> encountered when Apple switched to the Clang tool-chain, thereby >> causing code using `-XCPP` to suddenly break due to subtly >> different `cpp`-semantics? >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Andr?s From karel.gardas at centrum.cz Wed May 6 13:56:24 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 06 May 2015 15:56:24 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: <554A1D88.2010604@centrum.cz> Herbert, what about to extend plan (1) to also include cpphs as a bundled option with all cpphs advantages except no more fork/exec as the bundle will be in a form of binary application and not library? Shall I add it? I would not like to make a mess from your page... Thanks, Karel From svenpanne at gmail.com Wed May 6 14:32:11 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 6 May 2015 16:32:11 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson : > +1, I'll wager that the vast majority of usages are just for version > range checks. The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. From spam at scientician.net Wed May 6 14:59:43 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 06 May 2015 16:59:43 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On 06-05-2015 16:32, Sven Panne wrote: > 2015-05-06 16:21 GMT+02:00 Bardur Arantsson : >> +1, I'll wager that the vast majority of usages are just for version >> range checks. > > The OpenGL-related packages used macros to generate some binding magic > (a "foreign import" plus some helper functions for each API entry), > not just range checks. I had serious trouble when Apple switched to > clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources > had been checked in. :-P Nowadays the binding is generated from the > OpenGL XML registry file, so this is not an issue anymore. Ok, so it's *not* a counterexample :). > >> If there are packages that require more, they could just keep using the >> system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd >> want to see real evidence that that's actually worth the >> effort/complication. > > Simply relying on the system CPP doesn't work due to the various > differences between GCC's CPP and the one from clang, see e.g. > https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. > Ignoring the problem doesn't make it go away... ;-) > No, but is it worth the effort? (As opposed to workarounds, such as just checking in the preprocessed file as you provided an example of.) > Note that we still need CPP to handle the various calling conventions > on the different platforms when the FFI is used, so it's not only > range checks, see e.g. > https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. > Certainly. I'm not saying *everybody* just does range checks, but I'm guessing that it's the majority of CPP users are using it just for that. (I'm not going to be doing any of the work, so this is just armchairing, but this seems like an 80/20 solution would be warranted.) Regards, From _deepfire at feelingofgreen.ru Wed May 6 15:27:58 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Wed, 06 May 2015 18:27:58 +0300 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (sfid-20150506_184520_504504_BA56311D) (Sven Panne's message of "Wed, 6 May 2015 16:32:11 +0200") References: <87zj5i55gs.fsf@gmail.com> Message-ID: <87ioc5vi81.fsf@feelingofgreen.ru> Sven Panne writes: > 2015-05-06 16:21 GMT+02:00 Bardur Arantsson : >> +1, I'll wager that the vast majority of usages are just for version >> range checks. > > The OpenGL-related packages used macros to generate some binding magic > (a "foreign import" plus some helper functions for each API entry), > not just range checks. So, metaprogramming. The question that comes to mind -- why suffer such a lousy tool as cpp for metaprogramming? Why *shouldn't* TH fill that role? What can be done about it? -- regards, ??????? ?????? From allbery.b at gmail.com Wed May 6 15:28:45 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 11:28:45 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson wrote: > (I'm not going to be doing any of the work, so this is just armchairing, > but this seems like an 80/20 solution would be warranted.) > Only if you're convinced it will remain 80/20 for the foreseeable future. I do not want to bet on Linux always being gcc (and dislike the One True Platform-ism that line of thought encourages). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed May 6 15:33:35 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 11:33:35 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87ioc5vi81.fsf@feelingofgreen.ru> References: <87zj5i55gs.fsf@gmail.com> <87ioc5vi81.fsf@feelingofgreen.ru> Message-ID: On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a "meta" in a different dimension than TH does. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From singpolyma at singpolyma.net Wed May 6 15:36:05 2015 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Wed, 6 May 2015 10:36:05 -0500 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: <20150506153605.GD1459@xobs-novena> >As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >currently relies on the system's C-compiler bundled `cpp` program to >provide a "traditional mode" c-preprocessor. Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing. This allows other Haskell compilers to support CPP on basically any system (since cpp is so standard) without much effort, or even if the compiler does not support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the source files themselves before feeding the source into the compiler. Because it is a real `cpp` being used, the developmer must take care to follow the CPP syntax in the file that will then be transformed into Haskell by `cpp` in the same way that C, C++, and other developers have to take extra care (especially around use of # and end-of-line \) when using `cpp`, but this is the normal state of affairs for a secondary preprocessor step. As a benefit, the source code will be processable by standard `cpp` implementations available for virtually every platform. In short, the current solution provides a very robust and portable way to do pre-compile preprocessing, and I like it very much. From _deepfire at feelingofgreen.ru Wed May 6 15:51:51 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Wed, 06 May 2015 18:51:51 +0300 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <20150506153605.GD1459@xobs-novena> (sfid-20150506_194906_904048_E766970C) (Stephen Paul Weber's message of "Wed, 6 May 2015 10:36:05 -0500") References: <87zj5i55gs.fsf@gmail.com> <20150506153605.GD1459@xobs-novena> Message-ID: <87a8xhvh48.fsf@feelingofgreen.ru> Stephen Paul Weber writes: >>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >>currently relies on the system's C-compiler bundled `cpp` program to >>provide a "traditional mode" c-preprocessor. > > Yes. This is one of my favourite things in GHC-land -- that an existing, > good-enough, standardised, and widely-deployed solution was chosen over a NiH > reinvention of preprocessing. (Note: here I assume that my irony detector is hopelessly broken..) At the risk of spreading dangerous novelty.. ..come on, the C preprocessor *is* a NIH reinvention of proper metaprogramming, and the word used to denote it ("preprocessing") betrays it so badly. As an example: http://www.lispworks.com/documentation/HyperSpec/Body/24_abaa.htm Why can't we make TH be more like that? -- respectfully, ??????? ?????? From hvriedel at gmail.com Wed May 6 16:09:00 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 06 May 2015 18:09:00 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <20150506153605.GD1459@xobs-novena> (Stephen Paul Weber's message of "Wed, 6 May 2015 10:36:05 -0500") References: <87zj5i55gs.fsf@gmail.com> <20150506153605.GD1459@xobs-novena> Message-ID: <87h9rp663n.fsf@gmail.com> On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote: >>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >>currently relies on the system's C-compiler bundled `cpp` program to >>provide a "traditional mode" c-preprocessor. > > Yes. This is one of my favourite things in GHC-land -- that an > existing, good-enough, standardised, and widely-deployed solution was > chosen over a NiH reinvention of preprocessing. This allows other > Haskell compilers to support CPP on basically any system (since cpp is > so standard) without much effort, or even if the compiler does not > support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the > source files themselves before feeding the source into the compiler. > > Because it is a real `cpp` being used, the developmer must take care > to follow the CPP syntax in the file that will then be transformed > into Haskell by `cpp` in the same way that C, C++, and other > developers have to take extra care (especially around use of # and > end-of-line \) when using `cpp`, but this is the normal state of > affairs for a secondary preprocessor step. As a benefit, the source > code will be processable by standard `cpp` implementations available > for virtually every platform. > > In short, the current solution provides a very robust and portable way > to do pre-compile preprocessing, and I like it very much. The problem I have with that line of argument is that we're using the so-called 'traditional mode' of `cpp`[1] for which afaik there is no written down common specification different implementations commit to adhere to (well, that's because 'traditional mode' refers to some vague implementation-specific "pre-standard" cpp semantics). And how is the developer supposed to take care to follow the (traditional mode) CPP syntax, if he can't test it easily with all potentially used (traditional-mode) `cpp`s out there? This already has led to problems with Clang's cpp vs GCC's cpp. Moreover, I was under the impression that it's only a matter of time till `traditional mode` support may be dropped from C compiler toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor, as that would conflict even more heavily w/ Haskell's grammar to the point of being inpractical. [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html From allbery.b at gmail.com Wed May 6 16:47:28 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 12:47:28 -0400 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <20150506153605.GD1459@xobs-novena> References: <87zj5i55gs.fsf@gmail.com> <20150506153605.GD1459@xobs-novena> Message-ID: On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber < singpolyma at singpolyma.net> wrote: > Yes. This is one of my favourite things in GHC-land -- that an existing, > good-enough, standardised, and widely-deployed solution was chosen over a > NiH reinvention of preprocessing I have to assume my irony detector is broken as well. Or maybe I should just assume that "all the world's Linux with gcc" is assumed to be forever true and forever reliable by "all right-thinking people" so let's just sweep the nonissue under the rug because it can oh so obviously never be a real issue.... Because I had to face this back a couple decades ago, when my employer ported an application written in a 4GL (database language) to SCO Unix. The 4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO used one integrated into its lexer (making it even more tightly wedded to C syntax than clang's). Eventually we replaced its cpp with a wrapper that ran m4 and redid everything else in m4's syntax. Which is why I was always a bit worried about ghc relying on cpp, was unsurprised when clang caused issues, and am rather annoyed that there are people who believe that they can just ignore it because REAL users will always be on Linux with gcc and all them furriners using weird OSes like OS X and FreeBSD can safely be ignored with their not-the-One-True-OS-and-compiler platforms. Additional historical note that I assume True Believers will ignore as meaningless: X11 used to make the same assumption that cpp was always and forever guaranteed to be friendly to non-C and this still shows at times in things like xrdb resource databases. They did accept the inevitable and (mostly) stop abusing it that way, and are now moving away from imake which likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter the same inability to comprehend or accept change there.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Wed May 6 16:53:08 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 6 May 2015 16:53:08 +0000 (UTC) Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87a8xhvh48.fsf@feelingofgreen.ru> References: <87a8xhvh48.fsf@feelingofgreen.ru> Message-ID: <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> At the risk of antagonizing some (most? all?) of you, how about... -XCPP stands for the native CPP -XGNUCPP stands for GNU's GCC CPP -XClangCPP stands for Clang's CPP -XCPPHS stands for CPPHS ... with the hope that TH is the future? Howard From george.colpitts at gmail.com Wed May 6 18:02:09 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 6 May 2015 15:02:09 -0300 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: References: Message-ID: In my opinion it would be great if somebody could add the LLVM work to the "Upcoming plans for the next release" section Thanks On Wed, May 6, 2015 at 10:27 AM, Austin Seipp wrote: > Hi *, > > (Apologies for the caps lock cruise-control in the title.) > > After sitting on it for a bit, it dawned on me today that the may HCAR > report is due soon - in about two weeks! > > So, it's that time of the year again, and I'd like you all to take a > quick glance at the page and edit some stuff in about what you're all > working on, because I can't possibly keep up with it all. :) > > https://ghc.haskell.org/trac/ghc/wiki/Status/May15 > > Note that I've already put some boilerplate on the page, but some of > it is old, from the last report - but some other things slipped, so > maybe it's not old! > > The best case is you will read this page in 5 minutes and it will look > OK. At worst, you may need to tweak a paragraph or write a new one - > so please read and contribute! > > Note: I'll continue editing this page as time goes on, to prepare it > for submission. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Wed May 6 19:26:39 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 06 May 2015 20:26:39 +0100 Subject: release timing In-Reply-To: <55489878.5060602@ro-che.info> References: <55489878.5060602@ro-che.info> Message-ID: <554A6AEF.6040104@fuuzetsu.co.uk> On 05/05/2015 11:16 AM, Roman Cheplyaka wrote: > I'd love to see GHC 7.10.2 once this haddock issue is fixed: > https://github.com/haskell/haddock/issues/385 > There's a PR for it sitting on GitHub[1]. I did not have time to test it but if you want to go ahead and give it a quick look, I'd be happy to merge it if you give it an OK. [1]: https://github.com/haskell/haddock/pull/386 -- Mateusz K. From jan.stolarek at p.lodz.pl Wed May 6 19:55:56 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 6 May 2015 21:55:56 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: <201505062155.56858.jan.stolarek@p.lodz.pl> > I want to emphasize that cpphs is actively maintained as it's pointed > out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The > Agda team has found some cpphs bugs which have been *quickly* fixed by > cpphs's author, Malcolm Wallace. Yes. It was not my intention to imply in any way that cpphs suffers from maintanance issues. > Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale settings although we were unable to track down the cause. I also recall someone else reported being affected by the same problem. So, until that problem is solved I would say it is a blocker as it would essentialy make development of GHC impossible for some people. Janek > > On 6 May 2015 at 06:38, Jan Stolarek wrote: > > One thing to keep in mind is that while cpphs will solve some problems of > > system-cpp, it will also bring problems of its own. I, for one, have run > > into problems with it when installing Agda. There is a very long thread > > here: > > > > https://lists.chalmers.se/pipermail/agda/2014/006975.html > > > > and twice as more on my private inbox. We've reached no conclusion about > > the cause and the only solution was to use system-cpp. > > > > Regarding licensing issues: perhaps we should simply ask Malcolm Wallace > > if he would consider changing the license for the sake of GHC? Or perhaps > > he could grant a custom-tailored license to the GHC project? After all, > > the project page [1] says: " If that's a problem for you, contact me to > > make other arrangements." > > > > Janek > > > > [1] http://projects.haskell.org/cpphs/ > > > > Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: > >> Hello *, > >> > >> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > >> currently relies on the system's C-compiler bundled `cpp` program to > >> provide a "traditional mode" c-preprocessor. > >> > >> This has caused several problems in the past, since parsing Haskell code > >> with a preprocessor mode designed for use with C's tokenizer has caused > >> already quite some problems[1] in the past. I'd like to see GHC 7.12 > >> adopt an implemntation of `-XCPP` that does not rely on the shaky > >> system-`cpp` foundation. To this end I've created a wiki page > >> > >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > >> > >> to describe the actual problems in more detail, and a couple of possible > >> ways forward. Ideally, we'd simply integrate `cpphs` into GHC > >> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > >> discussed and debated since affects the overall-license of the GHC > >> code-base, which may or may not be a problem to GHC's user-base (and > >> that's what I hope this discussion will help to find out). > >> > >> So please go ahead and read the Wiki page... and then speak your mind! > >> > >> > >> Thanks, > >> HVR > >> > >> > >> [1]: ...does anybody remember the issues Haskell packages (& GHC) > >> encountered when Apple switched to the Clang tool-chain, thereby > >> causing code using `-XCPP` to suddenly break due to subtly > >> different `cpp`-semantics? > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From asr at eafit.edu.co Wed May 6 21:47:50 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 6 May 2015 16:47:50 -0500 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <201505062155.56858.jan.stolarek@p.lodz.pl> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <201505062155.56858.jan.stolarek@p.lodz.pl> Message-ID: Hi Janek, On 6 May 2015 at 14:55, Jan Stolarek wrote: > Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale > settings although we were unable to track down the cause. I also recall someone else reported > being affected by the same problem. AFIK, the only cpphs-Agda open problem is your problem. I would like to know if anyone else has some problem. If so, I propose to move the discussion to the Agda developers list (agda-dev at lists.chalmers.se). Best, -- Andr?s From tkn.akio at gmail.com Thu May 7 00:38:30 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Thu, 7 May 2015 09:38:30 +0900 Subject: release timing In-Reply-To: <114f7cc39f5746479c3856c281fc27fd@DB4PR30MB030.064d.mgd.msft.net> References: <55489878.5060602@ro-che.info> <114f7cc39f5746479c3856c281fc27fd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi, On Tue, May 5, 2015 at 8:16 PM, Simon Peyton Jones wrote: > Just to be clear, the issue is this > > * For whom is 7.10.2 mission-critical? I'd like to bring attention to the ticket https://ghc.haskell.org/trac/ghc/ticket/10380, because I imagine it affects a lot of people who use sockets. Specifically, it potentially affects all programs that (1) uses -threaded and (2) does both send and recv over one socket, simultaneously from multiple threads. That said, this isn't blocking us because we've decided to patch base ourselves. Regards, Takano Akio From carter.schonwald at gmail.com Thu May 7 00:42:32 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 May 2015 20:42:32 -0400 Subject: release timing In-Reply-To: <554A6AEF.6040104@fuuzetsu.co.uk> References: <55489878.5060602@ro-che.info> <554A6AEF.6040104@fuuzetsu.co.uk> Message-ID: I can't speak for others, but having haddock links work for me has been a large blocker on migrating my local home dev environment (i realize thats more haddock than ghc, but been a blocker for me locally :) ) likewise, https://ghc.haskell.org/trac/ghc/ticket/10317 (the bugfixes for multishot event manager) would be super useful likewise, https://ghc.haskell.org/trac/ghc/ticket/10236 makes the dwarf tooling that much more compelling thats ignoring a whole host of other fixes and issues that many awesome folks have already resolved or are currently in flight. basically, both at work (me and 2 other members of the engineering team), and in my personal work, i'm waiting for 7.10.2 before using ghc 7.10 in earnest. :) On Wednesday, May 6, 2015, Mateusz Kowalczyk wrote: > On 05/05/2015 11:16 AM, Roman Cheplyaka wrote: > > I'd love to see GHC 7.10.2 once this haddock issue is fixed: > > https://github.com/haskell/haddock/issues/385 > > > > There's a PR for it sitting on GitHub[1]. I did not have time to test it > but if you want to go ahead and give it a quick look, I'd be happy to > merge it if you give it an OK. > > [1]: https://github.com/haskell/haddock/pull/386 > > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu May 7 01:26:08 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 6 May 2015 21:26:08 -0400 Subject: release timing In-Reply-To: References: <55489878.5060602@ro-che.info> <554A6AEF.6040104@fuuzetsu.co.uk> Message-ID: to be especially specific, the event manager bug fixes alone are reason for 7.10.2 (though lots of other fixes should needs be happening too ) On Wed, May 6, 2015 at 8:42 PM, Carter Schonwald wrote: > I can't speak for others, but having haddock links work for me has been a > large blocker on migrating my local home dev environment (i realize thats > more haddock than ghc, but been a blocker for me locally :) ) > > likewise, https://ghc.haskell.org/trac/ghc/ticket/10317 (the bugfixes for > multishot event manager) would be super useful > > likewise, https://ghc.haskell.org/trac/ghc/ticket/10236 makes the dwarf > tooling that much more compelling > > thats ignoring a whole host of other fixes and issues that many awesome > folks have already resolved or are currently in flight. > > basically, both at work (me and 2 other members of the engineering team), > and in my personal work, i'm waiting for 7.10.2 before using ghc 7.10 in > earnest. :) > > > On Wednesday, May 6, 2015, Mateusz Kowalczyk > wrote: > >> On 05/05/2015 11:16 AM, Roman Cheplyaka wrote: >> > I'd love to see GHC 7.10.2 once this haddock issue is fixed: >> > https://github.com/haskell/haddock/issues/385 >> > >> >> There's a PR for it sitting on GitHub[1]. I did not have time to test it >> but if you want to go ahead and give it a quick look, I'd be happy to >> merge it if you give it an OK. >> >> [1]: https://github.com/haskell/haddock/pull/386 >> >> >> -- >> Mateusz K. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Thu May 7 07:47:15 2015 From: voldermort at hotmail.com (Harry .) Date: Thu, 7 May 2015 07:47:15 +0000 Subject: release timing Message-ID: #10293 should go in as it's a (significant?) regression. It would be nice to see #8224 in as well, but doesn't look like that's going to be fixed any time soon! Have GHC HQ ever considered asking Intel if they'd be willing to lend a hand? From hvriedel at gmail.com Thu May 7 07:47:20 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 07 May 2015 09:47:20 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> (Howard B. Golden's message of "Wed, 6 May 2015 16:53:08 +0000 (UTC)") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> Message-ID: <87sib896d3.fsf@gnu.org> On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Assuming this was a serious suggestion, the benefit is that you could clearly mark what CPP you want to develop against, but OTOH, we'd lose backward compat w/ Haskell compilers only knowing about the old -XCPP but not the other new variants of the language-pragma. Moreover, there can now be packages that require clang-cpp, while others require gcc-cpp, and I don't think it can be assumed that both are available on every GHC installation. So it could cause packages to fail compiling simply because the respective CPP-flavor is missing. On the bright side, this would maybe give us the opportunity to coin the new term "CPP Hell" =) Cheers, hvr From simonpj at microsoft.com Thu May 7 07:52:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 07:52:10 +0000 Subject: FW: release timing In-Reply-To: References: <1193432dbd5a48ffaeb703103aea2ebc@DB4PR30MB030.064d.mgd.msft.net> Message-ID: ccing ghc-devs From: David Fox [mailto:dsf at seereason.com] Sent: 07 May 2015 03:09 To: Simon Peyton Jones Subject: Re: release timing Drat, wrong "reply to"! On Wed, May 6, 2015 at 7:08 PM, David Fox > wrote: On Wed, May 6, 2015 at 2:58 AM, Simon Peyton Jones > wrote: Mark Good points but: ? If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it?s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release.? There are fixes in 7.10.2 that are important to ghcjs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 7 07:59:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 07:59:05 +0000 Subject: release timing In-Reply-To: References: Message-ID: <45ee4958d71043a5ae35e046f1cdb527@DB4PR30MB030.064d.mgd.msft.net> | It would be nice to see #8224 in as well, but doesn't look like that's | going to be fixed any time soon! Have GHC HQ ever considered asking | Intel if they'd be willing to lend a hand? What makes you think that Intel would help with #8224? (It's about the IO manager.) Also, GHC is an open source project. You don't have to wait for GHC HQ to do anything --- please go ahead and ask anyone you think could help! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Harry | . | Sent: 07 May 2015 08:47 | To: ghc-devs at haskell.org | Subject: Re: release timing | | #10293 should go in as it's a (significant?) regression. | | It would be nice to see #8224 in as well, but doesn't look like that's | going to be fixed any time soon! Have GHC HQ ever considered asking | Intel if they'd be willing to lend a hand? | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mle+hs at mega-nerd.com Thu May 7 08:20:51 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 7 May 2015 18:20:51 +1000 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150507182051.43b2dd317f272fc80fda5c84@mega-nerd.com> Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Oh please no! If someone releases a package on Hackage that uses -XGNUCPP, that will likely break on OSX because on OSX, gcc is actually clang. > ... with the hope that TH is the future? I suspect there will always be things that CPP does better than TH. What we need is a better CPP. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Thu May 7 09:28:59 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 7 May 2015 19:28:59 +1000 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: References: Message-ID: <20150507192859.69ad4429199eba8ed321c53e@mega-nerd.com> Austin Seipp wrote: > After sitting on it for a bit, it dawned on me today that the may HCAR > report is due soon - in about two weeks! Is the recent work on Arm and Arm64 worth mentioning? For Arm, I'm hoping that 7.10.2 will work out of the box for arm/linux but fixes for #10368, #10375 and #10376 are still outstanding. For Arm64, I'm hoping 7.12.1 will work as well for arm64/linux as it does for 32 bit arm/linux. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From voldermort at hotmail.com Thu May 7 09:45:17 2015 From: voldermort at hotmail.com (Harry .) Date: Thu, 7 May 2015 09:45:17 +0000 Subject: release timing In-Reply-To: <45ee4958d71043a5ae35e046f1cdb527@DB4PR30MB030.064d.mgd.msft.net> References: , <45ee4958d71043a5ae35e046f1cdb527@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon PJ wrote ... > > | It would be nice to see #8224 in as well, but doesn't look like that's > | going to be fixed any time soon! Have GHC HQ ever considered asking > | Intel if they'd be willing to lend a hand? > > What makes you think that Intel would help with #8224? (It's about the IO manager.) The title is about the IO manager :-) The diagnosis ends with performance issues that appear tied to CPU design, something that Intel ought to know something about. > Also, GHC is an open source project. You don't have to wait for GHC HQ to do anything --- please go ahead and ask anyone you think could help! While it's not unheard of for a corporation to assist an open source project, particularly with issues specific to their products, the request would have a lot more credibility if it came from GHC HQ than a random GHC user. I also have no idea who in Intel should be contacted for such things. But in the spirit of your suggestion I'm cross-posting this to haskell-cafe to reach a wider audience. Does anyone out there know of a contact in Intel who might be able/willing to help with CPU performance issues? From simonpj at microsoft.com Thu May 7 12:24:18 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 12:24:18 +0000 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: <20150507192859.69ad4429199eba8ed321c53e@mega-nerd.com> References: <20150507192859.69ad4429199eba8ed321c53e@mega-nerd.com> Message-ID: By all means! Go ahead and add it! S | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Erik de | Castro Lopo | Sent: 07 May 2015 10:29 | To: ghc-devs at haskell.org | Subject: Re: HCAR DUE SOON: Please help edit! | | Austin Seipp wrote: | | > After sitting on it for a bit, it dawned on me today that the may HCAR | > report is due soon - in about two weeks! | | Is the recent work on Arm and Arm64 worth mentioning? | | For Arm, I'm hoping that 7.10.2 will work out of the box for arm/linux | but fixes for #10368, #10375 and #10376 are still outstanding. | | For Arm64, I'm hoping 7.12.1 will work as well for arm64/linux as it | does for 32 bit arm/linux. | | Erik | -- | ---------------------------------------------------------------------- | Erik de Castro Lopo | http://www.mega-nerd.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu May 7 15:40:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 15:40:53 +0000 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: References: Message-ID: <7975ca810ec3484ab143b19b551d340c@DB4PR30MB030.064d.mgd.msft.net> Alan: could you add a bullet to the GHC 7.10 section about API annotations? Link to the relevant wiki page! Thanks! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 06 May 2015 14:27 | To: ghc-devs at haskell.org | Subject: HCAR DUE SOON: Please help edit! | | Hi *, | | (Apologies for the caps lock cruise-control in the title.) | | After sitting on it for a bit, it dawned on me today that the may HCAR | report is due soon - in about two weeks! | | So, it's that time of the year again, and I'd like you all to take a | quick glance at the page and edit some stuff in about what you're all | working on, because I can't possibly keep up with it all. :) | | https://ghc.haskell.org/trac/ghc/wiki/Status/May15 | | Note that I've already put some boilerplate on the page, but some of | it is old, from the last report - but some other things slipped, so | maybe it's not old! | | The best case is you will read this page in 5 minutes and it will look | OK. At worst, you may need to tweak a paragraph or write a new one - | so please read and contribute! | | Note: I'll continue editing this page as time goes on, to prepare it | for submission. | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From randyhaskell at outlook.com Thu May 7 16:29:34 2015 From: randyhaskell at outlook.com (Randy Polen) Date: Thu, 7 May 2015 09:29:34 -0700 Subject: release timing Message-ID: For the sake of the Haskell Platform users, I hope 7.10.2 will include the following fixes in the accompanying haddock and cabal. * Support for haddock response files to handle very long command lines (Windows) * https://github.com/haskell/cabal/pull/2512 * https://github.com/haskell/cabal/issues/1681 * https://github.com/haskell/haddock/issues/285 * https://github.com/haskell/haddock/issues/379 * Correct the cross-package links for all haddock-generated documentation (All) * https://github.com/haskell/haddock/issues/385 * https://ghc.haskell.org/trac/ghc/ticket/10206 The shenanigans I did to get the Windows HP built using a hacked up cabal and haddock were not appropriate for a release (and so I never released my builds of the HP 2015.2.0.0 on the Windows platform). On top of that, once I finally got it all to build in this uncomfortable, un-reproducible way (e.g., hacked PATH to hacked binaries), I noticed all the cross-package and index links in the docs were wrong, which sealed the deal (as far as I was concerned) to not release it. I hope that the solutions to these two issues can be incorporated into 7.10.2, so that build process for the Windows HP will be worthy and suitable for such a release, and so that the documentation links will be correct and useful to the users. Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu May 7 19:02:53 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 7 May 2015 21:02:53 +0200 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: <7975ca810ec3484ab143b19b551d340c@DB4PR30MB030.064d.mgd.msft.net> References: <7975ca810ec3484ab143b19b551d340c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Will do. I was just about to send a mail to ask if I should. Alan On Thu, May 7, 2015 at 5:40 PM, Simon Peyton Jones wrote: > Alan: could you add a bullet to the GHC 7.10 section about API > annotations? Link to the relevant wiki page! > > Thanks! > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin > | Seipp > | Sent: 06 May 2015 14:27 > | To: ghc-devs at haskell.org > | Subject: HCAR DUE SOON: Please help edit! > | > | Hi *, > | > | (Apologies for the caps lock cruise-control in the title.) > | > | After sitting on it for a bit, it dawned on me today that the may HCAR > | report is due soon - in about two weeks! > | > | So, it's that time of the year again, and I'd like you all to take a > | quick glance at the page and edit some stuff in about what you're all > | working on, because I can't possibly keep up with it all. :) > | > | https://ghc.haskell.org/trac/ghc/wiki/Status/May15 > | > | Note that I've already put some boilerplate on the page, but some of > | it is old, from the last report - but some other things slipped, so > | maybe it's not old! > | > | The best case is you will read this page in 5 minutes and it will look > | OK. At worst, you may need to tweak a paragraph or write a new one - > | so please read and contribute! > | > | Note: I'll continue editing this page as time goes on, to prepare it > | for submission. > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu May 7 19:54:51 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 07 May 2015 21:54:51 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <201505061338.16090.jan.stolarek@p.lodz.pl> (Jan Stolarek's message of "Wed, 6 May 2015 13:38:16 +0200") References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: <87h9ro5fjo.fsf@gnu.org> On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] > Regarding licensing issues: perhaps we should simply ask Malcolm > Wallace if he would consider changing the license for the sake of GHC? > Or perhaps he could grant a custom-tailored license to the GHC > project? After all, the project page [1] says: " If that's a problem > for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 From simonpj at microsoft.com Thu May 7 20:34:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 20:34:05 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Dear Cabal developers I guess everyone is busy, but I feel a bit stuck on knowing how to make progress on this thread. Thanks Simon From: Simon Peyton Jones Sent: 20 April 2015 09:12 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: RE: Cabal and simultaneous installations of the same package Friends We started this thread (below) a month ago, but it has once more run out of steam. The last contribution was from Vishal Agrawal I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. Can you review the proposal and give me suggestions. I don't feel qualified to drive this process, but I do think it's important to complete it. (I might be wrong about this too... please say so if so.) Nor do I understand why it's difficult to tie up the bow; the underlying infrastructure work is done. Duncan especially: how can we make progress? Do you think it's important to make progress, or are other things in cabal-land more important? My reason for thinking that it's important is that it appears to be the root cause of many people's difficulties with Haskell and Cabal. It might not be a panacea for all ills; but it might be a cheap remedy for a significant proportion of ills. And that would be a Good Thing. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Peyton Jones | Sent: 23 March 2015 08:46 | To: cabal-devel at haskell.org | Cc: haskell-platform at projects.haskell.org; haskell- | infrastructure at community.galois.com; Haskell Libraries; ghc- | devs at haskell.org | Subject: Cabal and simultaneous installations of the same package | | Dear Cabal developers | | You'll probably have seen the thread about the Haskell Platform. | | Among other things, this point arose: | | | Another thing we should fix is the (now false) impression that HP | | gets in the way of installing other packages and versions due to | cabal hell. | | People mean different things by "cabal hell", but the inability to | simultaneously install multiple versions of the same package, | compiled against different dependencies is certainly one of them, | and I think it is the one that Yitzchak is referring to here. | | But some time now GHC has allowed multiple versions of the same package | (compiled against different dependencies) to be installed | simultaneously. So all we need to do is to fix Cabal to allow it too, | and thereby kill of a huge class of cabal-hell problems at one blow. | | But time has passed and it hasn't happened. Is this because I'm | misunderstanding? Or because it is harder than I think? Or because | there are much bigger problems? Or because there is insufficient | effort available? Or what? | | Unless I'm way off beam, this "multiple installations of the same | package" thing has been a huge pain forever, and the solution is within | our grasp. What's stopping us grasping it? | | Simon | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Thu May 7 20:41:22 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 07 May 2015 21:41:22 +0100 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <87h9ro5fjo.fsf@gnu.org> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> Message-ID: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > [...] > >> Regarding licensing issues: perhaps we should simply ask Malcolm >> Wallace if he would consider changing the license for the sake of GHC? >> Or perhaps he could grant a custom-tailored license to the GHC >> project? After all, the project page [1] says: " If that's a problem >> for you, contact me to make other arrangements." > > Fyi, Neil talked to him[1]: > > | I talked to Malcolm. His contention is that it doesn't actually change > | the license of the ghc package. As such, it's just a single extra > | license to add to a directory full of licenses, which is no big deal. > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 From the.dead.shall.rise at gmail.com Thu May 7 21:19:46 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 7 May 2015 23:19:46 +0200 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 7 May 2015 at 22:34, Simon Peyton Jones wrote: > Dear Cabal developers > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > progress on this thread. Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have to wait and see what comes out of it now. From gershomb at gmail.com Thu May 7 21:28:32 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 7 May 2015 17:28:32 -0400 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: For the info of all, here is the proposal: https://gist.github.com/fugyk/37510958b52589737274 The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project proceeds, Vishal will be checking in with us, asking questions and seeking clarification where necessary, etc. --Gershom On Thu, May 7, 2015 at 5:19 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > On 7 May 2015 at 22:34, Simon Peyton Jones wrote: > > Dear Cabal developers > > > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > > progress on this thread. > > Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have > to wait and see what comes out of it now. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petersen at fedoraproject.org Fri May 8 01:48:57 2015 From: petersen at fedoraproject.org (Jens Petersen) Date: Fri, 8 May 2015 10:48:57 +0900 Subject: release timing In-Reply-To: References: Message-ID: On 5 May 2015 at 19:08, Simon Peyton Jones wrote: > In Austin?s last GHC Weekly News we asked if anyone had any constraints on > the release of GHC 7.10.2. So far as I know, no one replied. So the > current status is that we?ll hold it until someone says ?getting 7.10.2 out > really matters to me?. Other things being equal, the longer we wait, the > more fixes will be in. For Fedora 23, I would really like to ship ghc-7.10 with as many bugfixes as possible. So shipping 7.10.2 sounds much better to me than 7.10.1. eg It should include various aarch64 fixes assuming they all get reviewed in time. https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.10.2 But while Fedora 22 (with ghc-7.8.4) is about to be released this month, there is actually very little time left to fix the ghc version for Fedora 23. It needs to be finalized and built by next month basically to fit into the schedule. So a release this month would be very helpful. Jens From malcolm.wallace at me.com Fri May 8 06:07:56 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 08 May 2015 07:07:56 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> Message-ID: <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm From malcolm.wallace at me.com Fri May 8 06:10:22 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 08 May 2015 07:10:22 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> Message-ID: <567D3794-E088-45A1-8687-A877D47F59C1@me.com> Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From c.maeder at jacobs-university.de Fri May 8 07:50:46 2015 From: c.maeder at jacobs-university.de (Christian Maeder) Date: Fri, 8 May 2015 09:50:46 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> Message-ID: <554C6AD6.2090103@jacobs-university.de> Hi, using cpphs is the right way to go! Rewriting it from scratch may be a good exercise but is (essentially) a waste of time. However, always asking Malcolm to get source changes into cpphs would be annoying. Therefore it would be great if the sources were just part of the ghc sources (under git). Another "problem" might be the dependency "polyparse" that is currently not part of the core libraries. (I guess that replacing polyparse by something else would also be a nice exercise.) So (for me) the only question is, if Malcolm is willing to transfer control over cpphs to the haskell-community (or ghc head) - of course with due acknowledgements! Cheers Christian On 08.05.2015 08:07, Malcolm Wallace wrote: > > On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > >> I think it's important that there be *one* >> "cpp" used by Haskell. fpp is under 4 kSLOC >> of C, and surely Haskell can do a lot better. > > FWIW, cpphs is about 1600 LoC today. > > Regards, > Malcolm > From hvriedel at gmail.com Fri May 8 09:02:09 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 08 May 2015 11:02:09 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554C6AD6.2090103@jacobs-university.de> (Christian Maeder's message of "Fri, 8 May 2015 09:50:46 +0200") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> Message-ID: <87zj5f1lym.fsf@gmail.com> Hello Christian, (I've re-CC'ed haskell-cafe, assuming this wasn't deliberate) On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote: > using cpphs is the right way to go! > > Rewriting it from scratch may be a good exercise but is (essentially) a > waste of time. > > However, always asking Malcolm to get source changes into cpphs would > be annoying. > > Therefore it would be great if the sources were just part of the ghc > sources (under git). > > Another "problem" might be the dependency "polyparse" that is currently > not part of the core libraries. A scheme was actually discussed privately to address this: We certainly don't want to expose cpphs/polyparse (and text!) as new packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs as the other exposed boot libraries. Therefore we'd only use the few relevant modules from cpphs/polyparse as "other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't use cpphs/polyparse's .cabal files) compiled into GHC, but not exposed. We'd either create a new Git submodule to hold our "fork" of cpphs/polyparse, or just add it somewhere inside ghc.git > (I guess that replacing polyparse by something else would also be a nice > exercise.) > > So (for me) the only question is, if Malcolm is willing to transfer > control over cpphs to the haskell-community (or ghc head) - of course > with due acknowledgements! I don't think this will be necessary, as we don't need the cpphs-upstream to mirror each modifications immediately. The benefit of the scheme described above is that we'd be somewhat decoupled from cpphs' upstream, and can freely experiment in our "fork", and can sync up with Malcolm from time to time to merge improvements in both directions. -- hvr From metaniklas at gmail.com Fri May 8 09:28:08 2015 From: metaniklas at gmail.com (Niklas Larsson) Date: Fri, 8 May 2015 11:28:08 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5f1lym.fsf@gmail.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> Message-ID: <554c81a6.021d980a.468e.72fd@mx.google.com> If the intention is to use cpphs as a library, won't the license affect every program built with the GHC API? That seems to be a high price to pay. ----- Ursprungligt meddelande ----- Fr?n: "Herbert Valerio Riedel" Skickat: ?2015-?05-?08 11:02 Till: "Christian Maeder" Kopia: "Malcolm Wallace" ; "glasgow-haskell-users at haskell.org" ; "libraries at haskell.org" ; "ghc-devs at haskell.org" ; "haskell-cafe" ?mne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal Hello Christian, (I've re-CC'ed haskell-cafe, assuming this wasn't deliberate) On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote: > using cpphs is the right way to go! > > Rewriting it from scratch may be a good exercise but is (essentially) a > waste of time. > > However, always asking Malcolm to get source changes into cpphs would > be annoying. > > Therefore it would be great if the sources were just part of the ghc > sources (under git). > > Another "problem" might be the dependency "polyparse" that is currently > not part of the core libraries. A scheme was actually discussed privately to address this: We certainly don't want to expose cpphs/polyparse (and text!) as new packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs as the other exposed boot libraries. Therefore we'd only use the few relevant modules from cpphs/polyparse as "other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't use cpphs/polyparse's .cabal files) compiled into GHC, but not exposed. We'd either create a new Git submodule to hold our "fork" of cpphs/polyparse, or just add it somewhere inside ghc.git > (I guess that replacing polyparse by something else would also be a nice > exercise.) > > So (for me) the only question is, if Malcolm is willing to transfer > control over cpphs to the haskell-community (or ghc head) - of course > with due acknowledgements! I don't think this will be necessary, as we don't need the cpphs-upstream to mirror each modifications immediately. The benefit of the scheme described above is that we'd be somewhat decoupled from cpphs' upstream, and can freely experiment in our "fork", and can sync up with Malcolm from time to time to merge improvements in both directions. -- hvr _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri May 8 09:39:24 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 08 May 2015 11:39:24 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554c81a6.021d980a.468e.72fd@mx.google.com> (Niklas Larsson's message of "Fri, 8 May 2015 11:28:08 +0200") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> Message-ID: <87vbg31k8j.fsf@gmail.com> Hello, On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: > If the intention is to use cpphs as a library, won't the license > affect every program built with the GHC API? That seems to be a high > price to pay. Yes, every program linking the `ghc` package would be affected by LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: | - As a practical consequence of the //LGPL with static-linking-exception// | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** | (i.e. the LGPL+SLE covered modules) of the GHC code-base, | **then there is no requirement to ship (or make available) any source code** | together with the binaries, even if other parts of the GHC code-base | were modified. However, don't forget we already have this issue w/ integer-gmp, and with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) In that context, the suggestion was made[1] to handle the cpphs-code like the GMP code, i.e. allow a compile-time configuration in the GHC build-system to build a cpphs-free (and/or GMP-free) GHC for those parties that need to avoid any LGPL-ish code whatsoever in their toolchain. Would that address this concern? [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb From m at tweag.io Fri May 8 10:05:03 2015 From: m at tweag.io (Boespflug, Mathieu) Date: Fri, 8 May 2015 12:05:03 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87vbg31k8j.fsf@gmail.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process. Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by default GHC would call the cpphs binary for preprocessing, and have the cpphs binary be available in GHC's install dir somewhere? fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a single Haskell module. Can't we keep to this separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most license tainting concerns that way. On 8 May 2015 at 11:39, Herbert Valerio Riedel wrote: > Hello, > > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: > > If the intention is to use cpphs as a library, won't the license > > affect every program built with the GHC API? That seems to be a high > > price to pay. > > Yes, every program linking the `ghc` package would be affected by > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: > > | - As a practical consequence of the //LGPL with > static-linking-exception// > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, > | **then there is no requirement to ship (or make available) any source > code** > | together with the binaries, even if other parts of the GHC code-base > | were modified. > > However, don't forget we already have this issue w/ integer-gmp, and > with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) > > In that context, the suggestion was made[1] to handle the cpphs-code > like the GMP code, i.e. allow a compile-time configuration in the GHC > build-system to build a cpphs-free (and/or GMP-free) GHC for those > parties that need to avoid any LGPL-ish code whatsoever in their > toolchain. > > Would that address this concern? > > > [1]: > http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at tweag.io Fri May 8 10:06:09 2015 From: m at tweag.io (Boespflug, Mathieu) Date: Fri, 8 May 2015 12:06:09 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: [ Dropping wrong address for Malcolm. ] -- Mathieu Boespflug Founder at http://tweag.io. On 8 May 2015 at 12:05, Boespflug, Mathieu wrote: > I'm unclear why cpphs needs to be made a dependency of the GHC API and > included as a lib. Could you elaborate? (in the wiki page possibly) > > Currently, GHC uses the system preprocessor, as a separate process. > Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by > default GHC would call the cpphs binary for preprocessing, and have the > cpphs binary be available in GHC's install dir somewhere? > > fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a > single Haskell module. Can't we keep to this > separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most > license tainting concerns that way. > > > On 8 May 2015 at 11:39, Herbert Valerio Riedel wrote: > >> Hello, >> >> On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> > If the intention is to use cpphs as a library, won't the license >> > affect every program built with the GHC API? That seems to be a high >> > price to pay. >> >> Yes, every program linking the `ghc` package would be affected by >> LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: >> >> | - As a practical consequence of the //LGPL with >> static-linking-exception// >> | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** >> | (i.e. the LGPL+SLE covered modules) of the GHC code-base, >> | **then there is no requirement to ship (or make available) any source >> code** >> | together with the binaries, even if other parts of the GHC code-base >> | were modified. >> >> However, don't forget we already have this issue w/ integer-gmp, and >> with that the LGPL is in full effect (i.e. w/o a >> static-linkage-exception!) >> >> In that context, the suggestion was made[1] to handle the cpphs-code >> like the GMP code, i.e. allow a compile-time configuration in the GHC >> build-system to build a cpphs-free (and/or GMP-free) GHC for those >> parties that need to avoid any LGPL-ish code whatsoever in their >> toolchain. >> >> Would that address this concern? >> >> >> [1]: >> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboes at tweag.net Fri May 8 10:10:33 2015 From: mboes at tweag.net (Mathieu Boespflug) Date: Fri, 8 May 2015 12:10:33 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87vbg31k8j.fsf@gmail.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: [Gah, wrong From: email address given the list subscriptions, sorry for the duplicates.] I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process. Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by default GHC would call the cpphs binary for preprocessing, and have the cpphs binary be available in GHC's install dir somewhere? fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a single Haskell module. Can't we keep to this separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most license tainting concerns that way. On 8 May 2015 at 11:39, Herbert Valerio Riedel wrote: > Hello, > > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> If the intention is to use cpphs as a library, won't the license >> affect every program built with the GHC API? That seems to be a high >> price to pay. > > Yes, every program linking the `ghc` package would be affected by > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: > > | - As a practical consequence of the //LGPL with static-linking-exception// > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, > | **then there is no requirement to ship (or make available) any source code** > | together with the binaries, even if other parts of the GHC code-base > | were modified. > > However, don't forget we already have this issue w/ integer-gmp, and > with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) > > In that context, the suggestion was made[1] to handle the cpphs-code > like the GMP code, i.e. allow a compile-time configuration in the GHC > build-system to build a cpphs-free (and/or GMP-free) GHC for those > parties that need to avoid any LGPL-ish code whatsoever in their > toolchain. > > Would that address this concern? > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From carter.schonwald at gmail.com Fri May 8 12:07:07 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2015 08:07:07 -0400 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: Indeed. This is also how we use gcc and the llvm tooling. If we want the cpp tooling to be available as a library, that's a whole nother set of needs. Gmp lgpl I can brush under the rug at work because there's the various integer simple options, this gets a bit more squirrelly otherwise. Maybe it'd be simpler for two people to sit down for a weekend, one only narrating the cpphs code, the other only listening and paraphrasing it into a new program. Copyright on text only covers literal copying. Nontrivial rephrasing of everything plus some rejiggering of non local structure is not prevented by copyright law, and I doubt there are any patents in play. On Friday, May 8, 2015, Mathieu Boespflug wrote: > [Gah, wrong From: email address given the list subscriptions, sorry > for the duplicates.] > > I'm unclear why cpphs needs to be made a dependency of the GHC API and > included as a lib. Could you elaborate? (in the wiki page possibly) > > Currently, GHC uses the system preprocessor, as a separate process. > Couldn't we for GHC 7.12 keep to exactly that, save for the fact that > by default GHC would call the cpphs binary for preprocessing, and have > the cpphs binary be available in GHC's install dir somewhere? > > fork()/execvce() is cheap. Certainly cheaper than the cost of > compiling a single Haskell module. Can't we keep to this > separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep > most license tainting concerns that way. > > > On 8 May 2015 at 11:39, Herbert Valerio Riedel > wrote: > > Hello, > > > > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: > >> If the intention is to use cpphs as a library, won't the license > >> affect every program built with the GHC API? That seems to be a high > >> price to pay. > > > > Yes, every program linking the `ghc` package would be affected by > > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: > > > > | - As a practical consequence of the //LGPL with > static-linking-exception// > > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** > > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, > > | **then there is no requirement to ship (or make available) any > source code** > > | together with the binaries, even if other parts of the GHC code-base > > | were modified. > > > > However, don't forget we already have this issue w/ integer-gmp, and > > with that the LGPL is in full effect (i.e. w/o a > static-linkage-exception!) > > > > In that context, the suggestion was made[1] to handle the cpphs-code > > like the GMP code, i.e. allow a compile-time configuration in the GHC > > build-system to build a cpphs-free (and/or GMP-free) GHC for those > > parties that need to avoid any LGPL-ish code whatsoever in their > > toolchain. > > > > Would that address this concern? > > > > > > [1]: > http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri May 8 13:27:01 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 8 May 2015 10:27:01 -0300 Subject: HCAR DUE SOON: Please help edit! In-Reply-To: References: Message-ID: I've added this On Wed, May 6, 2015 at 3:02 PM, George Colpitts wrote: > In my opinion it would be great if somebody could add the LLVM work to the > "Upcoming plans for the next release" section > > Thanks > > > On Wed, May 6, 2015 at 10:27 AM, Austin Seipp > wrote: > >> Hi *, >> >> (Apologies for the caps lock cruise-control in the title.) >> >> After sitting on it for a bit, it dawned on me today that the may HCAR >> report is due soon - in about two weeks! >> >> So, it's that time of the year again, and I'd like you all to take a >> quick glance at the page and edit some stuff in about what you're all >> working on, because I can't possibly keep up with it all. :) >> >> https://ghc.haskell.org/trac/ghc/wiki/Status/May15 >> >> Note that I've already put some boilerplate on the page, but some of >> it is old, from the last report - but some other things slipped, so >> maybe it's not old! >> >> The best case is you will read this page in 5 minutes and it will look >> OK. At worst, you may need to tweak a paragraph or write a new one - >> so please read and contribute! >> >> Note: I'll continue editing this page as time goes on, to prepare it >> for submission. >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 8 14:08:06 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 May 2015 14:08:06 +0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <060.8a43f2c6bc75bc1896b4f256f019a02c@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> <060.8a43f2c6bc75bc1896b4f256f019a02c@haskell.org> Message-ID: Edward (Yang) I'm on a train so can't say this on Trac. I'm OK with enabling quotes (*not* quasiquotes) in stage1. Both typed and untyped quotes should work, correct? I'd rather it was done by using TemplateHaskell, and complaining if you use splices or quasi-quotes in stage1. (That is very much what happens now.) No new flags. Could the user manual briefly mention this? (Briefly because most users won't even know what a stage1 compiler is.) Could you add a Note somewhere appropriate to explain this? Perhaps mention the ticket, because Edward K's motivation is useful. Refer to the Note anywhere appropriate. Go for it. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of | GHC | Sent: 05 May 2015 16:06 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #10382: Template Haskell (non-quasi) quotes should | work with stage 1 compiler | | #10382: Template Haskell (non-quasi) quotes should work with stage 1 | compiler | -------------------------------------+----------------------------------- | -- | Reporter: ezyang | Owner: ezyang | Type: feature request | Status: new | Priority: normal | Milestone: 7.12.1 | Component: Template Haskell | Version: 7.11 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | Phab:D876 | -------------------------------------+----------------------------------- | -- | | Comment (by ekmett): | | The current situation: | | On one hand I have a number of packages that provide `TemplateHaskell` | convenience functions for users, `lens` being the go-to example. But on | the other hand, I have a bunch of folks who maintain releases for my | packages on platforms where only a stage1 compiler is available, Joachim | Breitner and the Debian folks used to maintain patches and versions of | my | code that removed large chunks of the libraries to build on those | platforms. | | When i found out, I offered to support stage1 compilers myself more | directly. This ensured a more uniform API, and that different | distributions weren't crippling my code in different ways, making it so | certain combinators or modules just weren't available on certain | platforms. | | But then we ran into an issue, we needed to generate names that linked | to | the right places within our code. So we manually construct all of our | names ourselves, using the cabal-supplied version number or package key | when needed: | | | https://github.com/ekmett/lens/blob/9a247b52ed20e578d9c843d8cc6dad5433a1c | 186/src/Control/Lens/Internal/TH.hs#L104 | | Then we just don't use the TemplateHaskell extension ourselves, despite | linking against the `template-haskell` package and everything is good | enough for us to limp along. | | I would love to eventually be able to drop this set of hoops, but I have | few opinions on the best way to get there. That said, Edward's | suggestion | of making TemplateHaskell just bomb when you reach a splice site in | stage1 | rather than immediately would avoid introducing any new flags and sounds | pretty simple. | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets From carter.schonwald at gmail.com Fri May 8 15:41:11 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2015 11:41:11 -0400 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: To clarify my point more concretely: Adding cpphs the cli tool to ghc build process / bin dist has no more licensing implications than does using gcc as a compiler / assembler. Ie NONE Using cpphs as a library is Another discussion. But I don't think it's the one we're having today. On Friday, May 8, 2015, Carter Schonwald wrote: > Indeed. This is also how we use gcc and the llvm tooling. > > If we want the cpp tooling to be available as a library, that's a whole > nother set of needs. > > Gmp lgpl I can brush under the rug at work because there's the various > integer simple options, this gets a bit more squirrelly otherwise. > > Maybe it'd be simpler for two people to sit down for a weekend, one only > narrating the cpphs code, the other only listening and paraphrasing it into > a new program. Copyright on text only covers literal copying. Nontrivial > rephrasing of everything plus some rejiggering of non local structure is > not prevented by copyright law, and I doubt there are any patents in play. > > > > On Friday, May 8, 2015, Mathieu Boespflug > wrote: > >> [Gah, wrong From: email address given the list subscriptions, sorry >> for the duplicates.] >> >> I'm unclear why cpphs needs to be made a dependency of the GHC API and >> included as a lib. Could you elaborate? (in the wiki page possibly) >> >> Currently, GHC uses the system preprocessor, as a separate process. >> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that >> by default GHC would call the cpphs binary for preprocessing, and have >> the cpphs binary be available in GHC's install dir somewhere? >> >> fork()/execvce() is cheap. Certainly cheaper than the cost of >> compiling a single Haskell module. Can't we keep to this >> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep >> most license tainting concerns that way. >> >> >> On 8 May 2015 at 11:39, Herbert Valerio Riedel >> wrote: >> > Hello, >> > >> > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> >> If the intention is to use cpphs as a library, won't the license >> >> affect every program built with the GHC API? That seems to be a high >> >> price to pay. >> > >> > Yes, every program linking the `ghc` package would be affected by >> > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: >> > >> > | - As a practical consequence of the //LGPL with >> static-linking-exception// >> > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** >> > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, >> > | **then there is no requirement to ship (or make available) any >> source code** >> > | together with the binaries, even if other parts of the GHC code-base >> > | were modified. >> > >> > However, don't forget we already have this issue w/ integer-gmp, and >> > with that the LGPL is in full effect (i.e. w/o a >> static-linkage-exception!) >> > >> > In that context, the suggestion was made[1] to handle the cpphs-code >> > like the GMP code, i.e. allow a compile-time configuration in the GHC >> > build-system to build a cpphs-free (and/or GMP-free) GHC for those >> > parties that need to avoid any LGPL-ish code whatsoever in their >> > toolchain. >> > >> > Would that address this concern? >> > >> > >> > [1]: >> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Fri May 8 16:12:28 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 8 May 2015 12:12:28 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: vector generates a considerable amount of code using CPP macros. And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written). On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson wrote: > On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > > Perhaps it makes sense to scan hackage to find all the different CPP > idioms > > that are actually used in Haskell code, if it is a small/well-defined set > > it may be worth writing a simple custom preprocessor. > > > > +1, I'll wager that the vast majority of usages are just for version > range checks. > > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri May 8 23:56:41 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 8 May 2015 19:56:41 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <20150508234028.C7ADC276CE1@mail.avvanta.com> References: <87zj5i55gs.fsf@gmail.com> <20150508234028.C7ADC276CE1@mail.avvanta.com> Message-ID: On Fri, May 8, 2015 at 7:40 PM, Donn Cave wrote: > But fatal if compilation is conditional on something that affects the > ability to type check, am I right? Such as different compilers or > versions of same compiler. > Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat May 9 14:05:09 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 9 May 2015 10:05:09 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <20150508234028.C7ADC276CE1@mail.avvanta.com> Message-ID: On Fri, May 8, 2015 at 7:56 PM, Brandon Allbery wrote: > On Fri, May 8, 2015 at 7:40 PM, Donn Cave wrote: > >> But fatal if compilation is conditional on something that affects the >> ability to type check, am I right? Such as different compilers or >> versions of same compiler. >> > > Not per the abstract (paper itself seems to be paywalled). They had an > earlier work with that issue, the linked one is about how to be robust in > the face of such conditionals. > There's also the question about handling changes in syntax, e.g. LambdaCase throws parse errors in older compilers. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sun May 10 18:39:18 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 10 May 2015 19:39:18 +0100 Subject: Non-deterministic package IDs are really bad in 7.10 Message-ID: <554FA5D6.3010403@fuuzetsu.co.uk> Hi, I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. The situation was pretty bad in 7.8.4 in presence of parallel builds so we switched those off. Joachim's a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and we were hopeful for 7.10. Now that 7.10.1 is out and people have been using and testing it, the situation turns out to be really bad: daily we get multiple reports from people about their packages ending up broken and our only advice is to do what we did back in 7.8 days which is to purge GHC and rebuild everything locally or fetch everything from a machine that already built it all, as long as the two don't mix. This is not really acceptable. See comment 76 on #4012 for an example of a rather simple file you can compile right now with nothing extra but -O and get different interface hash. This e-mail is just to raise awareness that there is a serious problem. If people are thinking about cutting 7.10.2 or whatever, I would consider part of this ticket to be a blocker as it makes using GHC reliably while benefitting from binary caches pretty much impossible. Of course there's the ?why don't you fix it yourself? question. I certainly plan to but do not have time for a couple more weeks to do so. For all I know right now, the fix to comment 76 might be easy and someone looking for something to hack on might have the time to get to it before I do. Thanks -- Mateusz K. From daniel.trstenjak at gmail.com Mon May 11 08:31:03 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 11 May 2015 10:31:03 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: <20150511083103.GA4434@machine> Hi Wren, > Incidentally, if we really want to pursue the "get rid of CPP by > building it into the GHC distro"... > > In recent years there've been a number of papers on "variational > lambda-calculi"[1] which essentially serve to embed flag-based > preprocessor conditionals directly into the language itself. One major > benefit of this approach is that the compiler can then typecheck *all* > variations of the code, rather than only checking whichever particular > variation we happen to be compiling at the time. This is extremely > useful for avoiding bitrot in the preprocessor conditionals. > > ...If we were to try and obviate the dependency on CPP, variational > typing seems like a far more solid approach than simply reinventing > the preprocessing wheel yet again. (The downside, of course, is making > the Haskell spec significantly more complex.) I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel From simonpj at microsoft.com Mon May 11 10:21:51 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 May 2015 10:21:51 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <32ac93f9ffb44faaa2a3771bbd9e3033@DB4PR30MB030.064d.mgd.msft.net> I see this as mission-critical to relieving Cabal hell. (Am I alone?) So it?s great that Vishal is going to work on it. Go Vishal! Can I take it, then, that the Cabal developers will be sufficiently involved that, assuming there are no show-stopping problems, they?ll accept the patch? It is tantalising to me that something so critical has been so long delayed. It?d be fantastic if it was done this summer. Simon From: Gershom B [mailto:gershomb at gmail.com] Sent: 07 May 2015 22:29 To: Mikhail Glushenkov Cc: Simon Peyton Jones; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package For the info of all, here is the proposal: https://gist.github.com/fugyk/37510958b52589737274 The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project proceeds, Vishal will be checking in with us, asking questions and seeking clarification where necessary, etc. --Gershom On Thu, May 7, 2015 at 5:19 PM, Mikhail Glushenkov > wrote: On 7 May 2015 at 22:34, Simon Peyton Jones > wrote: > Dear Cabal developers > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > progress on this thread. Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have to wait and see what comes out of it now. _______________________________________________ cabal-devel mailing list cabal-devel at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Mon May 11 11:04:52 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 11 May 2015 13:04:52 +0200 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <32ac93f9ffb44faaa2a3771bbd9e3033@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> <32ac93f9ffb44faaa2a3771bbd9e3033@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <20150511110452.GA17991@machine> Hi Simon, > It is tantalising to me that something so critical has been so long delayed. > It?d be fantastic if it was done this summer. I'm just wondering what kind of negative side effects it might have. Sure, it will - most likely - make installing of cabal packages a lot easier, especially for all non expert Haskell users. But if multiple versions of the same library can be linked into one binary, then the binary sizes will increase and therefore the memory usage might increase and even performance might decrease a bit if the number of cache misses increase. It's certainly annoying to keep up with library updates, but in a way it also pushes everyone forward to update their code bases, so if everything just "works" - respectively is easy buildable - then this force might be quite reduced. I'm just thinking e.g. of a case where you want to use at least a certain version of a library, because you know of major performance/bug fixes in this version, but now a considerable part of your code base might use an older version of this library, because the dependencies of your project haven't been updated. Greetings, Daniel From simonpj at microsoft.com Mon May 11 11:27:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 May 2015 11:27:58 +0000 Subject: QRE: Cabal and simultaneous installations of the same package Message-ID: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> | But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. Well, no one is actually suggesting that! The #1 issue is that installing package P1, which depends on Q-3.4, should not break other package P2 that also depends on Q-3.4. Today it can break P2. And re-installing P2 can break P1. How does that happen? Q-3.4 depends on R 1.4-3.8 P1 depends on R-1.4 P2 depends on R-2.8 Then P1 needs Q-3.4 compiled against R-1.4 P2 needs Q-3.4 compiled against R-2.8 So the two can only co-exist if both instances of Q-3.4 can be simultaneously installed. None of this means that both instances of Q-3.4 need be part of the same executable. (That would be necessary if you wanted P1 and P2 in the same program; but maybe you don't.) They certainly could be, but allowing it has the disadvantages you describe. Simon | -----Original Message----- | From: Daniel Trstenjak [mailto:daniel.trstenjak at gmail.com] | Sent: 11 May 2015 12:05 | To: Simon Peyton Jones | Cc: Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well- | typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; | cabal-devel at haskell.org; ghc-devs at haskell.org; Vishal Agrawal; Haskell | Libraries | Subject: Re: Cabal and simultaneous installations of the same package | | | Hi Simon, | | > It is tantalising to me that something so critical has been so long | delayed. | > It?d be fantastic if it was done this summer. | | I'm just wondering what kind of negative side effects it might have. | | Sure, it will - most likely - make installing of cabal packages a lot | easier, especially for all non expert Haskell users. | | But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. | | It's certainly annoying to keep up with library updates, but in a way | it also pushes everyone forward to update their code bases, so if | everything just "works" - respectively is easy buildable - then this | force might be quite reduced. | | I'm just thinking e.g. of a case where you want to use at least a | certain version of a library, because you know of major | performance/bug fixes in this version, but now a considerable part of | your code base might use an older version of this library, because the | dependencies of your project haven't been updated. | | | Greetings, | Daniel From daniel.trstenjak at gmail.com Mon May 11 12:52:36 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 11 May 2015 14:52:36 +0200 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <20150511125236.GA22281@machine> Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel From austin at well-typed.com Mon May 11 14:51:23 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 11 May 2015 09:51:23 -0500 Subject: GHC Weekly News - 2015/05/11 Message-ID: (This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150511) Hi *, It's been a few weeks since the last news bulletin - this is the result of mostly quietness on behalf of the list and developers, and some sickness on behalf of your editor for several days there. But now there's actually some things to write here! The past few weeks, GHC HQ has been having some quiet meetings mostly about bugfixes for a 7.10.2 release - as well as noodling about compiler performance. Austin has begun compiling his preliminary notes on the wiki, under the [wiki:CompilerPerformance] page, where we'll be trying to keep track of the ongoing performance story. Hopefully, GHC 7.12.1 will boast a bit better performance numbers. There are a lot of users who are interested in this particular pain point, so please file tickets and CC yourself on bugs (like #10370), or feel free to help out! == 7.10.2 status == There's been a bit of chatter about the lists about something on many peoples mind: the release of GHC 7.10.2. Most prominently, Mark Lentczner popped in to ask when the next GHC release will happen - in particular, he'd like to make a Haskell Platform release in lockstep with it (see below for a link to Mark's email). Until recently, the actual desire for 7.10.2 wasn't totally clear, and at this point, GHC HQ hasn't firmly committed to the 7.10.2 release date. But if milestone:7.10.2 is any indicator, we've already closed over three dozen bugs, several of them high priority - and they keep coming in. So it seems likely people will want these fixes in their hands relatively soon. Just remember: '''if you need a fix for 7.10.2''', or have a bug you need us to look at, please email the `ghc-devs` list, file a ticket, and get our attention! Just be sure to set the milestone to 7.10.2. == List chatter == - Herbert Valerio Riedel opened an RFC about a regression in GHC 7.10 relating to the update to Unicode 7. Any input from users of international languages or unicode users would be appreciated! https://mail.haskell.org/pipermail/ghc-devs/2015-May/008930.html - Herbert Valerio Riedel also asked about a new C pre-processor implementation for GHC - but in particular, adopting the extant `cpphs` into the GHC codebase for this task itself. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008934.html - Austin Seipp emailed `ghc-devs` about the HCAR report, for which the GHC entry is due May 17th! Developers should get their edits in quickly. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008939.html - Joachim Breitner asks if the branchless implementation for our literal cases are worth it for their complexity. There were some interesting responses, including some remarks on the V8 JavaScript compiler. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008852.html - Niklas Hamb?chen announced that he's backported the recent lightweight stack-trace support in GHC HEAD to GHC 7.10 and GHC 7.8 - meaning that users of these stable release can have informative call stack traces, even without profiling! FP Complete was interested in this feature, so they'd probably love to hear user input. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008862.html - David Terei has written up a proposal on reconciling the existence of Roles with Safe Haskell, which caused us a lot of problems during the 7.8 release cycle. In particular, concerning the ability to break module abstractions and requiring programmers to safeguard abstractions through careful use of roles - and David's written a proposal to address that. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008902.html - Mark Lentczner started a thread about the 7.10.2 release schedule - because this time, he wants to do a concurrent Haskell Platform release! The thread ended up with a good amount of discussion concerning if 7.10.2 is even needed - but at this rate, it looks like it will ship sometime soon. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008904.html - Mateusz Kowalczyk posted to `ghc-devs` hoping to get some help with a tricky, long-standing issue: #4012, which concerns the determinism of GHC binaries. It turns out GHC isn't entirely deterministic when it calculates package IDs, meaning things get really bad when you mix prebuilt binary packages for systems. This in particular has become a real problem for the Nix package manager and users of Haskell applications. Mateusz asks if anyone would be willing to help look into it - and a lot of people would appreciate the help! https://mail.haskell.org/pipermail/ghc-devs/2015-May/008992.html == Noteworthy commits == - Commit f2d1b7fcbbc55e33375a7321222a9f4ee189aa38 - Support unboxing for GADT product types. - Commit 51af102e5c6c56e0987432aa5a21fe10e24090e9 - Better hints when RTS options are not available. - Commit 524ddbdad5816f77b7b719cac0671eebd3473616 - Make sure `GHC.List.last` is memory-efficient. - Commit a1275a762ec04c1159ae37199b1c8f998a5c5499 - Improve improvement in the constraint solver. - Commit 4efa421327cf127ebefde59b2eece693e37dc3c6 - Permit empty closed type families. - Commit 477f514f6ebcf783810da93e2191e4b6ea65559b - rts: add "-no-rtsopts-suggestions" option - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for :set +s - Commit c4e8097ea8dd6e43eae7aadd6bae7e13272ba74d - Bump base version to `4.8.2.0` - Commit 0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5 - Use the gold linker for aarch64/linux (#9673) - Commit 1e8c9b81a819da8eb54405a029fc33a9f5220321 - Enable SMP and GHCi support for AArch64 == Closed tickets == #10293, #10273, #10021, #10209, #10255, #10326, #9745, #10314, #8928, #8743, #10182, #10281, #10325, #10297, #10292, #10304, #10260, #9204, #10121, #10329, #9920, #10308, #10234, #10356, #10351, #10364, #9564, #10306, #10108, #9581, #10369, #9673, #10288, #10260, #10363, #10315, #10389, #9929, #10384, #10382, #10400, #10256, #10254, #10277, #10299, #10268, #10269, #10280, #10312, #10209, #10109, #10321, #10285, #9895, #10395, #10263, #10293, #10210, #10302, #10206, #9858, #10045, and #9840. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From m at tweag.io Mon May 11 15:42:00 2015 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 11 May 2015 17:42:00 +0200 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: <20150511125236.GA22281@machine> References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> <20150511125236.GA22281@machine> Message-ID: As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak wrote: > > Hi Simon, > > On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > > Well, no one is actually suggesting that! > > But you're just getting it automatically if you're depending e.g. > on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. > > Currently you can't build this dependency graph, right? And with > this proposed feature you will be getting C 1.0 and 2.0 into your binary. > > > Perhaps a even more nasty case is, if you're using a haskell library > which wraps a stateful c library, and now you're having multiple > versions of the same haskell library operating on the same c library state. > > > Greetings, > Daniel > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Mon May 11 15:56:23 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 11 May 2015 17:56:23 +0200 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> <20150511125236.GA22281@machine> Message-ID: <20150511155623.GA28584@machine> On Mon, May 11, 2015 at 05:42:00PM +0200, Boespflug, Mathieu wrote: > In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever > one of those fits the constraints of both A and B, or the build will fail if no > such C exists. Thanks for the clarification! I thought this was part of the proposal, sorry for the noise. Greetings, Daniel From simonpj at microsoft.com Mon May 11 16:17:31 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 May 2015 16:17:31 +0000 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> <20150511125236.GA22281@machine> Message-ID: <3b9e8928144742e2a1e331a87a67f2d9@DB4PR30MB030.064d.mgd.msft.net> Exactly! It?s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it?s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal! Simon From: Boespflug, Mathieu [mailto:m at tweag.io] Sent: 11 May 2015 16:42 To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Vishal Agrawal; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak > wrote: Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 12 13:39:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 May 2015 13:39:48 +0000 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> <20150511125236.GA22281@machine> <3b9e8928144742e2a1e331a87a67f2d9@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. Let?s see if I understand this correctly. I believe that Duncan/you envisage the following scenario: ? Package database: you can install any package, compiled against any dependencies, without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies. ? Environment. The ?environment? maps a package name, such as ?P-2.3? to a particular package instance in the database. When you say ?ghc ?c Foo.hs ?package P?, the ?-package 2.3? consults the environment to determine which of the many P-2.3 instances you might mean. Mind you, GHC?s new ?package flag takes a package key (which identifies a unique package instance in the database). So I?m hazy about exactly when the environment is used. ? You can in principle have many environments (akin to sandboxes) but only one database. There is a UI issue about how you define and maintain environments. ? Duncan argues that, for predictability, every environment should be consistent. o I?m not sure exactly what ?consistent? means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)? o Intuitively, though, ?consistent? means that all packages in the environment are compatible; they won?t give rise to the confusing ?P-2.3:M.T does not match P-2.4:M.T? errors. ? The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user ?package flags. I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I?m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I?m sure I have repeated above stuff that is well worn territory.) Thanks! Simon From: Vishal Agrawal [mailto:vishal4556 at gmail.com] Sent: 11 May 2015 23:02 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan of the project. The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which I took most of the ideas from. http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/ > Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general. > While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form. I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced, errors like ?bytestring is not bytestring? can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time which can earlier work at the same time. My personal preference is to enforce consistency. On 11-May-2015, at 9:47 pm, Simon Peyton Jones > wrote: Exactly! It?s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it?s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal! Simon From: Boespflug, Mathieu [mailto:m at tweag.io] Sent: 11 May 2015 16:42 To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Vishal Agrawal; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak > wrote: Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 12 19:58:13 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 May 2015 19:58:13 +0000 Subject: QRE: Cabal and simultaneous installations of the same package In-Reply-To: References: <50cfb13dbe094374b877597991e1a664@DB4PR30MB030.064d.mgd.msft.net> <20150511125236.GA22281@machine> <3b9e8928144742e2a1e331a87a67f2d9@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <773a5caab7164e7c940b7107bc665e7a@DB4PR30MB030.064d.mgd.msft.net> Vishal Just to reiterate: I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I?m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I?m sure I have repeated above stuff that is well worn territory.) I urge you strongly to begin your project by writing out your proposed design, and seeking feedback from the community. Simon From: Vishal Agrawal [mailto:vishal4556 at gmail.com] Sent: 12 May 2015 18:54 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Yes, consistency means allowing only a single instance of a package in a environment. A environment is very cheap to create than sandbox. Like every time a package is imported in ghci, a new environment is created which includes all the earlier package and new package. Multiple environment can give sandbox for free. Single database will have many benefits, although I don't think it is requirement. I plan to move to single database somewhat in middle. On Tue, May 12, 2015 at 7:09 PM, Simon Peyton Jones > wrote: Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. Let?s see if I understand this correctly. I believe that Duncan/you envisage the following scenario: ? Package database: you can install any package, compiled against any dependencies, without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies. ? Environment. The ?environment? maps a package name, such as ?P-2.3? to a particular package instance in the database. When you say ?ghc ?c Foo.hs ?package P?, the ?-package 2.3? consults the environment to determine which of the many P-2.3 instances you might mean. Mind you, GHC?s new ?package flag takes a package key (which identifies a unique package instance in the database). So I?m hazy about exactly when the environment is used. ? You can in principle have many environments (akin to sandboxes) but only one database. There is a UI issue about how you define and maintain environments. ? Duncan argues that, for predictability, every environment should be consistent. o I?m not sure exactly what ?consistent? means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)? o Intuitively, though, ?consistent? means that all packages in the environment are compatible; they won?t give rise to the confusing ?P-2.3:M.T does not match P-2.4:M.T? errors. ? The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user ?package flags. I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I?m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I?m sure I have repeated above stuff that is well worn territory.) Thanks! Simon From: Vishal Agrawal [mailto:vishal4556 at gmail.com] Sent: 11 May 2015 23:02 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan of the project. The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which I took most of the ideas from. http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/ > Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general. > While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form. I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced, errors like ?bytestring is not bytestring? can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time which can earlier work at the same time. My personal preference is to enforce consistency. On 11-May-2015, at 9:47 pm, Simon Peyton Jones > wrote: Exactly! It?s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it?s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal! Simon From: Boespflug, Mathieu [mailto:m at tweag.io] Sent: 11 May 2015 16:42 To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com; cabal-devel at haskell.org; ghc-devs at haskell.org; Vishal Agrawal; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak > wrote: Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 13 08:07:34 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 May 2015 08:07:34 +0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <061.59a3f68accbe124791847d483e2a6156@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> <061.59a3f68accbe124791847d483e2a6156@haskell.org> Message-ID: Heads-up: this one changes interface file formats, so you need a clean build. Simon | -----Original Message----- | From: GHC [mailto:ghc-devs at haskell.org] | Sent: 13 May 2015 09:02 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #9858: Typeable instances should be kind-aware | | #9858: Typeable instances should be kind-aware | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: dreixel | Owner: | Type: bug | Status: | closed | Priority: highest | Milestone: | 7.10.2 | Component: Compiler | Version: 7.9 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | | typecheck/should_fail/T9858a,b,c; | | should_run/T9858b | | Blocking: | | Differential Revisions: | Phab:D652 | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Simon Peyton Jones ): | | In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]: | {{{ | #!CommitTicketReference repository="ghc" | revision="130e93aab220bdf14d08028771f83df210da340b" | Refactor tuple constraints | | Make tuple constraints be handled by a perfectly ordinary type | class, with the component constraints being the | superclasses: | class (c1, c2) => (c2, c2) | | This change was provoked by | | #10359 inability to re-use a given tuple | constraint as a whole | | #9858 confusion between term tuples | and constraint tuples | | but it's generally a very nice simplification. We get rid of | - In Type, the TuplePred constructor of PredTree, | and all the code that dealt with TuplePreds | - In TcEvidence, the constructors EvTupleMk, EvTupleSel | | See Note [How tuples work] in TysWiredIn. | | Of course, nothing is ever entirely simple. This one proved quite | fiddly. | | - I did quite a bit of renaming, which makes this patch | touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. | | - I made constraint tuples known-key rather than wired-in. | This is different to boxed/unboxed tuples, but it proved | awkward to have all the superclass selectors wired-in. | Easier just to use the standard mechanims. | | - While I was fiddling with known-key names, I split the TH Name | definitions out of DsMeta into a new module THNames. That meant | that the known-key names can all be gathered in PrelInfo, without | causing module loops. | | - I found that the parser was parsing an import item like | T( .. ) | as a *data constructor* T, and then using setRdrNameSpace to | fix it. Stupid! So I changed the parser to parse a *type | constructor* T, which means less use of setRdrNameSpace. | | I also improved setRdrNameSpace to behave better on Exact Names. | Largely on priciple; I don't think it matters a lot. | | - When compiling a data type declaration for a wired-in thing like | tuples (,), or lists, we don't really need to look at the | declaration. We have the wired-in thing! And not doing so avoids | having to line up the uniques for data constructor workers etc. | See Note [Declarations for wired-in things] | | - I found that FunDeps.oclose wasn't taking superclasses into | account; easily fixed. | | - Some error message refactoring for invalid constraints in | TcValidity }}} | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler From simonpj at microsoft.com Wed May 13 10:55:16 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 May 2015 10:55:16 +0000 Subject: Strange testsuite failure Message-ID: <85858201693a46fe9372ddad7079b061@DB4PR30MB030.064d.mgd.msft.net> Is this expected? Just started happening for me =====> T8333(normal) 140 of 185 [0, 0, 0] cd . && $MAKE -s --no-print-directory T8333 T8333.run.stdout 2> T8333.run.stderr Actual stdout output differs from expected: --- ./T8333.stdout 2015-01-27 13:00:30.000000000 +0000 +++ ./T8333.run.stdout 2015-05-13 11:54:03.199711197 +0100 @@ -0,0 +1,4 @@ +*** WARNING: . is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 .' +*** WARNING: /home/simonpj is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 /home/simonpj' *** unexpected failure for T8333(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 13 11:10:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 May 2015 11:10:27 +0000 Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in HscMain (stage2) In-Reply-To: <20150513094016.11940.66578@phabricator.haskell.org> References: <20150513094016.11940.66578@phabricator.haskell.org> Message-ID: <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> I'm very sorry but the build breaks if you build Haddock docs for ghc-prim. The failure is a call to tyConStupidTheta, but I have no idea why it is called or why it has changed. I'll chase, but may need help. S | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 13 May 2015 10:40 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in | HscMain (stage2) | | Harbormaster failed to build B4022: rGHCa8493e03b89f: Fix imports in | HscMain (stage2)! | | USERS | simonpj (Author) | GHC - Driver (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCa8493e03b89f | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Driver From alan.zimm at gmail.com Wed May 13 11:27:14 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 13 May 2015 13:27:14 +0200 Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in HscMain (stage2) In-Reply-To: <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> References: <20150513094016.11940.66578@phabricator.haskell.org> <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> Message-ID: You need to add import RdrHsSyn (setRdrNameSpace) to the imports Alan On Wed, May 13, 2015 at 1:10 PM, Simon Peyton Jones wrote: > I'm very sorry but the build breaks if you build Haddock docs for > ghc-prim. The failure is a call to tyConStupidTheta, but I have no idea > why it is called or why it has changed. I'll chase, but may need help. > > S > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 13 May 2015 10:40 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in > | HscMain (stage2) > | > | Harbormaster failed to build B4022: rGHCa8493e03b89f: Fix imports in > | HscMain (stage2)! > | > | USERS > | simonpj (Author) > | GHC - Driver (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHCa8493e03b89f > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Driver > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 13 11:52:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 May 2015 11:52:27 +0000 Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in HscMain (stage2) In-Reply-To: <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> References: <20150513094016.11940.66578@phabricator.haskell.org> <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <218127cd70cc42ab9fe0fd982bafae34@DB4PR30MB030.064d.mgd.msft.net> Things are better now, I think. But Haddock still crashes when generating documentation for GHC.Prim. It looks at an auto-generate file, GHC.Prim.hs, and from that we get typechecker errors like libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs:2632:1: error: Top-level bindings for unlifted types aren't allowed: nullAddr# = let x = x in x What I don't understand is - why did this not happen before? - why is Haddock type-checking the module anyway? Can anyone help? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Simon Peyton Jones | Sent: 13 May 2015 12:10 | To: ghc-devs at haskell.org | Subject: RE: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports | in HscMain (stage2) | | I'm very sorry but the build breaks if you build Haddock docs for ghc- | prim. The failure is a call to tyConStupidTheta, but I have no idea | why it is called or why it has changed. I'll chase, but may need | help. | | S | | | -----Original Message----- | | From: noreply at phabricator.haskell.org | | [mailto:noreply at phabricator.haskell.org] | | Sent: 13 May 2015 10:40 | | To: Simon Peyton Jones | | Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports | in | | HscMain (stage2) | | | | Harbormaster failed to build B4022: rGHCa8493e03b89f: Fix imports | in | | HscMain (stage2)! | | | | USERS | | simonpj (Author) | | GHC - Driver (Auditor) | | | | COMMIT | | https://phabricator.haskell.org/rGHCa8493e03b89f | | | | EMAIL PREFERENCES | | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | | | To: simonpj, GHC - Driver | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Wed May 13 11:53:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 May 2015 11:53:17 +0000 Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in HscMain (stage2) In-Reply-To: References: <20150513094016.11940.66578@phabricator.haskell.org> <811f50fee81d4347a708586b95463b05@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Not just that! see email From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 13 May 2015 12:27 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in HscMain (stage2) You need to add import RdrHsSyn (setRdrNameSpace) to the imports Alan On Wed, May 13, 2015 at 1:10 PM, Simon Peyton Jones > wrote: I'm very sorry but the build breaks if you build Haddock docs for ghc-prim. The failure is a call to tyConStupidTheta, but I have no idea why it is called or why it has changed. I'll chase, but may need help. S | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 13 May 2015 10:40 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCa8493e03b89f: Fix imports in | HscMain (stage2) | | Harbormaster failed to build B4022: rGHCa8493e03b89f: Fix imports in | HscMain (stage2)! | | USERS | simonpj (Author) | GHC - Driver (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCa8493e03b89f | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Driver _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Thu May 14 08:36:04 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 14 May 2015 18:36:04 +1000 Subject: Debugging the RTS Message-ID: <20150514183604.2476baaaacd6a85ef1430b37@mega-nerd.com> Hi all, I'm trying to debug a AArch64/Linux specific RTS issue and digging around in the rts C code, I see a large amount of code wrapped in "#if DEBUG" type statements, but no way to enable in either mk/build.mk or it seems in any of the other build related settings files in the mk/ directory. The only way I have found to enable this debug code that actually works is to enable this DEBUG code is to edit mk/ghc.mk as follows: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG However, once I do that I get a bunch of C synatx errors. I am doing this wrong or has the DEBUG code bit rotted? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From dcb314 at hotmail.com Thu May 14 11:40:44 2015 From: dcb314 at hotmail.com (David Binderman) Date: Thu, 14 May 2015 11:40:44 +0000 Subject: utils/hp2ps/Main.c:88: possible missing break ? Message-ID: Hello there, [utils/hp2ps/Main.c:88] -> [utils/hp2ps/Main.c:91]: (warning) Variable 'iflag' is reassigned a value before the old one has been used. 'break;' missing? Source code is ??????? switch( *(*argv + 1) ) { ????????? case '-': ??????????? iflag = -1; ????????? case '+': ????????? default: ??????????? iflag = 1; ??????? } Suggest add missing break. Regards David Binderman From berthold at Mathematik.Uni-Marburg.de Thu May 14 14:21:23 2015 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Fri, 15 May 2015 00:21:23 +1000 Subject: Debugging the RTS In-Reply-To: References: Message-ID: <5554AF63.5090501@mathematik.uni-marburg.de> Hi Eric, definitely not bit-rotted - the #if DEBUG code is what you get when you compile with -debug. Short roadmap: In general, GHC is built in many "ways", the -debug way is one. Some ways (like -threaded, -eventlog, -debug) are RTS-only, others (like -prof) lead to different library code. Ways are defined in compiler/main/DynFlags.hs as a Haskell data structure. In _dynamic_flags_, the actual flag strings for the ghc invocation are defined (like -prof, -threaded), they will activate the respective _Way_. _wayTag_, in turn, defines short names used as a suffix for *.o and *.a files, for instance *.p_o for profiling, *.l_o for eventlog. A number of other functions in there customise behaviour depending on the ways. Note _wayOptc_ which sets some options for the C compiler, like -DTRACING for the -eventlog way. However, it does not define DEBUG for the debug way! In mk/ways.mk you will find all the short names, and some more options are defined (WAY_*_HC_OPTS). These definitions are for the driver script, and pass on the right (long-name) options to the Haskell compiler to activate what is inside DynFlags (like -prof for WAY_p_HC_OPTS). Here we find WAY_debug_HC_OPTS= -static -optc-DDEBUG -ticky -DTICKY_TICKY which is what you were looking for To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug to your build.mk (also see mk/config.mk{.in}, which gathers the default ways to build depending on platform and build configuration). I guess this might produce quite a number of new warnings and errors if you do it on a new platform... Once you have built this, you can compile with -debug and pass RTS options to get debug traces and activate sanity checks, like so: ghc -debug -myprogram.hs -o myprogramDebug ./myprogramDebug +RTS -Ds -DS (-DS = sanity checks on, -Ds = scheduler tracing) The usage message (see /rts/RtsFlags.c) tells you more options you can use. Happy debugging! / Jost On 05/14/2015 10:00 PM, ghc-devs-request at haskell.org wrote: > Date: Thu, 14 May 2015 18:36:04 +1000 > From: Erik de Castro Lopo > To: ghc-devs at haskell.org > Subject: Debugging the RTS > Message-ID: <20150514183604.2476baaaacd6a85ef1430b37 at mega-nerd.com> > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > I'm trying to debug a AArch64/Linux specific RTS issue and digging > around in the rts C code, I see a large amount of code wrapped in > "#if DEBUG" type statements, but no way to enable in either > mk/build.mk or it seems in any of the other build related settings > files in the mk/ directory. > > The only way I have found to enable this debug code that actually > works is to enable this DEBUG code is to edit mk/ghc.mk as follows: > > -STANDARD_OPTS += -DCOMPILING_RTS > +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG > > However, once I do that I get a bunch of C synatx errors. > > I am doing this wrong or has the DEBUG code bit rotted? > > Cheers, > Erik > From simonpj at microsoft.com Thu May 14 14:22:29 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 14 May 2015 14:22:29 +0000 Subject: GHC semi-annual status report Message-ID: * All: the every-6-months GHC status report is nearly done: https://ghc.haskell.org/trac/ghc/wiki/Status/May15. Please review it and add any missing items or links. It serves as a useful roundup of ongoing work. If you are working away on something, just add it! * Edward: would you like to update the Backpack stuff, and add a suitable link? * Iavor/Adam: ditto the SMT solver plugin * Lennart: ditto signature sections Deadline 17 May (3 days time). Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Thu May 14 16:38:04 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 14 May 2015 13:38:04 -0300 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <554FA5D6.3010403@fuuzetsu.co.uk> References: <554FA5D6.3010403@fuuzetsu.co.uk> Message-ID: Currently the priority of #4012 is normal, shouldn't it be at least high? Also the milestone is 7.12.1, should it be 7.10.2? On Sun, May 10, 2015 at 3:39 PM, Mateusz Kowalczyk wrote: > Hi, > > I'd like to bring some attention to ticket #4012 about non-determinism. > As many of you may know, the nix package manager distributes binaries > throughout its binary caches. The binaries are shared as long as the > hash of some of their inputs matches: this means that we can end up with > two of the same hashes of inputs but thanks to #4012 means that the > actual contents can differ. You end up with machines with some packages > built locally and some elsewhere and due to non-determinism, the GHC > package IDs don't line up and everything is broken. > > The situation was pretty bad in 7.8.4 in presence of parallel builds so > we switched those off. Joachim's > a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and > we were hopeful for 7.10. Now that 7.10.1 is out and people have been > using and testing it, the situation turns out to be really bad: daily we > get multiple reports from people about their packages ending up broken > and our only advice is to do what we did back in 7.8 days which is to > purge GHC and rebuild everything locally or fetch everything from a > machine that already built it all, as long as the two don't mix. This is > not really acceptable. > > See comment 76 on #4012 for an example of a rather simple file you can > compile right now with nothing extra but -O and get different interface > hash. > > This e-mail is just to raise awareness that there is a serious problem. > If people are thinking about cutting 7.10.2 or whatever, I would > consider part of this ticket to be a blocker as it makes using GHC > reliably while benefitting from binary caches pretty much impossible. > > Of course there's the ?why don't you fix it yourself? question. I > certainly plan to but do not have time for a couple more weeks to do so. > For all I know right now, the fix to comment 76 might be easy and > someone looking for something to hack on might have the time to get to > it before I do. > > Thanks > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Thu May 14 18:22:44 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 14 May 2015 19:22:44 +0100 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: References: <554FA5D6.3010403@fuuzetsu.co.uk> Message-ID: <0CF02901-AA94-4E1D-B8F6-59DB80AC1F25@me.com> I'd like to add a +1 to getting this fixed. It bites us at work, where exact binary reproducibility of builds is strongly desirable. Regards, Malcolm On 14 May 2015, at 17:38, George Colpitts wrote: > Currently the priority of #4012 is normal, shouldn't it be at least high? Also the milestone is 7.12.1, should it be 7.10.2? > > On Sun, May 10, 2015 at 3:39 PM, Mateusz Kowalczyk wrote: > Hi, > > I'd like to bring some attention to ticket #4012 about non-determinism. > As many of you may know, the nix package manager distributes binaries > throughout its binary caches. The binaries are shared as long as the > hash of some of their inputs matches: this means that we can end up with > two of the same hashes of inputs but thanks to #4012 means that the > actual contents can differ. You end up with machines with some packages > built locally and some elsewhere and due to non-determinism, the GHC > package IDs don't line up and everything is broken. > > The situation was pretty bad in 7.8.4 in presence of parallel builds so > we switched those off. Joachim's > a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and > we were hopeful for 7.10. Now that 7.10.1 is out and people have been > using and testing it, the situation turns out to be really bad: daily we > get multiple reports from people about their packages ending up broken > and our only advice is to do what we did back in 7.8 days which is to > purge GHC and rebuild everything locally or fetch everything from a > machine that already built it all, as long as the two don't mix. This is > not really acceptable. > > See comment 76 on #4012 for an example of a rather simple file you can > compile right now with nothing extra but -O and get different interface > hash. > > This e-mail is just to raise awareness that there is a serious problem. > If people are thinking about cutting 7.10.2 or whatever, I would > consider part of this ticket to be a blocker as it makes using GHC > reliably while benefitting from binary caches pretty much impossible. > > Of course there's the ?why don't you fix it yourself? question. I > certainly plan to but do not have time for a couple more weeks to do so. > For all I know right now, the fix to comment 76 might be easy and > someone looking for something to hack on might have the time to get to > it before I do. > > Thanks > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Thu May 14 18:36:30 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 14 May 2015 20:36:30 +0200 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <554FA5D6.3010403@fuuzetsu.co.uk> References: <554FA5D6.3010403@fuuzetsu.co.uk> Message-ID: <1431628590.22790.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: > I'd like to bring some attention to ticket #4012 about non-determinism. > As many of you may know, the nix package manager distributes binaries > throughout its binary caches. The binaries are shared as long as the > hash of some of their inputs matches: this means that we can end up with > two of the same hashes of inputs but thanks to #4012 means that the > actual contents can differ. You end up with machines with some packages > built locally and some elsewhere and due to non-determinism, the GHC > package IDs don't line up and everything is broken. is NixOS sensitive to changes in the build directory. Debian is, and since 7.8 the build path creeps into the interface files and affects the hash: https://bugs.debian.org/785282 But you probably are not, otherwise you?d have complained when 7.8 was out, and not now :-) 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 austin at well-typed.com Thu May 14 23:44:53 2015 From: austin at well-typed.com (Austin Seipp) Date: Thu, 14 May 2015 18:44:53 -0500 Subject: NOTE: Phabricator is down for a moment Message-ID: All, Phabricator is down for a few minutes - in my latest update it looks like we may have gotten hit by a bug. I'm working with upstream to fix it now. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Fri May 15 07:46:51 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 15 May 2015 09:46:51 +0200 Subject: api annotations test failures Message-ID: <1431676011.1232.1.camel@joachim-breitner.de> Hi, I observe this on travis: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: collect2: ld terminated with signal 9 [Killed] make[3]: *** [t10358] Error 1 *** unexpected failure for T10358(normal) Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: collect2: ld terminated with signal 9 [Killed] make[3]: *** [T6145] Error 1 *** unexpected failure for T6145(normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/62625154/log.txt It?s hard to pin-point the exact time this started, as recently there a number of unrelated build failures made their way into master. Does anybody know where this comes from and how to fix it? 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 alan.zimm at gmail.com Fri May 15 07:57:37 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 15 May 2015 09:57:37 +0200 Subject: api annotations test failures In-Reply-To: <1431676011.1232.1.camel@joachim-breitner.de> References: <1431676011.1232.1.camel@joachim-breitner.de> Message-ID: That would be me, I will look into it. Current master builds fine though on Phab? Alan On Fri, May 15, 2015 at 9:46 AM, Joachim Breitner wrote: > Hi, > > I observe this on travis: > > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [t10358] Error 1 > > *** unexpected failure for T10358(normal) > > > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [T6145] Error 1 > > *** unexpected failure for T6145(normal) > > https://s3.amazonaws.com/archive.travis-ci.org/jobs/62625154/log.txt > > It?s hard to pin-point the exact time this started, as recently there a > number of unrelated build failures made their way into master. Does > anybody know where this comes from and how to fix it? > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri May 15 08:03:25 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 15 May 2015 10:03:25 +0200 Subject: api annotations test failures In-Reply-To: References: <1431676011.1232.1.camel@joachim-breitner.de> Message-ID: <1431677005.1232.4.camel@joachim-breitner.de> Hi, Am Freitag, den 15.05.2015, 09:57 +0200 schrieb Alan & Kim Zimmerman: > That would be me, I will look into it. Current master builds fine > though on Phab? indeed. Maybe a different linker version? Good luck debugging this :-? 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 mle+hs at mega-nerd.com Fri May 15 08:13:04 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 15 May 2015 18:13:04 +1000 Subject: api annotations test failures In-Reply-To: <1431676011.1232.1.camel@joachim-breitner.de> References: <1431676011.1232.1.camel@joachim-breitner.de> Message-ID: <20150515181304.dd1b70085cbc4e8355582fda@mega-nerd.com> Joachim Breitner wrote: > Hi, > > I observe this on travis: > > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [t10358] Error 1 I've seen this just recently on these tests. Looking at /var/log/messages showed the `ld` process had been killed by the OOM killer. My instance of this was on armhf/linux with only 2Gig of RAM and no swap. I have to recompile the kernel to get swap :-(. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From alan.zimm at gmail.com Fri May 15 08:37:05 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 15 May 2015 10:37:05 +0200 Subject: api annotations test failures In-Reply-To: <20150515181304.dd1b70085cbc4e8355582fda@mega-nerd.com> References: <1431676011.1232.1.camel@joachim-breitner.de> <20150515181304.dd1b70085cbc4e8355582fda@mega-nerd.com> Message-ID: Interesting. The t10358.hs test is a direct clone of a number of others with just the filename to be processed changed. I have a queued TODO to harmonise this into a single module. In other words the build process for this test is identical to say t10357.hs, which runs just before t10358. Alan On Fri, May 15, 2015 at 10:13 AM, Erik de Castro Lopo wrote: > Joachim Breitner wrote: > > > Hi, > > > > I observe this on travis: > > > > Wrong exit code (expected 0 , actual 2 ) > > Stdout: > > > > Stderr: > > collect2: ld terminated with signal 9 [Killed] > > make[3]: *** [t10358] Error 1 > > I've seen this just recently on these tests. Looking at > /var/log/messages showed the `ld` process had been killed > by the OOM killer. > > My instance of this was on armhf/linux with only 2Gig of > RAM and no swap. I have to recompile the kernel to get > swap :-(. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kolmodin at gmail.com Fri May 15 10:30:59 2015 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Fri, 15 May 2015 12:30:59 +0200 Subject: Debugging the RTS In-Reply-To: <5554AF63.5090501@mathematik.uni-marburg.de> References: <5554AF63.5090501@mathematik.uni-marburg.de> Message-ID: Searching for online resources brought me to https://ghc.haskell.org/trac/ghc/wiki/Debugging and https://ghc.haskell.org/trac/ghc/wiki/Debugging/RuntimeSystem This mail seems to be a more detailed description than available on the wiki. That page refers to GHC 6.12. Would it make sense to add some info to the RuntimeSystem page? 2015-05-14 16:21 GMT+02:00 Jost Berthold : > Hi Eric, > > definitely not bit-rotted - the #if DEBUG code is what you get when you > compile with -debug. > > Short roadmap: > > In general, GHC is built in many "ways", the -debug way is one. > Some ways (like -threaded, -eventlog, -debug) are RTS-only, others (like > -prof) lead to different library code. > > Ways are defined in compiler/main/DynFlags.hs as a Haskell data structure. > In _dynamic_flags_, the actual flag strings for the ghc invocation are > defined (like -prof, -threaded), they will activate the respective _Way_. > _wayTag_, in turn, defines short names used as a suffix for *.o and *.a > files, for instance *.p_o for profiling, *.l_o for eventlog. > A number of other functions in there customise behaviour depending on the > ways. Note _wayOptc_ which sets some options for the C compiler, like > -DTRACING for the -eventlog way. However, it does not define DEBUG for the > debug way! > > In mk/ways.mk you will find all the short names, and some more options > are defined (WAY_*_HC_OPTS). These definitions are for the driver script, > and pass on the right (long-name) options to the Haskell compiler to > activate what is inside DynFlags (like -prof for WAY_p_HC_OPTS). > Here we find > WAY_debug_HC_OPTS= -static -optc-DDEBUG -ticky -DTICKY_TICKY > which is what you were looking for > > To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug to > your build.mk (also see mk/config.mk{.in}, which gathers the default ways > to build depending on platform and build configuration). > I guess this might produce quite a number of new warnings and errors if > you do it on a new platform... > > Once you have built this, you can compile with -debug and pass RTS options > to get debug traces and activate sanity checks, like so: > ghc -debug -myprogram.hs -o myprogramDebug > ./myprogramDebug +RTS -Ds -DS > (-DS = sanity checks on, -Ds = scheduler tracing) > The usage message (see /rts/RtsFlags.c) tells you more options you can use. > > Happy debugging! > / Jost > > > On 05/14/2015 10:00 PM, ghc-devs-request at haskell.org wrote: > >> Date: Thu, 14 May 2015 18:36:04 +1000 >> From: Erik de Castro Lopo >> To: ghc-devs at haskell.org >> Subject: Debugging the RTS >> Message-ID: <20150514183604.2476baaaacd6a85ef1430b37 at mega-nerd.com> >> Content-Type: text/plain; charset=US-ASCII >> >> Hi all, >> >> I'm trying to debug a AArch64/Linux specific RTS issue and digging >> around in the rts C code, I see a large amount of code wrapped in >> "#if DEBUG" type statements, but no way to enable in either >> mk/build.mk or it seems in any of the other build related settings >> files in the mk/ directory. >> >> The only way I have found to enable this debug code that actually >> works is to enable this DEBUG code is to edit mk/ghc.mk as follows: >> >> -STANDARD_OPTS += -DCOMPILING_RTS >> +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG >> >> However, once I do that I get a bunch of C synatx errors. >> >> I am doing this wrong or has the DEBUG code bit rotted? >> >> Cheers, >> Erik >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 15 11:17:50 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 May 2015 11:17:50 +0000 Subject: Debugging the RTS In-Reply-To: References: <5554AF63.5090501@mathematik.uni-marburg.de> Message-ID: <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> Good idea. I think it?d great if Jost (or someone else) felt able to update those wiki pages with the info in his email. thanks! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Lennart Kolmodin Sent: 15 May 2015 11:31 To: Jost Berthold Cc: ghc-devs at haskell.org Subject: Re: Debugging the RTS Searching for online resources brought me to https://ghc.haskell.org/trac/ghc/wiki/Debugging and https://ghc.haskell.org/trac/ghc/wiki/Debugging/RuntimeSystem This mail seems to be a more detailed description than available on the wiki. That page refers to GHC 6.12. Would it make sense to add some info to the RuntimeSystem page? 2015-05-14 16:21 GMT+02:00 Jost Berthold >: Hi Eric, definitely not bit-rotted - the #if DEBUG code is what you get when you compile with -debug. Short roadmap: In general, GHC is built in many "ways", the -debug way is one. Some ways (like -threaded, -eventlog, -debug) are RTS-only, others (like -prof) lead to different library code. Ways are defined in compiler/main/DynFlags.hs as a Haskell data structure. In _dynamic_flags_, the actual flag strings for the ghc invocation are defined (like -prof, -threaded), they will activate the respective _Way_. _wayTag_, in turn, defines short names used as a suffix for *.o and *.a files, for instance *.p_o for profiling, *.l_o for eventlog. A number of other functions in there customise behaviour depending on the ways. Note _wayOptc_ which sets some options for the C compiler, like -DTRACING for the -eventlog way. However, it does not define DEBUG for the debug way! In mk/ways.mk you will find all the short names, and some more options are defined (WAY_*_HC_OPTS). These definitions are for the driver script, and pass on the right (long-name) options to the Haskell compiler to activate what is inside DynFlags (like -prof for WAY_p_HC_OPTS). Here we find WAY_debug_HC_OPTS= -static -optc-DDEBUG -ticky -DTICKY_TICKY which is what you were looking for To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug to your build.mk (also see mk/config.mk{.in}, which gathers the default ways to build depending on platform and build configuration). I guess this might produce quite a number of new warnings and errors if you do it on a new platform... Once you have built this, you can compile with -debug and pass RTS options to get debug traces and activate sanity checks, like so: ghc -debug -myprogram.hs -o myprogramDebug ./myprogramDebug +RTS -Ds -DS (-DS = sanity checks on, -Ds = scheduler tracing) The usage message (see /rts/RtsFlags.c) tells you more options you can use. Happy debugging! / Jost On 05/14/2015 10:00 PM, ghc-devs-request at haskell.org wrote: Date: Thu, 14 May 2015 18:36:04 +1000 From: Erik de Castro Lopo > To: ghc-devs at haskell.org Subject: Debugging the RTS Message-ID: <20150514183604.2476baaaacd6a85ef1430b37 at mega-nerd.com> Content-Type: text/plain; charset=US-ASCII Hi all, I'm trying to debug a AArch64/Linux specific RTS issue and digging around in the rts C code, I see a large amount of code wrapped in "#if DEBUG" type statements, but no way to enable in either mk/build.mk or it seems in any of the other build related settings files in the mk/ directory. The only way I have found to enable this debug code that actually works is to enable this DEBUG code is to edit mk/ghc.mk as follows: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG However, once I do that I get a bunch of C synatx errors. I am doing this wrong or has the DEBUG code bit rotted? Cheers, Erik _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From berthold at Mathematik.Uni-Marburg.de Fri May 15 12:12:20 2015 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Fri, 15 May 2015 22:12:20 +1000 Subject: Debugging the RTS In-Reply-To: <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> References: <5554AF63.5090501@mathematik.uni-marburg.de> <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <5555E2A4.4090308@mathematik.uni-marburg.de> On 05/15/2015 09:17 PM, Simon Peyton Jones wrote: > Good idea. I think it?d great if Jost (or someone else) felt able to > update those wiki pages with the info in his email. Sure, will do that. I am not sure whether either of those pages is the best place for information about the GHC ways. Maybe there is already a page about them in the commentary - I will take a look tomorrow and add the information about ways from the mail. If no page exists I'll add a page, and link to it from the Debugging/RuntimeSystem page. A few years ago, I wrote one page specifically about the parallel ways, http://ghc.haskell.org/trac/ghc/wiki/GpHEden/CompilerWays but the information is outdated. / Jost > > thanks! > > Simon > > *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of > *Lennart Kolmodin > *Sent:* 15 May 2015 11:31 > *To:* Jost Berthold > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Debugging the RTS > > Searching for online resources brought me to > > https://ghc.haskell.org/trac/ghc/wiki/Debugging and > > https://ghc.haskell.org/trac/ghc/wiki/Debugging/RuntimeSystem > > This mail seems to be a more detailed description than available on the > wiki. That page refers to GHC 6.12. > > Would it make sense to add some info to the RuntimeSystem > page? > > 2015-05-14 16:21 GMT+02:00 Jost Berthold > >: > > Hi Eric, > > definitely not bit-rotted - the #if DEBUG code is what you get when > you compile with -debug. > > Short roadmap: > > In general, GHC is built in many "ways", the -debug way is one. > Some ways (like -threaded, -eventlog, -debug) are RTS-only, others > (like -prof) lead to different library code. > > Ways are defined in compiler/main/DynFlags.hs as a Haskell data > structure. > In _dynamic_flags_, the actual flag strings for the ghc invocation > are defined (like -prof, -threaded), they will activate the > respective _Way_. > _wayTag_, in turn, defines short names used as a suffix for *.o and > *.a files, for instance *.p_o for profiling, *.l_o for eventlog. > A number of other functions in there customise behaviour depending > on the ways. Note _wayOptc_ which sets some options for the C > compiler, like -DTRACING for the -eventlog way. However, it does not > define DEBUG for the debug way! > > In mk/ways.mk you will find all the short names, > and some more options are defined (WAY_*_HC_OPTS). These definitions > are for the driver script, and pass on the right (long-name) options > to the Haskell compiler to activate what is inside DynFlags (like > -prof for WAY_p_HC_OPTS). > Here we find > WAY_debug_HC_OPTS= -static -optc-DDEBUG -ticky -DTICKY_TICKY > which is what you were looking for > > To build a GHC with debug-way RTS, you need to add GhcRtsWays += > debug to your build.mk (also see mk/config.mk > {.in}, which gathers the default ways to build > depending on platform and build configuration). > I guess this might produce quite a number of new warnings and errors > if you do it on a new platform... > > Once you have built this, you can compile with -debug and pass RTS > options to get debug traces and activate sanity checks, like so: > ghc -debug -myprogram.hs -o myprogramDebug > ./myprogramDebug +RTS -Ds -DS > (-DS = sanity checks on, -Ds = scheduler tracing) > The usage message (see /rts/RtsFlags.c) tells you more options you > can use. > > Happy debugging! > / Jost > > > On 05/14/2015 10:00 PM, ghc-devs-request at haskell.org > wrote: > > Date: Thu, 14 May 2015 18:36:04 +1000 > From: Erik de Castro Lopo > > To: ghc-devs at haskell.org > Subject: Debugging the RTS > Message-ID: > <20150514183604.2476baaaacd6a85ef1430b37 at mega-nerd.com > > > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > I'm trying to debug a AArch64/Linux specific RTS issue and digging > around in the rts C code, I see a large amount of code wrapped in > "#if DEBUG" type statements, but no way to enable in either > mk/build.mk or it seems in any of the other > build related settings > files in the mk/ directory. > > The only way I have found to enable this debug code that actually > works is to enable this DEBUG code is to edit mk/ghc.mk > as follows: > > -STANDARD_OPTS += -DCOMPILING_RTS > +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG > > However, once I do that I get a bunch of C synatx errors. > > I am doing this wrong or has the DEBUG code bit rotted? > > Cheers, > Erik > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Fri May 15 16:51:49 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 May 2015 16:51:49 +0000 Subject: Revert revert revert Message-ID: Devs, Austin I've found out what the problem was, and fixed it. What is the right way to re-do all this? My thought: * git revert 3cf8ecd I think this will re-apply all my patches, in one go. (call this new path 'foogle') * apply the fix as a new patch * validate The history will look odd. In particular, if someone does 'git blame' then lots of unrelated changes will all map to 'foogle'. And 'foogle's commit message will say "revert a revert of 10 patches". Which is not helpful. Best would be to re-apply the patches one by one I suppose. How could I do that? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf | Of GHC | Sent: 14 May 2015 22:26 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic | performance lossage | | #10359: Tuple constraint synonym led to asymptotic performance lossage | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: axch | Owner: | Type: bug | Status: | closed | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Resolution: fixed | Keywords: | Operating System: Linux | Architecture: | x86_64 | Type of failure: Runtime | (amd64) | performance bug | Test Case: | Blocked By: | perf/should_run/T10359 | Related Tickets: | Blocking: | | Differential Revisions: | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Austin Seipp ): | | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" | Revert multiple commits | | This reverts multiple commits from Simon: | | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable- | given" | check happen first | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to | checkValidTyCon | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet | from fixVarSet | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain | (stage2) | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the | build | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation | of error msg | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple | constraints | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out | line | | These break the build by causing Haddock to fail mysteriously when | trying to examine GHC.Prim it seems. | }}} | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets From eric at seidel.io Fri May 15 17:16:39 2015 From: eric at seidel.io (Eric Seidel) Date: Fri, 15 May 2015 10:16:39 -0700 Subject: Revert revert revert In-Reply-To: References: Message-ID: <1431710199.3700252.269821993.4344BB26@webmail.messagingengine.com> You could use `git cherry-pick` (http://git-scm.com/docs/git-cherry-pick) to re-apply each commit individually. I think it would just be a simple $ git cherry-pick for each commit in the reverted list. cherry-pick accepts multiple commits per invocation, but I'm not sure if it will squash them all together into a single commit.. On Fri, May 15, 2015, at 09:51, Simon Peyton Jones wrote: > Devs, Austin > > I've found out what the problem was, and fixed it. > > What is the right way to re-do all this? My thought: > > * git revert 3cf8ecd > I think this will re-apply all my patches, in one go. > (call this new path 'foogle') > > * apply the fix as a new patch > > * validate > > The history will look odd. In particular, if someone does 'git blame' > then lots of unrelated changes will all map to 'foogle'. And 'foogle's > commit message will say "revert a revert of 10 patches". Which is not > helpful. > > Best would be to re-apply the patches one by one I suppose. How could I > do that? > > Simon > > | -----Original Message----- > | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf > | Of GHC > | Sent: 14 May 2015 22:26 > | Cc: ghc-tickets at haskell.org > | Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic > | performance lossage > | > | #10359: Tuple constraint synonym led to asymptotic performance lossage > | -------------------------------------+-------------------------------- > | -- > | -------------------------------------+--- > | Reporter: axch | Owner: > | Type: bug | Status: > | closed > | Priority: normal | Milestone: > | Component: Compiler | Version: 7.6.3 > | Resolution: fixed | Keywords: > | Operating System: Linux | Architecture: > | x86_64 > | Type of failure: Runtime | (amd64) > | performance bug | Test Case: > | Blocked By: | perf/should_run/T10359 > | Related Tickets: | Blocking: > | | Differential Revisions: > | -------------------------------------+-------------------------------- > | -- > | -------------------------------------+--- > | > | Comment (by Austin Seipp ): > | > | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: > | {{{ > | #!CommitTicketReference repository="ghc" > | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" > | Revert multiple commits > | > | This reverts multiple commits from Simon: > | > | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 > | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 > | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 > | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable- > | given" > | check happen first > | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to > | checkValidTyCon > | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule > | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet > | from fixVarSet > | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain > | (stage2) > | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the > | build > | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation > | of error msg > | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple > | constraints > | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out > | line > | > | These break the build by causing Haddock to fail mysteriously when > | trying to examine GHC.Prim it seems. > | }}} > | > | -- > | Ticket URL: > | GHC > | The Glasgow Haskell Compiler > | _______________________________________________ > | ghc-tickets mailing list > | ghc-tickets at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From austin at well-typed.com Fri May 15 17:24:54 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 15 May 2015 12:24:54 -0500 Subject: Revert revert revert In-Reply-To: <1431710199.3700252.269821993.4344BB26@webmail.messagingengine.com> References: <1431710199.3700252.269821993.4344BB26@webmail.messagingengine.com> Message-ID: Yep, I was going to recommend what Eric said, if you want to reapply them all. `git cherry-pick`, if given multiple arguments, will pick multiple commits in the same order you specify them. So you could say: $ git cherry-pick 8da785d 130e93a 5910a1bc8 ... ... with all the commit hashes I previously reverted. That said, the main drawback here is re-applying these commits as they were will cause the build to break again, only to be fixed by a later commit, which hurts bisect. If you want, you can 'amend' the commits using rebase to make sure every individual commit builds. I'm not sure if anyone else has a strong opinion here, though! On Fri, May 15, 2015 at 12:16 PM, Eric Seidel wrote: > You could use `git cherry-pick` > (http://git-scm.com/docs/git-cherry-pick) to re-apply each commit > individually. > > I think it would just be a simple > > $ git cherry-pick > > for each commit in the reverted list. cherry-pick accepts multiple > commits per invocation, but I'm not sure if it will squash them all > together into a single commit.. > > On Fri, May 15, 2015, at 09:51, Simon Peyton Jones wrote: >> Devs, Austin >> >> I've found out what the problem was, and fixed it. >> >> What is the right way to re-do all this? My thought: >> >> * git revert 3cf8ecd >> I think this will re-apply all my patches, in one go. >> (call this new path 'foogle') >> >> * apply the fix as a new patch >> >> * validate >> >> The history will look odd. In particular, if someone does 'git blame' >> then lots of unrelated changes will all map to 'foogle'. And 'foogle's >> commit message will say "revert a revert of 10 patches". Which is not >> helpful. >> >> Best would be to re-apply the patches one by one I suppose. How could I >> do that? >> >> Simon >> >> | -----Original Message----- >> | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf >> | Of GHC >> | Sent: 14 May 2015 22:26 >> | Cc: ghc-tickets at haskell.org >> | Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic >> | performance lossage >> | >> | #10359: Tuple constraint synonym led to asymptotic performance lossage >> | -------------------------------------+-------------------------------- >> | -- >> | -------------------------------------+--- >> | Reporter: axch | Owner: >> | Type: bug | Status: >> | closed >> | Priority: normal | Milestone: >> | Component: Compiler | Version: 7.6.3 >> | Resolution: fixed | Keywords: >> | Operating System: Linux | Architecture: >> | x86_64 >> | Type of failure: Runtime | (amd64) >> | performance bug | Test Case: >> | Blocked By: | perf/should_run/T10359 >> | Related Tickets: | Blocking: >> | | Differential Revisions: >> | -------------------------------------+-------------------------------- >> | -- >> | -------------------------------------+--- >> | >> | Comment (by Austin Seipp ): >> | >> | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: >> | {{{ >> | #!CommitTicketReference repository="ghc" >> | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" >> | Revert multiple commits >> | >> | This reverts multiple commits from Simon: >> | >> | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 >> | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 >> | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 >> | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable- >> | given" >> | check happen first >> | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to >> | checkValidTyCon >> | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule >> | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet >> | from fixVarSet >> | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain >> | (stage2) >> | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the >> | build >> | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation >> | of error msg >> | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple >> | constraints >> | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out >> | line >> | >> | These break the build by causing Haddock to fail mysteriously when >> | trying to examine GHC.Prim it seems. >> | }}} >> | >> | -- >> | Ticket URL: >> | GHC >> | The Glasgow Haskell Compiler >> | _______________________________________________ >> | ghc-tickets mailing list >> | ghc-tickets at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mle+hs at mega-nerd.com Fri May 15 22:56:55 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 16 May 2015 08:56:55 +1000 Subject: Debugging the RTS In-Reply-To: <5554AF63.5090501@mathematik.uni-marburg.de> References: <5554AF63.5090501@mathematik.uni-marburg.de> Message-ID: <20150516085655.b2d384f6683b506776a9d6b9@mega-nerd.com> Jost Berthold wrote: > To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug > to your build.mk (also see mk/config.mk{.in}, which gathers the default > ways to build depending on platform and build configuration). Since we're talking about updating the documentation, I would like to note that the identifuer "GhcRtsWays" is not present at all, anywhere in the GHC tree :-). I do however notice that the debug way is built by default. I was also able to build a ghc-stage2 with the debug RTS by adding "-debug" to GhcStage2HcOpts in mk/build.mk. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From berthold at Mathematik.Uni-Marburg.de Sat May 16 02:30:39 2015 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Sat, 16 May 2015 12:30:39 +1000 Subject: Debugging the RTS In-Reply-To: <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> References: <5554AF63.5090501@mathematik.uni-marburg.de> <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <5556ABCF.8060702@mathematik.uni-marburg.de> On 05/15/2015 09:17 PM, Simon Peyton Jones wrote: > Good idea. I think it?d great if Jost (or someone else) felt able to > update those wiki pages with the info in his email. > I have added https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/CompilerWays and linked to it from the debugging page and the commentary main page. Maybe someone can complete/correct the text about the options definitions inside mk/ways.mk, I was not 100% sure I explained this part correctly. / Jost From thomasmiedema at gmail.com Sat May 16 07:46:28 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sat, 16 May 2015 09:46:28 +0200 Subject: Debugging the RTS In-Reply-To: <5556ABCF.8060702@mathematik.uni-marburg.de> References: <5554AF63.5090501@mathematik.uni-marburg.de> <68d7250a6acf4aadb195179bc1aadb91@DB4PR30MB030.064d.mgd.msft.net> <5556ABCF.8060702@mathematik.uni-marburg.de> Message-ID: On Sat, May 16, 2015 at 4:30 AM, Jost Berthold < berthold at mathematik.uni-marburg.de> wrote: > > I have added > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/CompilerWays Excellent. This page also has some information on ways, maybe they could be merged: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Config It is linked from here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun May 17 12:19:55 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 17 May 2015 14:19:55 +0200 Subject: New GHC performance dashboard Message-ID: <1431865195.19043.12.camel@joachim-breitner.de> Dear ghc developers, last July I set up a performance dashboard for GHC, i.e. a website where you can see our performance numbers (nofib results, performance unit tests, build time etc.) for each commit. I used the software codespeed? as the backend, but I was dissatisfied with it: I found it was a tad too slow, the URLs were hard to share, but ? most importantly ? it tries to be VCS-agnostic, which just doesn?t work well. So in January, I wrote a new tool, called gipeda (Git Performance Dashboard)?. The Haskell part generates static files, which are then displayed using JavaScript in the client (using bootstrap and handlebars), so it is reasonably fast. And it knows about (some) git concepts. I was about to announce it in February, but it ran on the same host as deb.haskell.org, which was compromised a few days before the announcement. Recently, though, davean of the haskell.org Admin team provided me with the required set (thanks for that!), so here it is: http://perf.haskell.org/ghc It should be relatively self-explanatory. Just note that by default it hides boring stuff (commits and results with no significant change), you can select what to show in the top-right corner. It does roughly what our codespeed setup did before, but I have some ideas that go beyond that: Comparison of arbitrary commits, better understanding of git branches and tags, aggregation of performance results from different hosts, e-mail notification. I hope that I?m not the only one who will work on them, and will be happy to receive help. The upcoming ZuriHac is a great possibility to join me here. There are also lot of ways you can contribute without touching Haskell (not that there are many people on this list to whom that matters :-)). Gipeda itself is in no way specific to GHC and you can use it for your own projects. We can possibly even host the results on http://perf.haskell.org/ ? just talk to me. Also, see my gipeda announcement on haskell-cafe (which I?ll write next). Enjoy! Joachim ? https://github.com/tobami/codespeed ? https://github.com/nomeata/gipeda -- 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 karel.gardas at centrum.cz Sun May 17 18:00:27 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun, 17 May 2015 20:00:27 +0200 Subject: New GHC performance dashboard In-Reply-To: <1431865195.19043.12.camel@joachim-breitner.de> References: <1431865195.19043.12.camel@joachim-breitner.de> Message-ID: <5558D73B.9050606@centrum.cz> On 05/17/15 02:19 PM, Joachim Breitner wrote: > provided me with the required set (thanks for that!), so here it is: > > http://perf.haskell.org/ghc > > It should be relatively self-explanatory. Joachim, this is indeed great stuff. But although it's self-explanatory I'm not able to find out what I'm looking for, i.e. simple way to see graph of whole nofib performance results. i.e. not graphs per benchmark, but per whole nofib suite. Is that possible? Thanks! Karel From mail at joachim-breitner.de Sun May 17 18:13:43 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 17 May 2015 20:13:43 +0200 Subject: New GHC performance dashboard In-Reply-To: <5558D73B.9050606@centrum.cz> References: <1431865195.19043.12.camel@joachim-breitner.de> <5558D73B.9050606@centrum.cz> Message-ID: <1431886423.13858.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 17.05.2015, 20:00 +0200 schrieb Karel Gardas: > this is indeed great stuff. But although it's self-explanatory I'm not > able to find out what I'm looking for, i.e. simple way to see graph of > whole nofib performance results. i.e. not graphs per benchmark, but per > whole nofib suite. Is that possible? indeed, not yet! I?m not quite sure if this should be handled in gipeda, or rather in the project-specific script. After all, such an average is quite domain specific (average? weighted average? median? what else). Maybe in the case of nofib, nofib-analize should calculate an "overall performance number" in a sensible way, and gipeda can treat it just like any other benchmark number. I filed https://github.com/nomeata/gipeda/issues/7 for this. 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 lonetiger at gmail.com Sun May 17 18:12:42 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sun, 17 May 2015 18:12:42 +0000 Subject: =?utf-8?Q?Some_test_data?= Message-ID: <5558dce8.e82fc20a.6408.6112@mx.google.com> Hi All, I?m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don?t have at the moment. I require an example file(s) for: - Apple Darwin - Sparc - PowerPC Linux - X86 Linux - X86_64 Linux The test file I require can be generated using ghc -split-objs -keep-tmp-files -v and I?m looking for the file ending with .split_s (e.g. "R:\Temp\ghc1764_0\ghc1764_2.split_s") Any file of a non-trivial nature would be helpful. Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Sun May 17 18:35:05 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun, 17 May 2015 20:35:05 +0200 Subject: Some test data In-Reply-To: <5558dce8.e82fc20a.6408.6112@mx.google.com> References: <5558dce8.e82fc20a.6408.6112@mx.google.com> Message-ID: <5558DF59.4060107@centrum.cz> On 05/17/15 08:12 PM, Tamar Christina wrote: > Hi All, > > I?m currently busy rewriting the GHC-split perl script into Haskell and > require some for the platforms I don?t have at the moment. > > I require an example file(s) for: > - Apple Darwin > - Sparc > - PowerPC Linux > - X86 Linux > - X86_64 Linux > > The test file I require can be generated using > ghc -split-objs -keep-tmp-files -v > > and I?m looking for the file ending with .split_s (e.g. > "R:\Temp\ghc1764_0\ghc1764_2.split_s") > > Any file of a non-trivial nature would be helpful. I can do SPARC for you, but you need to be more specific: 1) what GHC shall I use? Is 7.6.x ok for it? Or 7.10.x? 2) choose one or more files from GHC HEAD and tell what and I'll generate what you need... Karel From lonetiger at gmail.com Sun May 17 19:00:18 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sun, 17 May 2015 19:00:18 +0000 Subject: =?utf-8?Q?Re:_Some_test_data?= In-Reply-To: <5558DF59.4060107@centrum.cz> References: <5558dce8.e82fc20a.6408.6112@mx.google.com>, <5558DF59.4060107@centrum.cz> Message-ID: <5558eca7.b30db50a.1004.ffffce61@mx.google.com> Hi Karel, Thanks for the quick reply, I need them for 7.10.x, as for the files compiler/utils/GraphOps.hs and compiler/deSugar/Coverage.hs seem to be good candidates, if you could do those two for me it would be great. Thanks!, Tamar From: Karel Gardas Sent: ?Sunday?, ?May? ?17?, ?2015 ?20?:?35 To: Tamar Christina Cc: GHC On 05/17/15 08:12 PM, Tamar Christina wrote: > Hi All, > > I?m currently busy rewriting the GHC-split perl script into Haskell and > require some for the platforms I don?t have at the moment. > > I require an example file(s) for: > - Apple Darwin > - Sparc > - PowerPC Linux > - X86 Linux > - X86_64 Linux > > The test file I require can be generated using > ghc -split-objs -keep-tmp-files -v > > and I?m looking for the file ending with .split_s (e.g. > "R:\Temp\ghc1764_0\ghc1764_2.split_s") > > Any file of a non-trivial nature would be helpful. I can do SPARC for you, but you need to be more specific: 1) what GHC shall I use? Is 7.6.x ok for it? Or 7.10.x? 2) choose one or more files from GHC HEAD and tell what and I'll generate what you need... Karel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun May 17 21:07:17 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 17 May 2015 14:07:17 -0700 Subject: New GHC performance dashboard In-Reply-To: <1431865195.19043.12.camel@joachim-breitner.de> References: <1431865195.19043.12.camel@joachim-breitner.de> Message-ID: <1431896720-sup-5081@sabre> Outstanding work! Cheers, Edward Excerpts from Joachim Breitner's message of 2015-05-17 05:19:55 -0700: > Dear ghc developers, > > last July I set up a performance dashboard for GHC, i.e. a website where > you can see our performance numbers (nofib results, performance unit > tests, build time etc.) for each commit. I used the software codespeed? > as the backend, but I was dissatisfied with it: I found it was a tad too > slow, the URLs were hard to share, but ? most importantly ? it tries to > be VCS-agnostic, which just doesn?t work well. > > So in January, I wrote a new tool, called gipeda (Git Performance > Dashboard)?. The Haskell part generates static files, which are then > displayed using JavaScript in the client (using bootstrap and > handlebars), so it is reasonably fast. And it knows about (some) git > concepts. > > I was about to announce it in February, but it ran on the same host as > deb.haskell.org, which was compromised a few days before the > announcement. Recently, though, davean of the haskell.org Admin team > provided me with the required set (thanks for that!), so here it is: > > http://perf.haskell.org/ghc > > It should be relatively self-explanatory. Just note that by default it > hides boring stuff (commits and results with no significant change), you > can select what to show in the top-right corner. > > > It does roughly what our codespeed setup did before, but I have some > ideas that go beyond that: Comparison of arbitrary commits, better > understanding of git branches and tags, aggregation of performance > results from different hosts, e-mail notification. I hope that I?m not > the only one who will work on them, and will be happy to receive help. > The upcoming ZuriHac is a great possibility to join me here. > > There are also lot of ways you can contribute without touching Haskell > (not that there are many people on this list to whom that matters :-)). > > Gipeda itself is in no way specific to GHC and you can use it for your > own projects. We can possibly even host the results on > http://perf.haskell.org/ ? just talk to me. Also, see my gipeda > announcement on haskell-cafe (which I?ll write next). > > Enjoy! > > Joachim > > > ? https://github.com/tobami/codespeed > ? https://github.com/nomeata/gipeda > From alan.zimm at gmail.com Mon May 18 07:57:45 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 18 May 2015 09:57:45 +0200 Subject: GADT confusion Message-ID: Hi all I am working on D836 and have the following test case data MaybeDefault v where SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` The question is, due to the parens, is the return type not the whole RHS? i.e. Similar to how in the signature map :: (a -> b) -> [a] -> [b] the first paramater is a single function. I am sure I am just confused here. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon May 18 08:11:24 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 18 May 2015 11:11:24 +0300 Subject: GADT confusion In-Reply-To: References: Message-ID: <55599EAC.1040605@ro-che.info> On 18/05/15 10:57, Alan & Kim Zimmerman wrote: > Hi all > > I am working on D836 and have the following test case > > data MaybeDefault v where > SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v > -> a -> MaybeDefault [a]) > > GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` > > The question is, due to the parens, is the return type not the whole RHS? > > i.e. Similar to how in the signature > > map :: (a -> b) -> [a] -> [b] > > the first paramater is a single function. > > I am sure I am just confused here. This is the wrong analogy, since (a -> b) in map's type is in the negative position. The correct analogy would be the return type of map :: (a -> b) -> ([a] -> [b]) You could argue it both ways. (But only one of them leads to the above declaration being correct, since the function type is not an instance of MaybeDefault.) Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alan.zimm at gmail.com Mon May 18 08:21:23 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 18 May 2015 10:21:23 +0200 Subject: GADT confusion In-Reply-To: <55599EAC.1040605@ro-che.info> References: <55599EAC.1040605@ro-che.info> Message-ID: Thanks, that makes sense. And the existing behaviour is in the compiler, so the surrounding parens are optional and can/should be stripped (except for Api Annotations) Alan On Mon, May 18, 2015 at 10:11 AM, Roman Cheplyaka wrote: > On 18/05/15 10:57, Alan & Kim Zimmerman wrote: > > Hi all > > > > I am working on D836 and have the following test case > > > > data MaybeDefault v where > > SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v > > -> a -> MaybeDefault [a]) > > > > GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` > > > > The question is, due to the parens, is the return type not the whole RHS? > > > > i.e. Similar to how in the signature > > > > map :: (a -> b) -> [a] -> [b] > > > > the first paramater is a single function. > > > > I am sure I am just confused here. > > This is the wrong analogy, since (a -> b) in map's type is in the > negative position. > > The correct analogy would be the return type of > > map :: (a -> b) -> ([a] -> [b]) > > You could argue it both ways. (But only one of them leads to the above > declaration being correct, since the function type is not an instance of > MaybeDefault.) > > Roman > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 18 12:45:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 18 May 2015 12:45:59 +0000 Subject: Revert revert revert In-Reply-To: References: <1431710199.3700252.269821993.4344BB26@webmail.messagingengine.com> Message-ID: <1a27c5aab1714b0b873368e432db7373@DB4PR30MB030.064d.mgd.msft.net> OK thanks. I have cherry-picked, combined, validated, and pushed. Should be good now. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Austin Seipp | Sent: 15 May 2015 18:25 | To: Eric Seidel | Cc: ghc-devs at haskell.org | Subject: Re: Revert revert revert | | Yep, I was going to recommend what Eric said, if you want to reapply | them all. `git cherry-pick`, if given multiple arguments, will pick | multiple commits in the same order you specify them. So you could say: | | $ git cherry-pick 8da785d 130e93a 5910a1bc8 ... | | ... with all the commit hashes I previously reverted. | | That said, the main drawback here is re-applying these commits as they | were will cause the build to break again, only to be fixed by a later | commit, which hurts bisect. If you want, you can 'amend' the commits | using rebase to make sure every individual commit builds. I'm not sure | if anyone else has a strong opinion here, though! | | On Fri, May 15, 2015 at 12:16 PM, Eric Seidel wrote: | > You could use `git cherry-pick` | > (http://git-scm.com/docs/git-cherry-pick) to re-apply each commit | > individually. | > | > I think it would just be a simple | > | > $ git cherry-pick | > | > for each commit in the reverted list. cherry-pick accepts multiple | > commits per invocation, but I'm not sure if it will squash them all | > together into a single commit.. | > | > On Fri, May 15, 2015, at 09:51, Simon Peyton Jones wrote: | >> Devs, Austin | >> | >> I've found out what the problem was, and fixed it. | >> | >> What is the right way to re-do all this? My thought: | >> | >> * git revert 3cf8ecd | >> I think this will re-apply all my patches, in one go. | >> (call this new path 'foogle') | >> | >> * apply the fix as a new patch | >> | >> * validate | >> | >> The history will look odd. In particular, if someone does 'git | blame' | >> then lots of unrelated changes will all map to 'foogle'. And | >> 'foogle's commit message will say "revert a revert of 10 patches". | >> Which is not helpful. | >> | >> Best would be to re-apply the patches one by one I suppose. How | >> could I do that? | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On | >> | Behalf Of GHC | >> | Sent: 14 May 2015 22:26 | >> | Cc: ghc-tickets at haskell.org | >> | Subject: Re: [GHC] #10359: Tuple constraint synonym led to | >> | asymptotic performance lossage | >> | | >> | #10359: Tuple constraint synonym led to asymptotic performance | >> | lossage | >> | | >> | -------------------------------------+--------------------------- | -- | >> | --- | >> | -- | >> | -------------------------------------+--- | >> | Reporter: axch | Owner: | >> | Type: bug | Status: | >> | closed | >> | Priority: normal | Milestone: | >> | Component: Compiler | Version: | 7.6.3 | >> | Resolution: fixed | Keywords: | >> | Operating System: Linux | Architecture: | >> | x86_64 | >> | Type of failure: Runtime | (amd64) | >> | performance bug | Test Case: | >> | Blocked By: | perf/should_run/T10359 | >> | Related Tickets: | Blocking: | >> | | Differential Revisions: | >> | | >> | -------------------------------------+--------------------------- | -- | >> | --- | >> | -- | >> | -------------------------------------+--- | >> | | >> | Comment (by Austin Seipp ): | >> | | >> | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: | >> | {{{ | >> | #!CommitTicketReference repository="ghc" | >> | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" | >> | Revert multiple commits | >> | | >> | This reverts multiple commits from Simon: | >> | | >> | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 | >> | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 | >> | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 | >> | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the | "matchable- | >> | given" | >> | check happen first | >> | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to | >> | checkValidTyCon | >> | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock | submodule | >> | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate | >> | transCloVarSet from fixVarSet | >> | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in | HscMain | >> | (stage2) | >> | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix | >> | the build | >> | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in | >> | capitalisation of error msg | >> | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple | >> | constraints | >> | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented- | out | >> | line | >> | | >> | These break the build by causing Haddock to fail mysteriously | >> | when trying to examine GHC.Prim it seems. | >> | }}} | >> | | >> | -- | >> | Ticket URL: | >> | | >> | GHC | >> | The Glasgow Haskell Compiler | >> | _______________________________________________ | >> | ghc-tickets mailing list | >> | ghc-tickets at haskell.org | >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Mon May 18 13:15:49 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 18 May 2015 15:15:49 +0200 Subject: api annotations test failures In-Reply-To: References: <1431676011.1232.1.camel@joachim-breitner.de> <20150515181304.dd1b70085cbc4e8355582fda@mega-nerd.com> Message-ID: It looks like it is related somehow to having PartialTypeSignatures enabled, having no other warnings/errors, and not going beyond parseSource. Then it sometimes outputs the typed hole warnings, and sometimes not. Alan On Fri, May 15, 2015 at 10:37 AM, Alan & Kim Zimmerman wrote: > Interesting. The t10358.hs test is a direct clone of a number of others > with just the filename to be processed changed. > > I have a queued TODO to harmonise this into a single module. > > In other words the build process for this test is identical to say > t10357.hs, which runs just before t10358. > > Alan > > > On Fri, May 15, 2015 at 10:13 AM, Erik de Castro Lopo < > mle+hs at mega-nerd.com> wrote: > >> Joachim Breitner wrote: >> >> > Hi, >> > >> > I observe this on travis: >> > >> > Wrong exit code (expected 0 , actual 2 ) >> > Stdout: >> > >> > Stderr: >> > collect2: ld terminated with signal 9 [Killed] >> > make[3]: *** [t10358] Error 1 >> >> I've seen this just recently on these tests. Looking at >> /var/log/messages showed the `ld` process had been killed >> by the OOM killer. >> >> My instance of this was on armhf/linux with only 2Gig of >> RAM and no swap. I have to recompile the kernel to get >> swap :-(. >> >> Cheers, >> Erik >> -- >> ---------------------------------------------------------------------- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at kuhtz.eu Mon May 18 20:18:55 2015 From: haskell at kuhtz.eu (Lars Kuhtz) Date: Mon, 18 May 2015 13:18:55 -0700 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <567D3794-E088-45A1-8687-A877D47F59C1@me.com> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> Message-ID: <555A492F.5000209@kuhtz.eu> I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: > Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. > > Regards, > Malcolm > > On 7 May 2015, at 22:15, Tomas Carnecky wrote: > >> That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). >> >> On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: >> I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. >> >> Regards, >> Malcolm >> >> On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: >> >>> On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: >>> >>> [...] >>> >>>> Regarding licensing issues: perhaps we should simply ask Malcolm >>>> Wallace if he would consider changing the license for the sake of GHC? >>>> Or perhaps he could grant a custom-tailored license to the GHC >>>> project? After all, the project page [1] says: " If that's a problem >>>> for you, contact me to make other arrangements." >>> >>> Fyi, Neil talked to him[1]: >>> >>> | I talked to Malcolm. His contention is that it doesn't actually change >>> | the license of the ghc package. As such, it's just a single extra >>> | license to add to a directory full of licenses, which is no big deal. >>> >>> >>> [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From fuuzetsu at fuuzetsu.co.uk Tue May 19 02:13:58 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 19 May 2015 03:13:58 +0100 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <1431621823.22790.1.camel@debian.org> References: <554FA5D6.3010403@fuuzetsu.co.uk> <1431621823.22790.1.camel@debian.org> Message-ID: <555A9C66.10203@fuuzetsu.co.uk> On 05/14/2015 05:43 PM, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: >> I'd like to bring some attention to ticket #4012 about non-determinism. >> As many of you may know, the nix package manager distributes binaries >> throughout its binary caches. The binaries are shared as long as the >> hash of some of their inputs matches: this means that we can end up with >> two of the same hashes of inputs but thanks to #4012 means that the >> actual contents can differ. You end up with machines with some packages >> built locally and some elsewhere and due to non-determinism, the GHC >> package IDs don't line up and everything is broken. > > is NixOS sensitive to changes in the build directory. Debian is, and > since 7.8 the build path creeps into the interface files and affects the > hash: https://bugs.debian.org/785282 > > But you probably are not, otherwise you?d have complained when 7.8 was > out, and not now :-) > > Greetings, > Joachim > Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ?calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not?. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- Mateusz K. From carter.schonwald at gmail.com Tue May 19 05:31:33 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 19 May 2015 01:31:33 -0400 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: <555A492F.5000209@kuhtz.eu> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> <555A492F.5000209@kuhtz.eu> Message-ID: I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3! On Monday, May 18, 2015, Lars Kuhtz wrote: > I work for PivotCloud. We use Haskell/GHC in our production system on the > server side and on the client side. > > My experience is that any license that contains the string "GPL" can cause > problems in an corporate context, no matter if it actually is a legal issue > or not. > > Folks who are responsible for making decisions about legal implications of > the usage of third party software don't always have experience with open > source software. Also they are often not familiar with the technical > details of "derived work", different types of linking, or the subtleties of > distinguishing between build-, link-, and run-time dependencies in modern > software engineering pipelines. So, any mentioning of "LGPL" (or similar) > potentially causes overhead in the adaption. > > Regards, > Lars > > On 5/7/15 11:10 PM, Malcolm Wallace wrote: > >> Exactly. My post was an attempt to elicit response from anyone to whom >> it matters. There is no point in worrying about hypothetical licensing >> problems - let's hear about the real ones. >> >> Regards, >> Malcolm >> >> On 7 May 2015, at 22:15, Tomas Carnecky wrote: >> >> That doesn't mean those people don't exist. Maybe they do but are too >>> afraid to speak up (due to corporate policy or whatever). >>> >>> On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace >>> wrote: >>> I also note that in this discussion, so far not a single person has said >>> that the cpphs licence would actually be a problem for them. >>> >>> Regards, >>> Malcolm >>> >>> On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: >>> >>> On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: >>>> >>>> [...] >>>> >>>> Regarding licensing issues: perhaps we should simply ask Malcolm >>>>> Wallace if he would consider changing the license for the sake of GHC? >>>>> Or perhaps he could grant a custom-tailored license to the GHC >>>>> project? After all, the project page [1] says: " If that's a problem >>>>> for you, contact me to make other arrangements." >>>>> >>>> >>>> Fyi, Neil talked to him[1]: >>>> >>>> | I talked to Malcolm. His contention is that it doesn't actually change >>>> | the license of the ghc package. As such, it's just a single extra >>>> | license to add to a directory full of licenses, which is no big deal. >>>> >>>> >>>> [1]: >>>> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pumpkingod at gmail.com Tue May 19 05:46:52 2015 From: pumpkingod at gmail.com (Daniel Peebles) Date: Tue, 19 May 2015 01:46:52 -0400 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <555A9C66.10203@fuuzetsu.co.uk> References: <554FA5D6.3010403@fuuzetsu.co.uk> <1431621823.22790.1.camel@debian.org> <555A9C66.10203@fuuzetsu.co.uk> Message-ID: Don't Nix builds all happen in a randomly generated temporary directory by default? Then you just copy to $out in installPhase. Perhaps stabilizing the build directory would help alleviate some of the immediate problems, if what Joachim is describing affects us too. On Mon, May 18, 2015 at 10:13 PM, Mateusz Kowalczyk wrote: > On 05/14/2015 05:43 PM, Joachim Breitner wrote: > > Hi, > > > > Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: > >> I'd like to bring some attention to ticket #4012 about non-determinism. > >> As many of you may know, the nix package manager distributes binaries > >> throughout its binary caches. The binaries are shared as long as the > >> hash of some of their inputs matches: this means that we can end up with > >> two of the same hashes of inputs but thanks to #4012 means that the > >> actual contents can differ. You end up with machines with some packages > >> built locally and some elsewhere and due to non-determinism, the GHC > >> package IDs don't line up and everything is broken. > > > > is NixOS sensitive to changes in the build directory. Debian is, and > > since 7.8 the build path creeps into the interface files and affects the > > hash: https://bugs.debian.org/785282 > > > > But you probably are not, otherwise you?d have complained when 7.8 was > > out, and not now :-) > > > > Greetings, > > Joachim > > > > Not a problem for nix, the paths are are calculated based on the > derivation inputs. I don't want to go into details but if same > expression goes in, same path comes out. If the path that comes out is > different, you simply don't get to use it. More or less nix does > ?calculate the store path from this expression, check if it exists in > binary caches and fetch it if it does, build if it does not?. > > So for us the store paths in the interface files would always be the > same for the same inputs hence no problem there. > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Tue May 19 06:26:35 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 19 May 2015 08:26:35 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> <555A492F.5000209@kuhtz.eu> Message-ID: On 05/19/2015 07:31 AM, Carter Schonwald wrote: > I imagine your ghc build uses gcc to invoke the system assembler and linker > on your Linux servers, :-) and that's gplv3! That is of no consequence licensing-wise since those are a) separate programs/executables, thus "derived work" doesn't enter into it at any level, except... b) if the output contains bits of of the programs themselves, but e.g. gcc (and one assumes the linker, etc.) have specific licensing exemptions for the output. (And this *is* something that you can quickly explain to the lawyerly types.) From fuuzetsu at fuuzetsu.co.uk Tue May 19 06:27:18 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 19 May 2015 07:27:18 +0100 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: References: <554FA5D6.3010403@fuuzetsu.co.uk> <1431621823.22790.1.camel@debian.org> <555A9C66.10203@fuuzetsu.co.uk> Message-ID: <555AD7C6.2050102@fuuzetsu.co.uk> On 05/19/2015 06:46 AM, Daniel Peebles wrote: > Don't Nix builds all happen in a randomly generated temporary directory by > default? Then you just copy to $out in installPhase. Perhaps stabilizing > the build directory would help alleviate some of the immediate problems, if > what Joachim is describing affects us too. Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I suppose this could be a problem for us though I'd like to see it first before trying to work around it. > On Mon, May 18, 2015 at 10:13 PM, Mateusz Kowalczyk > wrote: > >> On 05/14/2015 05:43 PM, Joachim Breitner wrote: >>> Hi, >>> >>> Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: >>>> I'd like to bring some attention to ticket #4012 about non-determinism. >>>> As many of you may know, the nix package manager distributes binaries >>>> throughout its binary caches. The binaries are shared as long as the >>>> hash of some of their inputs matches: this means that we can end up with >>>> two of the same hashes of inputs but thanks to #4012 means that the >>>> actual contents can differ. You end up with machines with some packages >>>> built locally and some elsewhere and due to non-determinism, the GHC >>>> package IDs don't line up and everything is broken. >>> >>> is NixOS sensitive to changes in the build directory. Debian is, and >>> since 7.8 the build path creeps into the interface files and affects the >>> hash: https://bugs.debian.org/785282 >>> >>> But you probably are not, otherwise you?d have complained when 7.8 was >>> out, and not now :-) >>> >>> Greetings, >>> Joachim >>> >> >> Not a problem for nix, the paths are are calculated based on the >> derivation inputs. I don't want to go into details but if same >> expression goes in, same path comes out. If the path that comes out is >> different, you simply don't get to use it. More or less nix does >> ?calculate the store path from this expression, check if it exists in >> binary caches and fetch it if it does, build if it does not?. >> >> So for us the store paths in the interface files would always be the >> same for the same inputs hence no problem there. >> >> -- >> -- Mateusz K. From spam at scientician.net Tue May 19 06:27:44 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 19 May 2015 08:27:44 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> <555A492F.5000209@kuhtz.eu> Message-ID: On 05/19/2015 08:26 AM, Bardur Arantsson wrote: > On 05/19/2015 07:31 AM, Carter Schonwald wrote: >> I imagine your ghc build uses gcc to invoke the system assembler and linker >> on your Linux servers, :-) and that's gplv3! > > That is of no consequence licensing-wise since those are > > a) separate programs/executables, thus "derived work" doesn't enter > into it at any level, except... > > b) if the output contains bits of of the programs themselves, but > e.g. gcc (and one assumes the linker, etc.) have specific > licensing exemptions for the output. > > (And this *is* something that you can quickly explain to the lawyerly > types.) > Oh, and it's also pretty well-established at this point, though I'm not aware of any specific cases that have gone to the courts. From mail at joachim-breitner.de Tue May 19 07:33:59 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 May 2015 09:33:59 +0200 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <555AD7C6.2050102@fuuzetsu.co.uk> References: <554FA5D6.3010403@fuuzetsu.co.uk> <1431621823.22790.1.camel@debian.org> <555A9C66.10203@fuuzetsu.co.uk> <555AD7C6.2050102@fuuzetsu.co.uk> Message-ID: <1432020839.2029.1.camel@joachim-breitner.de> Hi, Am Dienstag, den 19.05.2015, 07:27 +0100 schrieb Mateusz Kowalczyk: > On 05/19/2015 06:46 AM, Daniel Peebles wrote: > > Don't Nix builds all happen in a randomly generated temporary directory by > > default? Then you just copy to $out in installPhase. Perhaps stabilizing > > the build directory would help alleviate some of the immediate problems, if > > what Joachim is describing affects us too. > > Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I > suppose this could be a problem for us though I'd like to see it first > before trying to work around it. it?s easy to check: Just run $ ghc --show-iface /usr/lib/ghc/base-4.7.0.2/System/Info.hi|grep Dep addDependentFile "/build/ghc-LIQtDg/ghc-7.8.4/includes/ghcplatform.h" addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" If you see the build path appearing there, you are affected by the bug. 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 m at tweag.io Tue May 19 09:04:33 2015 From: m at tweag.io (Boespflug, Mathieu) Date: Tue, 19 May 2015 11:04:33 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> <555A492F.5000209@kuhtz.eu> Message-ID: On 19 May 2015 at 08:26, Bardur Arantsson wrote: > On 05/19/2015 07:31 AM, Carter Schonwald wrote: > > I imagine your ghc build uses gcc to invoke the system assembler and > linker > > on your Linux servers, :-) and that's gplv3! > > That is of no consequence licensing-wise since those are > > a) separate programs/executables, thus "derived work" doesn't enter > into it at any level, except... > > b) if the output contains bits of of the programs themselves, but > e.g. gcc (and one assumes the linker, etc.) have specific > licensing exemptions for the output. > > (And this *is* something that you can quickly explain to the lawyerly > types.) Both conditions likewise hold true for cpphs-as-an-external-process-bundled-with-GHC. So any particular remaining concern there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Tue May 19 10:35:46 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Tue, 19 May 2015 12:35:46 +0200 Subject: Interactions between type-checker plugins Message-ID: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> Hi, My apologies for this rather lengthy email. I have a question about how type-checker plugins should interact. My situation is the following: I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-checker plugin that can prove equalities involving a new type-level operation GCD. In the following, the type-checker plugin involving the stand type-level operations is called ?A?, and the type checker involving the new GCD operations is called ?B?. When type-checker plugin A encounters: [W] GCD 6 8 + x ~ x + GCD 9 6 It knows that (+) is commutative, so it can prove the above equality _given_ that "GCD 6 8 ~ GCD 9 6? holds. So what type-checker plugin A does now is emits a new wanted constraints: [W] GCD 6 8 ~ GCD 9 6 And remembers that it emitted this wanted constraint. In type-checker plugin lingo, it returns: TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6?] Now whenever type-checker plugin encounters [W] GCD 6 8 + x ~ x + GCD 9 6 again, it checks to see if the discharged constraint [W] GCD 6 8 ~ GCD 9 6 Is already solved, is disproven, or unsolved. If the discharged constraint is solved, it will return: TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6?] [] If the discharged constraint is dis proven, it returns: TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6?] And otherwise, it doesn?t do anything: TcPluginOk [] [] Now, type-checker plugin B, the one that knows about GCD, comes along. It sees: [W] GCD 6 8 + x ~ x + GCD 9 6 [W] GCD 6 8 ~ GCD 9 6 I doesn?t know anything about (+); but it does know about GCD, and clearly sees that GCD 6 8 is not equal to GCD 9 6. So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. In type-checker plugin lingo it says: TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6?] According to https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcInteract.hs#L547 What happens next is that the insoluble constraint [W] GCD 6 8 ~ GCD 9 6 is taken of the work list for all plugins. However! the same thing happens when a plugin is able to prove a constraint. That is, if B would have (erroneously) returned: TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6?] [] Then there is _no_ way for type-checker plugin A to know what happened. Were its discharged constraints taken from the work-list because it was insoluble? or because it was solved? This is a problem because to me it seems that the work list is the only way that two type-checker plugins can communicate. I guess my question is: if not through the work list, how are type-checker plugins supposed to communicate? Am I going about it all wrong in terms how I should be writing type-checker plugins? Or, should the type of ?TcPluginSolver? (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcRnTypes.html#t:TcPluginSolver) be updated to?: ``` type TcPluginSolver = [Ct] -- ^ Given constraints -> [Ct] -- ^ Derived constraints -> [Ct] -- ^ Wanted constraints -> [Ct] -- ^ Insoluble constraints -> TcPluginM TcPluginResult ``` Best regards, Christiaan From malcolm.wallace at me.com Tue May 19 11:10:58 2015 From: malcolm.wallace at me.com (malcolm.wallace) Date: Tue, 19 May 2015 11:10:58 +0000 (GMT) Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal Message-ID: <59313347-cfde-4153-92f1-daee3304c77a@me.com> How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 19 11:31:11 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 19 May 2015 11:31:11 +0000 Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, #8555 In-Reply-To: <20150519111939.26830.49263@phabricator.haskell.org> References: <20150519111939.26830.49263@phabricator.haskell.org> Message-ID: <8eaed407dbd1413d83b5cb3e511d2a6d@DB4PR30MB030.064d.mgd.msft.net> Devs, The failure seems to be for ghci.debugger/print007. I can't see the build log on Phabricator, so I can't see what went wrong. Works on my machine. I do see print007.stderr : Warning: -O conflicts with --interactive; -O ignored. which seems odd. Why not fix the test? Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 19 May 2015 12:20 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, | #8555 | | Harbormaster failed to build B4076: rGHCfc8c5e7a5168: Test Trac #8799, | #8555! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCfc8c5e7a5168 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite From austin at well-typed.com Tue May 19 12:43:41 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 19 May 2015 07:43:41 -0500 Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, #8555 In-Reply-To: <8eaed407dbd1413d83b5cb3e511d2a6d@DB4PR30MB030.064d.mgd.msft.net> References: <20150519111939.26830.49263@phabricator.haskell.org> <8eaed407dbd1413d83b5cb3e511d2a6d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I've reverted this change - it also passes perfectly fine on my machine, which is why I reverted so I could investigate further, so it wouldn't hold up any patches people submit (it's much more important to have HEAD always building because of that!) I can look into it on the buildbot soon. At the very least, this build machine seems to be very good at exposing weird edge cases... On Tue, May 19, 2015 at 6:31 AM, Simon Peyton Jones wrote: > Devs, > > The failure seems to be for ghci.debugger/print007. I can't see the build log on Phabricator, so I can't see what went wrong. Works on my machine. > > I do see print007.stderr > > : Warning: > -O conflicts with --interactive; -O ignored. > > which seems odd. Why not fix the test? > > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 19 May 2015 12:20 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, > | #8555 > | > | Harbormaster failed to build B4076: rGHCfc8c5e7a5168: Test Trac #8799, > | #8555! > | > | USERS > | simonpj (Author) > | GHC - Testsuite (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHCfc8c5e7a5168 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Testsuite > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From metaniklas at gmail.com Tue May 19 13:51:38 2015 From: metaniklas at gmail.com (Niklas Larsson) Date: Tue, 19 May 2015 15:51:38 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <59313347-cfde-4153-92f1-daee3304c77a@me.com> References: <59313347-cfde-4153-92f1-daee3304c77a@me.com> Message-ID: <555b3feb.ed2a980a.27b6.ffffc8c6@mx.google.com> Hi! GMP is optional, anyone who cares about the license can build with integer-simple. Regards, Niklas ----- Ursprungligt meddelande ----- Fr?n: "malcolm.wallace" Skickat: ?2015-?05-?19 13:11 Till: "Lars Kuhtz" Kopia: "ghc-devs at haskell.org" ?mne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Tue May 19 13:56:25 2015 From: malcolm.wallace at me.com (malcolm.wallace) Date: Tue, 19 May 2015 13:56:25 +0000 (GMT) Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal Message-ID: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Yes, this is what I am asking. ?Is the LGPL so dangerous to your business, that you have taken the steps necessary to build a special GHC using integer-simple instead of integer-gmp? ?Or are the lawyers happy simply for the option to be available, but unexercised? ?(If the latter, then I could suggest that ghc using cpphs by default, but allowing the option of a different preprocessor, might suffice?) Regards, Malcolm On 19 May, 2015,at 02:51 PM, Niklas Larsson wrote: Hi! GMP is optional, anyone who cares about the license can build with integer-simple. Regards, Niklas Fr?n: malcolm.wallace Skickat: ?2015-?05-?19 13:11 Till: Lars Kuhtz Kopia: ghc-devs at haskell.org ?mne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Tue May 19 15:16:45 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 19 May 2015 17:16:45 +0200 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> <567D3794-E088-45A1-8687-A877D47F59C1@me.com> <555A492F.5000209@kuhtz.eu> Message-ID: On 05/19/2015 11:04 AM, Boespflug, Mathieu wrote: > On 19 May 2015 at 08:26, Bardur Arantsson wrote: > >> On 05/19/2015 07:31 AM, Carter Schonwald wrote: >>> I imagine your ghc build uses gcc to invoke the system assembler and >> linker >>> on your Linux servers, :-) and that's gplv3! >> >> That is of no consequence licensing-wise since those are >> >> a) separate programs/executables, thus "derived work" doesn't enter >> into it at any level, except... >> >> b) if the output contains bits of of the programs themselves, but >> e.g. gcc (and one assumes the linker, etc.) have specific >> licensing exemptions for the output. >> >> (And this *is* something that you can quickly explain to the lawyerly >> types.) > > > Both conditions likewise hold true for > cpphs-as-an-external-process-bundled-with-GHC. So any particular remaining > concern there? > > Not from me, certainly. I was just trying to point out that the example given (Linux, gcc, ...) was invalid. I would be more worried about e.g. Linux distributions *if* cpphs were under some weird license, but since it's LGPL that shouldn't prompt any issues. (We're talking "mere aggregation" in the terms used in the GPL.) As always, IANAL and in particular I am not *your* or anybody else's lawyer :). Regards, From adam at well-typed.com Tue May 19 16:00:53 2015 From: adam at well-typed.com (Adam Gundry) Date: Tue, 19 May 2015 17:00:53 +0100 Subject: Interactions between type-checker plugins In-Reply-To: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> References: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> Message-ID: <555B5E35.5040008@well-typed.com> Hi Christiaan, It may well be that we can improve the typechecker plugin interface. In particular, I at least haven't devoted a great deal of thought to how multiple plugins work together in practice (although theoretically it is possible to compose constraint solvers, even establishing termination of the composition is a bit fiddly). The thing that surprises me about your email is that when your plugin A sees [W] GCD 6 8 + x ~ x + GCD 9 6 it emits [W] GCD 6 8 ~ GCD 9 6 without solving the original constraint, so we end up with [W] GCD 6 8 + x ~ x + GCD 9 6 [W] GCD 6 8 ~ GCD 9 6 and proceed from there. What I'd expect is for the original constraint to be declared as solved (because it follows from the new wanted). Then plugin B will run and notice that the constraint is insoluble; there's no need for plugin A to keep track of the relationship between the constraints. Does that make sense? Why does plugin A need to remember the relationship between constraints it has seen on previous iterations? Hope this helps, Adam On 19/05/15 11:35, Christiaan Baaij wrote: > Hi, > > My apologies for this rather lengthy email. > > I have a question about how type-checker plugins should interact. > My situation is the following: > I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-checker plugin that can prove equalities involving a new type-level operation GCD. > In the following, the type-checker plugin involving the stand type-level operations is called ?A?, and the type checker involving the new GCD operations is called ?B?. > > When type-checker plugin A encounters: > [W] GCD 6 8 + x ~ x + GCD 9 6 > > It knows that (+) is commutative, so it can prove the above equality _given_ that "GCD 6 8 ~ GCD 9 6? holds. > So what type-checker plugin A does now is emits a new wanted constraints: > [W] GCD 6 8 ~ GCD 9 6 > And remembers that it emitted this wanted constraint. > In type-checker plugin lingo, it returns: > TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6?] > > Now whenever type-checker plugin encounters > [W] GCD 6 8 + x ~ x + GCD 9 6 > again, it checks to see if the discharged constraint > [W] GCD 6 8 ~ GCD 9 6 > Is already solved, is disproven, or unsolved. > If the discharged constraint is solved, it will return: > TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6?] [] > If the discharged constraint is dis proven, it returns: > TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6?] > And otherwise, it doesn?t do anything: > TcPluginOk [] [] > > Now, type-checker plugin B, the one that knows about GCD, comes along. > It sees: > [W] GCD 6 8 + x ~ x + GCD 9 6 > [W] GCD 6 8 ~ GCD 9 6 > I doesn?t know anything about (+); but it does know about GCD, and clearly sees that GCD 6 8 is not equal to GCD 9 6. > So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. > In type-checker plugin lingo it says: > TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6?] > > According to https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcInteract.hs#L547 > What happens next is that the insoluble constraint > [W] GCD 6 8 ~ GCD 9 6 > is taken of the work list for all plugins. > However! the same thing happens when a plugin is able to prove a constraint. > That is, if B would have (erroneously) returned: > TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6?] [] > > Then there is _no_ way for type-checker plugin A to know what happened. > Were its discharged constraints taken from the work-list because it was insoluble? or because it was solved? > This is a problem because to me it seems that the work list is the only way that two type-checker plugins can communicate. > > I guess my question is: if not through the work list, how are type-checker plugins supposed to communicate? > Am I going about it all wrong in terms how I should be writing type-checker plugins? > Or, should the type of ?TcPluginSolver? (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcRnTypes.html#t:TcPluginSolver) be updated to?: > > ``` > type TcPluginSolver = [Ct] -- ^ Given constraints > -> [Ct] -- ^ Derived constraints > -> [Ct] -- ^ Wanted constraints > -> [Ct] -- ^ Insoluble constraints > -> TcPluginM TcPluginResult > ``` > > Best regards, > > Christiaan -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From christiaan.baaij at gmail.com Tue May 19 16:44:15 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Tue, 19 May 2015 18:44:15 +0200 Subject: Interactions between type-checker plugins In-Reply-To: References: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> Message-ID: I have yet to test this properly, but I don't think your suggestions (which you happen to give with 1 minute of eachother...) play nicely with error reporting. Here is an output of my testsuite: ``` [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) [GHC.TypeLits.Normalise changed] tests/ErrorTests.hs:1:1: Warning: Couldn't match type ?GCD 6 9? with ?GCD 6 8? NB: ?GCD? is a type function, and may not be injective Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) tests/ErrorTests.hs:14:13: Warning: Couldn't match type ?GCD 6 8? with ?4? Expected type: Proxy (GCD 6 8) -> Proxy 4 Actual type: Proxy 4 -> Proxy 4 In the expression: id In an equation for ?testFail1?: testFail1 = id [2 of 2] Compiling Main ( tests/Main.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) [GHC.TypeLits.Normalise changed] Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... Running 1 test suites... Test suite test-ghc-tynat-normalise: RUNNING... ghc-typelits-natnormalise Basic functionality GCD 6 8 ~ 2: OK GCD 6 8 + x ~ x + GCD 10 8: OK errors GCD 6 8 ~ 4: OK GCD 6 8 + x ~ x + GCD 9 6: FAIL No exception! 1 out of 4 tests failed (0.00s) ``` Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'. There's a two things you may notice * The first error message's location is '1:1' * Evaluation the function with the type-error does not raise an exception. So by solving the constraint "GCD 6 8 + x ~ x + GCD 9 6" The boxed/run-time coercion no longer errors. Also, I'm using newSimpleWanted ( https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcMType.html#v:newSimpleWanted) to create the new wanted constraint. But for some reason the errror message doesn't get the source-error location of the original constraint. Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted constraints? The sources for the plugins are over here: https://github.com/christiaanb/ghc-typelits-natnormalise https://github.com/christiaanb/ghc-typelits-extra Cheers, Christiaan On 19 May 2015 at 18:01, Iavor Diatchki wrote: > Hi Christiaan, > > > Plugins should return the solved constraints in the first field of > `TcPLuginOk`, and additional sub-goals in the second. > The constraints in the first list are marked as solved, and do not need to > be processed further, while the constraints > in the second list will be added to the work queue, for further > processing. Also, the solutions of wanted goals may be in terms of other > as yet unsolved things. > > I think that there are two situations when a plugin might return an empty > first list, but new work in the second list. > Both are about computing new facts, and thus "communicating" with other > plugins: > 1. Discover new given facts: the plugin was presented with some > givens, and it computed some additional givens that it thinks might be of > use to someone else (typically these are equality constraints) > 2. Discover new derived facts: the plugin was presented with a mixture > of wanted and givens, and it thinks that the new derived facts might be > useful by specializing the problem----derived facts help with type > inference by instantiating unification variables. > > Generally, I don't think a plugin should ever need to emit new wanted > constraints without solving anything. It'd be interesting if that could > happen though... > > Another thing that might be relevant: at present, GHC's constraint solver > does not do back tracking. So there is no way for a plugin (or other parts > of the constraint solver) to say: "I'll emit this new wanted constraint, > and depending on if it was proved or disproved do something". Another way > to think of his is that constraints are either solved or unsolved, but > being unsolved does not mean that they are disproved. Now, there is a > mechanism to mark a constraint as "never solvable", but currently this is > mostly used for error reporting. > > For your concrete example though, the plugin can actually commit to the > given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if > "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: > > Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "GCD 6 8 ~ GCD 9 6" > Plugin B: "GCD 6 8 ~ GCD 9 6" --> impossible > Done. > > > -Iavor > > > > On Tue, May 19, 2015 at 3:35 AM, Christiaan Baaij < > christiaan.baaij at gmail.com> wrote: > >> I have a question about how type-checker plugins should interact. >> My situation is the following: >> I have two type-checker plugins, one that can solve equalities involving >> the standard type-level operations on kind Nat (+,*,-,^), and another >> type-checker plugin that can prove equalities involving a new type-level >> operation GCD. >> In the following, the type-checker plugin involving the stand type-level >> operations is called ?A?, and the type checker involving the new GCD >> operations is called ?B?. >> >> When type-checker plugin A encounters: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> >> It knows that (+) is commutative, so it can prove the above equality >> _given_ that "GCD 6 8 ~ GCD 9 6? holds. >> So what type-checker plugin A does now is emits a new wanted constraints: >> [W] GCD 6 8 ~ GCD 9 6 >> And remembers that it emitted this wanted constraint. >> In type-checker plugin lingo, it returns: >> TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6?] >> >> > > Now whenever type-checker plugin encounters >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> again, it checks to see if the discharged constraint >> [W] GCD 6 8 ~ GCD 9 6 >> Is already solved, is disproven, or unsolved. >> If the discharged constraint is solved, it will return: >> TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6?] [] >> If the discharged constraint is dis proven, it returns: >> TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6?] >> And otherwise, it doesn?t do anything: >> TcPluginOk [] [] >> >> > > >> Now, type-checker plugin B, the one that knows about GCD, comes along. >> It sees: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> [W] GCD 6 8 ~ GCD 9 6 >> I doesn?t know anything about (+); but it does know about GCD, and >> clearly sees that GCD 6 8 is not equal to GCD 9 6. >> So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. >> In type-checker plugin lingo it says: >> TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6?] >> >> According to >> https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcInteract.hs#L547 >> What happens next is that the insoluble constraint >> [W] GCD 6 8 ~ GCD 9 6 >> is taken of the work list for all plugins. >> However! the same thing happens when a plugin is able to prove a >> constraint. >> That is, if B would have (erroneously) returned: >> TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6?] [] >> >> Then there is _no_ way for type-checker plugin A to know what happened. >> Were its discharged constraints taken from the work-list because it was >> insoluble? or because it was solved? >> This is a problem because to me it seems that the work list is the only >> way that two type-checker plugins can communicate. >> >> I guess my question is: if not through the work list, how are >> type-checker plugins supposed to communicate? >> Am I going about it all wrong in terms how I should be writing >> type-checker plugins? >> Or, should the type of ?TcPluginSolver? ( >> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcRnTypes.html#t:TcPluginSolver) >> be updated to?: >> >> ``` >> type TcPluginSolver = [Ct] -- ^ Given constraints >> -> [Ct] -- ^ Derived constraints >> -> [Ct] -- ^ Wanted constraints >> -> [Ct] -- ^ Insoluble constraints >> -> TcPluginM TcPluginResult >> ``` >> >> Best regards, >> >> Christiaan >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Wed May 20 07:26:12 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 20 May 2015 09:26:12 +0200 Subject: Interactions between type-checker plugins In-Reply-To: References: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> Message-ID: <02ED7DE7-27DA-49FC-8DC6-FB2D6124DD63@gmail.com> Hi Iavor, Adam, List, I managed to fix the error message location by using: `newWantedEvVarNC`(https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcSMonad.html#v:newWantedEvVarNC ) So now the output of my test suite is: ``` [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) [GHC.TypeLits.Normalise changed] tests/ErrorTests.hs:14:13: Warning: Couldn't match type ?GCD 6 8? with ?4? Expected type: Proxy (GCD 6 8) -> Proxy 4 Actual type: Proxy 4 -> Proxy 4 In the expression: id In an equation for ?testFail1?: testFail1 = id tests/ErrorTests.hs:17:13: Warning: Couldn't match type ?GCD 6 9? with ?GCD 6 8? NB: ?GCD? is a type function, and may not be injective Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) In the expression: id In an equation for ?testFail2?: testFail2 = id [2 of 2] Compiling Main ( tests/Main.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) [GHC.TypeLits.Normalise changed] Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... Running 1 test suites... Test suite test-ghc-tynat-normalise: RUNNING... ghc-typelits-natnormalise Basic functionality GCD 6 8 ~ 2: OK GCD 6 8 + x ~ x + GCD 10 8: OK errors GCD 6 8 ~ 4: OK GCD 6 8 + x ~ x + GCD 9 6: FAIL No exception! 1 out of 4 tests failed (0.01s) ``` But evaluating the expression still doesn?t throw an exception because I solved the original constraint. ? Christiaan > On 19 May 2015, at 18:44, Christiaan Baaij wrote: > > I have yet to test this properly, but I don't think your suggestions (which you happen to give with 1 minute of eachother...) play nicely with error reporting. > Here is an output of my testsuite: > > ``` > [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) [GHC.TypeLits.Normalise changed] > > tests/ErrorTests.hs:1:1: Warning: > Couldn't match type ?GCD 6 9? with ?GCD 6 8? > NB: ?GCD? is a type function, and may not be injective > Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) > Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) > > tests/ErrorTests.hs:14:13: Warning: > Couldn't match type ?GCD 6 8? with ?4? > Expected type: Proxy (GCD 6 8) -> Proxy 4 > Actual type: Proxy 4 -> Proxy 4 > In the expression: id > In an equation for ?testFail1?: testFail1 = id > [2 of 2] Compiling Main ( tests/Main.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) [GHC.TypeLits.Normalise changed] > Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... > Running 1 test suites... > Test suite test-ghc-tynat-normalise: RUNNING... > ghc-typelits-natnormalise > Basic functionality > GCD 6 8 ~ 2: OK > GCD 6 8 + x ~ x + GCD 10 8: OK > errors > GCD 6 8 ~ 4: OK > GCD 6 8 + x ~ x + GCD 9 6: FAIL > No exception! > > 1 out of 4 tests failed (0.00s) > ``` > > Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'. > There's a two things you may notice > * The first error message's location is '1:1' > * Evaluation the function with the type-error does not raise an exception. > > So by solving the constraint > "GCD 6 8 + x ~ x + GCD 9 6" > The boxed/run-time coercion no longer errors. > Also, I'm using newSimpleWanted (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcMType.html#v:newSimpleWanted ) to create the new wanted constraint. > But for some reason the errror message doesn't get the source-error location of the original constraint. > Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted constraints? > > The sources for the plugins are over here: > https://github.com/christiaanb/ghc-typelits-natnormalise > https://github.com/christiaanb/ghc-typelits-extra > > Cheers, > > Christiaan > > > > On 19 May 2015 at 18:01, Iavor Diatchki > wrote: > Hi Christiaan, > > > Plugins should return the solved constraints in the first field of `TcPLuginOk`, and additional sub-goals in the second. > The constraints in the first list are marked as solved, and do not need to be processed further, while the constraints > in the second list will be added to the work queue, for further processing. Also, the solutions of wanted goals may be in terms of other as yet unsolved things. > > I think that there are two situations when a plugin might return an empty first list, but new work in the second list. > Both are about computing new facts, and thus "communicating" with other plugins: > 1. Discover new given facts: the plugin was presented with some givens, and it computed some additional givens that it thinks might be of use to someone else (typically these are equality constraints) > 2. Discover new derived facts: the plugin was presented with a mixture of wanted and givens, and it thinks that the new derived facts might be useful by specializing the problem----derived facts help with type inference by instantiating unification variables. > > Generally, I don't think a plugin should ever need to emit new wanted constraints without solving anything. It'd be interesting if that could happen though... > > Another thing that might be relevant: at present, GHC's constraint solver does not do back tracking. So there is no way for a plugin (or other parts of the constraint solver) to say: "I'll emit this new wanted constraint, and depending on if it was proved or disproved do something". Another way to think of his is that constraints are either solved or unsolved, but being unsolved does not mean that they are disproved. Now, there is a mechanism to mark a constraint as "never solvable", but currently this is mostly used for error reporting. > > For your concrete example though, the plugin can actually commit to the given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: > > Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "GCD 6 8 ~ GCD 9 6" > Plugin B: "GCD 6 8 ~ GCD 9 6" --> impossible > Done. > > > -Iavor > > > > On Tue, May 19, 2015 at 3:35 AM, Christiaan Baaij > wrote: > I have a question about how type-checker plugins should interact. > My situation is the following: > I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-checker plugin that can prove equalities involving a new type-level operation GCD. > In the following, the type-checker plugin involving the stand type-level operations is called ?A?, and the type checker involving the new GCD operations is called ?B?. > > When type-checker plugin A encounters: > [W] GCD 6 8 + x ~ x + GCD 9 6 > > It knows that (+) is commutative, so it can prove the above equality _given_ that "GCD 6 8 ~ GCD 9 6? holds. > So what type-checker plugin A does now is emits a new wanted constraints: > [W] GCD 6 8 ~ GCD 9 6 > And remembers that it emitted this wanted constraint. > In type-checker plugin lingo, it returns: > TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6?] > > > > Now whenever type-checker plugin encounters > [W] GCD 6 8 + x ~ x + GCD 9 6 > again, it checks to see if the discharged constraint > [W] GCD 6 8 ~ GCD 9 6 > Is already solved, is disproven, or unsolved. > If the discharged constraint is solved, it will return: > TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6?] [] > If the discharged constraint is dis proven, it returns: > TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6?] > And otherwise, it doesn?t do anything: > TcPluginOk [] [] > > > > Now, type-checker plugin B, the one that knows about GCD, comes along. > It sees: > [W] GCD 6 8 + x ~ x + GCD 9 6 > [W] GCD 6 8 ~ GCD 9 6 > I doesn?t know anything about (+); but it does know about GCD, and clearly sees that GCD 6 8 is not equal to GCD 9 6. > So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. > In type-checker plugin lingo it says: > TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6?] > > According to https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcInteract.hs#L547 > What happens next is that the insoluble constraint > [W] GCD 6 8 ~ GCD 9 6 > is taken of the work list for all plugins. > However! the same thing happens when a plugin is able to prove a constraint. > That is, if B would have (erroneously) returned: > TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6?] [] > > Then there is _no_ way for type-checker plugin A to know what happened. > Were its discharged constraints taken from the work-list because it was insoluble? or because it was solved? > This is a problem because to me it seems that the work list is the only way that two type-checker plugins can communicate. > > I guess my question is: if not through the work list, how are type-checker plugins supposed to communicate? > Am I going about it all wrong in terms how I should be writing type-checker plugins? > Or, should the type of ?TcPluginSolver? (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcRnTypes.html#t:TcPluginSolver ) be updated to?: > > ``` > type TcPluginSolver = [Ct] -- ^ Given constraints > -> [Ct] -- ^ Derived constraints > -> [Ct] -- ^ Wanted constraints > -> [Ct] -- ^ Insoluble constraints > -> TcPluginM TcPluginResult > ``` > > Best regards, > > Christiaan > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed May 20 08:34:44 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 20 May 2015 10:34:44 +0200 Subject: API to =?UTF-8?Q?=E2=80=9Craise?= =?UTF-8?Q?_concern=E2=80=9D?= in Phabricator Message-ID: <1432110884.2048.7.camel@joachim-breitner.de> Hi, with https://perf.haskell.org/ghc/ up and running I?m wondering about the best way to notify us about regressions. A mail to ghc-commits is one possibility, but maybe it?s neater to integrate that into Phabricator. How hard would it be comment and optionally ?raise concern? with a commit automatically? Or, put differently, I want a script that takes a git commit, a comment, and a flag that indicated whether a concern should be raised, and then does that on Phabricator. It seems that https://phabricator.haskell.org/conduit/ is an entry point, but I only see methods for attaching comments to DRs. 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 Wed May 20 10:48:50 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 May 2015 10:48:50 +0000 Subject: GHC Trac slow again Message-ID: <296026e675c04a309bfcec97f016242d@DB4PR30MB030.064d.mgd.msft.net> Herbert Did you manage to fix your Trac re-initialiser? Trac is soul-destroyingly slow today Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed May 20 10:53:56 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 20 May 2015 12:53:56 +0200 Subject: GHC Trac slow again In-Reply-To: <296026e675c04a309bfcec97f016242d@DB4PR30MB030.064d.mgd.msft.net> (Simon Peyton Jones's message of "Wed, 20 May 2015 10:48:50 +0000") References: <296026e675c04a309bfcec97f016242d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87siarzfi3.fsf@gmail.com> On 2015-05-20 at 12:48:50 +0200, Simon Peyton Jones wrote: > Did you manage to fix your Trac re-initialiser? Trac is soul-destroyingly slow today ...the periodic apache2 reloader is still working... not sure why it's still slow *today*... (otoh, for me it's currently not that slow) From gale at sefer.org Wed May 20 11:12:49 2015 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 20 May 2015 14:12:49 +0300 Subject: FFI problems on 64-bit Windows Message-ID: As I am sure many people have noticed, there is currently a serious problem with FFI on 64-bit Windows. It often happens that when you link in FFI against a standard DLL, the resulting application segfaults as soon as any function from the DLL is called. I experienced this problem with Bryan's text-icu library when I linked it against the standard Windows 64-bit DLLs provided by the ICU project. In this case, the workaround I found is to link instead against DLLs built using mingw-w64 and provided as part of MSYS2: https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119737.html On reddit, /u/awson (is that Kyra?) pointed out that this issue is probably caused by a serious bug in GNU binutils that was fixed about two months ago: https://sourceware.org/bugzilla/show_bug.cgi?id=16598 Is it possible to update the MSYS2/mingw-w64 toolchain used by GHC to a recent version that includes this fix? Thanks, Yitz From ben at smart-cactus.org Wed May 20 12:38:17 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 20 May 2015 08:38:17 -0400 Subject: Some test data In-Reply-To: <5558dce8.e82fc20a.6408.6112@mx.google.com> References: <5558dce8.e82fc20a.6408.6112@mx.google.com> Message-ID: <87bnhfl8zq.fsf@gmail.com> Tamar Christina writes: > Hi All, > > > I?m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don?t have at the moment. > > > I require an example file(s) for: > > - Apple Darwin > > - Sparc > > - PowerPC Linux > > - X86 Linux > > - X86_64 Linux > Is this to say that you have an ARM? If not I would be willing to do some testing once my hardware arrives (which may be a month or so sadly; it's currently drifting across the Atlantic). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From christiaan.baaij at gmail.com Wed May 20 13:02:27 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 20 May 2015 15:02:27 +0200 Subject: [commit: ghc] master: Refactor tuple constraints (ffc2150) In-Reply-To: <20150518124535.0FF013A300@ghc.haskell.org> References: <20150518124535.0FF013A300@ghc.haskell.org> Message-ID: <494EA8E8-1509-48B9-A687-C2BEAB46E3A6@gmail.com> Hi, This patch broke the ?Binary? instance for ?IfaceType? in ?iface/IfaceType.hs? Specifically, it changed: ``` put_ bh (IfaceLitTy n) = do { putByte bh 30; put_ bh n } ``` to: ``` put_ bh (IfaceLitTy n) = do { putByte bh 7; put_ bh n } ``` However, the ?get? definition was left as: ``` 30 -> do n <- get bh return (IfaceLitTy n) ``` I don?t know what?s preferable: - revert the definition of `put_`, - or update the `get` definition to `7` Regards, Christiaan > On 18 May 2015, at 14:45, 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/ffc21506894c7887d3620423aaf86bc6113a1071/ghc > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 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 ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits From lonetiger at gmail.com Wed May 20 13:24:29 2015 From: lonetiger at gmail.com (Tamar Christina) Date: Wed, 20 May 2015 06:24:29 -0700 Subject: Some test data Message-ID: <-4483404920143717312@unknownmsgid> Hi Ben, I haven't noticed a target for ARM in the split script which is why it wasn't in my list. I'll check later but my guess if the ARM version of the compiler does not support obj-split. Cheers, TamarFrom: Ben Gamari Sent: ?5/?20/?2015 14:38 To: Tamar Christina; GHC Subject: Re: Some test data Tamar Christina writes: > Hi All, > > > I?m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don?t have at the moment. > > > I require an example file(s) for: > > - Apple Darwin > > - Sparc > > - PowerPC Linux > > - X86 Linux > > - X86_64 Linux > Is this to say that you have an ARM? If not I would be willing to do some testing once my hardware arrives (which may be a month or so sadly; it's currently drifting across the Atlantic). Cheers, - Ben From simonpj at microsoft.com Wed May 20 13:33:30 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 May 2015 13:33:30 +0000 Subject: [commit: ghc] master: Refactor tuple constraints (ffc2150) In-Reply-To: <494EA8E8-1509-48B9-A687-C2BEAB46E3A6@gmail.com> References: <20150518124535.0FF013A300@ghc.haskell.org> <494EA8E8-1509-48B9-A687-C2BEAB46E3A6@gmail.com> Message-ID: <2243b95faa0d4c808825bd02f554a135@DB4PR30MB030.064d.mgd.msft.net> Eek. Well spotted. The "30" is really odd compared to all the other instances, so best to use "7". I'm validating a patch now. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Christiaan Baaij | Sent: 20 May 2015 14:02 | To: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Refactor tuple constraints | (ffc2150) | | Hi, | | This patch broke the ?Binary? instance for ?IfaceType? in | ?iface/IfaceType.hs? | Specifically, it changed: | | ``` | put_ bh (IfaceLitTy n) | = do { putByte bh 30; put_ bh n } | ``` | | to: | | ``` | put_ bh (IfaceLitTy n) | = do { putByte bh 7; put_ bh n } | ``` | | However, the ?get? definition was left as: | | ``` | 30 -> do n <- get bh | return (IfaceLitTy n) | ``` | | I don?t know what?s preferable: | - revert the definition of `put_`, | - or update the `get` definition to `7` | | Regards, | | Christiaan | | | > On 18 May 2015, at 14:45, 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/ffc21506894c7887d3620423aaf8 | 6bc6113a1071/ghc | > | >> --------------------------------------------------------------- | > | > commit ffc21506894c7887d3620423aaf86bc6113a1071 | > Author: Simon Peyton Jones | > Date: Mon May 11 23:19:14 2015 +0100 | > | > Refactor tuple constraints | > | > Make tuple constraints be handled by a perfectly ordinary | > type class, with the component constraints being the | > superclasses: | > class (c1, c2) => (c2, c2) | > | > This change was provoked by | > | > #10359 inability to re-use a given tuple | > constraint as a whole | > | > #9858 confusion between term tuples | > and constraint tuples | > | > but it's generally a very nice simplification. We get rid of | > - In Type, the TuplePred constructor of PredTree, | > and all the code that dealt with TuplePreds | > - In TcEvidence, the constructors EvTupleMk, EvTupleSel | > | > See Note [How tuples work] in TysWiredIn. | > | > Of course, nothing is ever entirely simple. This one | > proved quite fiddly. | > | > - I did quite a bit of renaming, which makes this patch | > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. | > | > - I made constraint tuples known-key rather than wired-in. | > This is different to boxed/unboxed tuples, but it proved | > awkward to have all the superclass selectors wired-in. | > Easier just to use the standard mechanims. | > | > - While I was fiddling with known-key names, I split the TH Name | > definitions out of DsMeta into a new module THNames. That | meant | > that the known-key names can all be gathered in PrelInfo, | without | > causing module loops. | > | > - I found that the parser was parsing an import item like | > T( .. ) | > as a *data constructor* T, and then using setRdrNameSpace to | > fix it. Stupid! So I changed the parser to parse a *type | > constructor* T, which means less use of setRdrNameSpace. | > | > I also improved setRdrNameSpace to behave better on Exact | Names. | > Largely on priciple; I don't think it matters a lot. | > | > - When compiling a data type declaration for a wired-in thing | like | > tuples (,), or lists, we don't really need to look at the | > declaration. We have the wired-in thing! And not doing so | avoids | > having to line up the uniques for data constructor workers etc. | > See Note [Declarations for wired-in things] | > | > - I found that FunDeps.oclose wasn't taking superclasses into | > account; easily fixed. | > | > - Some error message refactoring for invalid constraints in | TcValidity | > | > - Haddock needs to absorb the change too; so there is a submodule | update | > | > | >> --------------------------------------------------------------- | > | > ffc21506894c7887d3620423aaf86bc6113a1071 | > compiler/basicTypes/BasicTypes.hs | 21 +- | > compiler/basicTypes/DataCon.hs | 1 - | > compiler/basicTypes/RdrName.hs | 28 +- | > compiler/basicTypes/Unique.hs | 28 +- | > compiler/basicTypes/VarSet.hs | 23 +- | > compiler/coreSyn/CoreLint.hs | 2 +- | > compiler/coreSyn/MkCore.hs | 7 +- | > compiler/coreSyn/PprCore.hs | 4 +- | > compiler/deSugar/Check.hs | 2 +- | > compiler/deSugar/DsArrows.hs | 2 +- | > compiler/deSugar/DsBinds.hs | 25 +- | > compiler/deSugar/DsCCall.hs | 6 +- | > compiler/deSugar/DsExpr.hs | 5 +- | > compiler/deSugar/DsMeta.hs | 840 +---------- | ---------- | > compiler/deSugar/Match.hs | 4 +- | > compiler/ghc.cabal.in | 3 +- | > compiler/ghci/RtClosureInspect.hs | 7 +- | > compiler/hsSyn/Convert.hs | 4 +- | > compiler/hsSyn/HsExpr.hs | 3 +- | > compiler/hsSyn/HsPat.hs | 35 +- | > compiler/hsSyn/HsTypes.hs | 2 +- | > compiler/iface/BinIface.hs | 14 +- | > compiler/iface/BuildTyCl.hs | 4 + | > compiler/iface/IfaceSyn.hs | 9 +- | > compiler/iface/IfaceType.hs | 154 ++-- | > compiler/iface/TcIface.hs | 84 ++- | > compiler/main/Constants.hs | 3 + | > compiler/main/HscMain.hs | 11 +- | > compiler/parser/Parser.y | 20 +- | > compiler/parser/RdrHsSyn.hs | 164 +++- | > compiler/prelude/PrelInfo.hs | 28 +- | > compiler/prelude/PrelNames.hs | 17 - | > compiler/prelude/PrelRules.hs | 6 +- | > compiler/prelude/PrimOp.hs | 2 +- | > compiler/prelude/THNames.hs | 836 | ++++++++++++++++++++ | > compiler/prelude/TysWiredIn.hs | 269 ++++--- | > compiler/rename/RnEnv.hs | 1 + | > compiler/rename/RnNames.hs | 42 +- | > compiler/rename/RnSplice.hs | 6 +- | > compiler/simplStg/UnariseStg.hs | 10 +- | > compiler/specialise/Specialise.hs | 3 +- | > compiler/stranal/WwLib.hs | 6 +- | > compiler/typecheck/FunDeps.hs | 32 +- | > compiler/typecheck/TcBinds.hs | 52 +- | > compiler/typecheck/TcCanonical.hs | 32 - | > compiler/typecheck/TcErrors.hs | 2 - | > compiler/typecheck/TcEvidence.hs | 15 +- | > compiler/typecheck/TcExpr.hs | 10 +- | > compiler/typecheck/TcGenDeriv.hs | 15 +- | > compiler/typecheck/TcHsSyn.hs | 5 +- | > compiler/typecheck/TcHsType.hs | 15 +- | > compiler/typecheck/TcInstDcls.hs | 4 +- | > compiler/typecheck/TcInteract.hs | 11 +- | > compiler/typecheck/TcMType.hs | 1 - | > compiler/typecheck/TcPat.hs | 2 +- | > compiler/typecheck/TcRnMonad.hs | 4 + | > compiler/typecheck/TcSimplify.hs | 1 - | > compiler/typecheck/TcSplice.hs | 2 +- | > compiler/typecheck/TcTyClsDecls.hs | 20 +- | > compiler/typecheck/TcType.hs | 3 - | > compiler/typecheck/TcValidity.hs | 186 +++-- | > compiler/types/TyCon.hs | 34 +- | > compiler/types/Type.hs | 7 +- | > compiler/types/TypeRep.hs | 11 +- | > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- | > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- | > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- | > libraries/ghc-prim/GHC/Classes.hs | 44 +- | > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- | > libraries/ghc-prim/GHC/Types.hs | 2 +- | > .../should_fail/NotRelaxedExamples.stderr | 17 +- | > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- | > testsuite/tests/module/all.T | 2 +- | > testsuite/tests/module/mod89.hs | 2 + | > testsuite/tests/module/mod89.stderr | 10 +- | > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- | > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- | > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- | > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- | > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- | > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- | > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- | > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - | > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - | > utils/genprimopcode/Main.hs | 49 +- | > utils/haddock | 2 +- | > 86 files changed, 1985 insertions(+), 1672 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 | ffc21506894c7887d3620423aaf86bc6113a1071 | > _______________________________________________ | > ghc-commits mailing list | > ghc-commits at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gale at sefer.org Wed May 20 13:39:32 2015 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 20 May 2015 16:39:32 +0300 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: The license issue is a real concern for any company using GHC to develop a product whose binaries they distribute to customers. And it is concern for GHC itself, if we want GHC to continue to be viewed as a candidate for use in industry. The real issue is not whether you can explain why this license is OK, or whether anyone is actually going to the trouble of building GHC without GMP. The issue is the risk of a *potential* legal issue and its potential disastrous cost as *perceived* by lawyers and management. A potential future engineering cost, no matter how large and even if only marginally practical, is perceived as manageable and controllable, whereas a poorly understood potential future legal threat is perceived as an existential risk to the entire company. With GMP, we do have an engineering workaround to side-step the legal problem entirely if needed. Whereas if cpphs were to be linked into GHC with its current license, I would be ethically obligated to report it to my superiors, and the response might very well be: Then never mind, let's do the simple and safe thing and just rewrite all of our applications in Java or C#. Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP. Thanks, Yitz From spam at scientician.net Wed May 20 14:01:45 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 20 May 2015 16:01:45 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: On 05/20/2015 03:39 PM, Yitzchak Gale wrote: [--snip--] > Keeping the license as is seems to be important to Malcolm. > So could we have an option to build GHC without cpphs > and instead use it as a stand-alone external program? > That would make the situation no worse than GMP. I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Regards, From fuuzetsu at fuuzetsu.co.uk Wed May 20 18:01:26 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 20 May 2015 19:01:26 +0100 Subject: Non-deterministic package IDs are really bad in 7.10 In-Reply-To: <1432020839.2029.1.camel@joachim-breitner.de> References: <554FA5D6.3010403@fuuzetsu.co.uk> <1431621823.22790.1.camel@debian.org> <555A9C66.10203@fuuzetsu.co.uk> <555AD7C6.2050102@fuuzetsu.co.uk> <1432020839.2029.1.camel@joachim-breitner.de> Message-ID: <555CCBF6.60801@fuuzetsu.co.uk> On 05/19/2015 08:33 AM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 19.05.2015, 07:27 +0100 schrieb Mateusz Kowalczyk: >> On 05/19/2015 06:46 AM, Daniel Peebles wrote: >>> Don't Nix builds all happen in a randomly generated temporary directory by >>> default? Then you just copy to $out in installPhase. Perhaps stabilizing >>> the build directory would help alleviate some of the immediate problems, if >>> what Joachim is describing affects us too. >> >> Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I >> suppose this could be a problem for us though I'd like to see it first >> before trying to work around it. > > it?s easy to check: Just run > $ ghc --show-iface /usr/lib/ghc/base-4.7.0.2/System/Info.hi|grep Dep > addDependentFile "/build/ghc-LIQtDg/ghc-7.8.4/includes/ghcplatform.h" > addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h" > addDependentFile "/usr/include/stdc-predef.h" Seems we're good?: [nix-shell:~]$ ghc --show-iface /nix/store/rnxk1a1bz4rgy1rw4973blbfp9f0ic89-ghc-7.8.4/lib/ghc-7.8.4/base-4.7.0.2/System/Info.hi | grep Dep addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h" addDependentFile "/nix/store/6k9z1sfl7kghmagwd205k3i81pbcw57s-glibc-2.21/include/stdc-predef.h" With our new architecture using 7.10.1: [nix-shell:~]$ ghc --show-iface /nix/store/j50pk13r5jysqk20gsyjdi89qcpfii57-ghc-7.10.1/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/System/Info.hi | grep Dep addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h" addDependentFile "/nix/store/c2zjp7bqmp5wvpkrpl7p7sfhxbdyfryy-glibc-2.21/include/stdc-predef.h" > If you see the build path appearing there, you are affected by the bug. In light of above, I don't know if I should be happy because we don't seem to be affected or scared that it's just subtle and will bite us regardless. > > Greetings, > Joachim > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Mateusz K. From iavor.diatchki at gmail.com Wed May 20 21:51:14 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 20 May 2015 14:51:14 -0700 Subject: Interactions between type-checker plugins In-Reply-To: <02ED7DE7-27DA-49FC-8DC6-FB2D6124DD63@gmail.com> References: <70D1E8C3-A98B-4347-B4EA-56372E9C72B8@gmail.com> <02ED7DE7-27DA-49FC-8DC6-FB2D6124DD63@gmail.com> Message-ID: Hi, I am not sure about the "deferred type errors", as I never use that feature. To create new wanted variables, usually you use "newWantedEvVar". This gives you some evidence (well, really a place-holder for the actual evidence), and a "freshness" flag. You do two different things depending on the freshness: - If the evidence is "Fresh", then you have a brand new wanted constraint and you emit it as a new sub-goal (i.e., the usual thing) - if the evidence is cached, this means that this same constraint already exists; in that case you can use the returned evidence as needed, but you don't emit a new wanted constraint. This is a bit nicer than the "newWantedEvVarNC" as it generates fewer constraints. -Iavor On Wed, May 20, 2015 at 12:26 AM, Christiaan Baaij < christiaan.baaij at gmail.com> wrote: > Hi Iavor, Adam, List, > > I managed to fix the error message location by using: > `newWantedEvVarNC`( > https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcSMonad.html#v:newWantedEvVarNC > ) > > So now the output of my test suite is: > ``` > [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, > dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o > ) [GHC.TypeLits.Normalise changed] > > tests/ErrorTests.hs:14:13: Warning: > Couldn't match type ?GCD 6 8? with ?4? > Expected type: Proxy (GCD 6 8) -> Proxy 4 > Actual type: Proxy 4 -> Proxy 4 > In the expression: id > In an equation for ?testFail1?: testFail1 = id > > tests/ErrorTests.hs:17:13: Warning: > Couldn't match type ?GCD 6 9? with ?GCD 6 8? > NB: ?GCD? is a type function, and may not be injective > Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) > Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) > In the expression: id > In an equation for ?testFail2?: testFail2 = id > [2 of 2] Compiling Main ( tests/Main.hs, > dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) > [GHC.TypeLits.Normalise changed] > Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... > Running 1 test suites... > Test suite test-ghc-tynat-normalise: RUNNING... > ghc-typelits-natnormalise > Basic functionality > GCD 6 8 ~ 2: OK > GCD 6 8 + x ~ x + GCD 10 8: OK > errors > GCD 6 8 ~ 4: OK > GCD 6 8 + x ~ x + GCD 9 6: FAIL > No exception! > > 1 out of 4 tests failed (0.01s) > ``` > > But evaluating the expression still doesn?t throw an exception because I > solved the original constraint. > > ? Christiaan > > On 19 May 2015, at 18:44, Christiaan Baaij > wrote: > > I have yet to test this properly, but I don't think your suggestions > (which you happen to give with 1 minute of eachother...) play nicely with > error reporting. > Here is an output of my testsuite: > > ``` > [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, > dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o > ) [GHC.TypeLits.Normalise changed] > > tests/ErrorTests.hs:1:1: Warning: > Couldn't match type ?GCD 6 9? with ?GCD 6 8? > NB: ?GCD? is a type function, and may not be injective > Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) > Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) > > tests/ErrorTests.hs:14:13: Warning: > Couldn't match type ?GCD 6 8? with ?4? > Expected type: Proxy (GCD 6 8) -> Proxy 4 > Actual type: Proxy 4 -> Proxy 4 > In the expression: id > In an equation for ?testFail1?: testFail1 = id > [2 of 2] Compiling Main ( tests/Main.hs, > dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) > [GHC.TypeLits.Normalise changed] > Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... > Running 1 test suites... > Test suite test-ghc-tynat-normalise: RUNNING... > ghc-typelits-natnormalise > Basic functionality > GCD 6 8 ~ 2: OK > GCD 6 8 + x ~ x + GCD 10 8: OK > errors > GCD 6 8 ~ 4: OK > GCD 6 8 + x ~ x + GCD 9 6: FAIL > No exception! > > 1 out of 4 tests failed (0.00s) > ``` > > Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'. > There's a two things you may notice > * The first error message's location is '1:1' > * Evaluation the function with the type-error does not raise an exception. > > So by solving the constraint > "GCD 6 8 + x ~ x + GCD 9 6" > The boxed/run-time coercion no longer errors. > Also, I'm using newSimpleWanted ( > https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcMType.html#v:newSimpleWanted) > to create the new wanted constraint. > But for some reason the errror message doesn't get the source-error > location of the original constraint. > Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted > constraints? > > The sources for the plugins are over here: > https://github.com/christiaanb/ghc-typelits-natnormalise > https://github.com/christiaanb/ghc-typelits-extra > > Cheers, > > Christiaan > > > > On 19 May 2015 at 18:01, Iavor Diatchki wrote: > >> Hi Christiaan, >> >> >> Plugins should return the solved constraints in the first field of >> `TcPLuginOk`, and additional sub-goals in the second. >> The constraints in the first list are marked as solved, and do not need >> to be processed further, while the constraints >> in the second list will be added to the work queue, for further >> processing. Also, the solutions of wanted goals may be in terms of other >> as yet unsolved things. >> >> I think that there are two situations when a plugin might return an empty >> first list, but new work in the second list. >> Both are about computing new facts, and thus "communicating" with other >> plugins: >> 1. Discover new given facts: the plugin was presented with some >> givens, and it computed some additional givens that it thinks might be of >> use to someone else (typically these are equality constraints) >> 2. Discover new derived facts: the plugin was presented with a >> mixture of wanted and givens, and it thinks that the new derived facts >> might be useful by specializing the problem----derived facts help with type >> inference by instantiating unification variables. >> >> Generally, I don't think a plugin should ever need to emit new wanted >> constraints without solving anything. It'd be interesting if that could >> happen though... >> >> Another thing that might be relevant: at present, GHC's constraint solver >> does not do back tracking. So there is no way for a plugin (or other parts >> of the constraint solver) to say: "I'll emit this new wanted constraint, >> and depending on if it was proved or disproved do something". Another way >> to think of his is that constraints are either solved or unsolved, but >> being unsolved does not mean that they are disproved. Now, there is a >> mechanism to mark a constraint as "never solvable", but currently this is >> mostly used for error reporting. >> >> For your concrete example though, the plugin can actually commit to the >> given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if >> "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: >> >> Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "GCD 6 8 ~ GCD 9 >> 6" >> Plugin B: "GCD 6 8 ~ GCD 9 6" --> impossible >> Done. >> >> >> -Iavor >> >> >> >> On Tue, May 19, 2015 at 3:35 AM, Christiaan Baaij < >> christiaan.baaij at gmail.com> wrote: >> >>> I have a question about how type-checker plugins should interact. >>> My situation is the following: >>> I have two type-checker plugins, one that can solve equalities involving >>> the standard type-level operations on kind Nat (+,*,-,^), and another >>> type-checker plugin that can prove equalities involving a new type-level >>> operation GCD. >>> In the following, the type-checker plugin involving the stand type-level >>> operations is called ?A?, and the type checker involving the new GCD >>> operations is called ?B?. >>> >>> When type-checker plugin A encounters: >>> [W] GCD 6 8 + x ~ x + GCD 9 6 >>> >>> It knows that (+) is commutative, so it can prove the above equality >>> _given_ that "GCD 6 8 ~ GCD 9 6? holds. >>> So what type-checker plugin A does now is emits a new wanted constraints: >>> [W] GCD 6 8 ~ GCD 9 6 >>> And remembers that it emitted this wanted constraint. >>> In type-checker plugin lingo, it returns: >>> TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6?] >>> >>> >> >> Now whenever type-checker plugin encounters >>> [W] GCD 6 8 + x ~ x + GCD 9 6 >>> again, it checks to see if the discharged constraint >>> [W] GCD 6 8 ~ GCD 9 6 >>> Is already solved, is disproven, or unsolved. >>> If the discharged constraint is solved, it will return: >>> TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6?] [] >>> If the discharged constraint is dis proven, it returns: >>> TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6?] >>> And otherwise, it doesn?t do anything: >>> TcPluginOk [] [] >>> >>> >> >> >>> Now, type-checker plugin B, the one that knows about GCD, comes along. >>> It sees: >>> [W] GCD 6 8 + x ~ x + GCD 9 6 >>> [W] GCD 6 8 ~ GCD 9 6 >>> I doesn?t know anything about (+); but it does know about GCD, and >>> clearly sees that GCD 6 8 is not equal to GCD 9 6. >>> So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. >>> In type-checker plugin lingo it says: >>> TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6?] >>> >>> According to >>> https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcInteract.hs#L547 >>> What happens next is that the insoluble constraint >>> [W] GCD 6 8 ~ GCD 9 6 >>> is taken of the work list for all plugins. >>> However! the same thing happens when a plugin is able to prove a >>> constraint. >>> That is, if B would have (erroneously) returned: >>> TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6?] [] >>> >>> Then there is _no_ way for type-checker plugin A to know what happened. >>> Were its discharged constraints taken from the work-list because it was >>> insoluble? or because it was solved? >>> This is a problem because to me it seems that the work list is the only >>> way that two type-checker plugins can communicate. >>> >>> I guess my question is: if not through the work list, how are >>> type-checker plugins supposed to communicate? >>> Am I going about it all wrong in terms how I should be writing >>> type-checker plugins? >>> Or, should the type of ?TcPluginSolver? ( >>> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcRnTypes.html#t:TcPluginSolver) >>> be updated to?: >>> >>> ``` >>> type TcPluginSolver = [Ct] -- ^ Given constraints >>> -> [Ct] -- ^ Derived constraints >>> -> [Ct] -- ^ Wanted constraints >>> -> [Ct] -- ^ Insoluble constraints >>> -> TcPluginM TcPluginResult >>> ``` >>> >>> Best regards, >>> >>> Christiaan >>> >>> >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Thu May 21 01:51:05 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 20 May 2015 19:51:05 -0600 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: Hi Yitzchak, I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run. Respectfully, Howard > On May 20, 2015, at 7:39 AM, Yitzchak Gale wrote: > > The license issue is a real concern for any company using > GHC to develop a product whose binaries they distribute to > customers. And it is concern for GHC itself, if we want > GHC to continue to be viewed as a candidate for use in > industry. > > The real issue is not whether you can explain why this > license is OK, or whether anyone is actually going to the > trouble of building GHC without GMP. > > The issue is the risk of a *potential* legal issue and its > potential disastrous cost as *perceived* by lawyers and > management. A potential future engineering cost, no > matter how large and even if only marginally practical, > is perceived as manageable and controllable, whereas a > poorly understood potential future legal threat is perceived > as an existential risk to the entire company. > > With GMP, we do have an engineering workaround to side-step > the legal problem entirely if needed. Whereas if cpphs were > to be linked into GHC with its current license, I would be > ethically obligated to report it to my superiors, and the > response might very well be: Then never mind, let's do the > simple and safe thing and just rewrite all of our applications in > Java or C#. > > Keeping the license as is seems to be important to Malcolm. > So could we have an option to build GHC without cpphs > and instead use it as a stand-alone external program? > That would make the situation no worse than GMP. > > Thanks, > Yitz > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gale at sefer.org Thu May 21 09:16:48 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 21 May 2015 12:16:48 +0300 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: LGPL is well-known and non-acceptable here. Show me some serious case law for Malcolm's customized LGPL and we can start talking. Other than that, explanations are not going to be helpful. Thanks, Yitz On Thu, May 21, 2015 at 4:51 AM, Howard B. Golden wrote: > Hi Yitzchak, > > I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run. > > Respectfully, > > Howard > >> On May 20, 2015, at 7:39 AM, Yitzchak Gale wrote: >> >> The license issue is a real concern for any company using >> GHC to develop a product whose binaries they distribute to >> customers. And it is concern for GHC itself, if we want >> GHC to continue to be viewed as a candidate for use in >> industry. >> >> The real issue is not whether you can explain why this >> license is OK, or whether anyone is actually going to the >> trouble of building GHC without GMP. >> >> The issue is the risk of a *potential* legal issue and its >> potential disastrous cost as *perceived* by lawyers and >> management. A potential future engineering cost, no >> matter how large and even if only marginally practical, >> is perceived as manageable and controllable, whereas a >> poorly understood potential future legal threat is perceived >> as an existential risk to the entire company. >> >> With GMP, we do have an engineering workaround to side-step >> the legal problem entirely if needed. Whereas if cpphs were >> to be linked into GHC with its current license, I would be >> ethically obligated to report it to my superiors, and the >> response might very well be: Then never mind, let's do the >> simple and safe thing and just rewrite all of our applications in >> Java or C#. >> >> Keeping the license as is seems to be important to Malcolm. >> So could we have an option to build GHC without cpphs >> and instead use it as a stand-alone external program? >> That would make the situation no worse than GMP. >> >> Thanks, >> Yitz >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gale at sefer.org Thu May 21 09:25:46 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 21 May 2015 12:25:46 +0300 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: I wrote: >> Keeping the license as is seems to be important to Malcolm. >> So could we have an option to build GHC without cpphs >> and instead use it as a stand-alone external program? >> That would make the situation no worse than GMP. Bardur Arantsson wrote: > I don't see any need for an option. Just bundle cpphs together with GHC > and build/use it as an external program. AFAICT this has absolutely no > licensing implications for GHC, derived from GHC or anything compiled > with GHC. Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC. From malcolm.wallace at me.com Thu May 21 10:17:36 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 21 May 2015 11:17:36 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: <62C02693-C9E6-43C8-B06F-DD2F5996827E@me.com> Interesting. I'm not completely clear, when you say that your company distributes binaries to third-parties: do you distribute ghc itself? Or just the product that has been built by ghc? Regards, Malcolm On 21 May 2015, at 10:16, Yitzchak Gale wrote: > LGPL is well-known and non-acceptable here. > > Show me some serious case law for Malcolm's > customized LGPL and we can start talking. > Other than that, explanations are not going to > be helpful. > > Thanks, > Yitz > > > On Thu, May 21, 2015 at 4:51 AM, Howard B. Golden > wrote: >> Hi Yitzchak, >> >> I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run. >> >> Respectfully, >> >> Howard >> >>> On May 20, 2015, at 7:39 AM, Yitzchak Gale wrote: >>> >>> The license issue is a real concern for any company using >>> GHC to develop a product whose binaries they distribute to >>> customers. And it is concern for GHC itself, if we want >>> GHC to continue to be viewed as a candidate for use in >>> industry. >>> >>> The real issue is not whether you can explain why this >>> license is OK, or whether anyone is actually going to the >>> trouble of building GHC without GMP. >>> >>> The issue is the risk of a *potential* legal issue and its >>> potential disastrous cost as *perceived* by lawyers and >>> management. A potential future engineering cost, no >>> matter how large and even if only marginally practical, >>> is perceived as manageable and controllable, whereas a >>> poorly understood potential future legal threat is perceived >>> as an existential risk to the entire company. >>> >>> With GMP, we do have an engineering workaround to side-step >>> the legal problem entirely if needed. Whereas if cpphs were >>> to be linked into GHC with its current license, I would be >>> ethically obligated to report it to my superiors, and the >>> response might very well be: Then never mind, let's do the >>> simple and safe thing and just rewrite all of our applications in >>> Java or C#. >>> >>> Keeping the license as is seems to be important to Malcolm. >>> So could we have an option to build GHC without cpphs >>> and instead use it as a stand-alone external program? >>> That would make the situation no worse than GMP. >>> >>> Thanks, >>> Yitz >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hvriedel at gmail.com Thu May 21 10:31:43 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 21 May 2015 12:31:43 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (Yitzchak Gale's message of "Thu, 21 May 2015 12:25:46 +0300") References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> Message-ID: <87bnhenrw0.fsf@gmail.com> Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] > Bardur Arantsson wrote: >> I don't see any need for an option. Just bundle cpphs together with GHC >> and build/use it as an external program. AFAICT this has absolutely no >> licensing implications for GHC, derived from GHC or anything compiled >> with GHC. > > Agreed, that would work. But I thought that the idea was that we wanted > it actually integrated into GHC. That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. However, due to the, sadly, mostly non-technical issues brought up, it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics. NB: Nothing's been decided yet by GHC HQ PS: As an observation, http://packdeps.haskellers.com/reverse/cpphs shows that cpphs is already used by popular packages like hlint and haskell-src-exts (and thus an indirect build-dep of the haskell-suite project). Therefore, if LGPL+SLE is unacceptable in some work-environments, it may require some vigilance to keep track where cpphs may sneak into as a build-dependency... I'm surprised there's still such resistance given the ubiquity of Linux distributions made up of numerous (L)GPLed components, IMHO it's kinda like tilting at windmills... Cheers, hvr From gale at sefer.org Thu May 21 11:55:14 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 21 May 2015 14:55:14 +0300 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <62C02693-C9E6-43C8-B06F-DD2F5996827E@me.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <62C02693-C9E6-43C8-B06F-DD2F5996827E@me.com> Message-ID: Malcolm Wallace wrote: > Interesting. I'm not completely clear, when you say > that your company distributes binaries to third-parties: > do you distribute ghc itself? Or just the product that > has been built by ghc? You're right. We only distribute binaries built by GHC. So whatever doesn't make it into the runtime is not a problem for us at the moment. But as Herbert pointed out, it may not be so simple for everyone. There is GHC API ; there are EDSLs; etc. Herbert Valerio Riedel wrote: > I'm surprised there's still such resistance given the > ubiquity of Linux distributions made up of numerous > (L)GPLed components, IMHO it's kinda like tilting > at windmills... A few years ago, people would have said that using open source in industry at all was like tilting at windmills. I'm very happy that's not the case anymore. Some companies - including some big ones - use GPL'ed code and thumb their noses at the license. I hope that GHC will support use in industry by companies that do respect open source licenses. From gale at sefer.org Thu May 21 12:09:13 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 21 May 2015 15:09:13 +0300 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87bnhenrw0.fsf@gmail.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> Message-ID: I wrote: >> ...I thought that the idea was that we wanted >> it actually integrated into GHC. Herbert Valerio Riedel wrote: > That would be the preferred way from a technical standpoint, as it would > avoid fork/exec and make it easier to integrate the CPP-phase tighter > into the lexer/parser. > > However, due to the, sadly, mostly non-technical issues brought up, it > seems to me that isolating cpphs into a separate process (w/ the option > to configure GHC to use some other cpp implementation at your own risk > if you need to avoid the cpphs implementation at all costs) would be the > compromise acceptable to everyone in the short run while addressing the > primary goal to decouple the default-configuration of GHC from the > fragile system-cpp semantics. Correct me if I'm wrong: GHC already supports using an external CPP processor as an option. And cpphs is already easily buildable as a stand-alone external CPP processor compatible with GHC. So can't we incorporate cpphs into GHC as is, but also provide a build option to exclude it from a GHC build? In a non-cpphs build, CPP would only work if an external processor is provided. That's even better than the GMP situation - it really would be simple and practical to create and use a non-cpphs GHC if needed. As opposed to a non-GMP build, which in reality is only a theoretical possibility to satisfy the lawyers. Thanks, Yitz From spam at scientician.net Thu May 21 14:54:11 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 21 May 2015 16:54:11 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87bnhenrw0.fsf@gmail.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> Message-ID: On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote: > Hi Yitzchak, > > On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: > > [...] > >> Bardur Arantsson wrote: >>> I don't see any need for an option. Just bundle cpphs together with GHC >>> and build/use it as an external program. AFAICT this has absolutely no >>> licensing implications for GHC, derived from GHC or anything compiled >>> with GHC. >> >> Agreed, that would work. But I thought that the idea was that we wanted >> it actually integrated into GHC. > > That would be the preferred way from a technical standpoint, as it would > avoid fork/exec and make it easier to integrate the CPP-phase tighter > into the lexer/parser. fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. From malcolm.wallace at me.com Thu May 21 15:36:26 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 21 May 2015 16:36:26 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> Message-ID: <26C4010A-7653-49E0-A9AE-190D0B9B0140@me.com> On 21 May 2015, at 15:54, Bardur Arantsson wrote: > fork/exec is almost certainly going to be negligable compared to the > overall compile time anyway. It's not like GHC is fast enough for it to > matter. Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). This means that when ghc --make does lots of external things requiring a fork, such as preprocessing, a medium sized project (using many library packages) can take a surprisingly large amount of time (minutes instead of seconds), even for an incremental build where very little code has changed. We think an in-process cpphs could make some of our compilations literally hundreds of times faster. Regards, Malcolm From spam at scientician.net Thu May 21 15:51:35 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 21 May 2015 17:51:35 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <26C4010A-7653-49E0-A9AE-190D0B9B0140@me.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <26C4010A-7653-49E0-A9AE-190D0B9B0140@me.com> Message-ID: On 05/21/2015 05:36 PM, Malcolm Wallace wrote: > > On 21 May 2015, at 15:54, Bardur Arantsson wrote: > >> fork/exec is almost certainly going to be negligable compared to the >> overall compile time anyway. It's not like GHC is fast enough for it to >> matter. > > Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). > Yeah, that sounds... broken. Regards, From hvriedel at gmail.com Thu May 21 15:51:10 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 21 May 2015 17:51:10 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (Bardur Arantsson's message of "Thu, 21 May 2015 16:54:11 +0200") References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> Message-ID: <87617mnd3l.fsf@gmail.com> On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote: [...] >> That would be the preferred way from a technical standpoint, as it would >> avoid fork/exec and make it easier to integrate the CPP-phase tighter >> into the lexer/parser. > > fork/exec is almost certainly going to be negligable compared to the > overall compile time anyway. It's not like GHC is fast enough for it to > matter. Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. From allbery.b at gmail.com Thu May 21 16:02:57 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 21 May 2015 12:02:57 -0400 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87617mnd3l.fsf@gmail.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> Message-ID: On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel wrote: > Performance isn't (my) motivation for avoiding fork/exec (and the > equivalent on Win32) but rather avoiding the added complexity of > marshalling/IPC with fork/exec, as opposed to simply calling into a > native Haskell function and crossing process boundaries and having to > deal with the various things that can go wrong with the additional > moving parts you encounter when controlling an external process. So this > would IMO simplify code paths, and moreover I'd expect opportunities to > actually make the Haskell cpphs API richer (in case it isn't already) > and more tailored to GHC's lexer/parser pipeline and error-reporting. Don't you still have to support -pgmF? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu May 21 16:03:57 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 21 May 2015 18:03:57 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (Yitzchak Gale's message of "Thu, 21 May 2015 15:09:13 +0300") References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> Message-ID: <871ti9or2q.fsf@gmail.com> On 2015-05-21 at 14:09:13 +0200, Yitzchak Gale wrote: > I wrote: >>> ...I thought that the idea was that we wanted >>> it actually integrated into GHC. > Herbert Valerio Riedel wrote: >> That would be the preferred way from a technical standpoint, as it >> would avoid fork/exec and make it easier to integrate the CPP-phase >> tighter into the lexer/parser. >> >> However, due to the, sadly, mostly non-technical issues brought up, >> it seems to me that isolating cpphs into a separate process (w/ the >> option to configure GHC to use some other cpp implementation at your >> own risk if you need to avoid the cpphs implementation at all costs) >> would be the compromise acceptable to everyone in the short run while >> addressing the primary goal to decouple the default-configuration of >> GHC from the fragile system-cpp semantics. > > Correct me if I'm wrong: > > GHC already supports using an external CPP processor > as an option. And cpphs is already easily buildable as > a stand-alone external CPP processor compatible with > GHC. Yes > So can't we incorporate cpphs into GHC as is, but > also provide a build option to exclude it from a GHC > build? In a non-cpphs build, CPP would only work > if an external processor is provided. Well, that's more or less the plan (I hinted at in what I wrote earlier) for cpphs-as-an-executable/isolated-process; Except that we may[1] not want to build a cpphs as you'd get if you simply 'cabal install cpphs' (as that would pull in more build-deps than desirable), but maybe implement a stripped down GHC-specific frontend to the cpphs library (while trying keep the original cpphs modules untouched, and/or contributing changes back to upstream so we don't diverge). In any case, the cpphs-ish tool bundled with GHC could be considered a GHC-specific fork of cpphs (and possibly with a GHC-tailored CLI) *and* you'd have the option as you suggest to exclude it from the GHC build, in order to create a GHC toolchain w/o any "cpphs" code (which uses e.g. the system-cpp as in the past). > That's even better than the GMP situation - it really > would be simple and practical to create and use > a non-cpphs GHC if needed. As opposed to a non-GMP > build, which in reality is only a theoretical possibility > to satisfy the lawyers. [1]: I'm just thinking out loud here; it'll only become clear what's sensible once we have *actually* attempted to integrate cpphs into the GHC build-system, and have a working proof of concept (that'll need to be thrown at Hackage) From hvriedel at gmail.com Thu May 21 16:07:57 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 21 May 2015 18:07:57 +0200 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (Brandon Allbery's message of "Thu, 21 May 2015 12:02:57 -0400") References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> Message-ID: <87wq01ncbm.fsf@gmail.com> On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote: > On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel > wrote: > >> Performance isn't (my) motivation for avoiding fork/exec (and the >> equivalent on Win32) but rather avoiding the added complexity of >> marshalling/IPC with fork/exec, as opposed to simply calling into a >> native Haskell function and crossing process boundaries and having to >> deal with the various things that can go wrong with the additional >> moving parts you encounter when controlling an external process. So this >> would IMO simplify code paths, and moreover I'd expect opportunities to >> actually make the Haskell cpphs API richer (in case it isn't already) >> and more tailored to GHC's lexer/parser pipeline and error-reporting. > Don't you still have to support -pgmF? I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run... From david.macek.0 at gmail.com Thu May 21 20:52:56 2015 From: david.macek.0 at gmail.com (David Macek) Date: Thu, 21 May 2015 22:52:56 +0200 Subject: MSYS2 package for GHC 7.10.1 In-Reply-To: <5518A69B.1080400@gmail.com> References: <5518A69B.1080400@gmail.com> Message-ID: <555E45A8.1070203@gmail.com> With the helpful pointers from ezyang on IRC, I pushed this a bit forward. I converted most of the patches into more reasonable commits including short descriptions and created a git branch for it. See . As mentioned previously, the changes should be uncontroversial except for two big changes: removing bundled mingw, perl and touchy and changing the directory layout. While the directory layout change is mostly self-contained (barring any tools hardcoding ..\lib), the bundled dependency removal will required major changes to the build process. My proposals follow. For hacking on GHC ================== 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a GHC repository ready 3. Hack, hack, hack 4. Build and test as usual 5. GOTO 3 Alternatively, this could be replaced with a makepkg-based flow: 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a mingw-w64-ghc-git PKGBUILD 3. $ makepkg-mingw --nobuild # clone the repositories 4. Go to src/ghc and hack, hack, hack 5. $ makepkg-mingw --noextract --noprepare --noarchive # build and test 6. GOTO 4 For binary release ================== Phase 1: pacman package. This can be done in coordination with the MSYS2 maintainers, or a separate GHC-owned pacman repository can be created. 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Update the mingw-w64-ghc PKGBUILD to point to the new source release 3. $ makepkg-mingw # build a package 4. Upload the package to a pacman repository Phase 2: stand-alone bindist 1. Download the package and its dependencies 2. Extract them into a temporary directory 3. Create a tarball or an installer from that 4. Upload to GHC servers This is essentially what the new Git for Windows does (and what some other projects that use MSYS2 as their build environment do). -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4234 bytes Desc: S/MIME Cryptographic Signature URL: From gale at sefer.org Fri May 22 13:58:00 2015 From: gale at sefer.org (Yitzchak Gale) Date: Fri, 22 May 2015 16:58:00 +0300 Subject: MSYS2 package for GHC 7.10.1 In-Reply-To: <555E45A8.1070203@gmail.com> References: <5518A69B.1080400@gmail.com> <555E45A8.1070203@gmail.com> Message-ID: Wow, this sounds great! Just to clarify - this would still be a mingw-w64 build and not require the msys2 DLLs, correct? Thanks, Yitz On May 21, 2015 23:53, "David Macek" wrote: > With the helpful pointers from ezyang on IRC, I pushed this a bit forward. > > I converted most of the patches into more reasonable commits including > short descriptions and created a git branch for it. See < > https://github.com/ghc/ghc/compare/ghc-7.10.1-release...elieux:msys2-pkgbuild > >. > > As mentioned previously, the changes should be uncontroversial except for > two big changes: removing bundled mingw, perl and touchy and changing the > directory layout. While the directory layout change is mostly > self-contained (barring any tools hardcoding ..\lib), the bundled > dependency removal will required major changes to the build process. My > proposals follow. > > For hacking on GHC > ================== > > 1. Get MSYS2, update and install dependencies (including the bootstrapping > ghc that would come as a MSYS2 package) > 2. Get a GHC repository ready > 3. Hack, hack, hack > 4. Build and test as usual > 5. GOTO 3 > > Alternatively, this could be replaced with a makepkg-based flow: > > 1. Get MSYS2, update and install dependencies (including the bootstrapping > ghc that would come as a MSYS2 package) > 2. Get a mingw-w64-ghc-git PKGBUILD > 3. $ makepkg-mingw --nobuild # clone the repositories > 4. Go to src/ghc and hack, hack, hack > 5. $ makepkg-mingw --noextract --noprepare --noarchive # build and test > 6. GOTO 4 > > For binary release > ================== > > Phase 1: pacman package. This can be done in coordination with the MSYS2 > maintainers, or a separate GHC-owned pacman repository can be created. > > 1. Get MSYS2, update and install dependencies (including the bootstrapping > ghc that would come as a MSYS2 package) > 2. Update the mingw-w64-ghc PKGBUILD to point to the new source release > 3. $ makepkg-mingw # build a package > 4. Upload the package to a pacman repository > > Phase 2: stand-alone bindist > > 1. Download the package and its dependencies > 2. Extract them into a temporary directory > 3. Create a tarball or an installer from that > 4. Upload to GHC servers > > This is essentially what the new Git for Windows does (and what some other > projects that use MSYS2 as their build environment do). > > -- > David Macek > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 22 14:23:35 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 May 2015 14:23:35 +0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <061.154799b5eeec1c58ae69a33c3d4e4759@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> <061.154799b5eeec1c58ae69a33c3d4e4759@haskell.org> Message-ID: <9dcf949d095540cea91f6f3591bd4bc4@DB4PR30MB030.064d.mgd.msft.net> Austin: I have validated, but I am now going on holiday for a week. Can you monitor and revert if there's a major problem? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf | Of GHC | Sent: 22 May 2015 15:21 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #10370: Compile time regression in OpenGLRaw | | #10370: Compile time regression in OpenGLRaw | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: michalt | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: | 7.10.1 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time | Unknown/Multiple | performance bug | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by simonpj): | | The commit messages tell the story. Reid's example in comment:3 | showed up TWO separate, substantial non-linear performance holes in | GHC, both of which I have now fixed. Reid, your example was | amazingly helpful. | | '''Austin''' I have not added a `perf/compiler` test case. Could you | do so please? I wasn't sure that a 20-second compile time was | acceptable. | I'm leaving the ticket open for that reason. | | Simon | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets From austin at well-typed.com Fri May 22 14:42:05 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 22 May 2015 09:42:05 -0500 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <9dcf949d095540cea91f6f3591bd4bc4@DB4PR30MB030.064d.mgd.msft.net> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> <061.154799b5eeec1c58ae69a33c3d4e4759@haskell.org> <9dcf949d095540cea91f6f3591bd4bc4@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Will do. On Fri, May 22, 2015 at 9:23 AM, Simon Peyton Jones wrote: > Austin: I have validated, but I am now going on holiday for a week. Can you monitor and revert if there's a major problem? > > Simon > > | -----Original Message----- > | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf > | Of GHC > | Sent: 22 May 2015 15:21 > | Cc: ghc-tickets at haskell.org > | Subject: Re: [GHC] #10370: Compile time regression in OpenGLRaw > | > | #10370: Compile time regression in OpenGLRaw > | -------------------------------------+-------------------------------- > | -- > | -------------------------------------+--- > | Reporter: michalt | Owner: > | Type: bug | Status: new > | Priority: normal | Milestone: > | Component: Compiler | Version: > | 7.10.1 > | Resolution: | Keywords: > | Operating System: Unknown/Multiple | Architecture: > | Type of failure: Compile-time | Unknown/Multiple > | performance bug | Test Case: > | Blocked By: | Blocking: > | Related Tickets: | Differential Revisions: > | -------------------------------------+-------------------------------- > | -- > | -------------------------------------+--- > | > | Comment (by simonpj): > | > | The commit messages tell the story. Reid's example in comment:3 > | showed up TWO separate, substantial non-linear performance holes in > | GHC, both of which I have now fixed. Reid, your example was > | amazingly helpful. > | > | '''Austin''' I have not added a `perf/compiler` test case. Could you > | do so please? I wasn't sure that a 20-second compile time was > | acceptable. > | I'm leaving the ticket open for that reason. > | > | Simon > | > | -- > | Ticket URL: > | GHC > | The Glasgow Haskell Compiler > | _______________________________________________ > | ghc-tickets mailing list > | ghc-tickets at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From david.macek.0 at gmail.com Fri May 22 16:53:06 2015 From: david.macek.0 at gmail.com (David Macek) Date: Fri, 22 May 2015 18:53:06 +0200 Subject: MSYS2 package for GHC 7.10.1 In-Reply-To: References: <5518A69B.1080400@gmail.com> <555E45A8.1070203@gmail.com> Message-ID: <555F5EF2.5040002@gmail.com> On 22. 5. 2015 15:58, Yitzchak Gale wrote: > Wow, this sounds great! > > Just to clarify - this would still be a mingw-w64 build > and not require the msys2 DLLs, correct? Correct. -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4234 bytes Desc: S/MIME Cryptographic Signature URL: From roma at ro-che.info Sun May 24 13:15:40 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 24 May 2015 16:15:40 +0300 Subject: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87wq01ncbm.fsf@gmail.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: <5561CEFC.7020300@ro-che.info> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >> Don't you still have to support -pgmF? > > I guess so, unfortunately... so we'd have to keep a legacy code-path for > external cpp processing around, at least in the short run... It's not just about legacy; -pgmF is used for all sorts of awesome things; literate markdown is one example. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From malcolm.wallace at me.com Sun May 24 16:41:23 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sun, 24 May 2015 17:41:23 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <5561CEFC.7020300@ro-che.info> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> <5561CEFC.7020300@ro-che.info> Message-ID: <111C59B2-225F-427F-A9A1-3FC101AB5045@me.com> On 24 May 2015, at 14:15, Roman Cheplyaka wrote: > On 21/05/15 19:07, Herbert Valerio Riedel wrote: >>> Don't you still have to support -pgmF? >> >> I guess so, unfortunately... so we'd have to keep a legacy code-path for >> external cpp processing around, at least in the short run... > > It's not just about legacy; -pgmF is used for all sorts of awesome > things; literate markdown is one example. I think Herbert meant that -pgmP will also need to continue to be supported. Regards Malcolm From greg at gregweber.info Sun May 24 18:29:45 2015 From: greg at gregweber.info (Greg Weber) Date: Sun, 24 May 2015 11:29:45 -0700 Subject: MSYS2 package for GHC 7.10.1 In-Reply-To: <555F5EF2.5040002@gmail.com> References: <5518A69B.1080400@gmail.com> <555E45A8.1070203@gmail.com> <555F5EF2.5040002@gmail.com> Message-ID: Hi David, You may want to work closely with the minghc project which seems to be the best Haskell Windows installer at the moment: https://github.com/fpco/minghc Thanks, Greg Weber On Fri, May 22, 2015 at 9:53 AM, David Macek wrote: > On 22. 5. 2015 15:58, Yitzchak Gale wrote: > > Wow, this sounds great! > > > > Just to clarify - this would still be a mingw-w64 build > > and not require the msys2 DLLs, correct? > > Correct. > > -- > David Macek > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Wed May 27 08:33:20 2015 From: adam at well-typed.com (Adam Gundry) Date: Wed, 27 May 2015 09:33:20 +0100 Subject: Proposed changes to typechecker plugins API Message-ID: <55658150.8040701@well-typed.com> Hi devs, I thought I should flag up some proposed changes relating to typechecker plugins, which Christiaan, Iavor and I have been discussing. The quick summary: * make it possible for plugins to create constraints (Phab:D909); * make it easier for plugins to define special type families; * embed CoreExpr in EvTerm. For more details, see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changestoTcPluginMAPI Questions/review/comments very welcome. Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eric at seidel.io Wed May 27 14:13:37 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 27 May 2015 07:13:37 -0700 Subject: Proposed changes to typechecker plugins API In-Reply-To: <55658150.8040701@well-typed.com> References: <55658150.8040701@well-typed.com> Message-ID: <1432736017.4151931.279367289.4D3C5B0C@webmail.messagingengine.com> Hi Adam, I like the addition of the new* functions for creating constraints, that should make for a much nicer API than dealing directly with the CtEvidence constructors! I'm not so convinced however about embedding arbitrary CoreExprs in EvTerms. First of all, it feels a bit strange to generate CoreExprs before the desugarer (and we would have to add a `MonadThings TcPluginM` instance to generate Integer and String CoreExprs). But more importantly, based on your wiki page [1], it sounds like what we really want is a nice API for creating dictionaries. Eric [1]: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#EmbeddingCoreExprinEvTerm On Wed, May 27, 2015, at 01:33, Adam Gundry wrote: > Hi devs, > > I thought I should flag up some proposed changes relating to typechecker > plugins, which Christiaan, Iavor and I have been discussing. The quick > summary: > > * make it possible for plugins to create constraints (Phab:D909); > > * make it easier for plugins to define special type families; > > * embed CoreExpr in EvTerm. > > For more details, see the wiki page: > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changestoTcPluginMAPI > > Questions/review/comments very welcome. > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From haskell at kuhtz.eu Wed May 27 17:12:11 2015 From: haskell at kuhtz.eu (Lars Kuhtz) Date: Wed, 27 May 2015 10:12:11 -0700 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87wq01ncbm.fsf@gmail.com> References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: On 21/05/15 19:07, Herbert Valerio Riedel wrote: >> Don't you still have to support -pgmF? > > I guess so, unfortunately... so we'd have to keep a legacy code-path for > external cpp processing around, at least in the short run... I think it?s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don?t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let?s not just add another licensing issue. Lars From haskell at kuhtz.eu Wed May 27 20:21:26 2015 From: haskell at kuhtz.eu (Lars Kuhtz) Date: Wed, 27 May 2015 13:21:26 -0700 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: Carter, your explanation why the usage of LGPL is perfectly fine in most scenarios involves technical as well as legal details. My point is, that it is not a technical, probably not even a legal issue. I completely agree with you that it is a business problem. But it makes adaptation of GHC in a business more difficult if it creates business problems. Decisions are made most efficiently when there are rules of thumb. Such a rule is that BSD or MIT style licenses are not problematic. But if a GPL style license shows up some special treatment is needed. And a solution requires a detailed communication between two groups of persons who usually don't deal directly with each other and speak very different languages. This problem can be solved, and we actually solved it, and we use GHC. But it is annoying and it tends to come up again regularly. For a small company which considers adopting Haskell it would be best if that decision was a purely technical decision. With LGPL style libraries in the mix it isn?t a purely technical decision any more. Lars > On May 27, 2015, at 12:11 PM, Carter Schonwald wrote: > > Lars, > which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. > > gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) > > any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. > > > > On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz > wrote: > On 21/05/15 19:07, Herbert Valerio Riedel wrote: > >> Don't you still have to support -pgmF? > > > > I guess so, unfortunately... so we'd have to keep a legacy code-path for > > external cpp processing around, at least in the short run... > > > I think it?s unfortunate if industrial usage of GHC is supported only through legacy code-paths. > > I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don?t make that easier. > > The gmp dependency is causing already enough trouble for industrial users. Let?s not just add another licensing issue. > > Lars > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at kuhtz.eu Wed May 27 21:41:19 2015 From: haskell at kuhtz.eu (Lars Kuhtz) Date: Wed, 27 May 2015 14:41:19 -0700 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: The issue that GMP is LGPL licensed came up a couple of times in discussions at PivotCloud. Before each product release developers were requested to provided a list of all third party dependencies along with their licenses. This was given to the folks who deal with the legal stuff. If they spoted anything with (L)GPL in it, they had general concerns. Also someone also had heard some rumors on the web about issues with GMP and GHC (like for instance this thread in the mailing list archives :-) ) adding to the uncertainty. Some time back I was even asked to build GHC without GMP, which, at least at that time, wasn?t fun to do; though we never used that build. As a more general and not directly related remark: when I was working at Microsoft there were rules how to deal with open source software based on the style of the license. At least in my group anything with (L)GPL was simply a no-go without any further discussion about details. From this experience I think that if we want to make adaption of Haskell easy we may avoid (L)GPL when possible. If we can?t avoid it, well, probably it wouldn?t be a disaster neither. > On May 27, 2015, at 2:00 PM, Carter Schonwald wrote: > > could you be concrete about the specific challenges and experiences you've had, and with what organizations? Its very hard to evaluate the veracity of what youre saying otherwise! > > was using GCC an issue at this organization too? because that would be a real problem! 'cause tis GPLV3 rather than LGPL! :) > > On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz > wrote: > Carter, your explanation why the usage of LGPL is perfectly fine in most scenarios involves technical as well as legal details. My point is, that it is not a technical, probably not even a legal issue. I completely agree with you that it is a business problem. But it makes adaptation of GHC in a business more difficult if it creates business problems. > > Decisions are made most efficiently when there are rules of thumb. Such a rule is that BSD or MIT style licenses are not problematic. But if a GPL style license shows up some special treatment is needed. And a solution requires a detailed communication between two groups of persons who usually don't deal directly with each other and speak very different languages. > > This problem can be solved, and we actually solved it, and we use GHC. But it is annoying and it tends to come up again regularly. > > For a small company which considers adopting Haskell it would be best if that decision was a purely technical decision. With LGPL style libraries in the mix it isn?t a purely technical decision any more. > > Lars > >> On May 27, 2015, at 12:11 PM, Carter Schonwald > wrote: >> >> Lars, >> which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. >> >> gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) >> >> any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. >> >> >> >> On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz > wrote: >> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >> >> Don't you still have to support -pgmF? >> > >> > I guess so, unfortunately... so we'd have to keep a legacy code-path for >> > external cpp processing around, at least in the short run... >> >> >> I think it?s unfortunate if industrial usage of GHC is supported only through legacy code-paths. >> >> I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don?t make that easier. >> >> The gmp dependency is causing already enough trouble for industrial users. Let?s not just add another licensing issue. >> >> Lars >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 27 22:42:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 May 2015 22:42:03 +0000 Subject: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD In-Reply-To: References: <9EE5DA64-EB82-41F8-ADA7-EA8EA8724471@gmail.com> <555E0D10.4040804@well-typed.com> <55647660.6050609@well-typed.com> Message-ID: <076d049446174357a0834a23f77b0aa8@DB4PR30MB030.064d.mgd.msft.net> I am back from vacation! Well I am ON vacation, but the children are in bed... Two thoughts: ? I like EvTerm as a distinct data type precisely because it enumerates all the forms of evidence we need. Once you allow arbitrary CoreExprs, we lose that explicit enumeration. Now, that might be OK. Evidence terms are proof terms: any well typed EvTerm is a proof of the predicate described by its type. So if a CoreExpr has the right type, then it *should* be the case that the evidence term is OK (provided it?s not bottom). So I can?t quite nail down why I like the explicit EvTerm; except the relatively minor reason that it puts off desugaring to the desugarer. ? On a separate matter, can we eliminate the trap-door from TcPluginM to TcM? That is, can you enumerate all the things you need from TcPluginM? The reason I ask is that I?d like to stop building TcS on top of TcM, and instead make it a free-standing monad. Reason: we increasingly want to do constraint solving outside a full-blown typechecker. Eg. when doing pattern-match exhaustiveness checks. Faking up a TcM monad with lots of error thunks seems wrong. Lastly: would someone like to add Adam?s explanation to the Commentary somewhere? Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 27 May 2015 17:26 To: Adam Gundry; Richard Eisenberg; Simon Peyton Jones Cc: Christiaan Baaij Subject: Re: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD Hi guys, I am back from vacation! (cc-ing Richard and Simon, as they might also be interested in some of these changes). I am very much on board with the changes suggested by Adam. A couple of thoughts: * GHC already has some support for evaluation of custom type-families, we added it for evaluating + and friends. It might be good to use the same system for custom evaluation in tc-plugins too, even if we have to modify it some. Currently, this is done by having another "flavor" of type constructor (see `FamTyConFlav` in module `TyCon`), namely one that has built-in evaluation rules. The actual details of how the evaluation happens are in module `CoAxiom`, see `BuiltInSynFamily`: the first field is for evaluating the constructor applied to some arguments (the other two are for emitting derived constraints, `sfInteractTop` is for improvements of a constraint on it's own, and `sfInteractIntert` is for interactions with another constraint that already existis). * If we are going to be modifying `TcEvidence`, I'd be really keen on integrating the evidence for coersions and other evidence a bit more: in particular, it really make sense to allow class predicates in the assumptions of equality constraints. This would allow us to generate evidence for improvements due to interactions of given classes with functional dependencies (e.g., we could express axioms like this: `forall a b c. (C a b, C a c) => (b ~ c)`) -Iavor On Tue, May 26, 2015 at 6:34 AM, Adam Gundry > wrote: Thanks Christiaan, Nice work on ghc-tcplugins-extra. Providing a common package that abstracts away GHC API variations between versions (as far as possible) seems really useful. I notice you also include a workaround for GHC #10301, which is good. I'll try to switch over uom-plugin to use it. As far as I can see, there's no way to bind EvTerms outside TcS; indeed that's a major part of the point of TcS. I'm inclining towards making TcPluginM into a wrapper around TcS, then exposing a nice API to create givens etc. Perhaps we should put together a list of proposed changes to the plugins API, in the light of experience writing the things? There are a few other things I'd like: * the ability to embed arbitrary Core expressions in EvTerms; * a new field in TcPlugin to define type-family reductions directly, rather than having to look for equality constraints involving them; * serializable CoAxiomRules to allow proper evidence in place of UnivCo (doing this for families of rules is a bit tricky, but it should be easy enough to define single axioms). Anything you'd like to add? Iavor? Cheers, Adam On 21/05/15 18:46, Christiaan Baaij wrote: > Hi Adam, Iavor, > > 1. typechecker-plugins-extra package: > > I started on a typechecker-plugin-extra package > at: https://github.com/clash-lang/ghc-tcplugins-extra > Which currently > contains: https://github.com/clash-lang/ghc-tcplugins-extra/blob/master/src/GHC/TcPluginM/Extra.hs > > It currently compiles with both GHC 7.10.1 and HEAD. > Althought the 'newSimpleGiven' function is basically broken in HEAD > because there is no way to bind the evidence anywhere. > > 2. wanted & error messages: > > Indeed, I fixed the error message location by using the correct 'CtLoc'. > I needed the chain of wanted 'EvVar' to get deferred-type-errors working > properly. > However, as you say, the proper way to solve this problem it to create > evidence for the 'parent' wanted in terms of the discharged wanteds. > Currently I've been using the same thing you can Iavor are using: > UnivCo, the unsafeCoerce of EvTerms. > I'll investigate if I can somehow manage to properly solve this problem. > At least the fallback mechanism I've implemented already is currently > working. > > 3. TcS vs TcM > If we keep TcPluginM as a wrapper around TcM, do you know "where" we > could bind EvTerms so that other parts of the constraint solving > pipeline can also access them? > Are these EvTerms bound in some IORef'd environment which we can access > in TcM? > > Cheers, > > Christiaan > > On 21 May 2015 at 18:51, Adam Gundry > >> wrote: > > Hi Christiaan, > > Thanks for your emails, and sorry I can't quite keep up with them! Let > me try to tackle the issues you raise, in no particular order: > > > 1. TcS vs. TcM > > There's no immediate problem with running plugins in TcS rather than > TcM. Indeed, this was my original proposal, but we decided otherwise > because TcS is really supposed to capture the internal state of GHC's > constraint solver, which shouldn't (in principle) be of interest to > plugins. That is, plugins are deliberately not given access to the inert > set (and hence its cache of solved constraints), because we want to > build an interface that is independent of GHC's particular constraint > solving algorithm. At least that's the goal... > > > 2. Disappearance of ctev_evtm > > I don't follow HEAD closely enough to have spotted this, so thanks for > pointing it out. It looks like the change is indeed a problem for > plugins, because the plugin interface indeed doesn't offer the > integration with TcS necessary to create evidence variables that are > already bound. I guess we should add a function to TcPluginM to bind an > evidence variable. In fact, probably we should offer functions in > TcPluginM that look something like > > newWanted :: CtLoc -> PredType -> TcPluginM CtEvidence > newDerived :: CtLoc -> PredType -> TcPluginM CtEvidence > newGiven :: CtLoc -> PredType -> EvTerm -> TcPluginM CtEvidence > > (or perhaps CtOrigin instead of CtLoc? I can never remember the > difference). > > > 3. On wanteds and error messages > > I've not come across the issues you mention with error message locations > and deferred type errors, but I guess that might be because my plugin > tends to spot insoluble constraints fairly early (rather than > simplifying constraints that subsequently turn out to be insoluble on a > later iteration). > > The way this ought to work is that a plugin should solve a wanted with > an evidence term that contains a reference to a new wanted, rather than > completely bogus evidence; this should ensure that deferred type errors > fire correctly. But in practice that might be difficult at the moment. > > In general, I like the idea of a typechecker-plugin-extra package to > bundle up useful common plugin functionality, some of which may later be > moved into GHC itself. (We could start with those functions above!) > Perhaps it could also provide some measure of stability across GHC > releases. I've not yet convinced myself that the trick you describe for > creating chains of wanteds is really necessary to get good error > locations, but if it is, making it part of such a package is a good > plan. > > Cheers, > > Adam > > > > On 21/05/15 09:39, Christiaan Baaij wrote: > > Hi Adam, Hi Iavor, > > > > While working on creating my type-checker plugins, I noticed that > there are some functions in operate in the ?TcS? monad that I would > like to use. > > In an earlier email, for example, Iavor suggested that I use > ?newWantedEvVar? to create new wanted constraints, but this operates > in the ?TcS? monad. > > Of course, there?s ?runTcS?, but this creates a TcS monad with an > empty ?Bag' of ?EvBind?. > > What this means, is that (I think), ?newWantedEvVar? and > ?newWantedEvVarNC?, basically behave the same when run inside > ?runTcS?, because ?newWantedEvVar? is going to look for existing > evidence in an empty ?Bag?? > > > > Also, I saw that plugins are run by the functions in the > ?TcInteract? module, which all run inside the ?TcS? monad. > > So my question is, would it make sense to make ?TcPluginM? a > wrapper around ?TcS? instead of ?TcM?? > > I understand that it would mean > > > > tcPluginIO :: IO a -> TcPluginM a > > > > would have to be specified in terms of either > ?TcSMonad.wrapErrTcS? or ?TsSMonad.wrapErrTcS? and violate the > purpose of those functions. > > Anyhow, that?s my question/suggestion with regards to the TcS monad. > > On to the other part. > > > > > > I noticed that both your plugins store the Coercion/Evidence for a > new Given constraint in the ?ctev_evtm? field of the ?CtGiven? > constructor. > > However, in GHC HEAD, this field no longer exists? > > In GHC HEAD, there is only ?ctev_evar?, of type ?EvVar?, in the > ?CtGiven? constructor. > > I think Simon PJ refactored this because nowhere else in the GHC > compiler was ?ctev_evtm? used to store anything else than an identifier? > > The reason being that the evidence was stored ?TcSEnv? passed > around in the TcS monad. > > So in GHC HEAD, I think there?s no longer any way create new > Givens of which their evidence can be stored somewhere? > > Perhaps one of you two knows how to store evidence of a Given in > GHC HEAD? > > > > Best regards, > > > > Christiaan > > -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Wed May 27 14:04:38 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 27 May 2015 16:04:38 +0200 Subject: [commit: ghc] master: Refactor tuple constraints (ffc2150) In-Reply-To: <20150518124535.0FF013A300@ghc.haskell.org> References: <20150518124535.0FF013A300@ghc.haskell.org> Message-ID: <54300386-CC23-4AE7-BAA7-3A3A049693D5@gmail.com> Hi, This patch causes a regression from GHC 7.10 with regards to constraint kinds. Where previously, constraint tuples could go up to 62, the same as normal tuples, they have now been reduced to 8. I filed a bug report at: https://ghc.haskell.org/trac/ghc/ticket/10451 Regards, Christiaan > On 18 May 2015, at 14:45, 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/ffc21506894c7887d3620423aaf86bc6113a1071/ghc > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 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 ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Thu May 28 16:24:50 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Thu, 28 May 2015 17:24:50 +0100 Subject: Consecutive FFI calls Message-ID: Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David From eir at cis.upenn.edu Wed May 27 15:13:15 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 27 May 2015 11:13:15 -0400 Subject: Proposed changes to typechecker plugins API In-Reply-To: <1432736017.4151931.279367289.4D3C5B0C@webmail.messagingengine.com> References: <55658150.8040701@well-typed.com> <1432736017.4151931.279367289.4D3C5B0C@webmail.messagingengine.com> Message-ID: <6B1A56CC-C162-46CC-8862-89DDFB75BFBE@cis.upenn.edu> I like the general directional of travel here, with two specific points to make: - Unlike Eric, I like embedding CoreExprs directly into EvTerms. Yes, it's a little funny to do so before desugaring, but there's precedent for such things (like embedding Coercions into TcCoercions and Types into HsTypes). If a close reading of the code indicates it would be better, this could be changed to embedding a HsExpr Id into EvTerms -- perhaps there would be less impedance mismatch this way. Then, the current special-case constructors become plain old functions, and we get nice future expandability. - There's something getting smellier and smellier about type families. Here is the comment I posted to the wiki page, at the end of the "Defining type families" section [1]: --- This makes me uncomfortable, in exactly the same way that I was made to feel uncomfortable in the comments starting with comment:4:ticket:9840. The fact that the new, (what I will call) external type families will behave differently than internal type families is further evidence that something is amiss. (The difference in behavior I'm referring to is the difference between matchFam and reduceTyFamApp_maybe.) This, of course, ties into #9636 as well and to some of the more esoteric issues that cropped up while working on #6018/?Phab:D202 and perhaps even #10327. I would love to approach this problem with the idea of making broader changes instead of looking for a minimal change just to support typechecker plugins better. --- I don't have any grand ideas at the moment about this. But I do strongly feel that stepping back and considering the larger question of "What are type families?" would benefit us. [1]: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Definingtypefamilies Richard On May 27, 2015, at 10:13 AM, Eric Seidel wrote: > Hi Adam, > > I like the addition of the new* functions for creating constraints, that > should make for a much nicer API than dealing directly with the > CtEvidence constructors! > > I'm not so convinced however about embedding arbitrary CoreExprs in > EvTerms. First of all, it feels a bit strange to generate CoreExprs > before the desugarer (and we would have to add a `MonadThings TcPluginM` > instance to generate Integer and String CoreExprs). > > But more importantly, based on your wiki page [1], it sounds like what > we really want is a nice API for creating dictionaries. > > Eric > > [1]: > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#EmbeddingCoreExprinEvTerm > > > > On Wed, May 27, 2015, at 01:33, Adam Gundry wrote: >> Hi devs, >> >> I thought I should flag up some proposed changes relating to typechecker >> plugins, which Christiaan, Iavor and I have been discussing. The quick >> summary: >> >> * make it possible for plugins to create constraints (Phab:D909); >> >> * make it easier for plugins to define special type families; >> >> * embed CoreExpr in EvTerm. >> >> For more details, see the wiki page: >> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changestoTcPluginMAPI >> >> Questions/review/comments very welcome. >> >> Adam >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From m at tweag.io Wed May 27 21:44:55 2015 From: m at tweag.io (Boespflug, Mathieu) Date: Wed, 27 May 2015 23:44:55 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: Hi Lars, I'm really not sure that the community has the resources to spare to reimplement non-trivial pieces of *standalone (non-library)* software to address perceived but ethereal "business problems" that are based on lack of understanding about how IP law works as both you and Carter point out. Especially if there are no strong technical reasons to shun the existing implementation, which is perfectly good quality. Does the above cited compromise... >> it seems to me that isolating cpphs into a separate process (w/ the >> option to configure GHC to use some other cpp implementation at your >> own risk if you need to avoid the cpphs implementation at all costs) >> would be the compromise acceptable to everyone in the short run while >> addressing the primary goal to decouple the default-configuration of >> GHC from the fragile system-cpp semantics. ... sound fair to you? Best, Mathieu On 27 May 2015 at 22:21, Lars Kuhtz wrote: > Carter, your explanation why the usage of LGPL is perfectly fine in most > scenarios involves technical as well as legal details. My point is, that it > is not a technical, probably not even a legal issue. I completely agree with > you that it is a business problem. But it makes adaptation of GHC in a > business more difficult if it creates business problems. > > Decisions are made most efficiently when there are rules of thumb. Such a > rule is that BSD or MIT style licenses are not problematic. But if a GPL > style license shows up some special treatment is needed. And a solution > requires a detailed communication between two groups of persons who usually > don't deal directly with each other and speak very different languages. > > This problem can be solved, and we actually solved it, and we use GHC. But > it is annoying and it tends to come up again regularly. > > For a small company which considers adopting Haskell it would be best if > that decision was a purely technical decision. With LGPL style libraries in > the mix it isn?t a purely technical decision any more. > > Lars > > On May 27, 2015, at 12:11 PM, Carter Schonwald > wrote: > > Lars, > which users have an issue? could you please be concrete? Because I frankly > think you are being a bit vague. > > gmp on linux platforms is dynamically linked, so it has absolutely zero > implications there. For those wanting to deploy a proprietary appplication > on windows or OSX, they merely need to either a) bundle the dylib with the > application and suitable install scripting to adjust the load paths. (or > build the integer simple version of GHC and navigate choosing dependencies > that depend on integer-gmp specifically being installed ) > > any other problems with industrial usage and libgmp are artifacts of dealing > with business or legal staff that have not been educated about how > intellectual property law works. Which is business problem rather than a > haskell problem. > > > > On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz wrote: >> >> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >> >> Don't you still have to support -pgmF? >> > >> > I guess so, unfortunately... so we'd have to keep a legacy code-path for >> > external cpp processing around, at least in the short run... >> >> >> I think it?s unfortunate if industrial usage of GHC is supported only >> through legacy code-paths. >> >> I think non-technical arguments do matter here. It is about explanations. >> Convincing a company to use Haskell can be already quite a challenge. >> Additional legal issues don?t make that easier. >> >> The gmp dependency is causing already enough trouble for industrial users. >> Let?s not just add another licensing issue. >> >> Lars >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.bracker at googlemail.com Thu May 28 12:35:55 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Thu, 28 May 2015 13:35:55 +0100 Subject: Proposed changes to typechecker plugins API Message-ID: Hi Adam, Hi Eric, At least for what I want to use them for [1] it would be nice if there was an easy way to say: If you are stuck on solving "Constraint a b TypeC", then you should pick, e.g.: - "a ~ TypeA" and "b ~ TypeB" (What I am actually trying to say is: use the instance "Constraint TypeA TypeB TypeC") - "a ~ b" Currently I am producing equality constraints, like this: mkDerivedTypeEqCt :: TcTyVar -> TcType -> TcPluginM Ct mkDerivedTypeEqCt tyVar ty = do (_, lclEnv) <- getEnvs return $ CTyEqCan { cc_ev = CtDerived -- :: CtEvidence { ctev_pred = ty -- :: TcPredType -- This matches type-wise, but I have no idea what actually belongs here. , ctev_loc = mkGivenLoc topTcLevel (UnifyForAllSkol [tyVar] ty) lclEnv -- :: CtLoc -- Again no idea what actually belongs here: -- topTcLevel :: TcLevel -- To what does this relate? I guess top level -- is ok for equality constraints -- (UnifyForAllSkol [tyVar] ty) :: SkolemInfo -- This one matches what we have at disposal (no idea if it is the right one). -- lclEnv :: TcLclEnv -- I just use the only one I know. } , cc_tyvar = tyVar -- :: TcTyVar , cc_rhs = ty -- :: TcType , cc_eq_rel = NomEq -- :: EqRel -- Alternative would be ReprEq. Whats the difference? } Which seems to be working, but still leaves a lot of open questions (see comments). Maybe my problems using the API are more related to missing documentation, then lack of API functionality. Jan [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html On Wed, 27 May 2015 07:13:37, Eric Seidel wrote: > Hi Adam, > > I like the addition of the new* functions for creating constraints, that > should make for a much nicer API than dealing directly with the > CtEvidence constructors! > > I'm not so convinced however about embedding arbitrary CoreExprs in > EvTerms. First of all, it feels a bit strange to generate CoreExprs > before the desugarer (and we would have to add a `MonadThings TcPluginM` > instance to generate Integer and String CoreExprs). > > But more importantly, based on your wiki page [1], it sounds like what > we really want is a nice API for creating dictionaries. > > Eric > > [1]: > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#EmbeddingCoreExprinEvTerm > > > > On Wed, May 27, 2015, at 01:33, Adam Gundry wrote: > > Hi devs, > > > > I thought I should flag up some proposed changes relating to typechecker > > plugins, which Christiaan, Iavor and I have been discussing. The quick > > summary: > > > > * make it possible for plugins to create constraints (Phab:D909); > > > > * make it easier for plugins to define special type families; > > > > * embed CoreExpr in EvTerm. > > > > For more details, see the wiki page: > > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changestoTcPluginMAPI > > > > Questions/review/comments very welcome. > > > > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu May 28 16:35:54 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 28 May 2015 12:35:54 -0400 Subject: Test posting -- debugging mailinglist issues. Message-ID: Disregard this, sorry for the noise :-) --Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed May 27 19:11:30 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 May 2015 15:11:30 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: Lars, which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz wrote: > On 21/05/15 19:07, Herbert Valerio Riedel wrote: > >> Don't you still have to support -pgmF? > > > > I guess so, unfortunately... so we'd have to keep a legacy code-path for > > external cpp processing around, at least in the short run... > > > I think it?s unfortunate if industrial usage of GHC is supported only > through legacy code-paths. > > I think non-technical arguments do matter here. It is about explanations. > Convincing a company to use Haskell can be already quite a challenge. > Additional legal issues don?t make that easier. > > The gmp dependency is causing already enough trouble for industrial users. > Let?s not just add another licensing issue. > > Lars > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at tweag.io Mon May 25 14:08:49 2015 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Mon, 25 May 2015 11:08:49 -0300 Subject: StaticPointers to local definitions Message-ID: Hello, It is happening in practice that one wants to create a static pointer in a function and use some local definitions. > f :: Static (Int -> Int) > f x = sf > where > body = (+1) > sf = Static body 'body' defines a closed expression, but this is currently rejected because desugaring the static form would produce a top-level binding of the form: > sf_top_level :: Int -> Int > sf_top_level = body where the local binding 'body' is not in scope. Barring inlining, which wouldn't work in more complex examples, one approach around this is to have the compiler move local definitions to the top level during desugaring when they are referenced by a static pointer. Two questions arise: 1) Would this interfere with other aspects of compilation? 2) Would anyone argue there is a better approach to accomplish this? Thanks, Facundo From adam at well-typed.com Thu May 28 17:19:41 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 28 May 2015 18:19:41 +0100 Subject: Proposed changes to typechecker plugins API In-Reply-To: References: Message-ID: <55674E2D.9060807@well-typed.com> Hi Jan, Sadly I think your problems are more to do with lack of documentation in the GHC API in general, than the specific extension I'm proposing! Your use case should be possible with the existing setup: the easiest way is probably something like this (untested): mkNonCanonical $ CtDerived (mkTcEqPred (mkTyVarTy tyVar) ty) loc where loc = ctev_loc (cc_ev c) Here `c` should be the `Ct` you started with; reusing its `ctev_loc` makes it appear as if the new derived constraint came from the same location. Non-canonical constraints are those that have not yet been processed by GHC's constraint solver, which is fine for constraints generated by plugins. Hope this helps, Adam On 28/05/15 13:35, Jan Bracker wrote: > Hi Adam, Hi Eric, > > At least for what I want to use them for [1] it would be nice if there > was an easy way to say: > > If you are stuck on solving "Constraint a b TypeC", then you should > pick, e.g.: > - "a ~ TypeA" and "b ~ TypeB" (What I am actually trying to say is: use > the instance "Constraint TypeA TypeB TypeC") > - "a ~ b" > > Currently I am producing equality constraints, like this: > > mkDerivedTypeEqCt :: TcTyVar -> TcType -> TcPluginM Ct > mkDerivedTypeEqCt tyVar ty = do > (_, lclEnv) <- getEnvs > return $ CTyEqCan > { cc_ev = CtDerived -- :: CtEvidence > { ctev_pred = ty -- :: TcPredType > -- This matches type-wise, but I have no idea what actually > belongs here. > , ctev_loc = mkGivenLoc topTcLevel (UnifyForAllSkol [tyVar] ty) > lclEnv -- :: CtLoc > -- Again no idea what actually belongs here: > -- topTcLevel :: TcLevel > -- To what does this relate? I guess top level > -- is ok for equality constraints > -- (UnifyForAllSkol [tyVar] ty) :: SkolemInfo > -- This one matches what we have at disposal (no idea if it is > the right one). > -- lclEnv :: TcLclEnv > -- I just use the only one I know. > } > , cc_tyvar = tyVar -- :: TcTyVar > , cc_rhs = ty -- :: TcType > , cc_eq_rel = NomEq -- :: EqRel > -- Alternative would be ReprEq. Whats the difference? > } > > Which seems to be working, but still leaves a lot of open questions (see > comments). > > Maybe my problems using the API are more related to missing > documentation, then lack of API functionality. > > Jan > > [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From adam at well-typed.com Thu May 28 17:42:30 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 28 May 2015 18:42:30 +0100 Subject: [Haskell-cafe] Disambiguating a Num/RealFrac instance In-Reply-To: References: Message-ID: <55675386.9030809@well-typed.com> On 28/05/15 18:28, Brandon Allbery wrote: > On Tue, May 26, 2015 at 8:35 PM, > wrote: > > Is there any way (without IncoherentInstances or Rebindablesyntax) > that I can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") > and get back "F 4" without getting type errors that "4.0"'s type is > ambiguous? I can guarantee there won't be any additional instances > to "ToGPA" > > > A typeclass with only one instance is nonsensical, and often a symptom > of trying to use typeclasses as OO classes. All it's doing here is > hurting you. Like Brandon, I suspect this probably isn't what you should do. But if you *really* want to do it, this works: {-# LANGUAGE ExtendedDefaultRules, FlexibleInstances #-} default (Float) data GPA = F Float | Excuse String class ToGPA a where giveGPA :: a -> GPA instance ToGPA Float where giveGPA = F instance ToGPA String where giveGPA = Excuse x = giveGPA 4 y = giveGPA 4.0 z = giveGPA "Hello" For more information: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-evaluation.html#extended-default-rules Hope this helps, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Wed May 27 21:00:46 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 May 2015 17:00:46 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: could you be concrete about the specific challenges and experiences you've had, and with what organizations? Its very hard to evaluate the veracity of what youre saying otherwise! was using GCC an issue at this organization too? because that would be a real problem! 'cause tis GPLV3 rather than LGPL! :) On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz wrote: > Carter, your explanation why the usage of LGPL is perfectly fine in most > scenarios involves technical as well as legal details. My point is, that it > is not a technical, probably not even a legal issue. I completely agree > with you that it is a business problem. But it makes adaptation of GHC in a > business more difficult if it creates business problems. > > Decisions are made most efficiently when there are rules of thumb. Such a > rule is that BSD or MIT style licenses are not problematic. But if a GPL > style license shows up some special treatment is needed. And a solution > requires a detailed communication between two groups of persons who usually > don't deal directly with each other and speak very different languages. > > This problem can be solved, and we actually solved it, and we use GHC. But > it is annoying and it tends to come up again regularly. > > For a small company which considers adopting Haskell it would be best if > that decision was a purely technical decision. With LGPL style libraries in > the mix it isn?t a purely technical decision any more. > > Lars > > On May 27, 2015, at 12:11 PM, Carter Schonwald > wrote: > > Lars, > which users have an issue? could you please be concrete? Because I frankly > think you are being a bit vague. > > gmp on linux platforms is dynamically linked, so it has absolutely zero > implications there. For those wanting to deploy a proprietary appplication > on windows or OSX, they merely need to either a) bundle the dylib with the > application and suitable install scripting to adjust the load paths. (or > build the integer simple version of GHC and navigate choosing dependencies > that depend on integer-gmp specifically being installed ) > > any other problems with industrial usage and libgmp are artifacts of > dealing with business or legal staff that have not been educated about how > intellectual property law works. Which is business problem rather than a > haskell problem. > > > > On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz wrote: > >> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >> >> Don't you still have to support -pgmF? >> > >> > I guess so, unfortunately... so we'd have to keep a legacy code-path for >> > external cpp processing around, at least in the short run... >> >> >> I think it?s unfortunate if industrial usage of GHC is supported only >> through legacy code-paths. >> >> I think non-technical arguments do matter here. It is about explanations. >> Convincing a company to use Haskell can be already quite a challenge. >> Additional legal issues don?t make that easier. >> >> The gmp dependency is causing already enough trouble for industrial >> users. Let?s not just add another licensing issue. >> >> Lars >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at rodlogic.net Thu May 28 21:18:00 2015 From: dev at rodlogic.net (RodLogic) Date: Thu, 28 May 2015 17:18:00 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: Based on two different occasions with two different companies (one related to an acquisition and one to an OEM agreement), my experience is exactly as laid out by Lars. A LGPL license will raise concerns by the legal team and it will delay the process because it comes with a certain level of risk that they may or may not want to take. And good luck trying to find a precise reason why LGPL is fine or it isn't in all cases: the reality is a bit more complicated and with a few more shades of grey. Having said that, in both occasions, the LGPL dependencies were, ultimately, not an impediment to continuing negotiations. They were definitely a friction, though. On Wed, May 27, 2015 at 5:41 PM, Lars Kuhtz wrote: > The issue that GMP is LGPL licensed came up a couple of times in > discussions at PivotCloud. Before each product release developers were > requested to provided a list of all third party dependencies along with > their licenses. This was given to the folks who deal with the legal stuff. > If they spoted anything with (L)GPL in it, they had general concerns. Also > someone also had heard some rumors on the web about issues with GMP and GHC > (like for instance this thread in the mailing list archives :-) ) adding to > the uncertainty. Some time back I was even asked to build GHC without GMP, > which, at least at that time, wasn?t fun to do; though we never used that > build. > > As a more general and not directly related remark: when I was working at > Microsoft there were rules how to deal with open source software based on > the style of the license. At least in my group anything with (L)GPL was > simply a no-go without any further discussion about details. > > From this experience I think that if we want to make adaption of Haskell > easy we may avoid (L)GPL when possible. If we can?t avoid it, well, > probably it wouldn?t be a disaster neither. > > > On May 27, 2015, at 2:00 PM, Carter Schonwald > wrote: > > could you be concrete about the specific challenges and experiences you've > had, and with what organizations? Its very hard to evaluate the veracity of > what youre saying otherwise! > > was using GCC an issue at this organization too? because that would be a > real problem! 'cause tis GPLV3 rather than LGPL! :) > > On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz wrote: > >> Carter, your explanation why the usage of LGPL is perfectly fine in most >> scenarios involves technical as well as legal details. My point is, that it >> is not a technical, probably not even a legal issue. I completely agree >> with you that it is a business problem. But it makes adaptation of GHC in a >> business more difficult if it creates business problems. >> >> Decisions are made most efficiently when there are rules of thumb. Such a >> rule is that BSD or MIT style licenses are not problematic. But if a GPL >> style license shows up some special treatment is needed. And a solution >> requires a detailed communication between two groups of persons who usually >> don't deal directly with each other and speak very different languages. >> >> This problem can be solved, and we actually solved it, and we use GHC. >> But it is annoying and it tends to come up again regularly. >> >> For a small company which considers adopting Haskell it would be best if >> that decision was a purely technical decision. With LGPL style libraries in >> the mix it isn?t a purely technical decision any more. >> >> Lars >> >> On May 27, 2015, at 12:11 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >> Lars, >> which users have an issue? could you please be concrete? Because I >> frankly think you are being a bit vague. >> >> gmp on linux platforms is dynamically linked, so it has absolutely zero >> implications there. For those wanting to deploy a proprietary appplication >> on windows or OSX, they merely need to either a) bundle the dylib with the >> application and suitable install scripting to adjust the load paths. (or >> build the integer simple version of GHC and navigate choosing dependencies >> that depend on integer-gmp specifically being installed ) >> >> any other problems with industrial usage and libgmp are artifacts of >> dealing with business or legal staff that have not been educated about how >> intellectual property law works. Which is business problem rather than a >> haskell problem. >> >> >> >> On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz wrote: >> >>> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >>> >> Don't you still have to support -pgmF? >>> > >>> > I guess so, unfortunately... so we'd have to keep a legacy code-path >>> for >>> > external cpp processing around, at least in the short run... >>> >>> >>> I think it?s unfortunate if industrial usage of GHC is supported only >>> through legacy code-paths. >>> >>> I think non-technical arguments do matter here. It is about >>> explanations. Convincing a company to use Haskell can be already quite a >>> challenge. Additional legal issues don?t make that easier. >>> >>> The gmp dependency is causing already enough trouble for industrial >>> users. Let?s not just add another licensing issue. >>> >>> Lars >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri May 29 00:42:21 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 28 May 2015 17:42:21 -0700 Subject: Strange testsuite failure In-Reply-To: <85858201693a46fe9372ddad7079b061@DB4PR30MB030.064d.mgd.msft.net> References: <85858201693a46fe9372ddad7079b061@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1432860127-sup-5068@sabre> For the record, this was fixed the next day: commit 3ef7fcedfa1ad47968ca5fa107d51a6ab7051ed7 Author: Zejun Wu Date: Thu May 14 10:56:51 2015 -0500 Edward Excerpts from Simon Peyton Jones's message of 2015-05-13 03:55:16 -0700: > Is this expected? Just started happening for me > > > =====> T8333(normal) 140 of 185 [0, 0, 0] > > cd . && $MAKE -s --no-print-directory T8333 T8333.run.stdout 2> T8333.run.stderr > > Actual stdout output differs from expected: > > --- ./T8333.stdout 2015-01-27 13:00:30.000000000 +0000 > > +++ ./T8333.run.stdout 2015-05-13 11:54:03.199711197 +0100 > > @@ -0,0 +1,4 @@ > > +*** WARNING: . is writable by someone else, IGNORING! > > +Suggested fix: execute 'chmod 644 .' > > +*** WARNING: /home/simonpj is writable by someone else, IGNORING! > > +Suggested fix: execute 'chmod 644 /home/simonpj' > > *** unexpected failure for T8333(normal) From ezyang at mit.edu Fri May 29 00:46:40 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 28 May 2015 17:46:40 -0700 Subject: Travis builds failing Message-ID: <1432860362-sup-2108@sabre> To whoever manages our Travis setup https://travis-ci.org/ghc/ghc/builds We seem to be failing because our build takes longer than 50min. Edward From ezyang at mit.edu Fri May 29 01:23:57 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 28 May 2015 18:23:57 -0700 Subject: Fwd: Re: [commit: ghc] ghc-7.10: base: fix #10298 & #7695 (25b8478) Message-ID: <1432862625-sup-402@sabre> This commit broke the HM builds: https://phabricator.haskell.org/B4147 When I validate locally, though, it works fine. Edward Excerpts from git's message of 2015-05-28 18:11:07 -0700: > Repository : ssh://git at git.haskell.org/ghc > > On branch : ghc-7.10 > Link : http://ghc.haskell.org/trac/ghc/changeset/25b84781ed950d59c7bffb77a576d3c43a883ca9/ghc > > >--------------------------------------------------------------- > > commit 25b84781ed950d59c7bffb77a576d3c43a883ca9 > Author: Austin Seipp > Date: Tue May 19 04:56:40 2015 -0500 > > base: fix #10298 & #7695 > > Summary: > This applies a patch from Reid Barton and Sylvain Henry, which fix a > disasterous infinite loop when iconv fails to load locale files, as > specified in #10298. > > The fix is a bit of a hack but should be fine - for the actual reasoning > behind it, see `Note [Disaster and iconv]` for more info. > > In addition to this fix, we also patch up the IO Encoding utilities to > recognize several variations of the 'ASCII' encoding (including its > aliases) directly so that GHC can do conversions without iconv. This > allows a static binary to sit in an initramfs. > > Authored-by: Reid Barton > Authored-by: Sylvain Henry > Signed-off-by: Austin Seipp > > Test Plan: Eyeballed it. > > Reviewers: rwbarton, hvr > > Subscribers: bgamari, thomie > > Differential Revision: https://phabricator.haskell.org/D898 > > GHC Trac Issues: #10298, #7695 > > (cherry picked from commit e28462de700240288519a016d0fe44d4360d9ffd) > > >--------------------------------------------------------------- > > 25b84781ed950d59c7bffb77a576d3c43a883ca9 > libraries/base/GHC/IO/Encoding.hs | 14 +++++++++++++- > libraries/base/GHC/TopHandler.hs | 29 ++++++++++++++++++++++++++++- > 2 files changed, 41 insertions(+), 2 deletions(-) > > diff --git a/libraries/base/GHC/IO/Encoding.hs b/libraries/base/GHC/IO/Encoding.hs > index 31683b4..014b61b 100644 > --- a/libraries/base/GHC/IO/Encoding.hs > +++ b/libraries/base/GHC/IO/Encoding.hs > @@ -235,7 +235,14 @@ mkTextEncoding e = case mb_coding_failure_mode of > _ -> Nothing > > mkTextEncoding' :: CodingFailureMode -> String -> IO TextEncoding > -mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of > +mkTextEncoding' cfm enc > + -- First, specifically match on ASCII encodings directly using > + -- several possible aliases (specified by RFC 1345 & co), which > + -- allows us to handle ASCII conversions without iconv at all (see > + -- trac #10298). > + | any (== enc) ansiEncNames = return (UTF8.mkUTF8 cfm) > + -- Otherwise, handle other encoding needs via iconv. > + | otherwise = case [toUpper c | c <- enc, c /= '-'] of > "UTF8" -> return $ UTF8.mkUTF8 cfm > "UTF16" -> return $ UTF16.mkUTF16 cfm > "UTF16LE" -> return $ UTF16.mkUTF16le cfm > @@ -249,6 +256,11 @@ mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of > #else > _ -> Iconv.mkIconvEncoding cfm enc > #endif > + where > + ansiEncNames = -- ASCII aliases > + [ "ANSI_X3.4-1968", "iso-ir-6", "ANSI_X3.4-1986", "ISO_646.irv:1991" > + , "US-ASCII", "us", "IBM367", "cp367", "csASCII", "ASCII", "ISO646-US" > + ] > > latin1_encode :: CharBuffer -> Buffer Word8 -> IO (CharBuffer, Buffer Word8) > latin1_encode input output = fmap (\(_why,input',output') -> (input',output')) $ Latin1.latin1_encode input output -- unchecked, used for char8 > diff --git a/libraries/base/GHC/TopHandler.hs b/libraries/base/GHC/TopHandler.hs > index d7c0038..e725196 100644 > --- a/libraries/base/GHC/TopHandler.hs > +++ b/libraries/base/GHC/TopHandler.hs > @@ -157,13 +157,40 @@ real_handler exit se = do > Just (ExitFailure n) -> exit n > > -- EPIPE errors received for stdout are ignored (#2699) > - _ -> case fromException se of > + _ -> catch (case fromException se of > Just IOError{ ioe_type = ResourceVanished, > ioe_errno = Just ioe, > ioe_handle = Just hdl } > | Errno ioe == ePIPE, hdl == stdout -> exit 0 > _ -> do reportError se > exit 1 > + ) (disasterHandler exit) -- See Note [Disaster with iconv] > + > +-- don't use errorBelch() directly, because we cannot call varargs functions > +-- using the FFI. > +foreign import ccall unsafe "HsBase.h errorBelch2" > + errorBelch :: CString -> CString -> IO () > + > +disasterHandler :: (Int -> IO a) -> IOError -> IO a > +disasterHandler exit _ = > + withCAString "%s" $ \fmt -> > + withCAString msgStr $ \msg -> > + errorBelch fmt msg >> exit 1 > + where msgStr = "encountered an exception while trying to report an exception" > + > +{- Note [Disaster with iconv] > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +When using iconv, it's possible for things like iconv_open to fail in > +restricted environments (like an initram or restricted container), but > +when this happens the error raised inevitably calls `peekCString`, > +which depends on the users locale, which depends on using > +`iconv_open`... which causes an infinite loop. > + > +This occurrence is also known as tickets #10298 and #7695. So to work > +around it we just set _another_ error handler and bail directly by > +calling the RTS, without iconv at all. > +-} > > > -- try to flush stdout/stderr, but don't worry if we fail > --- End forwarded message --- From carter.schonwald at gmail.com Fri May 29 01:35:31 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 28 May 2015 21:35:31 -0400 Subject: RFC: "Native -XCPP" Proposal In-Reply-To: References: <618375c6-62d9-49d9-bb2f-e593600533e6@me.com> <87bnhenrw0.fsf@gmail.com> <87617mnd3l.fsf@gmail.com> <87wq01ncbm.fsf@gmail.com> Message-ID: Well said. However, until Someone finds the time to write something with a nicer license, that's a cross we'll have to bear. Otoh, the shelling out approach for cpp in the mean time has zero issues vs linking to a lgpl or gpl library. Unless those are organizations that done use Linux or gcc anywhere. On Thursday, May 28, 2015, RodLogic wrote: > Based on two different occasions with two different companies (one related > to an acquisition and one to an OEM agreement), my experience is exactly as > laid out by Lars. A LGPL license will raise concerns by the legal team and > it will delay the process because it comes with a certain level of risk > that they may or may not want to take. And good luck trying to find a > precise reason why LGPL is fine or it isn't in all cases: the reality is a > bit more complicated and with a few more shades of grey. > > Having said that, in both occasions, the LGPL dependencies were, > ultimately, not an impediment to continuing negotiations. They were > definitely a friction, though. > > > On Wed, May 27, 2015 at 5:41 PM, Lars Kuhtz > wrote: > >> The issue that GMP is LGPL licensed came up a couple of times in >> discussions at PivotCloud. Before each product release developers were >> requested to provided a list of all third party dependencies along with >> their licenses. This was given to the folks who deal with the legal stuff. >> If they spoted anything with (L)GPL in it, they had general concerns. Also >> someone also had heard some rumors on the web about issues with GMP and GHC >> (like for instance this thread in the mailing list archives :-) ) adding to >> the uncertainty. Some time back I was even asked to build GHC without GMP, >> which, at least at that time, wasn?t fun to do; though we never used that >> build. >> >> As a more general and not directly related remark: when I was working at >> Microsoft there were rules how to deal with open source software based on >> the style of the license. At least in my group anything with (L)GPL was >> simply a no-go without any further discussion about details. >> >> From this experience I think that if we want to make adaption of Haskell >> easy we may avoid (L)GPL when possible. If we can?t avoid it, well, >> probably it wouldn?t be a disaster neither. >> >> >> On May 27, 2015, at 2:00 PM, Carter Schonwald > > wrote: >> >> could you be concrete about the specific challenges and experiences >> you've had, and with what organizations? Its very hard to evaluate the >> veracity of what youre saying otherwise! >> >> was using GCC an issue at this organization too? because that would be a >> real problem! 'cause tis GPLV3 rather than LGPL! :) >> >> On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz > > wrote: >> >>> Carter, your explanation why the usage of LGPL is perfectly fine in most >>> scenarios involves technical as well as legal details. My point is, that it >>> is not a technical, probably not even a legal issue. I completely agree >>> with you that it is a business problem. But it makes adaptation of GHC in a >>> business more difficult if it creates business problems. >>> >>> Decisions are made most efficiently when there are rules of thumb. Such >>> a rule is that BSD or MIT style licenses are not problematic. But if a GPL >>> style license shows up some special treatment is needed. And a solution >>> requires a detailed communication between two groups of persons who usually >>> don't deal directly with each other and speak very different languages. >>> >>> This problem can be solved, and we actually solved it, and we use GHC. >>> But it is annoying and it tends to come up again regularly. >>> >>> For a small company which considers adopting Haskell it would be best if >>> that decision was a purely technical decision. With LGPL style libraries in >>> the mix it isn?t a purely technical decision any more. >>> >>> Lars >>> >>> On May 27, 2015, at 12:11 PM, Carter Schonwald < >>> carter.schonwald at gmail.com >>> > wrote: >>> >>> Lars, >>> which users have an issue? could you please be concrete? Because I >>> frankly think you are being a bit vague. >>> >>> gmp on linux platforms is dynamically linked, so it has absolutely zero >>> implications there. For those wanting to deploy a proprietary appplication >>> on windows or OSX, they merely need to either a) bundle the dylib with the >>> application and suitable install scripting to adjust the load paths. (or >>> build the integer simple version of GHC and navigate choosing dependencies >>> that depend on integer-gmp specifically being installed ) >>> >>> any other problems with industrial usage and libgmp are artifacts of >>> dealing with business or legal staff that have not been educated about how >>> intellectual property law works. Which is business problem rather than a >>> haskell problem. >>> >>> >>> >>> On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz >> > wrote: >>> >>>> On 21/05/15 19:07, Herbert Valerio Riedel wrote: >>>> >> Don't you still have to support -pgmF? >>>> > >>>> > I guess so, unfortunately... so we'd have to keep a legacy code-path >>>> for >>>> > external cpp processing around, at least in the short run... >>>> >>>> >>>> I think it?s unfortunate if industrial usage of GHC is supported only >>>> through legacy code-paths. >>>> >>>> I think non-technical arguments do matter here. It is about >>>> explanations. Convincing a company to use Haskell can be already quite a >>>> challenge. Additional legal issues don?t make that easier. >>>> >>>> The gmp dependency is causing already enough trouble for industrial >>>> users. Let?s not just add another licensing issue. >>>> >>>> Lars >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri May 29 07:52:53 2015 From: adam at well-typed.com (Adam Gundry) Date: Fri, 29 May 2015 08:52:53 +0100 Subject: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD In-Reply-To: <076d049446174357a0834a23f77b0aa8@DB4PR30MB030.064d.mgd.msft.net> References: <9EE5DA64-EB82-41F8-ADA7-EA8EA8724471@gmail.com> <555E0D10.4040804@well-typed.com> <55647660.6050609@well-typed.com> <076d049446174357a0834a23f77b0aa8@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <55681AD5.70600@well-typed.com> On 27/05/15 23:42, Simon Peyton Jones wrote: > I like EvTerm as a distinct data type precisely because it > enumerates all the forms of evidence we need. Once you allow arbitrary > CoreExprs, we lose that explicit enumeration. > > Now, that might be OK. Evidence terms are proof terms: any well typed > EvTerm is a proof of the predicate described by its type. So if a > CoreExpr has the right type, then it **should** be the case that the > evidence term is OK (provided it?s not bottom). So I can?t quite nail > down why I like the explicit EvTerm; except the relatively minor reason > that it puts off desugaring to the desugarer. I can see the appeal of the explicit enumeration of the evidence generated by GHC itself, but it's obviously not modular. I don't have a particularly strong opinion about whether the current special-case constructors should be subsumed by the embedding; this might remove some boilerplate, but we could also keep the embedding for plugins only. I'm also open to Richard's idea that we use HsExpr Id instead of CoreExpr if the former works out more easily. Can you elaborate on your parenthetical remark "provided it?s not bottom"? I was under the impression that EvTerms could be bottom (e.g. `EvDelayedError`) without compromising type safety. > On a separate matter, can we eliminate the trap-door from > TcPluginM to TcM? That is, can you enumerate all the things you need > from TcPluginM? The reason I ask is that I?d like to stop building TcS > on top of TcM, and instead make it a free-standing monad. Reason: we > increasingly want to do constraint solving outside a full-blown > typechecker. Eg. when doing pattern-match exhaustiveness checks. > Faking up a TcM monad with lots of error thunks seems wrong. It's convenient to have an escape hatch, but I think making TcS a separate monad is a good idea and I wouldn't like plugins to hold this up. I don't think plugins are likely to need anything not also needed by TcS (arbitrary IO perhaps excepted, but hopefully that shouldn't be a problem). Beyond the changes in Phab:D909, the only thing I'm still using unsafeTcPluginTcM for is newUnique (in order to generate new skolem variables), which could easily be added to the TcPluginM interface as well. Anyone need anything else? Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From christiaan.baaij at gmail.com Fri May 29 08:29:41 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 29 May 2015 10:29:41 +0200 Subject: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD In-Reply-To: <55681AD5.70600@well-typed.com> References: <9EE5DA64-EB82-41F8-ADA7-EA8EA8724471@gmail.com> <555E0D10.4040804@well-typed.com> <55647660.6050609@well-typed.com> <076d049446174357a0834a23f77b0aa8@DB4PR30MB030.064d.mgd.msft.net> <55681AD5.70600@well-typed.com> Message-ID: > Beyond the changes in Phab:D909, the only thing I'm still using > unsafeTcPluginTcM for is newUnique (in order to generate new skolem > variables), which could easily be added to the TcPluginM interface as > well. Anyone need anything else? No, In my own type-checker plugins I only use unsafeTcPluginTcM for TcmType.newEvVar, which has now been added to the TcPluginM in Phab:D909. From hsyl20 at gmail.com Fri May 29 15:35:50 2015 From: hsyl20 at gmail.com (Sylvain Henry) Date: Fri, 29 May 2015 17:35:50 +0200 Subject: [commit: ghc] ghc-7.10: base: fix #10298 & #7695 (25b8478) In-Reply-To: <1432862625-sup-402@sabre> References: <1432862625-sup-402@sabre> Message-ID: It depends on your locale, this explains the different behavior on your local machine. The build machine seems to be using an ASCII locale and GHC wants to print some Unicode characters (the tick and back-tick surrounding types in error messages). Before this patch, Iconv was used to do the conversion from Unicode to ASCII. It seems that it replaces the Unicode ticks with ASCII ticks (i.e. 0xE28098 in UTF-8 into 0x60 and 0xE28099 into 0x27). If you enter: cd ghc/testsuite/tests grep -rn "match expected type" **/*.stderr You can see that some .stderr have been generated with a ASCII locale and some others with a UTF-8 locale by looking at the ticks. Are the tests expecting ASCII output (e.g. driver/T2507) passing on platforms with UTF-8 locales? The output is not equal to the expected one except if it is converted to ASCII before the comparison. With this patch, we don't use Iconv to convert from Unicode to ASCII because it may not be available in some contexts (docker containers, initramdisk, etc.). Instead we use the UTF-8 encoder to encode ASCII (ASCII characters are encoded in the same way in ASCII and in UTF-8) and we don't try to match Unicode only characters to ASCII ones. Solutions: 1) change our patch to use our method only when Iconv cannot be used. 2) implement the Unicode to ASCII conversion as performed by Iconv 3) change the locale to a UTF-8 one on the build machine ;-) Sylvain 2015-05-29 3:23 GMT+02:00 Edward Z. Yang : > This commit broke the HM builds: https://phabricator.haskell.org/B4147 > > When I validate locally, though, it works fine. > > Edward > > Excerpts from git's message of 2015-05-28 18:11:07 -0700: > > Repository : ssh://git at git.haskell.org/ghc > > > > On branch : ghc-7.10 > > Link : > http://ghc.haskell.org/trac/ghc/changeset/25b84781ed950d59c7bffb77a576d3c43a883ca9/ghc > > > > >--------------------------------------------------------------- > > > > commit 25b84781ed950d59c7bffb77a576d3c43a883ca9 > > Author: Austin Seipp > > Date: Tue May 19 04:56:40 2015 -0500 > > > > base: fix #10298 & #7695 > > > > Summary: > > This applies a patch from Reid Barton and Sylvain Henry, which fix a > > disasterous infinite loop when iconv fails to load locale files, as > > specified in #10298. > > > > The fix is a bit of a hack but should be fine - for the actual > reasoning > > behind it, see `Note [Disaster and iconv]` for more info. > > > > In addition to this fix, we also patch up the IO Encoding utilities > to > > recognize several variations of the 'ASCII' encoding (including its > > aliases) directly so that GHC can do conversions without iconv. This > > allows a static binary to sit in an initramfs. > > > > Authored-by: Reid Barton > > Authored-by: Sylvain Henry > > Signed-off-by: Austin Seipp > > > > Test Plan: Eyeballed it. > > > > Reviewers: rwbarton, hvr > > > > Subscribers: bgamari, thomie > > > > Differential Revision: https://phabricator.haskell.org/D898 > > > > GHC Trac Issues: #10298, #7695 > > > > (cherry picked from commit e28462de700240288519a016d0fe44d4360d9ffd) > > > > >--------------------------------------------------------------- > > > > 25b84781ed950d59c7bffb77a576d3c43a883ca9 > > libraries/base/GHC/IO/Encoding.hs | 14 +++++++++++++- > > libraries/base/GHC/TopHandler.hs | 29 ++++++++++++++++++++++++++++- > > 2 files changed, 41 insertions(+), 2 deletions(-) > > > > diff --git a/libraries/base/GHC/IO/Encoding.hs > b/libraries/base/GHC/IO/Encoding.hs > > index 31683b4..014b61b 100644 > > --- a/libraries/base/GHC/IO/Encoding.hs > > +++ b/libraries/base/GHC/IO/Encoding.hs > > @@ -235,7 +235,14 @@ mkTextEncoding e = case mb_coding_failure_mode of > > _ -> Nothing > > > > mkTextEncoding' :: CodingFailureMode -> String -> IO TextEncoding > > -mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of > > +mkTextEncoding' cfm enc > > + -- First, specifically match on ASCII encodings directly using > > + -- several possible aliases (specified by RFC 1345 & co), which > > + -- allows us to handle ASCII conversions without iconv at all (see > > + -- trac #10298). > > + | any (== enc) ansiEncNames = return (UTF8.mkUTF8 cfm) > > + -- Otherwise, handle other encoding needs via iconv. > > + | otherwise = case [toUpper c | c <- enc, c /= '-'] of > > "UTF8" -> return $ UTF8.mkUTF8 cfm > > "UTF16" -> return $ UTF16.mkUTF16 cfm > > "UTF16LE" -> return $ UTF16.mkUTF16le cfm > > @@ -249,6 +256,11 @@ mkTextEncoding' cfm enc = case [toUpper c | c <- > enc, c /= '-'] of > > #else > > _ -> Iconv.mkIconvEncoding cfm enc > > #endif > > + where > > + ansiEncNames = -- ASCII aliases > > + [ "ANSI_X3.4-1968", "iso-ir-6", "ANSI_X3.4-1986", > "ISO_646.irv:1991" > > + , "US-ASCII", "us", "IBM367", "cp367", "csASCII", "ASCII", > "ISO646-US" > > + ] > > > > latin1_encode :: CharBuffer -> Buffer Word8 -> IO (CharBuffer, Buffer > Word8) > > latin1_encode input output = fmap (\(_why,input',output') -> > (input',output')) $ Latin1.latin1_encode input output -- unchecked, used > for char8 > > diff --git a/libraries/base/GHC/TopHandler.hs > b/libraries/base/GHC/TopHandler.hs > > index d7c0038..e725196 100644 > > --- a/libraries/base/GHC/TopHandler.hs > > +++ b/libraries/base/GHC/TopHandler.hs > > @@ -157,13 +157,40 @@ real_handler exit se = do > > Just (ExitFailure n) -> exit n > > > > -- EPIPE errors received for stdout are ignored (#2699) > > - _ -> case fromException se of > > + _ -> catch (case fromException se of > > Just IOError{ ioe_type = ResourceVanished, > > ioe_errno = Just ioe, > > ioe_handle = Just hdl } > > | Errno ioe == ePIPE, hdl == stdout -> exit 0 > > _ -> do reportError se > > exit 1 > > + ) (disasterHandler exit) -- See Note [Disaster with > iconv] > > + > > +-- don't use errorBelch() directly, because we cannot call varargs > functions > > +-- using the FFI. > > +foreign import ccall unsafe "HsBase.h errorBelch2" > > + errorBelch :: CString -> CString -> IO () > > + > > +disasterHandler :: (Int -> IO a) -> IOError -> IO a > > +disasterHandler exit _ = > > + withCAString "%s" $ \fmt -> > > + withCAString msgStr $ \msg -> > > + errorBelch fmt msg >> exit 1 > > + where msgStr = "encountered an exception while trying to report an > exception" > > + > > +{- Note [Disaster with iconv] > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +When using iconv, it's possible for things like iconv_open to fail in > > +restricted environments (like an initram or restricted container), but > > +when this happens the error raised inevitably calls `peekCString`, > > +which depends on the users locale, which depends on using > > +`iconv_open`... which causes an infinite loop. > > + > > +This occurrence is also known as tickets #10298 and #7695. So to work > > +around it we just set _another_ error handler and bail directly by > > +calling the RTS, without iconv at all. > > +-} > > > > > > -- try to flush stdout/stderr, but don't worry if we fail > > > --- End forwarded message --- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri May 29 20:42:50 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 29 May 2015 22:42:50 +0200 Subject: Travis builds failing In-Reply-To: <1432860362-sup-2108@sabre> References: <1432860362-sup-2108@sabre> Message-ID: <1432932170.2126.5.camel@joachim-breitner.de> Hi, Am Donnerstag, den 28.05.2015, 17:46 -0700 schrieb Edward Z. Yang: > To whoever manages our Travis setup https://travis-ci.org/ghc/ghc/builds that would be me. > We seem to be failing because our build takes longer than 50min. that happens occasionally, yes, and is the main reason we still don?t send failure mails to the commiter (and instead to me). But the real reason why the Travis setup is currently unusable is this: Unexpected failures: driver T2507 [bad stderr] (normal) driver T8959a [bad stderr] (normal) ghc-api T6145 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api/annotations T10278 [bad exit code] (normal) ghc-api/annotations T10357 [bad exit code] (normal) ghc-api/annotations T10358 [bad exit code] (normal) ghc-api/annotations T10396 [bad exit code] (normal) ghc-api/annotations T10399 [bad exit code] (normal) ghc-api/annotations boolFormula [bad exit code] (normal) all of which fail with collect2: ld terminated with signal 9 [Killed] make[3]: *** [t10358] Error 1 Unfortunately, when this first appeared, there were other build failures in HEAD, so I could not (easily) identify the first commit causing this. I raised this on this list (?api annotations test failures?, May 15). Alan Zimmerman looked into it, but it seems without success. 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 alan.zimm at gmail.com Fri May 29 21:49:50 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 29 May 2015 23:49:50 +0200 Subject: Travis builds failing In-Reply-To: <1432932170.2126.5.camel@joachim-breitner.de> References: <1432860362-sup-2108@sabre> <1432932170.2126.5.camel@joachim-breitner.de> Message-ID: I am still trying to track this down, in the context of D913. I am hoping that the extra logging that will be availiable once @thomie has finalised D926 will help. There seems to be some shared resource when using the GHC API, and it cannot tolerate running multiple tests at the same time. Alan On Fri, May 29, 2015 at 10:42 PM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 28.05.2015, 17:46 -0700 schrieb Edward Z. Yang: > > To whoever manages our Travis setup https://travis-ci.org/ghc/ghc/builds > > that would be me. > > > We seem to be failing because our build takes longer than 50min. > > that happens occasionally, yes, and is the main reason we still don?t > send failure mails to the commiter (and instead to me). > > But the real reason why the Travis setup is currently unusable is this: > > Unexpected failures: > driver T2507 [bad stderr] (normal) > driver T8959a [bad stderr] (normal) > ghc-api T6145 [bad exit code] (normal) > ghc-api T8639_api [bad exit code] (normal) > ghc-api/annotations T10278 [bad exit code] (normal) > ghc-api/annotations T10357 [bad exit code] (normal) > ghc-api/annotations T10358 [bad exit code] (normal) > ghc-api/annotations T10396 [bad exit code] (normal) > ghc-api/annotations T10399 [bad exit code] (normal) > ghc-api/annotations boolFormula [bad exit code] (normal) > > all of which fail with > > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [t10358] Error 1 > > > Unfortunately, when this first appeared, there were other build failures > in HEAD, so I could not (easily) identify the first commit causing > this. > > I raised this on this list (?api annotations test failures?, May 15). > Alan Zimmerman looked into it, but it seems without success. > > > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Fri May 29 22:28:33 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sat, 30 May 2015 00:28:33 +0200 Subject: [commit: ghc] ghc-7.10: base: fix #10298 & #7695 (25b8478) In-Reply-To: References: <1432862625-sup-402@sabre> Message-ID: I ran 'make accept' on those two tests (they were failing for me locally), and now the build is green again. This was the change: https://phabricator.haskell.org/rGHCa138fa1aa9fe2b6499d023ebff4e0fd2f0f1cac8 On Fri, May 29, 2015 at 5:35 PM, Sylvain Henry wrote: > It depends on your locale, this explains the different behavior on your > local machine. > > The build machine seems to be using an ASCII locale and GHC wants to print > some Unicode characters (the tick and back-tick surrounding types in error > messages). Before this patch, Iconv was used to do the conversion from > Unicode to ASCII. It seems that it replaces the Unicode ticks with ASCII > ticks (i.e. 0xE28098 in UTF-8 into 0x60 and 0xE28099 into 0x27). > > If you enter: > cd ghc/testsuite/tests > grep -rn "match expected type" **/*.stderr > > You can see that some .stderr have been generated with a ASCII locale and > some others with a UTF-8 locale by looking at the ticks. Are the tests > expecting ASCII output (e.g. driver/T2507) passing on platforms with UTF-8 > locales? The output is not equal to the expected one except if it is > converted to ASCII before the comparison. > > With this patch, we don't use Iconv to convert from Unicode to ASCII > because it may not be available in some contexts (docker containers, > initramdisk, etc.). Instead we use the UTF-8 encoder to encode ASCII (ASCII > characters are encoded in the same way in ASCII and in UTF-8) and we don't > try to match Unicode only characters to ASCII ones. > > Solutions: > 1) change our patch to use our method only when Iconv cannot be used. > 2) implement the Unicode to ASCII conversion as performed by Iconv > 3) change the locale to a UTF-8 one on the build machine ;-) > > Sylvain > > > > > 2015-05-29 3:23 GMT+02:00 Edward Z. Yang : > >> This commit broke the HM builds: https://phabricator.haskell.org/B4147 >> >> When I validate locally, though, it works fine. >> >> Edward >> >> Excerpts from git's message of 2015-05-28 18:11:07 -0700: >> > Repository : ssh://git at git.haskell.org/ghc >> > >> > On branch : ghc-7.10 >> > Link : >> http://ghc.haskell.org/trac/ghc/changeset/25b84781ed950d59c7bffb77a576d3c43a883ca9/ghc >> > >> > >--------------------------------------------------------------- >> > >> > commit 25b84781ed950d59c7bffb77a576d3c43a883ca9 >> > Author: Austin Seipp >> > Date: Tue May 19 04:56:40 2015 -0500 >> > >> > base: fix #10298 & #7695 >> > >> > Summary: >> > This applies a patch from Reid Barton and Sylvain Henry, which fix a >> > disasterous infinite loop when iconv fails to load locale files, as >> > specified in #10298. >> > >> > The fix is a bit of a hack but should be fine - for the actual >> reasoning >> > behind it, see `Note [Disaster and iconv]` for more info. >> > >> > In addition to this fix, we also patch up the IO Encoding utilities >> to >> > recognize several variations of the 'ASCII' encoding (including its >> > aliases) directly so that GHC can do conversions without iconv. This >> > allows a static binary to sit in an initramfs. >> > >> > Authored-by: Reid Barton >> > Authored-by: Sylvain Henry >> > Signed-off-by: Austin Seipp >> > >> > Test Plan: Eyeballed it. >> > >> > Reviewers: rwbarton, hvr >> > >> > Subscribers: bgamari, thomie >> > >> > Differential Revision: https://phabricator.haskell.org/D898 >> > >> > GHC Trac Issues: #10298, #7695 >> > >> > (cherry picked from commit e28462de700240288519a016d0fe44d4360d9ffd) >> > >> > >--------------------------------------------------------------- >> > >> > 25b84781ed950d59c7bffb77a576d3c43a883ca9 >> > libraries/base/GHC/IO/Encoding.hs | 14 +++++++++++++- >> > libraries/base/GHC/TopHandler.hs | 29 ++++++++++++++++++++++++++++- >> > 2 files changed, 41 insertions(+), 2 deletions(-) >> > >> > diff --git a/libraries/base/GHC/IO/Encoding.hs >> b/libraries/base/GHC/IO/Encoding.hs >> > index 31683b4..014b61b 100644 >> > --- a/libraries/base/GHC/IO/Encoding.hs >> > +++ b/libraries/base/GHC/IO/Encoding.hs >> > @@ -235,7 +235,14 @@ mkTextEncoding e = case mb_coding_failure_mode of >> > _ -> Nothing >> > >> > mkTextEncoding' :: CodingFailureMode -> String -> IO TextEncoding >> > -mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of >> > +mkTextEncoding' cfm enc >> > + -- First, specifically match on ASCII encodings directly using >> > + -- several possible aliases (specified by RFC 1345 & co), which >> > + -- allows us to handle ASCII conversions without iconv at all (see >> > + -- trac #10298). >> > + | any (== enc) ansiEncNames = return (UTF8.mkUTF8 cfm) >> > + -- Otherwise, handle other encoding needs via iconv. >> > + | otherwise = case [toUpper c | c <- enc, c /= '-'] of >> > "UTF8" -> return $ UTF8.mkUTF8 cfm >> > "UTF16" -> return $ UTF16.mkUTF16 cfm >> > "UTF16LE" -> return $ UTF16.mkUTF16le cfm >> > @@ -249,6 +256,11 @@ mkTextEncoding' cfm enc = case [toUpper c | c <- >> enc, c /= '-'] of >> > #else >> > _ -> Iconv.mkIconvEncoding cfm enc >> > #endif >> > + where >> > + ansiEncNames = -- ASCII aliases >> > + [ "ANSI_X3.4-1968", "iso-ir-6", "ANSI_X3.4-1986", >> "ISO_646.irv:1991" >> > + , "US-ASCII", "us", "IBM367", "cp367", "csASCII", "ASCII", >> "ISO646-US" >> > + ] >> > >> > latin1_encode :: CharBuffer -> Buffer Word8 -> IO (CharBuffer, Buffer >> Word8) >> > latin1_encode input output = fmap (\(_why,input',output') -> >> (input',output')) $ Latin1.latin1_encode input output -- unchecked, used >> for char8 >> > diff --git a/libraries/base/GHC/TopHandler.hs >> b/libraries/base/GHC/TopHandler.hs >> > index d7c0038..e725196 100644 >> > --- a/libraries/base/GHC/TopHandler.hs >> > +++ b/libraries/base/GHC/TopHandler.hs >> > @@ -157,13 +157,40 @@ real_handler exit se = do >> > Just (ExitFailure n) -> exit n >> > >> > -- EPIPE errors received for stdout are ignored (#2699) >> > - _ -> case fromException se of >> > + _ -> catch (case fromException se of >> > Just IOError{ ioe_type = ResourceVanished, >> > ioe_errno = Just ioe, >> > ioe_handle = Just hdl } >> > | Errno ioe == ePIPE, hdl == stdout -> exit 0 >> > _ -> do reportError se >> > exit 1 >> > + ) (disasterHandler exit) -- See Note [Disaster with >> iconv] >> > + >> > +-- don't use errorBelch() directly, because we cannot call varargs >> functions >> > +-- using the FFI. >> > +foreign import ccall unsafe "HsBase.h errorBelch2" >> > + errorBelch :: CString -> CString -> IO () >> > + >> > +disasterHandler :: (Int -> IO a) -> IOError -> IO a >> > +disasterHandler exit _ = >> > + withCAString "%s" $ \fmt -> >> > + withCAString msgStr $ \msg -> >> > + errorBelch fmt msg >> exit 1 >> > + where msgStr = "encountered an exception while trying to report an >> exception" >> > + >> > +{- Note [Disaster with iconv] >> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > + >> > +When using iconv, it's possible for things like iconv_open to fail in >> > +restricted environments (like an initram or restricted container), but >> > +when this happens the error raised inevitably calls `peekCString`, >> > +which depends on the users locale, which depends on using >> > +`iconv_open`... which causes an infinite loop. >> > + >> > +This occurrence is also known as tickets #10298 and #7695. So to work >> > +around it we just set _another_ error handler and bail directly by >> > +calling the RTS, without iconv at all. >> > +-} >> > >> > >> > -- try to flush stdout/stderr, but don't worry if we fail >> > >> --- End forwarded message --- >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat May 30 03:10:57 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 30 May 2015 12:10:57 +0900 Subject: [Haskell-cafe] Consecutive FFI calls In-Reply-To: References: Message-ID: Hi David, I'm not 100% sure, especially semantics, and I'm studying too. I don't have an answer, but I describe the related matters in order to organize my head. At first: "memory barrier" ... is order control mechanism between memory accesses. "bound thread" ... is association mechanism between ffi calls and a specified thread. And: "memory barrier" ... is depend on cpu hardware architecture(x86, ARM, ...). "OS level thread" ... is depend on OS(Linux, Windows, ...). Last: There are four cases about ffi call [1]: (1) safe ffi call on unbound thread(forkIO) (2) unsafe ffi call on unbound thread(forkIO) (3) safe ffi call on bound thread(main, forkOS) (4) unsafe ffi call on bound thread(main, forkOS) I think, maybe (2) and (4) have not guarantee with memory ordering. Because they might be inlined and optimized. If (1) and (3) always use pthread api (or memory barrier api) for thread/HEC context switch, they are guarantee. But I think that it would not guarantee the full case. I feel that order issues are very difficult. I think order issues can be safely solved by explicit notation, like explicit memory barrier notation, STM,... If I have misunderstood, please teach me :-) [1]: http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=98 Cheers, Takenobu 2015-05-29 1:24 GMT+09:00 David Turner : > Hi, > > If I make a sequence of FFI calls (on a single Haskell thread) but > which end up being called from different OS threads, is there any kind > of ordering guarantee given? More specifically, is there a full memory > barrier at the point where a Haskell thread migrates to a new OS > thread? > > Many thanks, > > David > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sat May 30 10:00:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 30 May 2015 12:00:52 +0200 Subject: Travis builds failing In-Reply-To: <1432932170.2126.5.camel@joachim-breitner.de> References: <1432860362-sup-2108@sabre> <1432932170.2126.5.camel@joachim-breitner.de> Message-ID: Your mail seems to indicate that the processes were sent a SIGKILL during the link phase. To my knowledge this can happen in two ways: from the test runner for a timeout or from the kernel for an out of memory condition. I suspect the timeout is not the culprit. Is there any way to check for out of memory kills on the travis box? Or is there another way it can be killed? Alan On Fri, May 29, 2015 at 10:42 PM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 28.05.2015, 17:46 -0700 schrieb Edward Z. Yang: > > To whoever manages our Travis setup https://travis-ci.org/ghc/ghc/builds > > that would be me. > > > We seem to be failing because our build takes longer than 50min. > > that happens occasionally, yes, and is the main reason we still don?t > send failure mails to the commiter (and instead to me). > > But the real reason why the Travis setup is currently unusable is this: > > Unexpected failures: > driver T2507 [bad stderr] (normal) > driver T8959a [bad stderr] (normal) > ghc-api T6145 [bad exit code] (normal) > ghc-api T8639_api [bad exit code] (normal) > ghc-api/annotations T10278 [bad exit code] (normal) > ghc-api/annotations T10357 [bad exit code] (normal) > ghc-api/annotations T10358 [bad exit code] (normal) > ghc-api/annotations T10396 [bad exit code] (normal) > ghc-api/annotations T10399 [bad exit code] (normal) > ghc-api/annotations boolFormula [bad exit code] (normal) > > all of which fail with > > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [t10358] Error 1 > > > Unfortunately, when this first appeared, there were other build failures > in HEAD, so I could not (easily) identify the first commit causing > this. > > I raised this on this list (?api annotations test failures?, May 15). > Alan Zimmerman looked into it, but it seems without success. > > > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sat May 30 12:04:38 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 30 May 2015 14:04:38 +0200 Subject: Travis builds failing In-Reply-To: References: <1432860362-sup-2108@sabre> <1432932170.2126.5.camel@joachim-breitner.de> Message-ID: I think the annotations tests are failing because the Makefile looks like this (excerpt) ------------------- CheckAnnotations: CheckAnnotations.hs rm -f CheckAnnotations CheckAnnotations.hi CheckAnnotations.o '$(TEST_HC)' $(TEST_HC_OPTS) --make -w -v0 -package ghc CheckAnnotations .PHONY: T10358 T10358: CheckAnnotations ./CheckAnnotations "`'$(TEST_HC)' $(TEST_HC_OPTS) --print-libdir | tr -d '\r'`" Test10358 .PHONY: T10396 T10396: CheckAnnotations ./CheckAnnotations "`'$(TEST_HC)' $(TEST_HC_OPTS) --print-libdir | tr -d '\r'`" Test10396 ------------------------ If separate processes are used to execute "make T10396" and "make T10358", they will each independently try to build CheckAnnotations. This causes problems. Alan On Sat, May 30, 2015 at 12:00 PM, Alan & Kim Zimmerman wrote: > Your mail seems to indicate that the processes were sent a SIGKILL during > the link phase. > > To my knowledge this can happen in two ways: from the test runner for a > timeout or from the kernel for an out of memory condition. > > I suspect the timeout is not the culprit. > > Is there any way to check for out of memory kills on the travis box? > > Or is there another way it can be killed? > > Alan > > > On Fri, May 29, 2015 at 10:42 PM, Joachim Breitner < > mail at joachim-breitner.de> wrote: > >> Hi, >> >> Am Donnerstag, den 28.05.2015, 17:46 -0700 schrieb Edward Z. Yang: >> > To whoever manages our Travis setup >> https://travis-ci.org/ghc/ghc/builds >> >> that would be me. >> >> > We seem to be failing because our build takes longer than 50min. >> >> that happens occasionally, yes, and is the main reason we still don?t >> send failure mails to the commiter (and instead to me). >> >> But the real reason why the Travis setup is currently unusable is this: >> >> Unexpected failures: >> driver T2507 [bad stderr] (normal) >> driver T8959a [bad stderr] (normal) >> ghc-api T6145 [bad exit code] (normal) >> ghc-api T8639_api [bad exit code] (normal) >> ghc-api/annotations T10278 [bad exit code] (normal) >> ghc-api/annotations T10357 [bad exit code] (normal) >> ghc-api/annotations T10358 [bad exit code] (normal) >> ghc-api/annotations T10396 [bad exit code] (normal) >> ghc-api/annotations T10399 [bad exit code] (normal) >> ghc-api/annotations boolFormula [bad exit code] (normal) >> >> all of which fail with >> >> collect2: ld terminated with signal 9 [Killed] >> make[3]: *** [t10358] Error 1 >> >> >> Unfortunately, when this first appeared, there were other build failures >> in HEAD, so I could not (easily) identify the first commit causing >> this. >> >> I raised this on this list (?api annotations test failures?, May 15). >> Alan Zimmerman looked into it, but it seems without success. >> >> >> >> 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 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: