From paolo.veronelli at gmail.com Fri May 1 08:42:13 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 1 May 2015 10:42:13 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions . With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. Regards paolino 2015-04-17 1:33 GMT+02:00 David Laing : > Hi all, > > I've been playing around with profiling GHC recently, so I thought I'd > chime in with a pointer that might save people searching for the right docs > - you could configure a cabal sandbox to work with multiple version of ghc, > which I've found useful: > > > https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage > > Cheers, > > Dave > > On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < > michal.terepeta at gmail.com> wrote: > >> Hi Richard, >> >> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >> build flavor 'prof' then get the haskell-src-exts sources, install the >> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >> the resulting ghc.prof contains the profiling information. >> >> For anyone interested about CallArity slowness, the problem is tracked in >> https://ghc.haskell.org/trac/ghc/ticket/10293 >> >> Cheers, >> Michal >> >> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >> wrote: >> >>> I've pasted Michal's numbers in #9630, which seems like a good place to >>> track this. Michal, would you mind fleshing out a bit precisely what you >>> did to get those numbers? That would be helpful (though you've already been >>> very helpful indeed in getting the data together)! >>> >>> Thanks, >>> Richard >>> >>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner >>> wrote: >>> >>> > Hi, >>> > >>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >>> >> wrote: >>> >>> Actually, I meant only with -fno-specialise. >>> >> >>> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >>> > >>> > I?m on that, and I think I have a quite neat fix for it. I?ll report on >>> > that in the trac ticket: >>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >>> > >>> > 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 >>> > _______________________________________________ >>> > Glasgow-haskell-users mailing list >>> > Glasgow-haskell-users at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 1 08:44:45 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 1 May 2015 08:44:45 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> Can you open a ticket, please? And put as much data as you can. Using `-dshow-passes` (both for 7.10 and prior versions) and showing the output would be helpful. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Paolino Sent: 01 May 2015 09:42 To: glasgow-haskell-users at haskell.org Subject: Re: Increased memory usage with GHC 7.10.1 Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. Regards paolino 2015-04-17 1:33 GMT+02:00 David Laing >: Hi all, I've been playing around with profiling GHC recently, so I thought I'd chime in with a pointer that might save people searching for the right docs - you could configure a cabal sandbox to work with multiple version of ghc, which I've found useful: https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta > wrote: Hi Richard, Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build flavor 'prof' then get the haskell-src-exts sources, install the dependencies and finally add +RTS -p -RTS to the cabal file and compile it, the resulting ghc.prof contains the profiling information. For anyone interested about CallArity slowness, the problem is tracked in https://ghc.haskell.org/trac/ghc/ticket/10293 Cheers, Michal On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg > wrote: I've pasted Michal's numbers in #9630, which seems like a good place to track this. Michal, would you mind fleshing out a bit precisely what you did to get those numbers? That would be helpful (though you've already been very helpful indeed in getting the data together)! Thanks, Richard On Apr 14, 2015, at 9:09 PM, Joachim Breitner > wrote: > Hi, > > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >> > wrote: >>> Actually, I meant only with -fno-specialise. >> >> Done. Helps quite a bit but CallArity is still a pretty expensive. > > I?m on that, and I think I have a quite neat fix for it. I?ll report on > that in the trac ticket: > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 > > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Fri May 1 09:00:10 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 1 May 2015 11:00:10 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Ghc trac is not sending the verification emails and won't let me file a bug without. As soon as this gets fixed I will. Thanks paolino 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones : > Can you open a ticket, please? And put as much data as you can. Using > `-dshow-passes` (both for 7.10 and prior versions) and showing the output > would be helpful. > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Paolino > *Sent:* 01 May 2015 09:42 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Re: Increased memory usage with GHC 7.10.1 > > > > Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible > with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. > The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions > . > With -O0 it uses 600 MB. > > The file is really huge, but I could compile it with prior versions of ghc. > > Regards > > paolino > > > > 2015-04-17 1:33 GMT+02:00 David Laing : > > Hi all, > > I've been playing around with profiling GHC recently, so I thought I'd > chime in with a pointer that might save people searching for the right docs > - you could configure a cabal sandbox to work with multiple version of ghc, > which I've found useful: > > > https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage > > > Cheers, > > > > Dave > > > > On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < > michal.terepeta at gmail.com> wrote: > > Hi Richard, > > Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with > build flavor 'prof' then get the haskell-src-exts sources, install the > dependencies and finally add +RTS -p -RTS to the cabal file and compile it, > the resulting ghc.prof contains the profiling information. > > > > For anyone interested about CallArity slowness, the problem is tracked in > https://ghc.haskell.org/trac/ghc/ticket/10293 > > > > Cheers, > > Michal > > > > On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg > wrote: > > I've pasted Michal's numbers in #9630, which seems like a good place to > track this. Michal, would you mind fleshing out a bit precisely what you > did to get those numbers? That would be helpful (though you've already been > very helpful indeed in getting the data together)! > > Thanks, > Richard > > On Apr 14, 2015, at 9:09 PM, Joachim Breitner > wrote: > > > Hi, > > > > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: > >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij > >> wrote: > >>> Actually, I meant only with -fno-specialise. > >> > >> Done. Helps quite a bit but CallArity is still a pretty expensive. > > > > I?m on that, and I think I have a quite neat fix for it. I?ll report on > > that in the trac ticket: > > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 > > > > 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 > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 1 12:00:57 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 1 May 2015 08:00:57 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> Message-ID: as a near term mitigation, could you enable having swap files on your VM ? On Fri, May 1, 2015 at 5:00 AM, Paolino wrote: > Ghc trac is not sending the verification emails and won't let me file a > bug without. As soon as this gets fixed I will. > > Thanks > > paolino > > 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones : > >> Can you open a ticket, please? And put as much data as you can. Using >> `-dshow-passes` (both for 7.10 and prior versions) and showing the output >> would be helpful. >> >> >> >> Simon >> >> >> >> *From:* Glasgow-haskell-users [mailto: >> glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Paolino >> *Sent:* 01 May 2015 09:42 >> *To:* glasgow-haskell-users at haskell.org >> *Subject:* Re: Increased memory usage with GHC 7.10.1 >> >> >> >> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible >> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. >> The file making memory explode is >> Graphics.Rendering.OpenGL.Raw.Functions >> . >> With -O0 it uses 600 MB. >> >> The file is really huge, but I could compile it with prior versions of >> ghc. >> >> Regards >> >> paolino >> >> >> >> 2015-04-17 1:33 GMT+02:00 David Laing : >> >> Hi all, >> >> I've been playing around with profiling GHC recently, so I thought I'd >> chime in with a pointer that might save people searching for the right docs >> - you could configure a cabal sandbox to work with multiple version of ghc, >> which I've found useful: >> >> >> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage >> >> >> Cheers, >> >> >> >> Dave >> >> >> >> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < >> michal.terepeta at gmail.com> wrote: >> >> Hi Richard, >> >> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >> build flavor 'prof' then get the haskell-src-exts sources, install the >> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >> the resulting ghc.prof contains the profiling information. >> >> >> >> For anyone interested about CallArity slowness, the problem is tracked in >> https://ghc.haskell.org/trac/ghc/ticket/10293 >> >> >> >> Cheers, >> >> Michal >> >> >> >> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >> wrote: >> >> I've pasted Michal's numbers in #9630, which seems like a good place to >> track this. Michal, would you mind fleshing out a bit precisely what you >> did to get those numbers? That would be helpful (though you've already been >> very helpful indeed in getting the data together)! >> >> Thanks, >> Richard >> >> On Apr 14, 2015, at 9:09 PM, Joachim Breitner >> wrote: >> >> > Hi, >> > >> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >> >> wrote: >> >>> Actually, I meant only with -fno-specialise. >> >> >> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >> > >> > I?m on that, and I think I have a quite neat fix for it. I?ll report on >> > that in the trac ticket: >> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >> > >> > 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 >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Fri May 1 12:22:37 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 1 May 2015 14:22:37 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> Message-ID: not that lucky, as it's btrfs which doesn't allow swapon :-/ btw, thanks for the hint paolino 2015-05-01 14:00 GMT+02:00 Carter Schonwald : > as a near term mitigation, could you enable having swap files on your VM ? > > On Fri, May 1, 2015 at 5:00 AM, Paolino wrote: > >> Ghc trac is not sending the verification emails and won't let me file a >> bug without. As soon as this gets fixed I will. >> >> Thanks >> >> paolino >> >> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones : >> >>> Can you open a ticket, please? And put as much data as you can. Using >>> `-dshow-passes` (both for 7.10 and prior versions) and showing the output >>> would be helpful. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Glasgow-haskell-users [mailto: >>> glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Paolino >>> *Sent:* 01 May 2015 09:42 >>> *To:* glasgow-haskell-users at haskell.org >>> *Subject:* Re: Increased memory usage with GHC 7.10.1 >>> >>> >>> >>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible >>> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. >>> The file making memory explode is >>> Graphics.Rendering.OpenGL.Raw.Functions >>> . >>> With -O0 it uses 600 MB. >>> >>> The file is really huge, but I could compile it with prior versions of >>> ghc. >>> >>> Regards >>> >>> paolino >>> >>> >>> >>> 2015-04-17 1:33 GMT+02:00 David Laing : >>> >>> Hi all, >>> >>> I've been playing around with profiling GHC recently, so I thought I'd >>> chime in with a pointer that might save people searching for the right docs >>> - you could configure a cabal sandbox to work with multiple version of ghc, >>> which I've found useful: >>> >>> >>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage >>> >>> >>> Cheers, >>> >>> >>> >>> Dave >>> >>> >>> >>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < >>> michal.terepeta at gmail.com> wrote: >>> >>> Hi Richard, >>> >>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >>> build flavor 'prof' then get the haskell-src-exts sources, install the >>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >>> the resulting ghc.prof contains the profiling information. >>> >>> >>> >>> For anyone interested about CallArity slowness, the problem is tracked >>> in https://ghc.haskell.org/trac/ghc/ticket/10293 >>> >>> >>> >>> Cheers, >>> >>> Michal >>> >>> >>> >>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >>> wrote: >>> >>> I've pasted Michal's numbers in #9630, which seems like a good place to >>> track this. Michal, would you mind fleshing out a bit precisely what you >>> did to get those numbers? That would be helpful (though you've already been >>> very helpful indeed in getting the data together)! >>> >>> Thanks, >>> Richard >>> >>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner >>> wrote: >>> >>> > Hi, >>> > >>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >>> >> wrote: >>> >>> Actually, I meant only with -fno-specialise. >>> >> >>> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >>> > >>> > I?m on that, and I think I have a quite neat fix for it. I?ll report on >>> > that in the trac ticket: >>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >>> > >>> > 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 >>> > _______________________________________________ >>> > Glasgow-haskell-users mailing list >>> > Glasgow-haskell-users at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Fri May 1 13:06:12 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 1 May 2015 15:06:12 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <07e072c32dae49f3921f183d69b74629@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I did the worst and splitted the file. It worked. Still waiting ghc trac to send me the verification mails paolino 2015-05-01 14:22 GMT+02:00 Paolino : > not that lucky, as it's btrfs which doesn't allow swapon :-/ > btw, thanks for the hint > > paolino > > 2015-05-01 14:00 GMT+02:00 Carter Schonwald : > >> as a near term mitigation, could you enable having swap files on your VM ? >> >> On Fri, May 1, 2015 at 5:00 AM, Paolino >> wrote: >> >>> Ghc trac is not sending the verification emails and won't let me file a >>> bug without. As soon as this gets fixed I will. >>> >>> Thanks >>> >>> paolino >>> >>> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones : >>> >>>> Can you open a ticket, please? And put as much data as you can. >>>> Using `-dshow-passes` (both for 7.10 and prior versions) and showing the >>>> output would be helpful. >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> >>>> *From:* Glasgow-haskell-users [mailto: >>>> glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Paolino >>>> *Sent:* 01 May 2015 09:42 >>>> *To:* glasgow-haskell-users at haskell.org >>>> *Subject:* Re: Increased memory usage with GHC 7.10.1 >>>> >>>> >>>> >>>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now >>>> impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB >>>> linux host. The file making memory explode is >>>> Graphics.Rendering.OpenGL.Raw.Functions >>>> . >>>> With -O0 it uses 600 MB. >>>> >>>> The file is really huge, but I could compile it with prior versions of >>>> ghc. >>>> >>>> Regards >>>> >>>> paolino >>>> >>>> >>>> >>>> 2015-04-17 1:33 GMT+02:00 David Laing : >>>> >>>> Hi all, >>>> >>>> I've been playing around with profiling GHC recently, so I thought I'd >>>> chime in with a pointer that might save people searching for the right docs >>>> - you could configure a cabal sandbox to work with multiple version of ghc, >>>> which I've found useful: >>>> >>>> >>>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Dave >>>> >>>> >>>> >>>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < >>>> michal.terepeta at gmail.com> wrote: >>>> >>>> Hi Richard, >>>> >>>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >>>> build flavor 'prof' then get the haskell-src-exts sources, install the >>>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >>>> the resulting ghc.prof contains the profiling information. >>>> >>>> >>>> >>>> For anyone interested about CallArity slowness, the problem is tracked >>>> in https://ghc.haskell.org/trac/ghc/ticket/10293 >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Michal >>>> >>>> >>>> >>>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >>>> wrote: >>>> >>>> I've pasted Michal's numbers in #9630, which seems like a good place >>>> to track this. Michal, would you mind fleshing out a bit precisely what you >>>> did to get those numbers? That would be helpful (though you've already been >>>> very helpful indeed in getting the data together)! >>>> >>>> Thanks, >>>> Richard >>>> >>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >>>> >> wrote: >>>> >>> Actually, I meant only with -fno-specialise. >>>> >> >>>> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >>>> > >>>> > I?m on that, and I think I have a quite neat fix for it. I?ll report >>>> on >>>> > that in the trac ticket: >>>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >>>> > >>>> > 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 >>>> > _______________________________________________ >>>> > Glasgow-haskell-users mailing list >>>> > Glasgow-haskell-users at haskell.org >>>> > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri May 1 13:31:11 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 1 May 2015 10:31:11 -0300 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: Should we recommend that all library developers compile their libraries with a max heap of 4G (to pick an arbitrary number) so that we can catch some of these issues earlier? On Fri, May 1, 2015 at 5:42 AM, Paolino wrote: > Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible > with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. > The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions > . > With -O0 it uses 600 MB. > > The file is really huge, but I could compile it with prior versions of ghc. > > Regards > > paolino > > 2015-04-17 1:33 GMT+02:00 David Laing : > >> Hi all, >> >> I've been playing around with profiling GHC recently, so I thought I'd >> chime in with a pointer that might save people searching for the right docs >> - you could configure a cabal sandbox to work with multiple version of ghc, >> which I've found useful: >> >> >> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage >> >> Cheers, >> >> Dave >> >> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < >> michal.terepeta at gmail.com> wrote: >> >>> Hi Richard, >>> >>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >>> build flavor 'prof' then get the haskell-src-exts sources, install the >>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >>> the resulting ghc.prof contains the profiling information. >>> >>> For anyone interested about CallArity slowness, the problem is tracked >>> in https://ghc.haskell.org/trac/ghc/ticket/10293 >>> >>> Cheers, >>> Michal >>> >>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >>> wrote: >>> >>>> I've pasted Michal's numbers in #9630, which seems like a good place to >>>> track this. Michal, would you mind fleshing out a bit precisely what you >>>> did to get those numbers? That would be helpful (though you've already been >>>> very helpful indeed in getting the data together)! >>>> >>>> Thanks, >>>> Richard >>>> >>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >>>> >> wrote: >>>> >>> Actually, I meant only with -fno-specialise. >>>> >> >>>> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >>>> > >>>> > I?m on that, and I think I have a quite neat fix for it. I?ll report >>>> on >>>> > that in the trac ticket: >>>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >>>> > >>>> > 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 >>>> > _______________________________________________ >>>> > Glasgow-haskell-users mailing list >>>> > Glasgow-haskell-users at haskell.org >>>> > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Fri May 1 14:30:02 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 1 May 2015 16:30:02 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: here is another file , which is small, which cannot be compiled within 4GB memory. https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs I'd just want to add that this problem is a nasty one if one doesn't set the max heap: a remote machine frozen that must be rebooted is not a nice adventure , hoping the crash remains confined to the vm. hth, paolino 2015-05-01 15:31 GMT+02:00 George Colpitts : > Should we recommend that all library developers compile their libraries > with a max heap of 4G (to pick an arbitrary number) so that we can catch > some of these issues earlier? > > On Fri, May 1, 2015 at 5:42 AM, Paolino wrote: > >> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible >> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. >> The file making memory explode is >> Graphics.Rendering.OpenGL.Raw.Functions >> . >> With -O0 it uses 600 MB. >> >> The file is really huge, but I could compile it with prior versions of >> ghc. >> >> Regards >> >> paolino >> >> 2015-04-17 1:33 GMT+02:00 David Laing : >> >>> Hi all, >>> >>> I've been playing around with profiling GHC recently, so I thought I'd >>> chime in with a pointer that might save people searching for the right docs >>> - you could configure a cabal sandbox to work with multiple version of ghc, >>> which I've found useful: >>> >>> >>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage >>> >>> Cheers, >>> >>> Dave >>> >>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < >>> michal.terepeta at gmail.com> wrote: >>> >>>> Hi Richard, >>>> >>>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with >>>> build flavor 'prof' then get the haskell-src-exts sources, install the >>>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it, >>>> the resulting ghc.prof contains the profiling information. >>>> >>>> For anyone interested about CallArity slowness, the problem is tracked >>>> in https://ghc.haskell.org/trac/ghc/ticket/10293 >>>> >>>> Cheers, >>>> Michal >>>> >>>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg >>>> wrote: >>>> >>>>> I've pasted Michal's numbers in #9630, which seems like a good place >>>>> to track this. Michal, would you mind fleshing out a bit precisely what you >>>>> did to get those numbers? That would be helpful (though you've already been >>>>> very helpful indeed in getting the data together)! >>>>> >>>>> Thanks, >>>>> Richard >>>>> >>>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner < >>>>> mail at joachim-breitner.de> wrote: >>>>> >>>>> > Hi, >>>>> > >>>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >>>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >>>>> >> wrote: >>>>> >>> Actually, I meant only with -fno-specialise. >>>>> >> >>>>> >> Done. Helps quite a bit but CallArity is still a pretty expensive. >>>>> > >>>>> > I?m on that, and I think I have a quite neat fix for it. I?ll report >>>>> on >>>>> > that in the trac ticket: >>>>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 >>>>> > >>>>> > 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 >>>>> > _______________________________________________ >>>>> > Glasgow-haskell-users mailing list >>>>> > Glasgow-haskell-users at haskell.org >>>>> > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 1 14:49:09 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 1 May 2015 14:49:09 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> It would be great if someone could ? create a ticket for Paolio ? investigate what is happening This smaller test case uses Repa, so it?s not clear that GHC is doing anything wrong. Maybe repa is inlining too much? We need insight. Thanks SImon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Paolino Sent: 01 May 2015 15:30 To: George Colpitts Cc: glasgow-haskell-users at haskell.org Subject: Re: Increased memory usage with GHC 7.10.1 here is another file , which is small, which cannot be compiled within 4GB memory. https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs I'd just want to add that this problem is a nasty one if one doesn't set the max heap: a remote machine frozen that must be rebooted is not a nice adventure , hoping the crash remains confined to the vm. hth, paolino 2015-05-01 15:31 GMT+02:00 George Colpitts >: Should we recommend that all library developers compile their libraries with a max heap of 4G (to pick an arbitrary number) so that we can catch some of these issues earlier? On Fri, May 1, 2015 at 5:42 AM, Paolino > wrote: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. Regards paolino 2015-04-17 1:33 GMT+02:00 David Laing >: Hi all, I've been playing around with profiling GHC recently, so I thought I'd chime in with a pointer that might save people searching for the right docs - you could configure a cabal sandbox to work with multiple version of ghc, which I've found useful: https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta > wrote: Hi Richard, Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build flavor 'prof' then get the haskell-src-exts sources, install the dependencies and finally add +RTS -p -RTS to the cabal file and compile it, the resulting ghc.prof contains the profiling information. For anyone interested about CallArity slowness, the problem is tracked in https://ghc.haskell.org/trac/ghc/ticket/10293 Cheers, Michal On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg > wrote: I've pasted Michal's numbers in #9630, which seems like a good place to track this. Michal, would you mind fleshing out a bit precisely what you did to get those numbers? That would be helpful (though you've already been very helpful indeed in getting the data together)! Thanks, Richard On Apr 14, 2015, at 9:09 PM, Joachim Breitner > wrote: > Hi, > > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >> > wrote: >>> Actually, I meant only with -fno-specialise. >> >> Done. Helps quite a bit but CallArity is still a pretty expensive. > > I?m on that, and I think I have a quite neat fix for it. I?ll report on > that in the trac ticket: > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 > > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Fri May 1 15:00:31 2015 From: greg at gregweber.info (Greg Weber) Date: Fri, 1 May 2015 08:00:31 -0700 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: We have observed issues with compile-time inlining taking much longer in newer versions of GHC in some cases https://github.com/larskuhtz/toCaseFoldBuildTimes This particular issue was reported to the text repo: https://github.com/bos/text/issues/116 On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones wrote: > It would be great if someone could > > ? create a ticket for Paolio > > ? investigate what is happening > > This smaller test case uses Repa, so it?s not clear that GHC is doing > anything wrong. Maybe repa is inlining too much? We need insight. > > > > Thanks > > > > SImon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Paolino > *Sent:* 01 May 2015 15:30 > *To:* George Colpitts > *Cc:* glasgow-haskell-users at haskell.org > *Subject:* Re: Increased memory usage with GHC 7.10.1 > > > > here is another file , which is small, which cannot be compiled within > 4GB memory. > > > https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs > > I'd just want to add that this problem is a nasty one if one doesn't > set the max heap: a remote machine frozen that must be rebooted is not a > nice adventure , hoping the crash remains confined to the vm. > > hth, paolino > > > > > > > 2015-05-01 15:31 GMT+02:00 George Colpitts : > > Should we recommend that all library developers compile their libraries > with a max heap of 4G (to pick an arbitrary number) so that we can catch > some of these issues earlier? > > > > On Fri, May 1, 2015 at 5:42 AM, Paolino wrote: > > Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now > impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB > linux host. The file making memory explode is > Graphics.Rendering.OpenGL.Raw.Functions > . > With -O0 it uses 600 MB. > > The file is really huge, but I could compile it with prior versions of ghc. > > Regards > > paolino > > > > 2015-04-17 1:33 GMT+02:00 David Laing : > > Hi all, > > I've been playing around with profiling GHC recently, so I thought I'd > chime in with a pointer that might save people searching for the right docs > - you could configure a cabal sandbox to work with multiple version of ghc, > which I've found useful: > > > https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage > > > Cheers, > > > > Dave > > > > On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < > michal.terepeta at gmail.com> wrote: > > Hi Richard, > > Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with > build flavor 'prof' then get the haskell-src-exts sources, install the > dependencies and finally add +RTS -p -RTS to the cabal file and compile it, > the resulting ghc.prof contains the profiling information. > > > > For anyone interested about CallArity slowness, the problem is tracked in > https://ghc.haskell.org/trac/ghc/ticket/10293 > > > > Cheers, > > Michal > > > > On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg > wrote: > > I've pasted Michal's numbers in #9630, which seems like a good place to > track this. Michal, would you mind fleshing out a bit precisely what you > did to get those numbers? That would be helpful (though you've already been > very helpful indeed in getting the data together)! > > Thanks, > Richard > > On Apr 14, 2015, at 9:09 PM, Joachim Breitner > wrote: > > > Hi, > > > > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: > >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij > >> wrote: > >>> Actually, I meant only with -fno-specialise. > >> > >> Done. Helps quite a bit but CallArity is still a pretty expensive. > > > > I?m on that, and I think I have a quite neat fix for it. I?ll report on > > that in the trac ticket: > > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 > > > > 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 > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 1 15:05:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 1 May 2015 15:05:04 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: It would be amazingly helpful if someone (anyone) could diagnose a bit. It may be a bug in GHC but it may also be a bug in the pragmas in a library. If someone can produce evidence for the former, I?ll gladly look at it. Simon From: Greg Weber [mailto:greg at gregweber.info] Sent: 01 May 2015 16:01 To: Simon Peyton Jones Cc: Paolino; George Colpitts; Manuel Chakravarty; glasgow-haskell-users at haskell.org Subject: Re: Increased memory usage with GHC 7.10.1 We have observed issues with compile-time inlining taking much longer in newer versions of GHC in some cases https://github.com/larskuhtz/toCaseFoldBuildTimes This particular issue was reported to the text repo: https://github.com/bos/text/issues/116 On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones > wrote: It would be great if someone could ? create a ticket for Paolio ? investigate what is happening This smaller test case uses Repa, so it?s not clear that GHC is doing anything wrong. Maybe repa is inlining too much? We need insight. Thanks SImon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Paolino Sent: 01 May 2015 15:30 To: George Colpitts Cc: glasgow-haskell-users at haskell.org Subject: Re: Increased memory usage with GHC 7.10.1 here is another file , which is small, which cannot be compiled within 4GB memory. https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs I'd just want to add that this problem is a nasty one if one doesn't set the max heap: a remote machine frozen that must be rebooted is not a nice adventure , hoping the crash remains confined to the vm. hth, paolino 2015-05-01 15:31 GMT+02:00 George Colpitts >: Should we recommend that all library developers compile their libraries with a max heap of 4G (to pick an arbitrary number) so that we can catch some of these issues earlier? On Fri, May 1, 2015 at 5:42 AM, Paolino > wrote: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. Regards paolino 2015-04-17 1:33 GMT+02:00 David Laing >: Hi all, I've been playing around with profiling GHC recently, so I thought I'd chime in with a pointer that might save people searching for the right docs - you could configure a cabal sandbox to work with multiple version of ghc, which I've found useful: https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta > wrote: Hi Richard, Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build flavor 'prof' then get the haskell-src-exts sources, install the dependencies and finally add +RTS -p -RTS to the cabal file and compile it, the resulting ghc.prof contains the profiling information. For anyone interested about CallArity slowness, the problem is tracked in https://ghc.haskell.org/trac/ghc/ticket/10293 Cheers, Michal On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg > wrote: I've pasted Michal's numbers in #9630, which seems like a good place to track this. Michal, would you mind fleshing out a bit precisely what you did to get those numbers? That would be helpful (though you've already been very helpful indeed in getting the data together)! Thanks, Richard On Apr 14, 2015, at 9:09 PM, Joachim Breitner > wrote: > Hi, > > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij >> > wrote: >>> Actually, I meant only with -fno-specialise. >> >> Done. Helps quite a bit but CallArity is still a pretty expensive. > > I?m on that, and I think I have a quite neat fix for it. I?ll report on > that in the trac ticket: > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 > > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Fri May 1 19:32:23 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Fri, 01 May 2015 19:32:23 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Fri, May 1, 2015 at 5:05 PM Simon Peyton Jones wrote: > It would be amazingly helpful if someone (anyone) could diagnose a bit. > > > > It may be a bug in GHC but it may also be a bug in the pragmas in a > library. If someone can produce evidence for the former, I?ll gladly look > at it. > > > > Simon > I've opened https://ghc.haskell.org/trac/ghc/ticket/10370 for the OpenGLRaw case (and it does seem that this might be a problem in GHC). Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Sat May 2 10:01:04 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Sat, 2 May 2015 12:01:04 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello, I succeded in compiling https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O HTH, paolino 2015-05-01 21:32 GMT+02:00 Michal Terepeta : > On Fri, May 1, 2015 at 5:05 PM Simon Peyton Jones > wrote: > >> It would be amazingly helpful if someone (anyone) could diagnose a bit. >> >> >> >> It may be a bug in GHC but it may also be a bug in the pragmas in a >> library. If someone can produce evidence for the former, I?ll gladly look >> at it. >> >> >> >> Simon >> > I've opened https://ghc.haskell.org/trac/ghc/ticket/10370 for the > OpenGLRaw case (and it does seem that this might be a problem in GHC). > > Cheers, > Michal > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun May 3 13:41:25 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 3 May 2015 15:41:25 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: 2015-05-02 12:01 GMT+02:00 Paolino : > Hello, I succeded in compiling > https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html > on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw (2.5.0.0) to Hackage, containing 2 improvements: * 'foreign import "dynamic"'s with the same signature are re-used, cutting down their number from 3062 to 864. * Those 'foreign import "dynamic"'s live in a separate module now. Travis CI seems to be happy with these changes (the VMs there don't have much memory, either), although Haddock still seems to eat memory like hell. But that's a different story... It would be nice to hear if the new version improved the situation for people who previous had trouble. From george.colpitts at gmail.com Sun May 3 14:45:24 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 3 May 2015 11:45:24 -0300 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I think this helps quite a bit. Although it still peaks briefly at over 3 GB mem usage on my Mac according to the Activity Monitor it seems to spend much of its time using 400 - 800 mb memory use. I can't be sure as I never tried to compile this before. I'm compiling by simply doing cabal install .... Not sure what optimization levels that uses, I assume -O1 On Sun, May 3, 2015 at 10:41 AM, Sven Panne wrote: > 2015-05-02 12:01 GMT+02:00 Paolino : > > Hello, I succeded in compiling > > > https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html > > on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O > > To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw > (2.5.0.0) to Hackage, containing 2 improvements: > > * 'foreign import "dynamic"'s with the same signature are re-used, > cutting down their number from 3062 to 864. > > * Those 'foreign import "dynamic"'s live in a separate module now. > > Travis CI seems to be happy with these changes (the VMs there don't > have much memory, either), although Haddock still seems to eat memory > like hell. But that's a different story... > > It would be nice to hear if the new version improved the situation for > people who previous had trouble. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Mon May 4 06:02:30 2015 From: paolo.veronelli at gmail.com (Paolino) Date: Mon, 4 May 2015 08:02:30 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> <2549e47361f64f6aa1a98801d56a2599@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello, compiling 2.5.0 on (linux 4.0.1, 64 bit) and ghc 7.10.1 with /usr/bin/time -f %M gives values between 2.3 GB and 2.6 GB on multiple runs. (2.4.1 was requesting more than 3 GB, cannot say how much precisely) Thanks Sven 2015-05-03 16:45 GMT+02:00 George Colpitts : > I think this helps quite a bit. Although it still peaks briefly at over 3 > GB mem usage on my Mac according to the Activity Monitor it seems to spend > much of its time using 400 - 800 mb memory use. I can't be sure as I never > tried to compile this before. I'm compiling by simply doing cabal install > .... Not sure what optimization levels that uses, I assume -O1 > > On Sun, May 3, 2015 at 10:41 AM, Sven Panne wrote: > >> 2015-05-02 12:01 GMT+02:00 Paolino : >> > Hello, I succeded in compiling >> > >> https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html >> > on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O >> >> To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw >> (2.5.0.0) to Hackage, containing 2 improvements: >> >> * 'foreign import "dynamic"'s with the same signature are re-used, >> cutting down their number from 3062 to 864. >> >> * Those 'foreign import "dynamic"'s live in a separate module now. >> >> Travis CI seems to be happy with these changes (the VMs there don't >> have much memory, either), although Haddock still seems to eat memory >> like hell. But that's a different story... >> >> It would be nice to hear if the new version improved the situation for >> people who previous had trouble. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > > -------------- 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 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 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 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 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 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 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 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 winterkoninkje at gmail.com Fri May 8 03:45:48 2015 From: winterkoninkje at gmail.com (wren romano) Date: Thu, 7 May 2015 23:45:48 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 9:05 AM, 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. Conditional imports are far and away the most commonly used idiom. Second most common, I'd say, is specifying GHC-specific vs compiler-generic implementations of top-level functions (e.g., using GHC.Exts.build or not). For both of these it's sufficient to have the #if construction plus everything needed for the conditional expressions. However, while the #if construction covers the vast majority of use cases, it doesn't cover all of them. Macros are also important. For example, a number of low-level libraries will use macros for things like having assertions which are either compiled as runtime checks, or as nothing, depending on a Cabal flag. Of course, there are plenty of other places where we want to use macros in low-level code, either to force inlining, or to have conditional compilation of (non-top-level) expressions that show up over and over. That these idioms aren't more common is just because there aren't more people working on such low-level code. In theory TH should be able to handle this stuff, but TH is a verbose sledgehammer for these sorts of problems, and using TH means restricting yourself to being GHC-only. -- Live well, ~wren 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 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 winterkoninkje at gmail.com Fri May 8 22:20:25 2015 From: winterkoninkje at gmail.com (wren romano) Date: Fri, 8 May 2015 18:20:25 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Fri, May 8, 2015 at 12:12 PM, Dan Doel wrote: > 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). 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.) [1] e.g., -- Live well, ~wren From donn at avvanta.com Fri May 8 23:40:28 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 8 May 2015 16:40:28 -0700 (PDT) Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: <20150508234028.C7ADC276CE1@mail.avvanta.com> Quoth wren romano , ... > 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. 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. Donn 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 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 petersen at fedoraproject.org Wed May 13 03:28:59 2015 From: petersen at fedoraproject.org (Jens Petersen) Date: Wed, 13 May 2015 12:28:59 +0900 Subject: Fedora ghc-7.10.1 repo Message-ID: Hi, It is a bit later than I wanted but I have prepared a Fedora Copr repo for ghc-7.10.1. https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.1/ (note the EPEL7 and F20 builds are currently quick builds and the F21+ builds are perf builds) I will probably add a cabal-install build soon. Let me know if you find any problems or if it is useful. :) Jens From mechvel at botik.ru Tue May 19 18:59:10 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Tue, 19 May 2015 22:59:10 +0400 Subject: making 7.10.1 Message-ID: <1432061950.28132.15.camel@one.mechvel.pereslavl.ru> People, I am trying to `make' ghc-7.10.1 from source by ghc-7.8.3 on Debian Linux. I command > ./configure --prefix=/home/mechvel/haskell/ghc/7.10.1/inst0 > make >& make.log The former command seems successful: ... #define HAVE_EVENTFD 1 #define CC_SUPPORTS_TLS 1 configure: exit 0 The latter command reports --------------------------------------- ... ... checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/home/mechvel/haskell/ghc/7.10.1/libffi/build/x86_64-unkn\ own-linux-gnu': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details --------------------------------------- And I do not find in config.log anything suspicious about cpp. config.log does have several `error' messages, like, say conftest.c:9:28: error: ac_nonexistent.h: No such file or directory But, probably, they are harmless. Please, how to fix? ------ Sergei From ben at smart-cactus.org Wed May 20 12:33:37 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 20 May 2015 08:33:37 -0400 Subject: making 7.10.1 In-Reply-To: <1432061950.28132.15.camel@one.mechvel.pereslavl.ru> References: <1432061950.28132.15.camel@one.mechvel.pereslavl.ru> Message-ID: <87h9r7l97i.fsf@gmail.com> Sergei Meshveliani writes: > People, > I am trying to `make' ghc-7.10.1 from source by ghc-7.8.3 > on Debian Linux. > I command > > > ./configure --prefix=/home/mechvel/haskell/ghc/7.10.1/inst0 > > > make >& make.log > > > The former command seems successful: > ... > #define HAVE_EVENTFD 1 #define CC_SUPPORTS_TLS 1 > > configure: exit 0 > > > The latter command reports > > --------------------------------------- > ... > ... > checking whether to build static libraries... yes > checking how to run the C++ preprocessor... /lib/cpp > configure: error: in > `/home/mechvel/haskell/ghc/7.10.1/libffi/build/x86_64-unkn\ > own-linux-gnu': > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > See `config.log' for more details > --------------------------------------- > What does `which cpp` output? I would expect to find it in `/usr/bin`, not `/lib`. Are you certain you have Debian's `build-essential` package installed? 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 mechvel at botik.ru Wed May 20 15:41:31 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Wed, 20 May 2015 19:41:31 +0400 Subject: making 7.10.1 In-Reply-To: <87h9r7l97i.fsf@gmail.com> References: <1432061950.28132.15.camel@one.mechvel.pereslavl.ru> <87h9r7l97i.fsf@gmail.com> Message-ID: <1432136491.26030.10.camel@one.mechvel.pereslavl.ru> On Wed, 2015-05-20 at 08:33 -0400, Ben Gamari wrote: > Sergei Meshveliani writes: > > > People, > > I am trying to `make' ghc-7.10.1 from source by ghc-7.8.3 > > on Debian Linux. > > I command > > > > > ./configure --prefix=/home/mechvel/haskell/ghc/7.10.1/inst0 > > > > > make >& make.log > > > > > > The former command seems successful: > > ... > > #define HAVE_EVENTFD 1 #define CC_SUPPORTS_TLS 1 > > > > configure: exit 0 > > > > > > The latter command reports > > > > --------------------------------------- > > ... > > ... > > checking whether to build static libraries... yes > > checking how to run the C++ preprocessor... /lib/cpp > > configure: error: in > > `/home/mechvel/haskell/ghc/7.10.1/libffi/build/x86_64-unkn\ > > own-linux-gnu': > > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > > See `config.log' for more details > > --------------------------------------- > > > What does `which cpp` output? I would expect to find it in `/usr/bin`, > not `/lib`. Are you certain you have Debian's `build-essential` package > installed? cpp is indeed in usr/bin/. My colleague (who knows more of Linux) has discovered that this fail is due to that g++ is absent for the used gcc-4.4.5 version. Installing this g++ version makes this `make' successful. Thanks, ------ Sergei From facundo.dominguez at tweag.io Wed May 20 15:51:08 2015 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Wed, 20 May 2015 12:51:08 -0300 Subject: Can GHCi inspect the state of running threads? Message-ID: Hello, I have a multi-threaded and interactive application that sometimes stops responding, and it would be helpful being able to inspect the state when it doesn't. I thought the GHCi debugger could be useful here, however I see no way to signal a thread and have GHCi show me its state. Here is an example GHCi session: $ cat t.hs import Control.Concurrent import Control.Exception import Control.Monad import System.IO spawnThread :: String -> IO ThreadId spawnThread label = forkIO $ flip finally (putStrLn $ "bye " ++ label) $ forM_ [0..] $ \i -> threadDelay 1000000 $ ghci-7.10.1 t.hs -fbreak-on-exception -v0 *Main> hSetBuffering stdout LineBuffering *Main> t0 <- spawnThread "t0" *Main> throwTo t0 (ErrorCall "end") *Main> It looks like I'm not getting the "bye t0" message when stopping the thread while using -fbreak-on-exception. Is the debugger supposed to be used like this? Otherwise, is there any way in which I could inspect the state of a running thread? Thanks, Facundo From facundo.dominguez at tweag.io Wed May 20 16:52:27 2015 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Wed, 20 May 2015 13:52:27 -0300 Subject: Can GHCi inspect the state of running threads? In-Reply-To: References: Message-ID: Perhaps a more sensible example: $ cat t.hs import Control.Concurrent import Control.Monad spawnThread :: IO ThreadId spawnThread = forkIO $ forM_ [0..] $ \i -> threadDelay 1000000 $ ghci-7.10.1 t.hs -v0 *Main> t0 <- spawnThread *Main> :break 8 Breakpoint 0 activated at t.hs:8:9-27 *Main> *** Ignoring breakpoint *** Ignoring breakpoint *** Ignoring breakpoint *** Ignoring breakpoint :q $ Thanks, Facundo On Wed, May 20, 2015 at 12:51 PM, Facundo Dom?nguez wrote: > Hello, > I have a multi-threaded and interactive application that sometimes > stops responding, and it would be helpful being able to inspect the > state when it doesn't. > > I thought the GHCi debugger could be useful here, however I see no way > to signal a thread and have GHCi show me its state. > > Here is an example GHCi session: > > $ cat t.hs > import Control.Concurrent > import Control.Exception > import Control.Monad > import System.IO > > spawnThread :: String -> IO ThreadId > spawnThread label = > forkIO $ flip finally (putStrLn $ "bye " ++ label) $ > forM_ [0..] $ \i -> threadDelay 1000000 > $ ghci-7.10.1 t.hs -fbreak-on-exception -v0 > *Main> hSetBuffering stdout LineBuffering > *Main> t0 <- spawnThread "t0" > *Main> throwTo t0 (ErrorCall "end") > *Main> > > It looks like I'm not getting the "bye t0" message when stopping the > thread while using -fbreak-on-exception. > > Is the debugger supposed to be used like this? Otherwise, is there any > way in which I could inspect the state of a running thread? > > Thanks, > Facundo From mechvel at botik.ru Wed May 20 19:52:36 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Wed, 20 May 2015 23:52:36 +0400 Subject: overlapping instances in 7.10.1 Message-ID: <1432151556.26520.79.camel@one.mechvel.pereslavl.ru> Dear GHC developers, Please, test ghc-7.10.1 on making docon-2.12 http://www.botik.ru/pub/local/Mechveliani/docon/ and running its demotest/Main (see install.txt). docon-2.12 has been tested under ghc-7.8.2, and it has extensions: ... OverlappingInstances in docon.cabal. Making with ghc-7.10.1 issues a warning and advises to set the related pragma individually to each corresponding instance. (1) First, I ignored this warning, and surprisingly, the library has been made. In the build/ subdirectory there are .hi and .o files, and there have newly appeared the "dyn" files: Matr0_.dyn_hi Matr0_.dyn_o Matr0_.hi Matr0_.o ... (I do not know what does it mean "dyn"). Then, > make install reports runghc Setup.hs install --user Installing library in /home/mechvel/docon/2.12/docon/source/inst/lib/x86_64-linux-ghc-7.10.1/docon_99cUeE74HI58Sb9XilYAZ2 Registering docon-2.12.1... Instead of the .a file, ls shows there docon_99cUeE74HI58Sb9XilYAZ2 docon_JzkSttB1MsX3R5AQ1eIgvC Are these names intended? Then I command > cd demotest > ghc $doconCpOpt -O -rtsopts --make Main > ./Main It is built and runs. But breaks in the middle with a certain reasonable DoCon error message. The DoCon design is so that choosing a different instance among the overlapping ones may change the algorithm, and the computation cost, but still must produce the same result. It must -- unless DoCon has a bug in some of these instances. (2) All right, I need to set {-# OVERLAPPABLE #-} individually to each instance which may overlap with some other instance in DoCon. There is declared a great number of instances. And it occurs difficult for me to recall now: which instance does overlap with something and which does not (at least they all worked correct in ghc-7.8.2). Well, I can set {-# OVERLAPPABLE #-} to _each_ instance. But such a program does not look nice. And I would like to be more definite and to set {-# OVERLAPPING #-} to all appropriate places. Suppose that I forget that some instance overlaps with something and skipped this pragma. The above test shows that this can lead to a wrong program to run (is this feature intended?). And what will be the consequence if {-# OVERLAPPING #-} is set to an instance which does not overlap with anything? Can the compiler help to list the overlaps? Please, advise, ------ Sergei From mechvel at botik.ru Wed May 20 20:42:36 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Thu, 21 May 2015 00:42:36 +0400 Subject: overlapping instances in 7.10.1 In-Reply-To: <1432151556.26520.79.camel@one.mechvel.pereslavl.ru> References: <1432151556.26520.79.camel@one.mechvel.pereslavl.ru> Message-ID: <1432154556.27159.16.camel@one.mechvel.pereslavl.ru> Now, I delete `OverlappingInstances' from docon.cabal and also from the $doconCpOpt options to call ghc on demotest/Main.hs. And now the test runs correct in ghc-7.10.1 ! Only it is 1.5 times slower than in ghc-7.8.2. So: a) The test intends overlapping instances, b) instance overlaps are not declared for ghc-7.10.1, c) this leads to a correct running, but 1.5 times slower. I do not know of whether this slow down is due to the removed pragma or due to other features of ghc-7.10.1. And there remains my question about how GHC could help to recall the overlapping instance pairs. Regards, ------ Sergei On Wed, 2015-05-20 at 23:52 +0400, Sergei Meshveliani wrote: > Dear GHC developers, > > Please, test ghc-7.10.1 on making docon-2.12 > > http://www.botik.ru/pub/local/Mechveliani/docon/ > > and running its demotest/Main > (see install.txt). > > > docon-2.12 has been tested under ghc-7.8.2, > > and it has > extensions: ... OverlappingInstances > in docon.cabal. > > Making with ghc-7.10.1 issues a warning and advises to set the related > pragma individually to each corresponding instance. > > > (1) First, I ignored this warning, and surprisingly, the library has > been made. > > In the build/ subdirectory there are .hi and .o files, > and there have newly appeared the "dyn" files: > > Matr0_.dyn_hi Matr0_.dyn_o Matr0_.hi Matr0_.o ... > > (I do not know what does it mean "dyn"). > > Then, > > make install > reports > > runghc Setup.hs install --user > Installing library in > /home/mechvel/docon/2.12/docon/source/inst/lib/x86_64-linux-ghc-7.10.1/docon_99cUeE74HI58Sb9XilYAZ2 > > Registering docon-2.12.1... > > Instead of the .a file, ls shows there > > docon_99cUeE74HI58Sb9XilYAZ2 docon_JzkSttB1MsX3R5AQ1eIgvC > > Are these names intended? > > Then I command > > > cd demotest > > ghc $doconCpOpt -O -rtsopts --make Main > > ./Main > > It is built and runs. But breaks in the middle with a certain reasonable > DoCon error message. > > The DoCon design is so that choosing a different instance among the > overlapping ones may change the algorithm, and the computation cost, but > still must produce the same result. It must -- unless DoCon has a bug in > some of these instances. > > > (2) All right, I need to set {-# OVERLAPPABLE #-} individually to each > instance which may overlap with some other instance in DoCon. > > There is declared a great number of instances. And it occurs difficult > for me to recall now: which instance does overlap with something and > which does not > (at least they all worked correct in ghc-7.8.2). > > Well, I can set {-# OVERLAPPABLE #-} to _each_ instance. > But such a program does not look nice. > > And I would like to be more definite and to set {-# OVERLAPPING #-} to > all appropriate places. > Suppose that I forget that some instance overlaps with something and > skipped this pragma. The above test shows that this can lead to a wrong > program to run > (is this feature intended?). > > And what will be the consequence if {-# OVERLAPPING #-} is set to an > instance which does not overlap with anything? > > Can the compiler help to list the overlaps? > > Please, advise, > > ------ > Sergei > > > > > > > > > > > > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From sumit.sahrawat.apm13 at iitbhu.ac.in Wed May 20 20:48:25 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 21 May 2015 02:18:25 +0530 Subject: overlapping instances in 7.10.1 In-Reply-To: <1432154556.27159.16.camel@one.mechvel.pereslavl.ru> References: <1432151556.26520.79.camel@one.mechvel.pereslavl.ru> <1432154556.27159.16.camel@one.mechvel.pereslavl.ru> Message-ID: [Adding ghc-devs at haskell.org to cc] On 21 May 2015 at 02:12, Sergei Meshveliani wrote: > Now, I delete `OverlappingInstances' from docon.cabal > > and also from the $doconCpOpt options to call ghc on > demotest/Main.hs. > > And now the test runs correct in ghc-7.10.1 ! > > Only it is 1.5 times slower than in ghc-7.8.2. > So: > a) The test intends overlapping instances, > b) instance overlaps are not declared for ghc-7.10.1, > c) this leads to a correct running, but 1.5 times slower. > > I do not know of whether this slow down is due to the removed pragma or > due to other features of ghc-7.10.1. > > And there remains my question about how GHC could help to recall the > overlapping instance pairs. > > Regards, > > ------ > Sergei > > > > > On Wed, 2015-05-20 at 23:52 +0400, Sergei Meshveliani wrote: > > Dear GHC developers, > > > > Please, test ghc-7.10.1 on making docon-2.12 > > > > http://www.botik.ru/pub/local/Mechveliani/docon/ > > > > and running its demotest/Main > > (see install.txt). > > > > > > docon-2.12 has been tested under ghc-7.8.2, > > > > and it has > > extensions: ... OverlappingInstances > > in docon.cabal. > > > > Making with ghc-7.10.1 issues a warning and advises to set the related > > pragma individually to each corresponding instance. > > > > > > (1) First, I ignored this warning, and surprisingly, the library has > > been made. > > > > In the build/ subdirectory there are .hi and .o files, > > and there have newly appeared the "dyn" files: > > > > Matr0_.dyn_hi Matr0_.dyn_o Matr0_.hi Matr0_.o ... > > > > (I do not know what does it mean "dyn"). > > > > Then, > > > make install > > reports > > > > runghc Setup.hs install --user > > Installing library in > > > /home/mechvel/docon/2.12/docon/source/inst/lib/x86_64-linux-ghc-7.10.1/docon_99cUeE74HI58Sb9XilYAZ2 > > > > Registering docon-2.12.1... > > > > Instead of the .a file, ls shows there > > > > docon_99cUeE74HI58Sb9XilYAZ2 docon_JzkSttB1MsX3R5AQ1eIgvC > > > > Are these names intended? > > > > Then I command > > > > > cd demotest > > > ghc $doconCpOpt -O -rtsopts --make Main > > > ./Main > > > > It is built and runs. But breaks in the middle with a certain reasonable > > DoCon error message. > > > > The DoCon design is so that choosing a different instance among the > > overlapping ones may change the algorithm, and the computation cost, but > > still must produce the same result. It must -- unless DoCon has a bug in > > some of these instances. > > > > > > (2) All right, I need to set {-# OVERLAPPABLE #-} individually to each > > instance which may overlap with some other instance in DoCon. > > > > There is declared a great number of instances. And it occurs difficult > > for me to recall now: which instance does overlap with something and > > which does not > > (at least they all worked correct in ghc-7.8.2). > > > > Well, I can set {-# OVERLAPPABLE #-} to _each_ instance. > > But such a program does not look nice. > > > > And I would like to be more definite and to set {-# OVERLAPPING #-} to > > all appropriate places. > > Suppose that I forget that some instance overlaps with something and > > skipped this pragma. The above test shows that this can lead to a wrong > > program to run > > (is this feature intended?). > > > > And what will be the consequence if {-# OVERLAPPING #-} is set to an > > instance which does not overlap with anything? > > > > Can the compiler help to list the overlaps? > > > > Please, advise, > > > > ------ > > Sergei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From mechvel at botik.ru Thu May 21 12:00:02 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Thu, 21 May 2015 15:00:02 +0300 Subject: OI in 7.10.1 Message-ID: <1432209602.14933.6.camel@scico.botik.ru> Please, what is wrong here? --------------------------------------------------------------- module OI where class Foo a where foo :: a -> Bool instance Foo Bool where foo _ = True data C a = C a instance {-# OVERLAPPING #-} Foo a => Foo (C a) where foo (C a) = foo a instance {-# OVERLAPPING #-} Foo (C Bool) where foo _ = False --------------------------------------------------------------- By this I intended to test the overlapping instance control. I set the pragma as it is shown in the User guide. And ghc-7.10.1 -c -XFlexibleInstances OI.hs reports "Unrecognised pragma". Please, advise, ------ Sergei From mechvel at botik.ru Thu May 21 12:30:30 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Thu, 21 May 2015 15:30:30 +0300 Subject: OI in 7.10.1 In-Reply-To: <1432209602.14933.6.camel@scico.botik.ru> References: <1432209602.14933.6.camel@scico.botik.ru> Message-ID: <1432211430.16162.5.camel@scico.botik.ru> False alarm. I am sorry. This was an unexpected ghc-7.8.2 intrusion instead of 7.10.1. The only remaining question is, so far -- of how to find all the needed places in docon-2.12 to set OVERLAPPING, what errors are possible in this matter. ------ Sergei On Thu, 2015-05-21 at 15:00 +0300, Sergei Meshveliani wrote: > Please, what is wrong here? > > --------------------------------------------------------------- > module OI where > class Foo a where foo :: a -> Bool > > instance Foo Bool where foo _ = True > > data C a = C a > > instance {-# OVERLAPPING #-} Foo a => Foo (C a) where foo (C a) = foo a > instance {-# OVERLAPPING #-} Foo (C Bool) where foo _ = False > --------------------------------------------------------------- > > By this I intended to test the overlapping instance control. > I set the pragma as it is shown in the User guide. > And > ghc-7.10.1 -c -XFlexibleInstances OI.hs > > reports "Unrecognised pragma". > > Please, advise, > > ------ > Sergei > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From mechvel at botik.ru Thu May 21 13:40:37 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Thu, 21 May 2015 16:40:37 +0300 Subject: overlapping instances 7.10.1 Message-ID: <1432215637.17657.15.camel@scico.botik.ru> People, I wrote recently about finding places to set {-# OVERLAPPING #-} when porting an application from 7.8.2 to 7.10.1. I am doing this for porting docon-2.12 from 7.8.2 to 7.10.1. And ghc-7.10.1 indeed helped me to find several places to set this pragma (instead of using the total key -XOverlappingInstances). Finally, it has come to this module: --------------------------------------------- Preprocessing library docon-2.12.1... [48 of 86] Compiling ResRing__ ( ResRing__.hs, dist/build/ResRing__.o ) ResRing__.hs:183:31: Overlapping instances for Eq (Maybe PropValue) arising from a use of ?/=? Matching instances: instance Eq a => Eq (Maybe a) -- Defined in ?GHC.Base? instance (Residue r, Eq a) => Eq (r a) -- Defined in ?ResEuc0_? In the expression: lookup IsGxBasis ps /= Just Yes ... ---------------------------------------------- As before, I set instance {-# OVERLAPPING #-} (Residue r, Eq a) => Eq (r a) where ... in ResEuc0_.hs. But this does not help, the compiler continues with the same report. I see the difference to previous porting process in that one of the overlapping instances is of the GHC library, so that I cannot set the needed overlap pragma for it. On the other hand, ghc-7.8.2 compiled docon-2.12 successfully. What my be a way out? Thanks, ------ Sergei From qdunkan at gmail.com Thu May 21 17:49:17 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 21 May 2015 10:49:17 -0700 Subject: documentation links broken in 7.10.1 Message-ID: It seems like haddock's index.html generation is broken in 7.10.1. Namely, it creates links to e.g. Codec-Binary-UTF8-Generic.html when it should be to utf8-string-1/html/Codec-Binary-UTF8-Generic.html This is haddock 2.16.0, which comes with the binary distribution for 7.10.1. I looked at https://github.com/haskell/haddock/issues but didn't see anything related to this, which makes me think it's just me. You'd think someone would notice if all documentation links were broken. Does anyone else see this? From vogt.adam at gmail.com Thu May 21 18:14:14 2015 From: vogt.adam at gmail.com (adam vogt) Date: Thu, 21 May 2015 14:14:14 -0400 Subject: overlapping instances 7.10.1 In-Reply-To: <1432215637.17657.15.camel@scico.botik.ru> References: <1432215637.17657.15.camel@scico.botik.ru> Message-ID: Hi Sergei, I think you should use {-# OVERLAPPABLE #-}: see the description here https://ghc.haskell.org/trac/ghc/ticket/9242#comment:16 which is probably in the manual somewhere too. Regards, Adam On Thu, May 21, 2015 at 9:40 AM, Sergei Meshveliani wrote: > People, > > I wrote recently about finding places to set {-# OVERLAPPING #-} > when porting an application from 7.8.2 to 7.10.1. > > I am doing this for porting docon-2.12 from 7.8.2 to 7.10.1. > > And ghc-7.10.1 indeed helped me to find several places to set this > pragma (instead of using the total key -XOverlappingInstances). > > Finally, it has come to this module: > > --------------------------------------------- > Preprocessing library docon-2.12.1... > [48 of 86] Compiling ResRing__ ( ResRing__.hs, dist/build/ResRing__.o ) > > ResRing__.hs:183:31: > Overlapping instances for Eq (Maybe PropValue) > arising from a use of ?/=? > Matching instances: > instance Eq a => Eq (Maybe a) -- Defined in ?GHC.Base? > instance (Residue r, Eq a) => Eq (r a) -- Defined in ?ResEuc0_? > In the expression: lookup IsGxBasis ps /= Just Yes > ... > ---------------------------------------------- > > As before, I set > instance {-# OVERLAPPING #-} (Residue r, Eq a) => Eq (r a) where > ... > > in ResEuc0_.hs. > > But this does not help, the compiler continues with the same report. > > I see the difference to previous porting process in that one of the > overlapping instances is of the GHC library, so that I cannot set the > needed overlap pragma for it. > > On the other hand, ghc-7.8.2 compiled docon-2.12 successfully. > > What my be a way out? > > Thanks, > > ------ > Sergei > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu May 21 21:30:54 2015 From: austin at well-typed.com (Austin Seipp) Date: Thu, 21 May 2015 16:30:54 -0500 Subject: documentation links broken in 7.10.1 In-Reply-To: References: Message-ID: Hi Evan, This was due to bug #10206 - https://ghc.haskell.org/trac/ghc/ticket/10206 It should already be fixed in the STABLE branch and will be part of 7.10.2. On Thu, May 21, 2015 at 12:49 PM, Evan Laforge wrote: > It seems like haddock's index.html generation is broken in 7.10.1. > Namely, it creates links to e.g. Codec-Binary-UTF8-Generic.html when > it should be to utf8-string-1/html/Codec-Binary-UTF8-Generic.html > > This is haddock 2.16.0, which comes with the binary distribution for 7.10.1. > > I looked at https://github.com/haskell/haddock/issues but didn't see > anything related to this, which makes me think it's just me. You'd > think someone would notice if all documentation links were broken. > > Does anyone else see this? > _______________________________________________ > 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 qdunkan at gmail.com Thu May 21 23:40:33 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 21 May 2015 16:40:33 -0700 Subject: documentation links broken in 7.10.1 In-Reply-To: References: Message-ID: Glad to hear. I guess I should have tested the release candidate. Next time I will! On Thu, May 21, 2015 at 2:30 PM, Austin Seipp wrote: > Hi Evan, > > This was due to bug #10206 - https://ghc.haskell.org/trac/ghc/ticket/10206 > > It should already be fixed in the STABLE branch and will be part of 7.10.2. > > On Thu, May 21, 2015 at 12:49 PM, Evan Laforge wrote: >> It seems like haddock's index.html generation is broken in 7.10.1. >> Namely, it creates links to e.g. Codec-Binary-UTF8-Generic.html when >> it should be to utf8-string-1/html/Codec-Binary-UTF8-Generic.html >> >> This is haddock 2.16.0, which comes with the binary distribution for 7.10.1. >> >> I looked at https://github.com/haskell/haddock/issues but didn't see >> anything related to this, which makes me think it's just me. You'd >> think someone would notice if all documentation links were broken. >> >> Does anyone else see this? >> _______________________________________________ >> 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 nikita at karetnikov.org Fri May 22 10:06:37 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 22 May 2015 13:06:37 +0300 Subject: -Wall and the fail method Message-ID: <87r3q9vscy.fsf@karetnikov.org> Can -Wall be extended to report pattern match failures in do expressions, like it does for case expressions? Prelude> :set -Wall Prelude> let f = do Just x <- return Nothing; return x Prelude> let g = case Nothing of Just x -> x :9:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: Nothing One can argue that it's similar to undefined, error, and various unsafeSomething functions, which I think should be reported as well, if possible. But these things can be found already with a simple grep while a pattern match cannot. I bet it has been discussed already, but "fail" is a terrible search term, so I cannot find anything relevant in the archives nor in the bug tracker. From mechvel at botik.ru Fri May 22 11:26:22 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Fri, 22 May 2015 15:26:22 +0400 Subject: error in 7.10.1 ? Message-ID: <1432293982.2877.51.camel@one.mechvel.pereslavl.ru> Dear GHC developers, The confirmation token letter from the bug tracker travels too long, I do not know, why. Meanwhile I cannot report there. So, I report it in the below way: http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may22-2015.zip Make it, please, with ghc-7.10.1 as it is written there in install.txt, including making demotest/Main. Then ./Main breaks in the middle reporting a DoCon application error ---------------------------------------------------------------------------- Factorization in K1[x], K1 a generic finite extension of a prime field K = Z/(p) .. factor f, f = (x^10 + x^7 + x^5 + x^3 + x^2 + (2)*x+ (2)) <- K[x] = ((Z/<5>)["t"]/<(t^3 + 4*t + 3)>)["x"] Domain term of K must contain a Finite field description. --------------------------------------------------------------------------- I obtain this for ghc-7.10.1 made from source by ghc-7.8.2 on Debian Linux, x-86, 64 bit. The story is as follows. docon-2.12 http://www.botik.ru/pub/local/Mechveliani/docon/2.12/ has been tested under ghc-7.8.2, and it works. Now I am trying to port it to ghc-7.10.1. This needs inserting certain pragmas for OVERLAPPING/OVERLAPPABLE into some instance declarations. So I call this port docon-2.12.1. 7.10.1-errReport-may22-2015.zip is the error report of docon-2.12.1 to ghc-7.10.1. This application has the OVERLAPPABLE pragma set to one instance and the OVERLAPPING pragma set to many instances. GHC itself warns of overlaps. Then I 1) set the pragma to the reported instance (pair), 2) recompile the corresponding module 3) rerun make configure; make build. This process has finished in `making' the application. Then, > cd demotest > ghc $doconCpOpt -O --make -rtsopts Main > ./Main produces the above error instead of the test success report. I suspect that the reason is in treating the instance overlaps (but there may be another source). Comparing docon-2.12 + ghc-7.8.2 to 7.10.1-errReport-may22-201 + ghc-7.10.1, can you, please, find: how to fix the latter version? Is this a bug in ghc-7.10.1 ? Regards, -------- Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrix at galois.com Fri May 22 19:10:41 2015 From: jhendrix at galois.com (Joe Hendrix) Date: Fri, 22 May 2015 12:10:41 -0700 Subject: Recursive loop in context simplification with GHC 7.10.1 Message-ID: <3087DD53-F627-448D-AC7E-AB122AF4743A@galois.com> Hi, I?m trying to migrate some code that compiles under GHC 7.8.4 to GHC 7.10.1. It uses the comparison operator (<=) in TypeLits, and seems to get in a recursive loop when simplifying contexts. I?ve included part of the output from "-ddump-tc-trace? once it gets stuck in the loop below. I?d appreciate any help on understanding what is happening. If it?s useful I could try to extract a minimal example showing the error, but I thought I?d try to understand what?s happening first. Thanks, Joe === flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK Following filled tyvar s_aifJ[fuv:0] = 1 GHC.TypeLits.<=? n_abP7[sk] flattenTyVar1 n_abP7[sk] GHC.TypeLits.Nat flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK Following filled tyvar s_aifJ[fuv:0] = 1 GHC.TypeLits.<=? n_abP7[sk] flattenTyVar1 n_abP7[sk] GHC.TypeLits.Nat flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2205 bytes Desc: not available URL: From ekmett at gmail.com Sat May 23 01:05:28 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 23 May 2015 11:05:28 +1000 Subject: -Wall and the fail method In-Reply-To: <87r3q9vscy.fsf@karetnikov.org> References: <87r3q9vscy.fsf@karetnikov.org> Message-ID: It probably doesn't belong in -Wall, as it is a fairly common idiom to use fail intentionally this way, but it could pretty easily be added to the 'do' and list/monad comprehension desugaring to issue a separate warning that we don't turn on by default. Making it possible to see where you use 'fail' explicitly might be a nice step on the road towards splitting out MonadFail though. Herbert has been working up a plan we can put forth to the community for how to proceed on that front. It may make sense to roll any such warnings into that effort. -Edward On Fri, May 22, 2015 at 8:06 PM, Nikita Karetnikov wrote: > Can -Wall be extended to report pattern match failures in do > expressions, like it does for case expressions? > > Prelude> :set -Wall > Prelude> let f = do Just x <- return Nothing; return x > Prelude> let g = case Nothing of Just x -> x > > :9:9: Warning: > Pattern match(es) are non-exhaustive > In a case alternative: Patterns not matched: Nothing > > One can argue that it's similar to undefined, error, and various > unsafeSomething functions, which I think should be reported as well, if > possible. But these things can be found already with a simple grep > while a pattern match cannot. > > I bet it has been discussed already, but "fail" is a terrible search > term, so I cannot find anything relevant in the archives nor in the bug > tracker. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mechvel at botik.ru Sat May 23 11:51:21 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Sat, 23 May 2015 15:51:21 +0400 Subject: error in 7.10.1 ? In-Reply-To: <1432293982.2877.51.camel@one.mechvel.pereslavl.ru> References: <1432293982.2877.51.camel@one.mechvel.pereslavl.ru> Message-ID: <1432381881.2752.6.camel@one.mechvel.pereslavl.ru> Now, I am investigating this, trying to provide a simpler report. Most probably this is the effect of a wrong instance overlap resolving. Regards, ------ Sergei On Fri, 2015-05-22 at 15:26 +0400, Sergei Meshveliani wrote: > Dear GHC developers, > > The confirmation token letter from the bug tracker travels too long, > I do not know, why. > Meanwhile I cannot report there. > So, I report it in the below way: > > > http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may22-2015.zip > > > Make it, please, with ghc-7.10.1 as it is written there in > install.txt, > including making demotest/Main. > Then > ./Main > > breaks in the middle reporting a DoCon application error > > [..] From mechvel at botik.ru Sat May 23 21:08:02 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Sun, 24 May 2015 01:08:02 +0400 Subject: overlapping instances in 7.10.1 Message-ID: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru> Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei From voldermort at hotmail.com Mon May 25 13:44:10 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 25 May 2015 06:44:10 -0700 (MST) Subject: SRC_HC_OPTS in perf build Message-ID: <1432561450352-5809863.post@n5.nabble.com> build.mk.sample contains the lines: # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m However, in config.mk.in this is: SRC_HC_OPTS += -H32m -O What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem to set it to -H32m, then every profile in build.mk.sample sets -H64m? -- View this message in context: http://haskell.1045720.n5.nabble.com/SRC-HC-OPTS-in-perf-build-tp5809863.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From ezyang at mit.edu Tue May 26 15:29:29 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 26 May 2015 08:29:29 -0700 Subject: SRC_HC_OPTS in perf build In-Reply-To: <1432561450352-5809863.post@n5.nabble.com> References: <1432561450352-5809863.post@n5.nabble.com> Message-ID: <1432654131-sup-2826@sabre> Sounds like an oversight to me! Submit a fix? Excerpts from Jeremy's message of 2015-05-25 06:44:10 -0700: > build.mk.sample contains the lines: > > # perf matches the default settings, repeated here for comparison: > SRC_HC_OPTS = -O -H64m > > However, in config.mk.in this is: > > SRC_HC_OPTS += -H32m -O > > What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem to > set it to -H32m, then every profile in build.mk.sample sets -H64m? > From voldermort at hotmail.com Wed May 27 06:57:14 2015 From: voldermort at hotmail.com (Jeremy) Date: Tue, 26 May 2015 23:57:14 -0700 (MST) Subject: SRC_HC_OPTS in perf build In-Reply-To: <1432654131-sup-2826@sabre> References: <1432561450352-5809863.post@n5.nabble.com> <1432654131-sup-2826@sabre> Message-ID: <1432709834765-5809930.post@n5.nabble.com> Edward Z. Yang wrote > Sounds like an oversight to me! Submit a fix? > > Excerpts from Jeremy's message of 2015-05-25 06:44:10 -0700: >> build.mk.sample contains the lines: >> >> # perf matches the default settings, repeated here for comparison: >> SRC_HC_OPTS = -O -H64m >> >> However, in config.mk.in this is: >> >> SRC_HC_OPTS += -H32m -O >> >> What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem >> to >> set it to -H32m, then every profile in build.mk.sample sets -H64m? Which should it be? -- View this message in context: http://haskell.1045720.n5.nabble.com/SRC-HC-OPTS-in-perf-build-tp5809863p5809930.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From dct25-561bs at mythic-beasts.com Fri May 29 07:52:19 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 29 May 2015 08:52:19 +0100 Subject: Consecutive FFI calls Message-ID: (cross-posted from ghc-dev and the cafe, with apologies to cross-subscribers) 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