From yongqli at kerrmetric.com Wed Apr 1 01:48:32 2015 From: yongqli at kerrmetric.com (Yongqian Li) Date: Tue, 31 Mar 2015 18:48:32 -0700 Subject: Bug: GHC creates incorrect code which throws <> Message-ID: Hi all, I wanted to bring to your attention this bug, https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about two days ago but hasn't gotten any replies to yet. In my opinion, this is a rather serious bug since GHC is producing incorrect code. While there is a workaround, it makes my program take about 2 hours to compile. Since reporting the bug, I've also seen "strange closure type" exceptions, which I believe are also caused by this bug, although I do not have a test case. Based on my limited understanding of GHC internals, I suspect the problem lies in how type class dictionaries are looked up at run time, as the problem disappears if GHC can fully resolve the types. Can others see if they can reproduce this bug? If there is any way I can help, please let me know. Sincerely, Yongqian Li From svenpanne at gmail.com Wed Apr 1 06:57:00 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 1 Apr 2015 08:57:00 +0200 Subject: GHC 7.10.1 html docs all flat? In-Reply-To: References: Message-ID: 2015-03-31 20:20 GMT+02:00 Randy Polen : > [...] Just want to make sure this is what is expected, and then change the HP > build code accordingly. [...] Hmmm, unless there is a strong reason to change this into a flat layout, I would propose to keep the docs hierarchical. I could envision clashes and tooling problems with the flat layout, but I fail to see why it should be better. To me, it just looks like a bug. If it's not a bug, could somebody point me to the discussion regarding the rationale behind the flat layout? Another related point: All "Source" links on haskell.org are currently broken, so the docs need to be regenerated an re-uploaded, anyway. From thomasmiedema at gmail.com Wed Apr 1 10:34:12 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 1 Apr 2015 12:34:12 +0200 Subject: How to better parallelize GHC build. In-Reply-To: <54FAD7D1.1050101@centrum.cz> References: <54FAD7D1.1050101@centrum.cz> Message-ID: Hi Karel, could you try adding `-j8` to `SRC_HC_OPTS` for the build flavor you're using in `mk/build.mk`, and running `gmake -j8` instead of `gmake -j64`. A graph like the one you attached will likely look even worse, but the walltime of your build should hopefully be improved. The build system seems to currently rely entirely on `make` for parallelism. It doesn't exploit ghc's own parallel `--make` at all, unless you explictly add `-jn` to SRC_HC_OPTS, with n>1 (which also sets the number of capabilities for the runtime system, so also adding `+RTS -Nn` is not needed). Case study: One of the first things the build system does is build ghc-cabal and Cabal using the stage 0 compiler, through a single invocation of `ghc --make`. All the later make targets depend on that step to complete first. Because `ghc --make` is not instructed to build in parallel, using `make -j1` or `make -j100000` doesn't make any difference (for that step). I think your graph shows that there are many of more of such bottlenecks. You would have to find out empirically how to best divide your number of threads (32) between `make` and `ghc --make`. From reading this comment by Simon in #9221 I understand it's better not to call `ghc --make -jn` with `n` higher than the number of physical cores of your machine (8 in your case). Once you get some better parallelism, other flags like `-A` might also have an effect on walltime (see that ticket). -Thomas On Sat, Mar 7, 2015 at 11:49 AM, Karel Gardas wrote: > > Folks, > > first of all, I remember someone already mentioned issue with decreased > parallelism of the GHC build recently somewhere but I cann't find it now. > Sorry, for that since otherwise I would use this thread if it was on this > mailing list. > > Anyway, while working on SPARC NCG I'm using T2000 which provides 32 > threads/8 core UltraSPARC T1 CPU. The property of this machine is that it's > really slow on single-threaded work. To squeeze some perf from it man > really needs to push 32 threads of work on it. Now, it really hurts my > nerves to see it's lazy building/running just one or two ghc processes. To > verify the fact I've created simple script to collect number of ghc > processes over time and putting this to graph. The result is in the > attached picture. The graph is result of running: > > gmake -j64 > > anyway, the average number of running ghc processes is 4.4 and the median > value is 2. IMHO such low number not only hurts build times on something > like CMT SPARC machine, but also on let say a cluster of ARM machines using > NFS and also on common engineering workstations which provide these days > (IMHO!) around 8-16 cores (and double the threads number). > > My naive idea(s) for fixing this issue is (I'm assuming no Haskell file > imports unused imports here, but perhaps this may be also investigated): > > 1) provide explicit dependencies which guides make to build in more > optimal way > > 2) hack GHC's make depend to kind of compute explicit dependencies from > (1) in an optimal way automatically > > 3) someone already mentioned using shake for building ghc. I don't know > shake but perhaps this is the right direction? > > 4) hack GHC to compile needed hi file directly in its memory if hi file is > not (yet!) available (issue how to get compiling options right here). Also > I don't know hi file semantics yet so bear with me on this. > > > Is there anything else which may be done to fix that issue? Is someone > already working on some of those? (I mean those reasonable from the list)? > > Thanks! > Karel > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Apr 1 10:58:37 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 1 Apr 2015 12:58:37 +0200 Subject: Bug: GHC creates incorrect code which throws <> In-Reply-To: References: Message-ID: <201504011258.37170.jan.stolarek@p.lodz.pl> Hi, I can confirm that the bug is reproducable on my system as well (64bit Debian Wheezy). Janek Dnia ?roda, 1 kwietnia 2015, Yongqian Li napisa?: > Hi all, > > I wanted to bring to your attention this bug, > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about > two days ago but hasn't gotten any replies to yet. > > > In my opinion, this is a rather serious bug since GHC is producing > incorrect code. While there is a workaround, it makes my program take > about 2 hours to compile. > > > Since reporting the bug, I've also seen "strange closure type" > exceptions, which I believe are also caused by this bug, although I do > not have a test case. Based on my limited understanding of GHC > internals, I suspect the problem lies in how type class dictionaries > are looked up at run time, as the problem disappears if GHC can fully > resolve the types. > > > Can others see if they can reproduce this bug? If there is any way I > can help, please let me know. > > > Sincerely, > Yongqian Li > _______________________________________________ > 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 jan.stolarek at p.lodz.pl Wed Apr 1 12:26:06 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 1 Apr 2015 14:26:06 +0200 Subject: Increased memory usage with GHC 7.10.1 Message-ID: <201504011426.06628.jan.stolarek@p.lodz.pl> Forall hi, I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From karel.gardas at centrum.cz Wed Apr 1 21:17:01 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 01 Apr 2015 23:17:01 +0200 Subject: How to better parallelize GHC build. In-Reply-To: References: <54FAD7D1.1050101@centrum.cz> Message-ID: <551C604D.7050205@centrum.cz> Hi Thomas, thanks for your suggestion. Also thanks for the PR number. I've tried with quick way (build.mk) and benchmarking ghc while compiling ghc-cabal manually and here are the results: -j1: 45s -j2: 28s -j3: 26s -j4: 24s -j5: 24s -j6: 25s -j6 -A32m: 23s -j6 -A64m: 21s -j6 -A128m: 23s real time is reported, GHC compiles into i386 code on Solaris 11. GHC is located in /tmp hence basically in RAM. CPU is 6c/12ht E5-2620. So not that bad, but on the other hand also not that good result. Anyway, unfortunately on my niagara this will probably not help me, since I guess --make -jX is recent addition probably not presented in 7.6.x, right? If so, then I'm afraid this will not help me since on niagara I'm using patched 7.6.x with fixed SPARC NCG and this single-threaded will be probably faster than 7.10.1 multithreaded but building unregisterised (hence with C compiler...). Anyway, I'll try to benchmark this tomorrow and will keep you posted. Thanks! Karel On 04/ 1/15 12:34 PM, Thomas Miedema wrote: > Hi Karel, > > could you try adding `-j8` to `SRC_HC_OPTS` for the build flavor you're > using in `mk/build.mk `, and running `gmake -j8` > instead of `gmake -j64`. A graph like the one you attached will likely > look even worse, but the walltime of your build should hopefully be > improved. > > The build system seems to currently rely entirely on `make` for > parallelism. It doesn't exploit ghc's own parallel `--make` at all, > unless you explictly add `-jn` to SRC_HC_OPTS, with n>1 (which also sets > the number of capabilities for the runtime system, so also adding `+RTS > -Nn` is not needed). > > Case study: One of the first things the build system does is build > ghc-cabal and Cabal using the stage 0 compiler, through a single > invocation of `ghc --make`. All the later make targets depend on that > step to complete first. Because `ghc --make` is not instructed to build > in parallel, using `make -j1` or `make -j100000` doesn't make any > difference (for that step). I think your graph shows that there are many > of more of such bottlenecks. > > You would have to find out empirically how to best divide your number of > threads (32) between `make` and `ghc --make`. From reading this comment > by Simon in > #9221 I understand it's better not to call `ghc --make -jn` with `n` > higher than the number of physical cores of your machine (8 in your > case). Once you get some better parallelism, other flags like `-A` might > also have an effect on walltime (see that ticket). > > -Thomas > > On Sat, Mar 7, 2015 at 11:49 AM, Karel Gardas > wrote: > > > Folks, > > first of all, I remember someone already mentioned issue with > decreased parallelism of the GHC build recently somewhere but I > cann't find it now. Sorry, for that since otherwise I would use this > thread if it was on this mailing list. > > Anyway, while working on SPARC NCG I'm using T2000 which provides 32 > threads/8 core UltraSPARC T1 CPU. The property of this machine is > that it's really slow on single-threaded work. To squeeze some perf > from it man really needs to push 32 threads of work on it. Now, it > really hurts my nerves to see it's lazy building/running just one or > two ghc processes. To verify the fact I've created simple script to > collect number of ghc processes over time and putting this to graph. > The result is in the attached picture. The graph is result of running: > > gmake -j64 > > anyway, the average number of running ghc processes is 4.4 and the > median value is 2. IMHO such low number not only hurts build times > on something like CMT SPARC machine, but also on let say a cluster > of ARM machines using NFS and also on common engineering > workstations which provide these days (IMHO!) around 8-16 cores (and > double the threads number). > > My naive idea(s) for fixing this issue is (I'm assuming no Haskell > file imports unused imports here, but perhaps this may be also > investigated): > > 1) provide explicit dependencies which guides make to build in more > optimal way > > 2) hack GHC's make depend to kind of compute explicit dependencies > from (1) in an optimal way automatically > > 3) someone already mentioned using shake for building ghc. I don't > know shake but perhaps this is the right direction? > > 4) hack GHC to compile needed hi file directly in its memory if hi > file is not (yet!) available (issue how to get compiling options > right here). Also I don't know hi file semantics yet so bear with me > on this. > > > Is there anything else which may be done to fix that issue? Is > someone already working on some of those? (I mean those reasonable > from the list)? > > Thanks! > Karel > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From eir at cis.upenn.edu Thu Apr 2 04:15:28 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 2 Apr 2015 00:15:28 -0400 Subject: Typeable In-Reply-To: References: Message-ID: <6D9D31EE-F4C8-479A-88B4-5554D215BCEA@cis.upenn.edu> On Mar 26, 2015, at 10:50 AM, Richard Eisenberg wrote: > This is now on Phab as https://phabricator.haskell.org/D757 > > I'll be making some comments there. Comments made. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Thu Apr 2 12:19:20 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 13:19:20 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504011426.06628.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> Message-ID: <201504021419.21520.jan.stolarek@p.lodz.pl> An update frrom my second machine, this time with 4GB of RAM. Compiling Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the build the module was compiled succesfully in a matter of minutes and using around 50% of memory. This looks like some kind of memory leak in GHC. Janek Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?: > Forall hi, > > I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed > installations of GHC and this means I had to rebuild Agda and Idris because > the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 > sandbox. Sadly, I had problems building both Agda and Idris due to GHC > taking up all of available memory. > > With Idris the problematic module was Idris.ElabTerm (~2900LOC). The > interesting part of the story is that when I do a clean build of Idris GHC > consumes all of memory when compiling that module and I have to kill the > build. But when I restart the build after killing GHC the module is > compiled using a reasonable amount of memory and within reasonable time. > > With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). > The trick with killing the build and restarting it didn't work in this > case. I had to compile Agda with GHC 7.8.4 (which works without problems > though the mentioned module still requires a lot of memory) and alter my > setup so that Agda binary is not stored inside GHC sandbox. > > I wonder if any of you came across similar issues with GHC 7.10.1? Do we > have any performance data that allows to compare memory usage and > performance of GHC 7.10.1 with previous stable releases? > > All of the above happened on 64bit Debian Wheezy with 2GB of RAM. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. If you are not the intended recipient > or if you have received this message in error, please notify the sender and > delete it from your system. > _______________________________________________ > 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 eir at cis.upenn.edu Thu Apr 2 12:29:55 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 2 Apr 2015 08:29:55 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021419.21520.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> Message-ID: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> Post a bug report! :) On Apr 2, 2015, at 8:19 AM, Jan Stolarek wrote: > An update frrom my second machine, this time with 4GB of RAM. Compiling Agda ran out of memory > (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the > build the module was compiled succesfully in a matter of minutes and using around 50% of memory. > This looks like some kind of memory leak in GHC. > > Janek > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?: >> Forall hi, >> >> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed >> installations of GHC and this means I had to rebuild Agda and Idris because >> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 >> sandbox. Sadly, I had problems building both Agda and Idris due to GHC >> taking up all of available memory. >> >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The >> interesting part of the story is that when I do a clean build of Idris GHC >> consumes all of memory when compiling that module and I have to kill the >> build. But when I restart the build after killing GHC the module is >> compiled using a reasonable amount of memory and within reasonable time. >> >> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). >> The trick with killing the build and restarting it didn't work in this >> case. I had to compile Agda with GHC 7.8.4 (which works without problems >> though the mentioned module still requires a lot of memory) and alter my >> setup so that Agda binary is not stored inside GHC sandbox. >> >> I wonder if any of you came across similar issues with GHC 7.10.1? Do we >> have any performance data that allows to compare memory usage and >> performance of GHC 7.10.1 with previous stable releases? >> >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM. >> >> Janek >> >> --- >> Politechnika ??dzka >> Lodz University of Technology >> >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. >> >> This email contains information intended solely for the use of the >> individual to whom it is addressed. If you are not the intended recipient >> or if you have received this message in error, please notify the sender and >> delete it from your system. >> _______________________________________________ >> 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. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From jan.stolarek at p.lodz.pl Thu Apr 2 12:47:25 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 13:47:25 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> Message-ID: <201504021447.25480.jan.stolarek@p.lodz.pl> I will. But I was curious whether this is only me or is anyone else seeing similar behaviour. And what about performance comparisson between 7.8.4 and 7.10.1? Do we have any numbers? Janek Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?: > Post a bug report! :) > > On Apr 2, 2015, at 8:19 AM, Jan Stolarek wrote: > > An update frrom my second machine, this time with 4GB of RAM. Compiling > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I > > had to kill the build. But once I restarted the build the module was > > compiled succesfully in a matter of minutes and using around 50% of > > memory. This looks like some kind of memory leak in GHC. > > > > Janek > > > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?: > >> Forall hi, > >> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed > >> installations of GHC and this means I had to rebuild Agda and Idris > >> because the binaries built with GHC 7.8.4 were stored inside deactivated > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to > >> GHC taking up all of available memory. > >> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The > >> interesting part of the story is that when I do a clean build of Idris > >> GHC consumes all of memory when compiling that module and I have to kill > >> the build. But when I restart the build after killing GHC the module is > >> compiled using a reasonable amount of memory and within reasonable time. > >> > >> With Agda the problematic module is Agda.TypeChecking.Serialise > >> (~2000LOC). The trick with killing the build and restarting it didn't > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works > >> without problems though the mentioned module still requires a lot of > >> memory) and alter my setup so that Agda binary is not stored inside GHC > >> sandbox. > >> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do we > >> have any performance data that allows to compare memory usage and > >> performance of GHC 7.10.1 with previous stable releases? > >> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM. > >> > >> Janek > >> > >> --- > >> Politechnika ??dzka > >> Lodz University of Technology > >> > >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > >> > >> This email contains information intended solely for the use of the > >> individual to whom it is addressed. If you are not the intended > >> recipient or if you have received this message in error, please notify > >> the sender and delete it from your system. > >> _______________________________________________ > >> 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. > > _______________________________________________ > > 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 mail at joachim-breitner.de Thu Apr 2 12:53:46 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 02 Apr 2015 14:53:46 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl> 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> Message-ID: <1427979226.1578.19.camel@joachim-breitner.de> Hi, Am Donnerstag, den 02.04.2015, 13:47 +0100 schrieb Jan Stolarek: > I will. But I was curious whether this is only me or is anyone else seeing similar behaviour. And > what about performance comparisson between 7.8.4 and 7.10.1? Do we have any numbers? we have a few numbers between 7.8.3 and HEAD, on http://ghcspeed-nomeata.rhcloud.com/comparison/ e.g. http://ghcspeed-nomeata.rhcloud.com/comparison/?exe=2%2B68%2C2%2BL%2Bdefault&ben=320%2C321%2C322%2C323%2C324%2C325%2C326%2C327%2C328%2C329%2C330%2C331%2C332%2C333%2C334%2C335%2C336%2C337%2C338%2C339%2C340%2C341%2C342%2C343%2C344%2C345%2C346%2C347%2C348%2C349%2C350%2C351%2C352%2C353%2C354%2C355%2C356%2C357%2C358%2C359%2C360%2C361%2C362%2C363%2C364%2C365%2C366%2C367%2C368%2C369%2C370%2C371%2C372%2C373%2C374%2C375%2C376%2C377%2C378%2C379%2C380%2C381%2C382%2C383%2C384%2C385%2C386%2C387%2C388%2C389%2C390%2C391%2C392%2C393%2C394%2C395%2C396%2C397%2C398%2C399%2C400%2C401%2C402%2C403%2C404%2C405%2C406%2C407%2C408%2C409%2C410%2C411%2C412%2C413%2C414%2C415%2C416%2C417%2C418%2C419&env=1&hor=false&bas=none&chart=normal+bars but it does not have numbers on binary size for 7.8.3. http://ghcspeed-nomeata.rhcloud.com/timeline/#/?exe=2&base=2+68&ben=nofib/size/anna&env=1&revs=1000&equid=on does not show anything worrying (but only goes back to last October). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From dan.doel at gmail.com Thu Apr 2 14:00:08 2015 From: dan.doel at gmail.com (Dan Doel) Date: Thu, 2 Apr 2015 10:00:08 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl> 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> Message-ID: You aren't the only one. The vector test suite also has these kind of issues. In its case, it's hard for me to tell how big the code is, because template haskell is being used to generate it. However, I don't think the template haskell is what's using the additional performance, because the test suite is compiled with both -O0 and -O2, and only the latter runs into performance issues. In vector's case, 7.6.3 compiles significantly faster than 7.8.4, which is in turn significantly faster than 7.10.1. And memory usage follows the same pattern (with -O2 at least). 7.6.3 uses ~400MB of memory, 7.8.4 1-2GB and 7.10.1 3-4GB (if I'm remembering correctly). And while I can build the tests on 7.10 in around 5 minutes, travis times out building them after around half an hour. On Thu, Apr 2, 2015 at 8:47 AM, Jan Stolarek wrote: > I will. But I was curious whether this is only me or is anyone else seeing > similar behaviour. And > what about performance comparisson between 7.8.4 and 7.10.1? Do we have > any numbers? > > Janek > > Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?: > > Post a bug report! :) > > > > On Apr 2, 2015, at 8:19 AM, Jan Stolarek wrote: > > > An update frrom my second machine, this time with 4GB of RAM. Compiling > > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I > > > had to kill the build. But once I restarted the build the module was > > > compiled succesfully in a matter of minutes and using around 50% of > > > memory. This looks like some kind of memory leak in GHC. > > > > > > Janek > > > > > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?: > > >> Forall hi, > > >> > > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep > sandboxed > > >> installations of GHC and this means I had to rebuild Agda and Idris > > >> because the binaries built with GHC 7.8.4 were stored inside > deactivated > > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due > to > > >> GHC taking up all of available memory. > > >> > > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The > > >> interesting part of the story is that when I do a clean build of Idris > > >> GHC consumes all of memory when compiling that module and I have to > kill > > >> the build. But when I restart the build after killing GHC the module > is > > >> compiled using a reasonable amount of memory and within reasonable > time. > > >> > > >> With Agda the problematic module is Agda.TypeChecking.Serialise > > >> (~2000LOC). The trick with killing the build and restarting it didn't > > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works > > >> without problems though the mentioned module still requires a lot of > > >> memory) and alter my setup so that Agda binary is not stored inside > GHC > > >> sandbox. > > >> > > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do > we > > >> have any performance data that allows to compare memory usage and > > >> performance of GHC 7.10.1 with previous stable releases? > > >> > > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM. > > >> > > >> Janek > > >> > > >> --- > > >> Politechnika ??dzka > > >> Lodz University of Technology > > >> > > >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > adresata. > > >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? > przez > > >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej > usuni?cie. > > >> > > >> This email contains information intended solely for the use of the > > >> individual to whom it is addressed. If you are not the intended > > >> recipient or if you have received this message in error, please notify > > >> the sender and delete it from your system. > > >> _______________________________________________ > > >> 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. > > > _______________________________________________ > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Thu Apr 2 15:08:43 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 2 Apr 2015 12:08:43 -0300 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl> 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> Message-ID: I'm curious why the amount of RAM is relevant as all of our OS have virtual memory so it is only the size of the heap and the amount of swap that should be relevant for an Out Of Memory error, right? How big is your heap? Amount of RAM should only affect speed (i.e. if there is excessive paging) but should not affect Out Of Memory right? On Thu, Apr 2, 2015 at 9:47 AM, Jan Stolarek wrote: > I will. But I was curious whether this is only me or is anyone else seeing > similar behaviour. And > what about performance comparisson between 7.8.4 and 7.10.1? Do we have > any numbers? > > Janek > > Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?: > > Post a bug report! :) > > > > On Apr 2, 2015, at 8:19 AM, Jan Stolarek wrote: > > > An update frrom my second machine, this time with 4GB of RAM. Compiling > > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I > > > had to kill the build. But once I restarted the build the module was > > > compiled succesfully in a matter of minutes and using around 50% of > > > memory. This looks like some kind of memory leak in GHC. > > > > > > Janek > > > > > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?: > > >> Forall hi, > > >> > > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep > sandboxed > > >> installations of GHC and this means I had to rebuild Agda and Idris > > >> because the binaries built with GHC 7.8.4 were stored inside > deactivated > > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due > to > > >> GHC taking up all of available memory. > > >> > > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The > > >> interesting part of the story is that when I do a clean build of Idris > > >> GHC consumes all of memory when compiling that module and I have to > kill > > >> the build. But when I restart the build after killing GHC the module > is > > >> compiled using a reasonable amount of memory and within reasonable > time. > > >> > > >> With Agda the problematic module is Agda.TypeChecking.Serialise > > >> (~2000LOC). The trick with killing the build and restarting it didn't > > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works > > >> without problems though the mentioned module still requires a lot of > > >> memory) and alter my setup so that Agda binary is not stored inside > GHC > > >> sandbox. > > >> > > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do > we > > >> have any performance data that allows to compare memory usage and > > >> performance of GHC 7.10.1 with previous stable releases? > > >> > > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM. > > >> > > >> Janek > > >> > > >> --- > > >> Politechnika ??dzka > > >> Lodz University of Technology > > >> > > >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > adresata. > > >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? > przez > > >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej > usuni?cie. > > >> > > >> This email contains information intended solely for the use of the > > >> individual to whom it is addressed. If you are not the intended > > >> recipient or if you have received this message in error, please notify > > >> the sender and delete it from your system. > > >> _______________________________________________ > > >> 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. > > > _______________________________________________ > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Thu Apr 2 15:21:34 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 16:21:34 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: <201504021721.35386.jan.stolarek@p.lodz.pl> > I'm curious why the amount of RAM is relevant as all of our OS have virtual > memory so it is only the size of the heap and the amount of swap that > should be relevant for an Out Of Memory error, right? How big is your heap? > Amount of RAM should only affect speed (i.e. if there is excessive paging) > but should not affect Out Of Memory right? Actually, I never allowed GHC to completely run out of memory. I just killed the build process when it consumed all of physical RAM memory and started growing into swap. At that point machine becomes barely usable and the build practically stalls as CPU usage drops to 0. FYI: both machines have size of swap equal to size of RAM. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From austin at well-typed.com Thu Apr 2 18:38:13 2015 From: austin at well-typed.com (Austin Seipp) Date: Thu, 2 Apr 2015 13:38:13 -0500 Subject: GHC 7.10.1 html docs all flat? In-Reply-To: References: Message-ID: Hi Randy, This is due to an upstream Haddock bug I didn't manage to fix before the release; see https://ghc.haskell.org/trac/ghc/ticket/10206 - we really need to fix this for 7.10.2. I believe the problem we need to fix is in Haddock. The fact that the non-hierarchical version appears on the website is just so people can browse it (and FWIW, the 'correct links' are there, but obviously the hyperlinks *to* the proper places are broken...) On Tue, Mar 31, 2015 at 1:20 PM, Randy Polen wrote: > The HP build expects that the html docs for the ghc-bundled packages will be in > heirarchical directories, based on the package name (e.g., GHC.Magic docs in > libraries/ghc-prim-0.3.1.0/GHC-Magic.html) which is how it has been for many > ghc releases. In 7.10.1, I thought it was an error but it seems the > haskell.org docs reflect this new, flat way (e.g,. GHC.Magic docs in > libraries/GHC-Magic.html). > > > Just want to make sure this is what is expected, and then change the HP > build code accordingly. > > > Follow up question: should the HP-bundled docs do the same thing? Is the > > flat model the way to go for all the docs? Won't this cause collisions for > > updated packages? > > > Randy > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Apr 3 11:36:43 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 3 Apr 2015 06:36:43 -0500 Subject: Help wanted: working on the GHC webpage Message-ID: Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From sergey.bushnyak at sigrlami.eu Fri Apr 3 13:16:24 2015 From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak) Date: Fri, 03 Apr 2015 16:16:24 +0300 Subject: Help wanted: working on the GHC webpage In-Reply-To: References: Message-ID: <551E92A8.7020901@sigrlami.eu> Hi, Austin. Here is my fork of yours `ghc-homepage' repo https://github.com/sigrlami/ghc-homepage. It builds main page with Hakyll and overall work could be done in couple of days or week. But I want to raise couple of issues related to design. 1)The site is built on outdated html markup and not consistent in it's structure, a lot of stuff linked to other pages which have different design. 2) Could we discuss possibility to make it look more like new haskell.org page and update design in general, switch to HTML5/CSS3 . 3) Also, it might be easier to publish blog posts on this site, like weekly news, without linking to `track`. I can reuse some code we are using for building haskell.od.ua (OdHug, Odessa Haskell User Group) I can work on this transition. -- Best regards, Sergey Bushnyak On 04/03/2015 02:36 PM, Austin Seipp wrote: > Hello *, > > For a while now, I've been wanting to do a facelift on the GHC > homepage, but among many other things it's been a low priority. I'd > like for people to help, so I've tried to get the ball rolling. > > The webpages existed in a Darcs repository previously (which wasn't > available online), but earlier today I converted them to a git > repository which you can find here: > > https://github.com/haskell-infra/ghc-homepage > > The site is currently composed of a set of "server side include" files > that have a crude form of HTML templating. So it's mostly just pretty > verbose to add or refactor anything, and the sites templating and > styling is quite old (it dates back at least 10 years!) > > So, I'm making an official call for some help. At the very least, I'd > like to at least end up converting the site to something like Hakyll > which is doable without me causing a lot of damage to the stylesheets, > but for the actual page itself I'd really appreciate it if anyone > could help out! Please send pull requests or file issues, it's much > appreciated. > From hvriedel at gmail.com Fri Apr 3 13:44:13 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 03 Apr 2015 15:44:13 +0200 Subject: Help wanted: working on the GHC webpage In-Reply-To: <551E92A8.7020901@sigrlami.eu> (Sergey Bushnyak's message of "Fri, 03 Apr 2015 16:16:24 +0300") References: <551E92A8.7020901@sigrlami.eu> Message-ID: <87y4m9conm.fsf@gmail.com> Hi Sergey, On 2015-04-03 at 15:16:24 +0200, Sergey Bushnyak wrote: [...] > 3) Also, it might be easier to publish blog posts on this site, like > weekly news, without linking to `track`. I can reuse some code we are > using for building haskell.od.ua (OdHug, Odessa Haskell User Group) Why would it be easier? What's difficult about publishing on https://ghc.haskell.org/trac/ghc/blog? Moreover, the GHC weekly news are intimately linked to Trac, as they reference Trac-tickets and Git commits, which Trac is able to annotate with meta-data (ticket-type, -status, and -title for Ticket references, as well as part of the Git commit msg for Git-commit refs). Finally, GHC blog-posts are listed as events on https://ghc.haskell.org/trac/ghc/timeline Cheers, hvr From sergey.bushnyak at sigrlami.eu Fri Apr 3 14:08:26 2015 From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak) Date: Fri, 03 Apr 2015 17:08:26 +0300 Subject: Help wanted: working on the GHC webpage In-Reply-To: <87y4m9conm.fsf@gmail.com> References: <551E92A8.7020901@sigrlami.eu> <87y4m9conm.fsf@gmail.com> Message-ID: <551E9EDA.40301@sigrlami.eu> > Why would it be easier? What's difficult about publishing on > https://ghc.haskell.org/trac/ghc/blog? I'm actually don't know how it's published on track. From my standpoint as newcomer it's better to see what's happening from one place, with one design, have some shared git repo where people contribute in markdown. > Moreover, the GHC weekly news are intimately linked to Trac, as they > reference Trac-tickets and Git commits, which Trac is able to annotate > with meta-data (ticket-type, -status, and -title for Ticket references, > as well as part of the Git commit msg for Git-commit refs). Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about annotation. Anyway, still can help on updating ghc home page. From ozataman at gmail.com Sun Apr 5 18:01:06 2015 From: ozataman at gmail.com (Ozgun Ataman) Date: Sun, 5 Apr 2015 14:01:06 -0400 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) Message-ID: Hello, Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification. Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times. We made a few measurements to quantify the issue and here is the data: - This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes - Tests were performed on OS X, though we saw similar results on Linux - Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project - With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!) - With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!) - With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) - 7.8.4: 3 min. 35 seconds - 7.6.3: 1 min. 2 seconds - Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile: - We have 10 modules that each take over 10 seconds - We have 3 modules that each take over 35 seconds - Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing: - Example with 7.6.3, O0: cabal build 140.57s user 13.25s system 100% cpu 2:33.70 total - Example with 7.8.4, O0: cabal build 507.83s user 655.43s system 549% cpu 3:31.59 total The main hurt here has been the infeasibility of using "cabal repl / ghci" fast-feedback style development (via emacs, vim, command-line, etc.), since: - Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation) - The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes. - cabal repl does not seem to benefit from -j at all - cabal repl 7.8.4 appears to be hurt particularly by the heavier modules - The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time Let me know if I'm missing anything here and any/all feedback is much appreciated! Cheers, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Mon Apr 6 06:52:01 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Mon, 6 Apr 2015 09:52:01 +0300 Subject: DPH tests Message-ID: Hi! There?s ?Additional Packages? section [0] which lists packages that need to be installed in order to run full testsuite. But I couldn?t install dph-* ones, first errors I was getting were regular cabal-constraint ones. I wrote an author Ben Lippmeier, but he replied that dph-* packages were obsolete and not maintained anymore. I grepped and saw that all tests are under testsuite/dph folder. So: does GHC still run them at all? Should we edit wiki? Or edit test-suite? Thanks! [0]: https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Apr 6 07:46:09 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 6 Apr 2015 09:46:09 +0200 Subject: DPH tests In-Reply-To: References: Message-ID: Hi Konstantine, thanks for investigating this. I updated the wiki by removing those packages from the list. The testsuite driver simply skips tests that depend on packages that are not installed (dph-* in this case). I don't know what to about those tests though, as dph is unmaintained and not in a working state. I someone really wanted to, they could try building ghc with `BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all `reqlib` calls to the deprecated dph-* packages in the `.T` files, run `make test`, and see what happens. Please note that running the full testsuite in general results in lots of failed tests. The continuous integration system only runs `make fasttest`. Thomas On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov wrote: > Hi! > > There?s ?Additional Packages? section [0] which lists packages that need > to be installed in order to run full testsuite. But I couldn?t install > dph-* ones, first errors I was getting were regular cabal-constraint ones. > I wrote an author Ben Lippmeier, but he replied that dph-* packages were > obsolete and not maintained anymore. I grepped and saw that all tests are > under testsuite/dph folder. So: does GHC still run them at all? Should we > edit wiki? Or edit test-suite? > > Thanks! > > [0]: > https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 6 07:47:40 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 Apr 2015 07:47:40 +0000 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: References: Message-ID: Oz, and others, Thanks for this data point. Two things: ? Oz: is there any chance you could boil out a test case that highlights the regression most starkly? It is sad to know that GHC?s compilation time is increasing, but hard to tackle. A test case, preferably one that doesn?t rely on zillions of other libraries, increases the chances of something getting done by a factor of 10 or 100. Do make a ticket for it as well. Otherwise it just gets lost. ? Everyone. It?s really hard to keep focus on keeping GHC?s compilation time and space down. Everyone is usually focused on bugs and features. It would be incredibly helpful if someone, or a small group, could build a profiled version of GHC 7.8, 7.10, and HEAD, and track down what is happening. Usually there are multiple causes, but a factor of 7.5 ought not to be hard to nail down. Please! Thanks. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ozgun Ataman Sent: 05 April 2015 19:01 To: ghc-devs at haskell.org Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) Hello, Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification. Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times. We made a few measurements to quantify the issue and here is the data: * This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes * Tests were performed on OS X, though we saw similar results on Linux * Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project * With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!) * With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!) * With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) * 7.8.4: 3 min. 35 seconds * 7.6.3: 1 min. 2 seconds * Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile: * We have 10 modules that each take over 10 seconds * We have 3 modules that each take over 35 seconds * Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing: * Example with 7.6.3, O0: cabal build 140.57s user 13.25s system 100% cpu 2:33.70 total * Example with 7.8.4, O0: cabal build 507.83s user 655.43s system 549% cpu 3:31.59 total The main hurt here has been the infeasibility of using "cabal repl / ghci" fast-feedback style development (via emacs, vim, command-line, etc.), since: * Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation) * The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes. * cabal repl does not seem to benefit from -j at all * cabal repl 7.8.4 appears to be hurt particularly by the heavier modules * The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time Let me know if I'm missing anything here and any/all feedback is much appreciated! Cheers, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 6 09:00:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 Apr 2015 09:00:17 +0000 Subject: DynFlags.hs In-Reply-To: <1427722251.1537.16.camel@joachim-breitner.de> References: <20150330.222155.554427425406328754.kazu@iij.ad.jp> <1427722251.1537.16.camel@joachim-breitner.de> Message-ID: <837be3e6465b4a3f909f7f42d654cc52@DB4PR30MB030.064d.mgd.msft.net> And #7528 identifies that something non-linear is going on; and gives a test program "W2" to provoke it. Might anyone be willing to investigate further? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim | Breitner | Sent: 30 March 2015 14:31 | To: ghc-devs at haskell.org | Subject: Re: DynFlags.hs | | Hi, | | Am Montag, den 30.03.2015, 22:21 +0900 schrieb Kazu Yamamoto: | > I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This | > is because compiler/main/DynFlags.hs is huge. It would be nice if this | > file could be split. | | this has been reported as | https://ghc.haskell.org/trac/ghc/ticket/7258 | | It would be great to be able to make the compiler cope with the file | gracefully, instead of working around the issue. | | 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 From eir at cis.upenn.edu Mon Apr 6 10:39:46 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 6 Apr 2015 06:39:46 -0400 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: References: Message-ID: > > ? Everyone. It?s really hard to keep focus on keeping GHC?s compilation time and space down. Everyone is usually focused on bugs and features. It would be incredibly helpful if someone, or a small group, could build a profiled version of GHC 7.8, 7.10, and HEAD, and track down what is happening. Usually there are multiple causes, but a factor of 7.5 ought not to be hard to nail down. > > Please! This is a great newcomer-to-ghc-hacking task. It's both relatively easy to do and gives a newcomer a chance to tour the codebase. The person doing the profiling doesn't also have to fix the bug. Just knowing what module or component of GHC is causing the trouble helps immensely. As a further plug: when a change I made introduced a performance regression, I went into the debugging process very warily, expecting profiling GHC to be painful. It was just the opposite -- remarkably straightforward and able to produce results without terribly much effort. On the other hand, it does generally require having multiple (profiled) builds of GHC to get meaningful comparisons. Thanks to whoever takes this on! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Apr 6 11:10:20 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 6 Apr 2015 07:10:20 -0400 Subject: DPH tests In-Reply-To: References: Message-ID: Relatedly, might it be a good idea for at least the phab build bot tests to enable stuff like the tests that use vector and other widely used packages? On Apr 6, 2015 3:46 AM, "Thomas Miedema" wrote: > Hi Konstantine, > > thanks for investigating this. I updated the wiki by removing those > packages from the list. > > The testsuite driver simply skips tests that depend on packages that are > not installed (dph-* in this case). I don't know what to about those tests > though, as dph is unmaintained and not in a working state. > > I someone really wanted to, they could try building ghc with > `BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all > `reqlib` calls to the deprecated dph-* packages in the `.T` files, run > `make test`, and see what happens. > > Please note that running the full testsuite in general results in lots of > failed tests. The continuous integration system only runs `make fasttest`. > > Thomas > > On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov > wrote: > >> Hi! >> >> There?s ?Additional Packages? section [0] which lists packages that need >> to be installed in order to run full testsuite. But I couldn?t install >> dph-* ones, first errors I was getting were regular cabal-constraint ones. >> I wrote an author Ben Lippmeier, but he replied that dph-* packages were >> obsolete and not maintained anymore. I grepped and saw that all tests are >> under testsuite/dph folder. So: does GHC still run them at all? Should we >> edit wiki? Or edit test-suite? >> >> Thanks! >> >> [0]: >> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Mon Apr 6 11:42:27 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Mon, 6 Apr 2015 14:42:27 +0300 Subject: DPH tests In-Reply-To: References: Message-ID: Would be a strong +1 from me, since it would mean: 1. We could script in the "Plan B" from here [0] and add it to default "./validate" to have less work for people to either search via Wiki or get recommendations in Trac tickets to notice these additional tests 2. We would notice things like currently-broken hmatrix installation and previously-broken dph- ones immediately. 3. Dead-tests and dead-code is always an unfortunate thing to have. [0]: https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace On Mon, Apr 6, 2015 at 2:10 PM, Carter Schonwald wrote: > Relatedly, might it be a good idea for at least the phab build bot tests > to enable stuff like the tests that use vector and other widely used > packages? > On Apr 6, 2015 3:46 AM, "Thomas Miedema" wrote: > >> Hi Konstantine, >> >> thanks for investigating this. I updated the wiki by removing those >> packages from the list. >> >> The testsuite driver simply skips tests that depend on packages that are >> not installed (dph-* in this case). I don't know what to about those tests >> though, as dph is unmaintained and not in a working state. >> >> I someone really wanted to, they could try building ghc with >> `BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all >> `reqlib` calls to the deprecated dph-* packages in the `.T` files, run >> `make test`, and see what happens. >> >> Please note that running the full testsuite in general results in lots of >> failed tests. The continuous integration system only runs `make fasttest`. >> >> Thomas >> >> On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov >> wrote: >> >>> Hi! >>> >>> There?s ?Additional Packages? section [0] which lists packages that need >>> to be installed in order to run full testsuite. But I couldn?t install >>> dph-* ones, first errors I was getting were regular cabal-constraint ones. >>> I wrote an author Ben Lippmeier, but he replied that dph-* packages were >>> obsolete and not maintained anymore. I grepped and saw that all tests are >>> under testsuite/dph folder. So: does GHC still run them at all? Should we >>> edit wiki? Or edit test-suite? >>> >>> Thanks! >>> >>> [0]: >>> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpquigl at tycho.nsa.gov Mon Apr 6 14:27:36 2015 From: dpquigl at tycho.nsa.gov (dpquigl) Date: Mon, 06 Apr 2015 10:27:36 -0400 Subject: Use of GHC in Open Embedded Environments Message-ID: <1428330456.15416.39.camel@tycho.nsa.gov> Hello Everyone, I sent a couple of private messages to Simon and he suggested I post to the list instead to get more eyes on the problem. I have been working for the better part of 3 days on trying to get GHC to build within an Open Embedded environment. Open Embedded is used to set up embedded build environments that are completely isolated from the build platform. The problem I'm encountering is due to the way GHC builds its requiring the build and host platforms to be the same. I want to create a GHC build where the build and host are different so I can guarantee the isolation of the Haskell used to build our programs and libraries on target. I looked extensively through the cross compilation wiki page and even tried specifying paths into configure script to specify the tools from within my toolchain to build with and I am still running into problems. It seems that even if the top level makefile gets configured properly the build environment for the modules created with cabal under libraries do not retain any of that configuration information. The reason this is important is that I'm working on OpenXT which is a recently Open Sources version of a product Citrix use to have called Xen Client XT. The idea of OpenXT is that we use Xen to decompose what is traditionally a monolithic system into several VMs which serve specific purposes. For example we have the user interface for the platform which manages things like sound levels and bringing up and shutting down VMs into its own domain called the UI domain. We also separate out networking into its own domain as well where the network card is mapped exclusively into that domain and it manages creating and running virtual network adapters for other VMs on the platform. We use haskell in two different ways in this system. We personally want to use OpenXT as a research platform and we have special purpose mini domains for doing things like measurement and attestation and we have components of these written in Haskell to do formal verification of the domains. What OpenXT is using Haskell for directly is as part of its management engine for the platform. We have a haskell and ocaml(just for glue) based versions of metadata storage and platform management APIs. Now when we build the platform we want to remove the dependency on the host platform GHC version. We try to do this by building what would essentially be a stage 1 compiler which will then be used to build the runtime and tools used in the final platform VMs. The issue is that the GHC build does not recognize the use case of host and build machines being different. They expect host and build to be the same and target to be different. Because of this even if we specify each component individually on the configure line for the base GHC build when the build gets to the point of building the libraries it seems to have this information completely vanish. I think this is because it is using cabal to build the libraries and cabal isn't taking into account that GHC is built for a second platform and we want to build those libraries for that same platform. Dave From rwbarton at gmail.com Mon Apr 6 18:57:09 2015 From: rwbarton at gmail.com (Reid Barton) Date: Mon, 6 Apr 2015 14:57:09 -0400 Subject: Use of GHC in Open Embedded Environments In-Reply-To: <1428330456.15416.39.camel@tycho.nsa.gov> References: <1428330456.15416.39.camel@tycho.nsa.gov> Message-ID: Hi Dave, Have you seen https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling? In GHC's build system the build, host and target are relative to the stage1 compiler only, which will be a cross-compiler when host /= target. Since the GHC ABI and interface file format can change arbitrarily between different versions of GHC, programs built by the stage1 compiler must be linked against libraries that were also built by the stage1 compiler (since by definition the stage1 compiler is the first build of the new GHC version). In order to build those libraries, the build system needs to be able to run the stage1 compiler, which runs on host. So, either build must equal host (which is what the GHC build system expects), or the build system would have to somehow communicate with a second system of platform host to build the libraries there. However, if you also build the stage2 compiler, since it was built by the stage1 compiler, which targets target, the stage2 compiler will be a native compiler that runs on and targets target, and it will be capable of dynamic code loading (ghci and Template Haskell). This is the most common thing to want when building a compiler that runs on a platform other than the build platform, though other configurations are (at least theoretically) possible. We use haskell in two different ways in this system. We personally want > to use OpenXT as a research platform and we have special purpose mini > domains for doing things like measurement and attestation and we have > components of these written in Haskell to do formal verification of the > domains. What OpenXT is using Haskell for directly is as part of its > management engine for the platform. We have a haskell and ocaml(just for > glue) based versions of metadata storage and platform management APIs. > Now when we build the platform we want to remove the dependency on the > host platform GHC version. We try to do this by building what would > essentially be a stage 1 compiler which will then be used to build the > runtime and tools used in the final platform VMs. The issue is that the > GHC build does not recognize the use case of host and build machines > being different. They expect host and build to be the same and target to > be different. Because of this even if we specify each component > individually on the configure line for the base GHC build when the build > gets to the point of building the libraries it seems to have this > information completely vanish. I think this is because it is using cabal > to build the libraries and cabal isn't taking into account that GHC is > built for a second platform and we want to build those libraries for > that same platform. > I have to say I don't follow what you are trying to do here. If your question isn't already answered by now, could you be more specific, e.g. "a stage-n compiler that is built on X, runs on Y and targets Z"? Even if X, Y and Z are just opaque strings it would be helpful. Since you mention removing the dependency on the host GHC version, maybe you want to do an extra bootstrap stage, where instead of building (maybe cross-compiling) the eventually desired version V with bootstrap compiler B, you first build a native V compiler, then use that to bootstrap the cross-compile. However, in theory the stage2 compiler should not depend at all on the choice of bootstrap compiler. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Apr 7 00:58:41 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 6 Apr 2015 20:58:41 -0400 Subject: [haskell.org Google Summer of Code] Call for Mentors Message-ID: We have had a rather large pool of potential students apply for this year's Google Summer of Code, but, ultimately, Google won't let us ask for a slot unless we have a potential mentor assigned in advance. On top of that, one thing we try to do with each project is wherever possible, assign both a primary and a backup mentor, so the available mentoring pool is drawn a little thin. Many hands make for light work, though: If you've mentored or thought about mentoring in years past, I'd encourage you to sign up on google-melange for the Google Summer of Code at: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and request a connection to haskell.org as a Mentor. Once you've done this you can help us vote on proposals, and should something seem appropriate to you, you can flag yourself as available as a potential mentor or backup mentor for one (or more) of the projects. We have a couple of weeks left to rate proposals and request slots, but it'd be good to make as much progress as we can this week. If you have any questions, feel free to reach out to me, or to Shachaf Ben-Kiki or Gershom Bazerman who have been helping out with organizational issues this year. We also have a #haskell-gsoc channel on irc.freenode.net if you have questions about what is involved. Thank you for your time and consideration, -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Apr 7 19:39:47 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 07 Apr 2015 20:39:47 +0100 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: References: Message-ID: <55243283.3050506@gmail.com> Just a comment on this one point: On 05/04/2015 19:01, Ozgun Ataman wrote: > * With O0 and -j=N the overall wall-clock time is 40% higher, but the > CPU time spent is a staggering 7.5X higher (!) When looking at Haskell programs executing in parallel, it's normal to see a high CPU time, because the GC threads spin looking for work. The extra CPU time is just time spent spinning, it doesn't imply that the compiler was doing extra work. What matters is the overall wall-clock time - a worse wall-clock time indicates that something has gone wrong. We should look at compile-time regression independently of performance issues with -j. Parallel compilation is a new feature and mostly likely needs a lot of tuning. Note that cabal's -j feature is different from GHC's (and is likely to give much more reliable improvements) because it runs multiple compiler instances in parallel. Cheers, Simon > * With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) > o 7.8.4: 3 min. 35 seconds > o 7.6.3: 1 min. 2 seconds > * Measuring compile times for individual modules, we see that those > that are heavily loaded with lots of types, TH-facilitated type and > typeclass derivations and those that contain large "blobs" of values > directly at the top level now take much longer to compile: > o We have 10 modules that each take over 10 seconds > o We have 3 modules that each take over 35 seconds > * Sidenote observation: In general, parallel builds with -j appear to > cause a very significant overhead under the "system" part of timing: > o Example with 7.6.3, O0: cabal build 140.57s user 13.25s system > 100% cpu 2:33.70 total > o Example with 7.8.4, O0: cabal build 507.83s user 655.43s system > 549% cpu 3:31.59 total > > > The main hurt here has been the infeasibility of using "cabal repl / > ghci" fast-feedback style development (via emacs, vim, command-line, > etc.), since: > > * Unlike "cabal build", "cabal repl" re-compiles from scratch with > every invocation ":l App.Foo.Bar", which itself is the necessary > first step when starting to hack on a module (we can then use :r to > somewhat help the situation) > * The slowdown is about 2.5X as stated above: What used to take a > minute now takes 3.5 minutes. > * cabal repl does not seem to benefit from -j at all > * cabal repl 7.8.4 appears to be hurt particularly by the heavier modules > * The heavier modules are often at the top of the compile tree (types, > derivations, etc) and are practically loaded on the critical path > all the time > > Let me know if I'm missing anything here and any/all feedback is much > appreciated! > > Cheers, > Oz > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From dan at kernelim.com Tue Apr 7 20:33:42 2015 From: dan at kernelim.com (Dan Aloni) Date: Tue, 7 Apr 2015 23:33:42 +0300 Subject: Toward better syntax errors Message-ID: <20150407203342.GA12600@gmail.com> Hello, Forwarded here is a link to a blog post I authored about improving GHC's syntax errors: http://blog.aloni.org/posts/toward-better-ghc-syntax-errors/ In fact, this came about after I started using Happy more extensively, and at one point thought that GHC could benefit too The gist of it, is that it was relatively easy to reach an improvement such as follows (notice 'possible tokens' below): input: -- test i = case i of 2 main = return () output: -- example1.hs:2:1: parse error (possibly incorrect indentation or mismatched brackets), possible tokens: '|' '->' It spawned a more extensive discussion regarding type errors here: https://www.reddit.com/r/haskell/comments/31m7pc/toward_better_ghc_syntax_errors/ Following to that, it was suggested that a further discussion in the GHC dev mailing list can continue about this direction (syntax errors, type errors and whatnot). -- Dan Aloni From simonpj at microsoft.com Tue Apr 7 20:51:47 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 Apr 2015 20:51:47 +0000 Subject: Validate problems on Windows Message-ID: <521bc53b3abc48fb923d26d6f4f3f6d1@DB4PR30MB030.064d.mgd.msft.net> Folks I'm getting this stuff at the end of a validate run. The test failures are at least understandable. But what's all this "traceback" stuff from Python? And "Warning:haddock-interfaces"? Simon Unexpected failures: ../../libraries/array/tests T9220 [bad stdout] (ghci) ../../libraries/base/tests/System Timeout001 [bad exit code] (normal) codeGen/should_compile debug [bad exit code] (normal) ghc-e/should_fail T9930fail [bad exit code] (normal) ghci/linking T1407 [bad stderr] (ghci) ghci/scripts T5975a [bad stderr] (ghci) ghci/scripts T9878b [bad exit code] (ghci) rts T7037 [bad stdout] (normal) stranal/should_run T10148 [bad stderr] (optasm) Unexpected stat failures: perf/compiler T5030 [stat too good] (normal) perf/compiler T5837 [stat too good] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9872d [stat not good enough] (normal) perf/should_run T9203 [stat not good enough] (normal) Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist-install/doc/html/base/base.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t' make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' == Start post-testsuite package check Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d\package.cache Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d (same as cache) using cache: C:/code/HEAD/inplace\lib\package.conf.d\package.cache db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] modifying: Nothing flag db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] Warning: haddock-interfaces: C:\code\HEAD\libraries\stm\dist-install\doc\html\stm\stm.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\parallel\dist-install\doc\html\parallel\parallel.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\compiler\stage2\doc\html\ghc\ghc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\haskeline\dist-install\doc\html\haskeline\haskeline.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\transformers\dist-install\doc\html\transformers\transformers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hoopl\dist-install\doc\html\hoopl\hoopl.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bin-package-db\dist-install\doc\html\bin-package-db\bin-package-db.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Cabal\Cabal\dist-install\doc\html\Cabal\Cabal.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\binary\dist-install\doc\html\binary\binary.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\template-haskell\dist-install\doc\html\template-haskell\template-haskell.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\pretty\dist-install\doc\html\pretty\pretty.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hpc\dist-install\doc\html\hpc\hpc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\process\dist-install\doc\html\process\process.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\directory\dist-install\doc\html\directory\directory.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\time\dist-install\doc\html\time\time.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Win32\dist-install\doc\html\Win32\Win32.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\containers\dist-install\doc\html\containers\containers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bytestring\dist-install\doc\html\bytestring\bytestring.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\deepseq\dist-install\doc\html\deepseq\deepseq.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\array\dist-install\doc\html\array\array.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\filepath\dist-install\doc\html\filepath\filepath.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\base\dist-install\doc\html\base\base.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\integer-gmp\dist-install\doc\html\integer-gmp\integer-gmp.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\ghc-prim\dist-install\doc\html\ghc-prim\ghc-prim.haddock doesn't exist or isn't a file == End post-testsuite package check -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 7 22:11:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 Apr 2015 22:11:07 +0000 Subject: Toward better syntax errors In-Reply-To: <20150407203342.GA12600@gmail.com> References: <20150407203342.GA12600@gmail.com> Message-ID: Thank Dan. I'm keen on better error messages. If you want to change Happy, though, you need talk to Simon Marlow. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dan | Aloni | Sent: 07 April 2015 21:34 | To: ghc-devs at haskell.org | Subject: Toward better syntax errors | | Hello, | | Forwarded here is a link to a blog post I authored about improving | GHC's syntax errors: | | http://blog.aloni.org/posts/toward-better-ghc-syntax-errors/ | | In fact, this came about after I started using Happy more extensively, | and at one point thought that GHC could benefit too | | The gist of it, is that it was relatively easy to reach an improvement | such as follows (notice 'possible tokens' below): | | | input: | -- | test i = case i of 2 | main = return () | | | output: | -- | example1.hs:2:1: parse error (possibly incorrect indentation or | mismatched brackets), possible tokens: '|' '->' | | | It spawned a more extensive discussion regarding type errors here: | | https://www.reddit.com/r/haskell/comments/31m7pc/toward_better_ghc_syntax | _errors/ | | Following to that, it was suggested that a further discussion in the GHC | dev mailing list can continue about this direction (syntax errors, | type errors and whatnot). | | -- | Dan Aloni | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From dan at kernelim.com Wed Apr 8 04:44:15 2015 From: dan at kernelim.com (Dan Aloni) Date: Wed, 8 Apr 2015 07:44:15 +0300 Subject: Toward better syntax errors In-Reply-To: References: <20150407203342.GA12600@gmail.com> Message-ID: <20150408044415.GA21744@gmail.com> On Tue, Apr 07, 2015 at 10:11:07PM +0000, Simon Peyton Jones wrote: > Thank Dan. I'm keen on better error messages. > > If you want to change Happy, though, you need talk to Simon Marlow. Definitely, and there has been already a pull request recently open inthe Happy github repo. The mailing list is a better platform for discussions though :) -- Dan Aloni From alan.zimm at gmail.com Wed Apr 8 10:10:54 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 8 Apr 2015 12:10:54 +0200 Subject: Flurry of late patches for 7.10.2 Message-ID: You may have noticed that I have submitted a lot of patches for the 7.10.2 release at a very late stage. I apologise for this, but it has been triggered by an exciting test conducted by Matt Pickering using the new ghc-exactprint[1] based on the API Annotations in 7.10.1 He ran it in round-trip mode over all the source files in hackage, with the following results Total: 62,741 files. Parse fails: 6,611 CPP: 4,487 (not currently processed, coming soon) So the total succesfully processed was 51,643 files. Of these, 3,042 failed to reproduce the source exactly. The patches coming in are to bring the 3,042 count down even further. Regards Alan [1] https://github.com/alanz/ghc-exactprint -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 9 07:56:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 Apr 2015 07:56:53 +0000 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: Message-ID: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 about whether the new Coercible story makes GND ok for Safe Haskell. At a type-soundness level, definitely yes. But there are other less-clear-cut issues like ?breaking abstractions? to consider. The decision on the ticket (comment:36) seems to be: GND stays out of Safe Haskell for now, but there is room for a better proposal. I don?t have an opinion myself. David Terei and David Mazieres are in the driving seat, but I?m sure they?ll be responsive to user input. However, I think the user manual may not have kept up with #8827. The sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.? vanished from the 7.8 user manual (links below). Maybe it should be restored. Safe Haskell aficionados, would you like to offer a patch for the manual? And maybe also a less drastic remedy than omitting GND altogether? Simon From: Omari Norman [mailto:omari at smileystation.com] Sent: 09 April 2015 02:44 To: haskell Cafe Subject: Generalized Newtype Deriving not allowed in Safe Haskell When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe flag, I get -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell This happens both in GHC 7.8 and GHC 7.10. I thought I remembered reading somewhere that GNTD is now part of the safe language? The GHC manual used to state that GNTD is not allowed in Safe Haskell: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language But this language on GNTD not being part of the safe language was removed in the 7.8 manual: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language The GHC release notes don't say anything about this one way or the other. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Apr 9 08:30:23 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 9 Apr 2015 10:30:23 +0200 Subject: Where are the HsTyVarBndrs collapsed in an explicit HsForAllTy? Message-ID: When parsing extremumNewton :: (Eq a, Fractional a) => (forall tag. forall tag1. Tower tag1 (Tower tag a) -> Tower tag1 (Tower tag a)) -> a -> [a] the nested `forall` declarations are parsed by ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (sLL $1 $> $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } This generates a HsForAllTy for the first forall that simply wraps the second one, which is also a `ctypedoc`. But, when looking at the AST provided via ParsedSource, the two `forall`s are collapsed into a single one, containing both `tag` and `tag1` in the TyVarBndrs. In the process the annotation for the second forall loses its anchor, as that span is no longer in the AST. I cannot find where this collapsing takes place, can anyone point me at it? Thanks Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Thu Apr 9 18:14:26 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Thu, 9 Apr 2015 18:14:26 +0000 Subject: =?utf-8?Q?Advice_on_replacing_ghc-split?= Message-ID: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com> Hi All, I have been working on creating a Haskell replacement for the perl script ghc-split. The issue I need some advice on is that the perl script is 280 SLOC primarily because of the use of RegExpr. The problem I have is that It seems i?m limited to only packages that are available already because GHC needs them (since it seems to compile using the in-place cabal and pkg list, am I correct here?). So I see my options as follows: Inline one of the regexp libraries, e.g. pcre-light Create my own string matching functions (possibly a simple DFA and encode the rexexpr into that) Use parsec (which I think is available as part of the ghc build no?) Does anyone have an idea on what the best approach would be? The regexpr don?t seem to use any perl extensions, so normal posix regex would be fine, I thought Base contained a regexp component. But it seems that?s now a separate library? Kind Regards, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Apr 9 20:56:50 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 9 Apr 2015 22:56:50 +0200 Subject: Advice on replacing ghc-split In-Reply-To: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com> References: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com> Message-ID: Hi, On 9 April 2015 at 20:14, Tamar Christina wrote: > [...] > > So I see my options as follows: > > Inline one of the regexp libraries, e.g. pcre-light > [...] When LLVM developers were faced with a similar issue [1], they decided to use OpenBSD's regex implementation [2,3]. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html [2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html [3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html From alan.zimm at gmail.com Thu Apr 9 21:15:15 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 9 Apr 2015 23:15:15 +0200 Subject: Collapsing HsForAllTy, again Message-ID: With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 9 22:14:02 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 Apr 2015 22:14:02 +0000 Subject: Collapsing HsForAllTy, again In-Reply-To: References: Message-ID: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Hmm. I?m not sure what the motivation is either. Try dropping it out and see if anything goes wrong. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 09 April 2015 22:15 To: ghc-devs at haskell.org Subject: Collapsing HsForAllTy, again With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Fri Apr 10 03:32:35 2015 From: lonetiger at gmail.com (Tamar Christina) Date: Thu, 9 Apr 2015 20:32:35 -0700 Subject: Advice on replacing ghc-split Message-ID: <7940687690104868991@unknownmsgid> Thanks Mikhail, I'll read through the threads. Cheers, TamarFrom: Mikhail Glushenkov Sent: ?09/?04/?2015 22:56 To: Tamar Christina Cc: GHC Subject: Re: Advice on replacing ghc-split Hi, On 9 April 2015 at 20:14, Tamar Christina wrote: > [...] > > So I see my options as follows: > > Inline one of the regexp libraries, e.g. pcre-light > [...] When LLVM developers were faced with a similar issue [1], they decided to use OpenBSD's regex implementation [2,3]. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html [2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html [3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html From alan.zimm at gmail.com Fri Apr 10 07:01:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 10 Apr 2015 09:01:52 +0200 Subject: Collapsing HsForAllTy, again In-Reply-To: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: If I replace it with mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName -- Smart constructor for HsForAllTy -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) cleanCtxt ty where -- Separate the extra-constraints wildcard when present (cleanCtxt, extra) | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l) | otherwise = (ctxt, Nothing) ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here ignoreParens ty = ty I get the following errors in the stage 2 compile (only first 3 shown here) libraries/ghc-prim/GHC/Classes.hs:52:19: Malformed instance: (Eq a, Eq b) => Eq (a, b) libraries/ghc-prim/GHC/Classes.hs:53:19: Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) libraries/ghc-prim/GHC/Classes.hs:54:19: Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) Alan On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones wrote: > Hmm. I?m not sure what the motivation is either. Try dropping it out > and see if anything goes wrong. > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 09 April 2015 22:15 > *To:* ghc-devs at haskell.org > *Subject:* Collapsing HsForAllTy, again > > > > With the help of Jan Stolarek I tracked down the HsForAllTy flattening to > `HsTypes.mk_forall_ty`. > > This function takes any nested HsForAllTy's where the top one does not > have a context defined, and collapses them into a single one. > > I do not know what the motivation for this is, and if it perhaps speeds up > or simplifies further compilation. > > But now that API Annotations have arrived, making sure we do not lose the > annotations for the sub-HsForAllTy causes significant gymnastics in the > parser [1]. > > So my question is, is there a good reason to continue doing this, given > the trade-off in parser complexity. > > Regards > > Alan > > [1] https://phabricator.haskell.org/D833 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Apr 10 08:13:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 10 Apr 2015 08:13:53 +0000 Subject: Collapsing HsForAllTy, again In-Reply-To: References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Look at how instance declarations are parsed. If you look at Parser.y you?ll see that for instance (Eq a, Eq b) => Eq (a,b) we get (in effect) mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b)) The outer mkImplicit.. is to ensure that there is always, in the end, a HsForAllTy around the whole thing, even around instance Eq a say. But we don?t actually want two nested HsForAllTys. mk_forall_ty collapsed the two. But you don?t want that either. So I think you should make mkImplictHsForAllTy do the test instead. Its goal is to wrap a HsForallTy if there isn?t one already. So mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty) = HsForAllTy exp? tvs cxt ty where exp? = case exp of Qualified -> Implicit _ -> exp mkImplicitHsForAllTy ty = mkHsForAllTy Implicit [] (L loc _) ty should do the job. Incidentally, mkImplicitHsForAllTy should not take a ctxt argument. If you have a non-empty context, use mkQualifiedHsForAllTy. That means that in Convert you?ll need to use mkHsForAllTy Implicit ctxt ty? instead of mkImplicitHsForAllTy Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 10 April 2015 08:02 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Collapsing HsForAllTy, again If I replace it with mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName -- Smart constructor for HsForAllTy -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) cleanCtxt ty where -- Separate the extra-constraints wildcard when present (cleanCtxt, extra) | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l) | otherwise = (ctxt, Nothing) ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here ignoreParens ty = ty I get the following errors in the stage 2 compile (only first 3 shown here) libraries/ghc-prim/GHC/Classes.hs:52:19: Malformed instance: (Eq a, Eq b) => Eq (a, b) libraries/ghc-prim/GHC/Classes.hs:53:19: Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) libraries/ghc-prim/GHC/Classes.hs:54:19: Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) Alan On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones > wrote: Hmm. I?m not sure what the motivation is either. Try dropping it out and see if anything goes wrong. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 09 April 2015 22:15 To: ghc-devs at haskell.org Subject: Collapsing HsForAllTy, again With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.terei at gmail.com Fri Apr 10 08:37:57 2015 From: dave.terei at gmail.com (David Terei) Date: Fri, 10 Apr 2015 01:37:57 -0700 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I'll prepare a patch for the userguide soon. As for something better, yes I think we can and should. It's on my todo list :) Basically, the new-GND design has all the mechanisms to be safe, but sadly the defaults are rather worrying. Without explicit annotations from the user, module abstractions are broken. This is why we left GND out of Safe Haskell for the moment as it is a subtle and easy mistake to make. If the module contained explicit role annotations then it could be allowed. The discussion in https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I prefer, such as only exporting the Coerce instance if all the constructors are exported, it seems that the ship sailed on these bigger changes sadly. Cheers, David On 9 April 2015 at 00:56, Simon Peyton Jones wrote: > There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 > about whether the new Coercible story makes GND ok for Safe Haskell. At a > type-soundness level, definitely yes. But there are other less-clear-cut > issues like ?breaking abstractions? to consider. The decision on the ticket > (comment:36) seems to be: GND stays out of Safe Haskell for now, but there > is room for a better proposal. > > > > I don?t have an opinion myself. David Terei and David Mazieres are in the > driving seat, but I?m sure they?ll be responsive to user input. > > > > However, I think the user manual may not have kept up with #8827. The > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor > access control, by allowing untrusted code to manipulate protected data > types in ways the data type author did not intend, breaking invariants they > have established.? vanished from the 7.8 user manual (links below). Maybe > it should be restored. > > > > Safe Haskell aficionados, would you like to offer a patch for the manual? > And maybe also a less drastic remedy than omitting GND altogether? > > > > Simon > > > > From: Omari Norman [mailto:omari at smileystation.com] > Sent: 09 April 2015 02:44 > To: haskell Cafe > Subject: Generalized Newtype Deriving not allowed in Safe Haskell > > > > When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe > flag, I get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. > > > > I thought I remembered reading somewhere that GNTD is now part of the safe > language? The GHC manual used to state that GNTD is not allowed in Safe > Haskell: > > > > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language > > > > But this language on GNTD not being part of the safe language was removed in > the 7.8 manual: > > > > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language > > > > The GHC release notes don't say anything about this one way or the other. > Thoughts? > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Fri Apr 10 08:48:52 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 10 Apr 2015 08:48:52 +0000 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: | prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these Coercible is relatively recent; I don't think we should regard it as cast in stone. But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope. Simon | -----Original Message----- | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of | David Terei | Sent: 10 April 2015 09:38 | To: Simon Peyton Jones | Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | I'll prepare a patch for the userguide soon. | | As for something better, yes I think we can and should. It's on my todo | list :) Basically, the new-GND design has all the mechanisms to be | safe, but sadly the defaults are rather worrying. Without explicit | annotations from the user, module abstractions are broken. This is why | we left GND out of Safe Haskell for the moment as it is a subtle and | easy mistake to make. | | If the module contained explicit role annotations then it could be | allowed. The discussion in | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I | prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these | bigger changes sadly. | | Cheers, | David | | On 9 April 2015 at 00:56, Simon Peyton Jones | wrote: | > There is a long discussion on | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > about whether the new Coercible story makes GND ok for Safe Haskell. | > At a type-soundness level, definitely yes. But there are other | > less-clear-cut issues like ?breaking abstractions? to consider. The | > decision on the ticket | > (comment:36) seems to be: GND stays out of Safe Haskell for now, but | > there is room for a better proposal. | > | > | > | > I don?t have an opinion myself. David Terei and David Mazieres are in | > the driving seat, but I?m sure they?ll be responsive to user input. | > | > | > | > However, I think the user manual may not have kept up with #8827. | The | > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate | > constructor access control, by allowing untrusted code to manipulate | > protected data types in ways the data type author did not intend, | > breaking invariants they have established.? vanished from the 7.8 | > user manual (links below). Maybe it should be restored. | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for the | manual? | > And maybe also a less drastic remedy than omitting GND altogether? | > | > | > | > Simon | > | > | > | > From: Omari Norman [mailto:omari at smileystation.com] | > Sent: 09 April 2015 02:44 | > To: haskell Cafe | > Subject: Generalized Newtype Deriving not allowed in Safe Haskell | > | > | > | > When compiling code with Generalized Newtype Deriving and the | > -fwarn-unsafe flag, I get | > | > | > | > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell | > | > | > | > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > I thought I remembered reading somewhere that GNTD is now part of the | > safe language? The GHC manual used to state that GNTD is not allowed | > in Safe | > Haskell: | > | > | > | > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > But this language on GNTD not being part of the safe language was | > removed in the 7.8 manual: | > | > | > | > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > The GHC release notes don't say anything about this one way or the | other. | > Thoughts? | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > From alan.zimm at gmail.com Fri Apr 10 09:30:21 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 10 Apr 2015 11:30:21 +0200 Subject: API Annotations, MINIMAL pragma and BooleanFormula Message-ID: My last (known) issue is the MINIMAL pragma for a class definition. In Parser.y this is captured (via `name_boolformula`) as a BooleanFormula (Located RdrName) There is a problem with this from an API annotations point of view in that the constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the boolean formula as it is constructed. Unfortunately this discards information in the process. I see a number of potential solutions a. Capture the original source string for the pragma, and use that for the annotations. This is a bad option. b. Introduce a new variant of BooleanFormula for the AST, and convert to use the current one when evaluating the pragma. c. Keep the BooleanFormula as it is, but do not minimise the formula on construction. I suspect that c is the best option, I do not believe the formulas constructed are particularly complex or numerous, so early optimisation is not necessary. Which is the best option? Or is there a different one? Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Apr 10 11:11:48 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 10 Apr 2015 13:11:48 +0200 Subject: Collapsing HsForAllTy, again In-Reply-To: References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: It looks like splitLHsForAllTy :: LHsType name -> (LHsTyVarBndrs name, HsContext name, LHsType name) splitLHsForAllTy poly_ty = case unLoc poly_ty of HsParTy ty -> splitLHsForAllTy ty HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty) _ -> (emptyHsQTvs, [], poly_ty) -- The type vars should have been computed by now, even if they were implicit needs a recursive call for the HsForAllTy case, it now generates libraries/base/Data/Monoid.hs:217:10: Malformed instance: forall f a. Alternative f => Monoid (Alt f a) Alan On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones wrote: > Look at how instance declarations are parsed. If you look at Parser.y > you?ll see that for > > > > instance (Eq a, Eq b) => Eq (a,b) > > > > we get (in effect) > > > > mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b)) > > > > The outer mkImplicit.. is to ensure that there is always, in the end, a > HsForAllTy around the whole thing, even around > > instance Eq a > > say. > > > > But we don?t actually want two nested HsForAllTys. mk_forall_ty collapsed > the two. > > > > But you don?t want that either. So I think you should make > mkImplictHsForAllTy do the test instead. Its goal is to wrap a HsForallTy > if there isn?t one already. So > > > > mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty) > > = HsForAllTy exp? tvs cxt ty > > where > > exp? = case exp of > > Qualified -> Implicit > > _ -> exp > > mkImplicitHsForAllTy ty = mkHsForAllTy Implicit [] (L loc _) ty > > > > should do the job. > > > > Incidentally, mkImplicitHsForAllTy should not take a ctxt argument. If > you have a non-empty context, use mkQualifiedHsForAllTy. That means that > in Convert you?ll need to use > > mkHsForAllTy Implicit ctxt ty? > > instead of mkImplicitHsForAllTy > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 10 April 2015 08:02 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Collapsing HsForAllTy, again > > > > If I replace it with > > > mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext > RdrName -> LHsType RdrName -> HsType RdrName > -- Smart constructor for HsForAllTy > -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty > mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) > (L noSrcSpan []) ty > mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) > cleanCtxt ty > where -- Separate the extra-constraints wildcard when present > (cleanCtxt, extra) > | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init > `fmap` ctxt, Just l) > | otherwise = (ctxt, Nothing) > ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the > annotation here > ignoreParens ty = ty > > > I get the following errors in the stage 2 compile (only first 3 shown here) > > > libraries/ghc-prim/GHC/Classes.hs:52:19: > Malformed instance: (Eq a, Eq b) => Eq (a, b) > > libraries/ghc-prim/GHC/Classes.hs:53:19: > Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) > > libraries/ghc-prim/GHC/Classes.hs:54:19: > Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) > > > Alan > > > > On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Hmm. I?m not sure what the motivation is either. Try dropping it out > and see if anything goes wrong. > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 09 April 2015 22:15 > *To:* ghc-devs at haskell.org > *Subject:* Collapsing HsForAllTy, again > > > > With the help of Jan Stolarek I tracked down the HsForAllTy flattening to > `HsTypes.mk_forall_ty`. > > This function takes any nested HsForAllTy's where the top one does not > have a context defined, and collapses them into a single one. > > I do not know what the motivation for this is, and if it perhaps speeds up > or simplifies further compilation. > > But now that API Annotations have arrived, making sure we do not lose the > annotations for the sub-HsForAllTy causes significant gymnastics in the > parser [1]. > > So my question is, is there a good reason to continue doing this, given > the trade-off in parser complexity. > > Regards > > Alan > > [1] https://phabricator.haskell.org/D833 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Apr 10 12:05:21 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 10 Apr 2015 14:05:21 +0200 Subject: Collapsing HsForAllTy, again In-Reply-To: References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: And once the splitLHsForAllTy is sorted, this tc_inst_head :: HsType Name -> TcM TcType tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty) = tcHsTyVarBndrs hs_tvs $ \ tvs -> do { ctxt <- tcHsContext hs_ctxt ; ty <- tc_lhs_type hs_ty ekConstraint -- Body for forall has kind Constraint ; return (mkSigmaTy tvs ctxt ty) } results in libraries/base/Data/Monoid.hs:217:23: Illegal constraint: Alternative f => Monoid (Alt f a) In the instance declaration for ?Alternative f => Monoid (Alt f a)? Alan On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman wrote: > It looks like > > splitLHsForAllTy > :: LHsType name > -> (LHsTyVarBndrs name, HsContext name, LHsType name) > splitLHsForAllTy poly_ty > = case unLoc poly_ty of > HsParTy ty -> splitLHsForAllTy ty > HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty) > _ -> (emptyHsQTvs, [], poly_ty) > -- The type vars should have been computed by now, even if they > were implicit > > needs a recursive call for the HsForAllTy case, it now generates > > libraries/base/Data/Monoid.hs:217:10: > Malformed instance: forall f a. Alternative f => Monoid (Alt f a) > > > Alan > > On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > >> Look at how instance declarations are parsed. If you look at Parser.y >> you?ll see that for >> >> >> >> instance (Eq a, Eq b) => Eq (a,b) >> >> >> >> we get (in effect) >> >> >> >> mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b)) >> >> >> >> The outer mkImplicit.. is to ensure that there is always, in the end, a >> HsForAllTy around the whole thing, even around >> >> instance Eq a >> >> say. >> >> >> >> But we don?t actually want two nested HsForAllTys. mk_forall_ty >> collapsed the two. >> >> >> >> But you don?t want that either. So I think you should make >> mkImplictHsForAllTy do the test instead. Its goal is to wrap a HsForallTy >> if there isn?t one already. So >> >> >> >> mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty) >> >> = HsForAllTy exp? tvs cxt ty >> >> where >> >> exp? = case exp of >> >> Qualified -> Implicit >> >> _ -> exp >> >> mkImplicitHsForAllTy ty = mkHsForAllTy Implicit [] (L loc _) ty >> >> >> >> should do the job. >> >> >> >> Incidentally, mkImplicitHsForAllTy should not take a ctxt argument. If >> you have a non-empty context, use mkQualifiedHsForAllTy. That means that >> in Convert you?ll need to use >> >> mkHsForAllTy Implicit ctxt ty? >> >> instead of mkImplicitHsForAllTy >> >> >> >> Simon >> >> >> >> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] >> *Sent:* 10 April 2015 08:02 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: Collapsing HsForAllTy, again >> >> >> >> If I replace it with >> >> >> mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext >> RdrName -> LHsType RdrName -> HsType RdrName >> -- Smart constructor for HsForAllTy >> -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty >> mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) >> (L noSrcSpan []) ty >> mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) >> cleanCtxt ty >> where -- Separate the extra-constraints wildcard when present >> (cleanCtxt, extra) >> | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = >> (init `fmap` ctxt, Just l) >> | otherwise = (ctxt, Nothing) >> ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the >> annotation here >> ignoreParens ty = ty >> >> >> I get the following errors in the stage 2 compile (only first 3 shown >> here) >> >> >> libraries/ghc-prim/GHC/Classes.hs:52:19: >> Malformed instance: (Eq a, Eq b) => Eq (a, b) >> >> libraries/ghc-prim/GHC/Classes.hs:53:19: >> Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) >> >> libraries/ghc-prim/GHC/Classes.hs:54:19: >> Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) >> >> >> Alan >> >> >> >> On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> Hmm. I?m not sure what the motivation is either. Try dropping it out >> and see if anything goes wrong. >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan >> & Kim Zimmerman >> *Sent:* 09 April 2015 22:15 >> *To:* ghc-devs at haskell.org >> *Subject:* Collapsing HsForAllTy, again >> >> >> >> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to >> `HsTypes.mk_forall_ty`. >> >> This function takes any nested HsForAllTy's where the top one does not >> have a context defined, and collapses them into a single one. >> >> I do not know what the motivation for this is, and if it perhaps speeds >> up or simplifies further compilation. >> >> But now that API Annotations have arrived, making sure we do not lose the >> annotations for the sub-HsForAllTy causes significant gymnastics in the >> parser [1]. >> >> So my question is, is there a good reason to continue doing this, given >> the trade-off in parser complexity. >> >> Regards >> >> Alan >> >> [1] https://phabricator.haskell.org/D833 >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Apr 10 12:07:05 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 10 Apr 2015 13:07:05 +0100 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <86F7E6C0-6CD5-40CD-BAF9-1CA07FA80872@cis.upenn.edu> Here's an idea: For a module to be Safe, then for each exported datatype, one of the following must hold: 1) The datatype comes with a role annotation. 2) The module exports all of the datatype's constructors. 3) If the datatype is defined in a place other than the current module, the current module exports no fewer data constructors than are exported in the datatype's defining module. Why? 1) The role annotation, even if it has no effect, shows that the programmer has considered roles. Any mistake here is clearly the programmer's fault. 2) This datatype is clearly meant not to be abstract. `Coercible` then gives clients no more power than they already have. 3) This is subtler. It is a common idiom to export a datatype's constructors from a package-internal module, but then never to export the constructors beyond the package. If such a datatype has a role annotation (in its defining module, of course), then we're fine, even if it is exported abstractly later. However, suppose we are abstractly re-exporting a datatype that exports its constructors from its defining module. If there is no role annotation on the datatype, we're in trouble and should fail. BUT, if the datatype were exported abstractly in its defining module, then we don't need to fail on re-export, because nothing has changed. Actually, we could simplify the conditions. Change (2) to: 2') The module exports all of the datatype's visible constructors. I think explaining in terms of separate rules (2) and (3) is a little clearer, because the re-export case is slightly subtle, and this subtlety can be lost in (2'). This proposal would require tracking (in interface files, too) whether or not a datatype comes with a role annotation. This isn't hard, though. It might even help in pretty-printing. An alternative would be to have a way of setting roles differently on export than internally. I don't think this breaks the type system, but it's yet another thing to specify and support. And we'd have to consider the possibility that some module will import a datatype from multiple re-exporting modules, each with different ascribed role annotations. Is this an error? Does GHC take some sort of least upper bound? I prefer not to go here, but there's nothing terribly wrong with this approach. Richard On Apr 10, 2015, at 9:37 AM, David Terei wrote: > I'll prepare a patch for the userguide soon. > > As for something better, yes I think we can and should. It's on my > todo list :) Basically, the new-GND design has all the mechanisms to > be safe, but sadly the defaults are rather worrying. Without explicit > annotations from the user, module abstractions are broken. This is why > we left GND out of Safe Haskell for the moment as it is a subtle and > easy mistake to make. > > If the module contained explicit role annotations then it could be > allowed. The discussion in > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that > I prefer, such as only exporting the Coerce instance if all the > constructors are exported, it seems that the ship sailed on these > bigger changes sadly. > > Cheers, > David > > On 9 April 2015 at 00:56, Simon Peyton Jones wrote: >> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 >> about whether the new Coercible story makes GND ok for Safe Haskell. At a >> type-soundness level, definitely yes. But there are other less-clear-cut >> issues like ?breaking abstractions? to consider. The decision on the ticket >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there >> is room for a better proposal. >> >> >> >> I don?t have an opinion myself. David Terei and David Mazieres are in the >> driving seat, but I?m sure they?ll be responsive to user input. >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor >> access control, by allowing untrusted code to manipulate protected data >> types in ways the data type author did not intend, breaking invariants they >> have established.? vanished from the 7.8 user manual (links below). Maybe >> it should be restored. >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the manual? >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> Simon >> >> >> >> From: Omari Norman [mailto:omari at smileystation.com] >> Sent: 09 April 2015 02:44 >> To: haskell Cafe >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe >> flag, I get >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the safe >> language? The GHC manual used to state that GNTD is not allowed in Safe >> Haskell: >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language >> >> >> >> But this language on GNTD not being part of the safe language was removed in >> the 7.8 manual: >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language >> >> >> >> The GHC release notes don't say anything about this one way or the other. >> Thoughts? >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Fri Apr 10 12:08:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 10 Apr 2015 12:08:43 +0000 Subject: Collapsing HsForAllTy, again In-Reply-To: References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net> You are describing code I cannot see. Can you perhaps just work out what is happening and fix it? Nothing very deep is here, I think. If you get really stuck and cannot make progress then put it in a Phab patch and I will try to look. But I?m struggling with time at the moment. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 10 April 2015 13:05 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Collapsing HsForAllTy, again And once the splitLHsForAllTy is sorted, this tc_inst_head :: HsType Name -> TcM TcType tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty) = tcHsTyVarBndrs hs_tvs $ \ tvs -> do { ctxt <- tcHsContext hs_ctxt ; ty <- tc_lhs_type hs_ty ekConstraint -- Body for forall has kind Constraint ; return (mkSigmaTy tvs ctxt ty) } results in libraries/base/Data/Monoid.hs:217:23: Illegal constraint: Alternative f => Monoid (Alt f a) In the instance declaration for ?Alternative f => Monoid (Alt f a)? Alan On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman > wrote: It looks like splitLHsForAllTy :: LHsType name -> (LHsTyVarBndrs name, HsContext name, LHsType name) splitLHsForAllTy poly_ty = case unLoc poly_ty of HsParTy ty -> splitLHsForAllTy ty HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty) _ -> (emptyHsQTvs, [], poly_ty) -- The type vars should have been computed by now, even if they were implicit needs a recursive call for the HsForAllTy case, it now generates libraries/base/Data/Monoid.hs:217:10: Malformed instance: forall f a. Alternative f => Monoid (Alt f a) Alan On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones > wrote: Look at how instance declarations are parsed. If you look at Parser.y you?ll see that for instance (Eq a, Eq b) => Eq (a,b) we get (in effect) mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b)) The outer mkImplicit.. is to ensure that there is always, in the end, a HsForAllTy around the whole thing, even around instance Eq a say. But we don?t actually want two nested HsForAllTys. mk_forall_ty collapsed the two. But you don?t want that either. So I think you should make mkImplictHsForAllTy do the test instead. Its goal is to wrap a HsForallTy if there isn?t one already. So mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty) = HsForAllTy exp? tvs cxt ty where exp? = case exp of Qualified -> Implicit _ -> exp mkImplicitHsForAllTy ty = mkHsForAllTy Implicit [] (L loc _) ty should do the job. Incidentally, mkImplicitHsForAllTy should not take a ctxt argument. If you have a non-empty context, use mkQualifiedHsForAllTy. That means that in Convert you?ll need to use mkHsForAllTy Implicit ctxt ty? instead of mkImplicitHsForAllTy Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 10 April 2015 08:02 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Collapsing HsForAllTy, again If I replace it with mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName -- Smart constructor for HsForAllTy -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) cleanCtxt ty where -- Separate the extra-constraints wildcard when present (cleanCtxt, extra) | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l) | otherwise = (ctxt, Nothing) ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here ignoreParens ty = ty I get the following errors in the stage 2 compile (only first 3 shown here) libraries/ghc-prim/GHC/Classes.hs:52:19: Malformed instance: (Eq a, Eq b) => Eq (a, b) libraries/ghc-prim/GHC/Classes.hs:53:19: Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) libraries/ghc-prim/GHC/Classes.hs:54:19: Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) Alan On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones > wrote: Hmm. I?m not sure what the motivation is either. Try dropping it out and see if anything goes wrong. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 09 April 2015 22:15 To: ghc-devs at haskell.org Subject: Collapsing HsForAllTy, again With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Apr 10 12:31:01 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 10 Apr 2015 14:31:01 +0200 Subject: Collapsing HsForAllTy, again In-Reply-To: <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net> References: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net> <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Ok, I am making progress, when it is done I will put up a patch. I figured I was probably posting too much, sorry all. Alan On Fri, Apr 10, 2015 at 2:08 PM, Simon Peyton Jones wrote: > You are describing code I cannot see. Can you perhaps just work out > what is happening and fix it? Nothing very deep is here, I think. If you > get really stuck and cannot make progress then put it in a Phab patch and I > will try to look. But I?m struggling with time at the moment. > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 10 April 2015 13:05 > > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Collapsing HsForAllTy, again > > > > And once the splitLHsForAllTy is sorted, this > > tc_inst_head :: HsType Name -> TcM TcType > tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty) > = tcHsTyVarBndrs hs_tvs $ \ tvs -> > do { ctxt <- tcHsContext hs_ctxt > ; ty <- tc_lhs_type hs_ty ekConstraint -- Body for forall has > kind Constraint > ; return (mkSigmaTy tvs ctxt ty) } > > results in > > libraries/base/Data/Monoid.hs:217:23: > Illegal constraint: Alternative f => Monoid (Alt f a) > In the instance declaration for ?Alternative f => Monoid (Alt f a)? > > Alan > > > > On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman > wrote: > > It looks like > > splitLHsForAllTy > :: LHsType name > -> (LHsTyVarBndrs name, HsContext name, LHsType name) > splitLHsForAllTy poly_ty > = case unLoc poly_ty of > HsParTy ty -> splitLHsForAllTy ty > HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty) > _ -> (emptyHsQTvs, [], poly_ty) > -- The type vars should have been computed by now, even if they > were implicit > > needs a recursive call for the HsForAllTy case, it now generates > > libraries/base/Data/Monoid.hs:217:10: > Malformed instance: forall f a. Alternative f => Monoid (Alt f a) > > Alan > > > > On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Look at how instance declarations are parsed. If you look at Parser.y > you?ll see that for > > > > instance (Eq a, Eq b) => Eq (a,b) > > > > we get (in effect) > > > > mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b)) > > > > The outer mkImplicit.. is to ensure that there is always, in the end, a > HsForAllTy around the whole thing, even around > > instance Eq a > > say. > > > > But we don?t actually want two nested HsForAllTys. mk_forall_ty collapsed > the two. > > > > But you don?t want that either. So I think you should make > mkImplictHsForAllTy do the test instead. Its goal is to wrap a HsForallTy > if there isn?t one already. So > > > > mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty) > > = HsForAllTy exp? tvs cxt ty > > where > > exp? = case exp of > > Qualified -> Implicit > > _ -> exp > > mkImplicitHsForAllTy ty = mkHsForAllTy Implicit [] (L loc _) ty > > > > should do the job. > > > > Incidentally, mkImplicitHsForAllTy should not take a ctxt argument. If > you have a non-empty context, use mkQualifiedHsForAllTy. That means that > in Convert you?ll need to use > > mkHsForAllTy Implicit ctxt ty? > > instead of mkImplicitHsForAllTy > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 10 April 2015 08:02 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Collapsing HsForAllTy, again > > > > If I replace it with > > > mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext > RdrName -> LHsType RdrName -> HsType RdrName > -- Smart constructor for HsForAllTy > -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty > mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) > (L noSrcSpan []) ty > mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) > cleanCtxt ty > where -- Separate the extra-constraints wildcard when present > (cleanCtxt, extra) > | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init > `fmap` ctxt, Just l) > | otherwise = (ctxt, Nothing) > ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the > annotation here > ignoreParens ty = ty > > > I get the following errors in the stage 2 compile (only first 3 shown here) > > > libraries/ghc-prim/GHC/Classes.hs:52:19: > Malformed instance: (Eq a, Eq b) => Eq (a, b) > > libraries/ghc-prim/GHC/Classes.hs:53:19: > Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c) > > libraries/ghc-prim/GHC/Classes.hs:54:19: > Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d) > > Alan > > > > On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Hmm. I?m not sure what the motivation is either. Try dropping it out > and see if anything goes wrong. > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 09 April 2015 22:15 > *To:* ghc-devs at haskell.org > *Subject:* Collapsing HsForAllTy, again > > > > With the help of Jan Stolarek I tracked down the HsForAllTy flattening to > `HsTypes.mk_forall_ty`. > > This function takes any nested HsForAllTy's where the top one does not > have a context defined, and collapses them into a single one. > > I do not know what the motivation for this is, and if it perhaps speeds up > or simplifies further compilation. > > But now that API Annotations have arrived, making sure we do not lose the > annotations for the sub-HsForAllTy causes significant gymnastics in the > parser [1]. > > So my question is, is there a good reason to continue doing this, given > the trade-off in parser complexity. > > Regards > > Alan > > [1] https://phabricator.haskell.org/D833 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Apr 10 22:54:18 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 10 Apr 2015 18:54:18 -0400 Subject: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> <86F7E6C0-6CD5-40CD-BAF9-1CA07FA80872@cis.upenn.edu> Message-ID: I think a module exporting some but not all data constructors of a type is fundamentally broken behavior. I would generally be in favor of prohibiting it altogether, and I would be strongly opposed to letting continued support for it break anything else. On Apr 10, 2015 9:05 AM, "Douglas McClean" wrote: > I don't think that 2+3 is equivalent to 2', because an explicit import > list or hiding list could've brought only some of the datatype's > constructors into visibility. > > On Fri, Apr 10, 2015 at 8:07 AM, Richard Eisenberg > wrote: > >> Here's an idea: For a module to be Safe, then for each exported datatype, >> one of the following must hold: >> 1) The datatype comes with a role annotation. >> 2) The module exports all of the datatype's constructors. >> 3) If the datatype is defined in a place other than the current module, >> the current module exports no fewer data constructors than are exported in >> the datatype's defining module. >> >> Why? >> 1) The role annotation, even if it has no effect, shows that the >> programmer has considered roles. Any mistake here is clearly the >> programmer's fault. >> 2) This datatype is clearly meant not to be abstract. `Coercible` then >> gives clients no more power than they already have. >> 3) This is subtler. It is a common idiom to export a datatype's >> constructors from a package-internal module, but then never to export the >> constructors beyond the package. If such a datatype has a role annotation >> (in its defining module, of course), then we're fine, even if it is >> exported abstractly later. However, suppose we are abstractly re-exporting >> a datatype that exports its constructors from its defining module. If there >> is no role annotation on the datatype, we're in trouble and should fail. >> BUT, if the datatype were exported abstractly in its defining module, then >> we don't need to fail on re-export, because nothing has changed. >> >> >> Actually, we could simplify the conditions. Change (2) to: >> >> 2') The module exports all of the datatype's visible constructors. >> >> I think explaining in terms of separate rules (2) and (3) is a little >> clearer, because the re-export case is slightly subtle, and this subtlety >> can be lost in (2'). >> >> This proposal would require tracking (in interface files, too) whether or >> not a datatype comes with a role annotation. This isn't hard, though. It >> might even help in pretty-printing. >> >> >> An alternative would be to have a way of setting roles differently on >> export than internally. I don't think this breaks the type system, but it's >> yet another thing to specify and support. And we'd have to consider the >> possibility that some module will import a datatype from multiple >> re-exporting modules, each with different ascribed role annotations. Is >> this an error? Does GHC take some sort of least upper bound? I prefer not >> to go here, but there's nothing terribly wrong with this approach. >> >> Richard >> >> On Apr 10, 2015, at 9:37 AM, David Terei wrote: >> >> > I'll prepare a patch for the userguide soon. >> > >> > As for something better, yes I think we can and should. It's on my >> > todo list :) Basically, the new-GND design has all the mechanisms to >> > be safe, but sadly the defaults are rather worrying. Without explicit >> > annotations from the user, module abstractions are broken. This is why >> > we left GND out of Safe Haskell for the moment as it is a subtle and >> > easy mistake to make. >> > >> > If the module contained explicit role annotations then it could be >> > allowed. The discussion in >> > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that >> > I prefer, such as only exporting the Coerce instance if all the >> > constructors are exported, it seems that the ship sailed on these >> > bigger changes sadly. >> > >> > Cheers, >> > David >> > >> > On 9 April 2015 at 00:56, Simon Peyton Jones >> wrote: >> >> There is a long discussion on >> https://ghc.haskell.org/trac/ghc/ticket/8827 >> >> about whether the new Coercible story makes GND ok for Safe Haskell. >> At a >> >> type-soundness level, definitely yes. But there are other >> less-clear-cut >> >> issues like ?breaking abstractions? to consider. The decision on the >> ticket >> >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but >> there >> >> is room for a better proposal. >> >> >> >> >> >> >> >> I don?t have an opinion myself. David Terei and David Mazieres are in >> the >> >> driving seat, but I?m sure they?ll be responsive to user input. >> >> >> >> >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> >> sentence ?GeneralizedNewtypeDeriving ? It can be used to violate >> constructor >> >> access control, by allowing untrusted code to manipulate protected data >> >> types in ways the data type author did not intend, breaking invariants >> they >> >> have established.? vanished from the 7.8 user manual (links below). >> Maybe >> >> it should be restored. >> >> >> >> >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the >> manual? >> >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Omari Norman [mailto:omari at smileystation.com] >> >> Sent: 09 April 2015 02:44 >> >> To: haskell Cafe >> >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> >> >> >> >> When compiling code with Generalized Newtype Deriving and the >> -fwarn-unsafe >> >> flag, I get >> >> >> >> >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the >> safe >> >> language? The GHC manual used to state that GNTD is not allowed in >> Safe >> >> Haskell: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language >> >> >> >> >> >> >> >> But this language on GNTD not being part of the safe language was >> removed in >> >> the 7.8 manual: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language >> >> >> >> >> >> >> >> The GHC release notes don't say anything about this one way or the >> other. >> >> Thoughts? >> >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > J. Douglas McClean > > (781) 561-5540 (cell) > > _______________________________________________ > 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 marlowsd at gmail.com Sat Apr 11 20:26:48 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 11 Apr 2015 21:26:48 +0100 Subject: stack traces when debugging GHC In-Reply-To: References: Message-ID: <55298388.7040502@gmail.com> On 09/02/2015 02:51, Richard Eisenberg wrote: > Hi devs, > > I've just made a miraculous discovery and I want to share! > > It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). > > And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I should have advertised this more widely, thanks for pointing it out. > I'd love to put this on the wiki. Any clue where this might be found? I see you've added a reference buried in Debugging/Compiler. Why don't we just make traceStack the default? Perhaps with a flag to disable (or enable) the stack trace. Cheers, Simon From moritz at lichtzwerge.de Sat Apr 11 23:39:29 2015 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Sun, 12 Apr 2015 07:39:29 +0800 Subject: stack traces when debugging GHC In-Reply-To: <55298388.7040502@gmail.com> References: <55298388.7040502@gmail.com> Message-ID: <19256E3C-E94A-4190-93FF-7DC99493A239@lichtzwerge.de> > On 12 Apr 2015, at 04:26, Simon Marlow wrote: > >> On 09/02/2015 02:51, Richard Eisenberg wrote: >> Hi devs, >> >> I've just made a miraculous discovery and I want to share! >> >> It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). >> >> And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! > > I should have advertised this more widely, thanks for pointing it out. > >> I'd love to put this on the wiki. Any clue where this might be found? > > I see you've added a reference buried in Debugging/Compiler. Why don't we just make traceStack the default? Perhaps with a flag to disable (or enable) the stack trace. I think this is a great idea and would really like to see this being the default. > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From dave.terei at gmail.com Sun Apr 12 08:51:41 2015 From: dave.terei at gmail.com (David Terei) Date: Sun, 12 Apr 2015 01:51:41 -0700 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 10 April 2015 at 01:48, Simon Peyton Jones wrote: > | prefer, such as only exporting the Coerce instance if all the > | constructors are exported, it seems that the ship sailed on these > > Coercible is relatively recent; I don't think we should regard it as cast in stone. > > But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope. Yes, so as you point out in the paper, this is done to preserve abstractions, but the same rule isn't applied to data types since some types like IORef don't even have constructors that can be in scope. Ideally I'd like to find a way forward that works for everyone and isn't just a Safe Haskell mode setting. I think the first question is, are there situations where you'd want to use `coerce` internally to a module but disallow it externally? The role mechanism is a little awkward as it doesn't allow this (although it does for newtype's). If yes, then I think we should start there. If it seems we don't need external vs internal control, then we could simply change the default to be that GHC sets referential type parameters to nominal and allows them to be weakened to referential through role annotations. We could use hackage to test how much breakage this would cause. The third option is something Safe Haskell specific, so probably applying the newtype constructor rule to data types. > > Simon > > | -----Original Message----- > | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of > | David Terei > | Sent: 10 April 2015 09:38 > | To: Simon Peyton Jones > | Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org > | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell > | > | I'll prepare a patch for the userguide soon. > | > | As for something better, yes I think we can and should. It's on my todo > | list :) Basically, the new-GND design has all the mechanisms to be > | safe, but sadly the defaults are rather worrying. Without explicit > | annotations from the user, module abstractions are broken. This is why > | we left GND out of Safe Haskell for the moment as it is a subtle and > | easy mistake to make. > | > | If the module contained explicit role annotations then it could be > | allowed. The discussion in > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I > | prefer, such as only exporting the Coerce instance if all the > | constructors are exported, it seems that the ship sailed on these > | bigger changes sadly. > | > | Cheers, > | David > | > | On 9 April 2015 at 00:56, Simon Peyton Jones > | wrote: > | > There is a long discussion on > | > https://ghc.haskell.org/trac/ghc/ticket/8827 > | > about whether the new Coercible story makes GND ok for Safe Haskell. > | > At a type-soundness level, definitely yes. But there are other > | > less-clear-cut issues like ?breaking abstractions? to consider. The > | > decision on the ticket > | > (comment:36) seems to be: GND stays out of Safe Haskell for now, but > | > there is room for a better proposal. > | > > | > > | > > | > I don?t have an opinion myself. David Terei and David Mazieres are in > | > the driving seat, but I?m sure they?ll be responsive to user input. > | > > | > > | > > | > However, I think the user manual may not have kept up with #8827. > | The > | > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate > | > constructor access control, by allowing untrusted code to manipulate > | > protected data types in ways the data type author did not intend, > | > breaking invariants they have established.? vanished from the 7.8 > | > user manual (links below). Maybe it should be restored. > | > > | > > | > > | > Safe Haskell aficionados, would you like to offer a patch for the > | manual? > | > And maybe also a less drastic remedy than omitting GND altogether? > | > > | > > | > > | > Simon > | > > | > > | > > | > From: Omari Norman [mailto:omari at smileystation.com] > | > Sent: 09 April 2015 02:44 > | > To: haskell Cafe > | > Subject: Generalized Newtype Deriving not allowed in Safe Haskell > | > > | > > | > > | > When compiling code with Generalized Newtype Deriving and the > | > -fwarn-unsafe flag, I get > | > > | > > | > > | > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell > | > > | > > | > > | > This happens both in GHC 7.8 and GHC 7.10. > | > > | > > | > > | > I thought I remembered reading somewhere that GNTD is now part of the > | > safe language? The GHC manual used to state that GNTD is not allowed > | > in Safe > | > Haskell: > | > > | > > | > > | > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- > | ha > | > skell.html#safe-language > | > > | > > | > > | > But this language on GNTD not being part of the safe language was > | > removed in the 7.8 manual: > | > > | > > | > > | > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- > | ha > | > skell.html#safe-language > | > > | > > | > > | > The GHC release notes don't say anything about this one way or the > | other. > | > Thoughts? > | > > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Sun Apr 12 14:33:46 2015 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 12 Apr 2015 16:33:46 +0200 Subject: Overlapping instances for poly-kinded data Message-ID: Hi all, I observe a strange "deriving Show" behaviour for my data type Foo that has proxies: data Foo :: k -> * where Foo :: Proxy t -> Foo t deriving instance Show (Foo t) This works as expected. But now I add instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where show = ('#' :) . symbolVal instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where show = ('#' :) . show . natVal these orphan instances, and "deriving Show" won't pick them up. When I go and specialise deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat)) deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol)) then it seems to work allright. Is polykinded derivation so different from the monokinded one? Or is this simply a bug? (a more elaborate WIP example can be found here: https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn2465&r=2465) Cheers, Gabor From eir at cis.upenn.edu Sun Apr 12 17:10:57 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 12 Apr 2015 18:10:57 +0100 Subject: Overlapping instances for poly-kinded data In-Reply-To: References: Message-ID: I believe this is expected behavior, for sufficiently nuanced expectations. Let's consider a simpler story: ``` {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-} class ShowType a where showType :: a -> String instance ShowType Int where showType _ = "Int" instance ShowType Bool where showType _ = "Bool" instance ShowType [a] where showType _ = "list" instance {-# OVERLAPPING #-} ShowType String where showType _ = "String" class ShowType a => IsListy a where isListy :: a -> String instance IsListy Int where isListy x = showType x ++ " is not listy." instance IsListy Bool where isListy x = showType x ++ " is not listy." instance IsListy [a] where isListy x = showType x ++ " is indeed listy." ``` The Int and Bool instances are just for exposition -- they don't really matter. The question here is: should the `IsListy [a]` instance compile? (Spoiler: It does.) It seems at first that the instance should not compile. For the definition of `isListy` to compile, GHC needs an instance for `ShowType [a]`. But, we don't know what `a` is... so there are two potential instances. Indeed, if we add the following definition ``` topIsListy :: [a] -> String topIsListy x = showType x ++ " is indeed listy." ``` we get a "several potential instances" error. Yet, the instance compiles. The reason is that GHC is a little cheeky when picking instances while in the middle of an instance declaration: it skips the check for extra instances that might match. To understand why this happens, imagine adding the following declaration to our module: ``` instance {-# OVERLAPPING #-} IsListy String where isListy _ = "Strings sure are listy!" ``` Such an instance makes sense in this context. Yet, if GHC did a full overlap check when compiling the `IsListy [a]` instance, that instance would fail, and we'd never get to write the nice, coherent set of instances we see here (including the new overlapping string instance). So, GHC skips the overlap check. The exact same scenario is happening with your Show instance. The new orphans are overlapping, but GHC skips the overlap check in your Show instance. PolyKinds is not at issue. Personally, I'm ambivalent on this skip-overlap-check-in-instances behavior. I understand why it's there, but I find it somewhat disturbing. If others do, too, I wouldn't be against opening a debate about this design decision. I hope this is helpful! Richard On Apr 12, 2015, at 3:33 PM, Gabor Greif wrote: > Hi all, > > I observe a strange "deriving Show" behaviour for my data type Foo > that has proxies: > > data Foo :: k -> * where > Foo :: Proxy t -> Foo t > > deriving instance Show (Foo t) > > This works as expected. But now I add > > instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where > show = ('#' :) . symbolVal > instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where > show = ('#' :) . show . natVal > > these orphan instances, and "deriving Show" won't pick them up. When I > go and specialise > deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat)) > deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol)) > > then it seems to work allright. Is polykinded derivation so different > from the monokinded one? Or is this simply a bug? > > (a more elaborate WIP example can be found here: > https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn2465&r=2465) > > Cheers, > > Gabor > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Sun Apr 12 20:01:22 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 12 Apr 2015 21:01:22 +0100 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu> On Apr 12, 2015, at 9:51 AM, David Terei wrote: > > Ideally I'd like to find a way forward that works for everyone and > isn't just a Safe Haskell mode setting. Agreed. I'm not convinced this can be done, but it's certainly worth trying. > > I think the first question is, are there situations where you'd want > to use `coerce` internally to a module but disallow it externally? The > role mechanism is a little awkward as it doesn't allow this (although > it does for newtype's). If yes, then I think we should start there. Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it. > > If it seems we don't need external vs internal control, then we could > simply change the default to be that GHC sets referential type > parameters to nominal and allows them to be weakened to referential > through role annotations. We could use hackage to test how much > breakage this would cause. I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does. Richard From dave.terei at gmail.com Sun Apr 12 23:41:01 2015 From: dave.terei at gmail.com (David Terei) Date: Sun, 12 Apr 2015 16:41:01 -0700 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu> References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu> Message-ID: On 12 April 2015 at 13:01, Richard Eisenberg wrote: > > On Apr 12, 2015, at 9:51 AM, David Terei wrote: >> >> Ideally I'd like to find a way forward that works for everyone and >> isn't just a Safe Haskell mode setting. > > Agreed. I'm not convinced this can be done, but it's certainly worth trying. > >> >> I think the first question is, are there situations where you'd want >> to use `coerce` internally to a module but disallow it externally? The >> role mechanism is a little awkward as it doesn't allow this (although >> it does for newtype's). If yes, then I think we should start there. > > Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it. > >> >> If it seems we don't need external vs internal control, then we could >> simply change the default to be that GHC sets referential type >> parameters to nominal and allows them to be weakened to referential >> through role annotations. We could use hackage to test how much >> breakage this would cause. > > I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does. A way to temper this as discussed in the ticket is to have the default be determined by the export list. A data type with all it's constructors exported can default to representational roles when possible, while nominal roles would be the default when a subset of constructors are exported. This is more complex for users to understand, but does map to the semantics expected under Haskell2010. It may be best to drive this decision with data. Luckily we've also got infrastructure for testing against Hackage: http://hackage.haskell.org/package/hackager > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 13 06:50:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Apr 2015 06:50:04 +0000 Subject: GHC Trac down Message-ID: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net> Is GHC's Trac down again? It's not working for me. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 13 06:57:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Apr 2015 06:57:15 +0000 Subject: stack traces when debugging GHC In-Reply-To: <55298388.7040502@gmail.com> References: <55298388.7040502@gmail.com> Message-ID: | I see you've added a reference buried in Debugging/Compiler. Why don't | we just make traceStack the default? Perhaps with a flag to disable | (or enable) the stack trace. Sounds desirable to me. It'll only work with profiling, though, of course. Would someone like to do this? At least make a ticket? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Marlow | Sent: 11 April 2015 21:27 | To: Richard Eisenberg; ghc-devs at haskell.org Devs | Subject: Re: stack traces when debugging GHC | | On 09/02/2015 02:51, Richard Eisenberg wrote: | > Hi devs, | > | > I've just made a miraculous discovery and I want to share! | > | > It has happened many times that I create some bizarre error in GHC | and have no clue where it comes from. In the past, I've ended up using | pprTrace to label all calls of the failing function, sometimes | recursively, until I get an idea of what's going on. This is terribly | painful. And then, I noticed that the function Debug.Trace.traceStack | (just in the `base` package, not part of GHC) will print out a stack | trace, when profiling is enabled. So, I tried building a profiled build | of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" | section of build.mk). | > | > And then, voila, ASSERTs now print stack traces! And, with a small | change in Outputable, I can get pprTrace to print stack traces, too! | Hooray! | | I should have advertised this more widely, thanks for pointing it out. | | > I'd love to put this on the wiki. Any clue where this might be found? | | I see you've added a reference buried in Debugging/Compiler. Why don't | we just make traceStack the default? Perhaps with a flag to disable | (or | enable) the stack trace. | | Cheers, | Simon | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 13 07:10:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Apr 2015 07:10:59 +0000 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: David If you would like to lead a debate, and drive it to a conclusion, that would be most helpful. Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate. Otherwise you risk misunderstandings, with red herrings being discussed repeatedly. Thanks Simon | -----Original Message----- | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of | David Terei | Sent: 12 April 2015 09:52 | To: Simon Peyton Jones | Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | On 10 April 2015 at 01:48, Simon Peyton Jones | wrote: | > | prefer, such as only exporting the Coerce instance if all the | > | constructors are exported, it seems that the ship sailed on these | > | > Coercible is relatively recent; I don't think we should regard it as | cast in stone. | > | > But yes, the Coerbible instance of a newtype is only available when | the data constructor for the newtype is lexically in scope. | | Yes, so as you point out in the paper, this is done to preserve | abstractions, but the same rule isn't applied to data types since some | types like IORef don't even have constructors that can be in scope. | | Ideally I'd like to find a way forward that works for everyone and | isn't just a Safe Haskell mode setting. | | I think the first question is, are there situations where you'd want to | use `coerce` internally to a module but disallow it externally? The | role mechanism is a little awkward as it doesn't allow this (although | it does for newtype's). If yes, then I think we should start there. | | If it seems we don't need external vs internal control, then we could | simply change the default to be that GHC sets referential type | parameters to nominal and allows them to be weakened to referential | through role annotations. We could use hackage to test how much | breakage this would cause. | | The third option is something Safe Haskell specific, so probably | applying the newtype constructor rule to data types. | | > | > Simon | > | > | -----Original Message----- | > | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf | > | Of David Terei | > | Sent: 10 April 2015 09:38 | > | To: Simon Peyton Jones | > | Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org | > | Subject: Re: Generalized Newtype Deriving not allowed in Safe | > | Haskell | > | | > | I'll prepare a patch for the userguide soon. | > | | > | As for something better, yes I think we can and should. It's on my | > | todo list :) Basically, the new-GND design has all the mechanisms | > | to be safe, but sadly the defaults are rather worrying. Without | > | explicit annotations from the user, module abstractions are | broken. | > | This is why we left GND out of Safe Haskell for the moment as it | is | > | a subtle and easy mistake to make. | > | | > | If the module contained explicit role annotations then it could be | > | allowed. The discussion in | > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions | > | that I prefer, such as only exporting the Coerce instance if all | > | the constructors are exported, it seems that the ship sailed on | > | these bigger changes sadly. | > | | > | Cheers, | > | David | > | | > | On 9 April 2015 at 00:56, Simon Peyton Jones | > | | > | wrote: | > | > There is a long discussion on | > | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > | > about whether the new Coercible story makes GND ok for Safe | Haskell. | > | > At a type-soundness level, definitely yes. But there are other | > | > less-clear-cut issues like ?breaking abstractions? to consider. | > | The > decision on the ticket > (comment:36) seems to be: GND | stays | > | out of Safe Haskell for now, but > there is room for a better | > | proposal. | > | > | > | > | > | > | > | > I don?t have an opinion myself. David Terei and David Mazieres | > | are in > the driving seat, but I?m sure they?ll be responsive to | user input. | > | > | > | > | > | > | > | > However, I think the user manual may not have kept up with | #8827. | > | The | > | > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate | > | > constructor access control, by allowing untrusted code to | > | manipulate > protected data types in ways the data type author did | > | not intend, > breaking invariants they have established.? | vanished | > | from the 7.8 > user manual (links below). Maybe it should be | restored. | > | > | > | > | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for | the | > | manual? | > | > And maybe also a less drastic remedy than omitting GND | altogether? | > | > | > | > | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Omari Norman [mailto:omari at smileystation.com] > Sent: 09 | > | April 2015 02:44 > To: haskell Cafe > Subject: Generalized | Newtype | > | Deriving not allowed in Safe Haskell > > > > When compiling | code | > | with Generalized Newtype Deriving and the > -fwarn-unsafe flag, I | > | get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe | > | Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > | > | > | > | > I thought I remembered reading somewhere that GNTD is now part | of | > | the > safe language? The GHC manual used to state that GNTD is | not | > | allowed > in Safe > Haskell: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > But this language on GNTD not being part of the safe language | was | > | > removed in the 7.8 manual: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > The GHC release notes don't say anything about this one way or | > | the other. | > | > Thoughts? | > | > | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 13 07:48:52 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Apr 2015 07:48:52 +0000 Subject: Overlapping instances for poly-kinded data In-Reply-To: References: Message-ID: | Personally, I'm ambivalent on this skip-overlap-check-in-instances | behavior. I understand why it's there, but I find it somewhat | disturbing. If others do, too, I wouldn't be against opening a debate | about this design decision. I agree that it's a "bit disturbing". Here's the comment that justifies it. If someone can think of a better way, I'm all ears. Simon Note [Subtle interaction of recursion and overlap] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this class C a where { op1,op2 :: a -> a } instance C a => C [a] where op1 x = op2 x ++ op2 x op2 x = ... instance C [Int] where ... When type-checking the C [a] instance, we need a C [a] dictionary (for the call of op2). If we look up in the instance environment, we find an overlap. And in *general* the right thing is to complain (see Note [Overlapping instances] in InstEnv). But in *this* case it's wrong to complain, because we just want to delegate to the op2 of this same instance. Why is this justified? Because we generate a (C [a]) constraint in a context in which 'a' cannot be instantiated to anything that matches other overlapping instances, or else we would not be executing this version of op1 in the first place. It might even be a bit disguised: nullFail :: C [a] => [a] -> [a] nullFail x = op2 x ++ op2 x instance C a => C [a] where op1 x = nullFail x Precisely this is used in package 'regex-base', module Context.hs. See the overlapping instances for RegexContext, and the fact that they call 'nullFail' just like the example above. The DoCon package also does the same thing; it shows up in module Fraction.hs. Conclusion: when typechecking the methods in a C [a] instance, we want to treat the 'a' as an *existential* type variable, in the sense described by Note [Binding when looking up instances]. That is why isOverlappableTyVar responds True to an InstSkol, which is the kind of skolem we use in tcInstDecl2. | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 12 April 2015 18:11 | To: Gabor Greif | Cc: ghc-devs | Subject: Re: Overlapping instances for poly-kinded data | | I believe this is expected behavior, for sufficiently nuanced | expectations. | | Let's consider a simpler story: | | ``` | {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-} | | class ShowType a where | showType :: a -> String | | instance ShowType Int where | showType _ = "Int" | instance ShowType Bool where | showType _ = "Bool" | | instance ShowType [a] where | showType _ = "list" | instance {-# OVERLAPPING #-} ShowType String where | showType _ = "String" | | class ShowType a => IsListy a where | isListy :: a -> String | | instance IsListy Int where | isListy x = showType x ++ " is not listy." | instance IsListy Bool where | isListy x = showType x ++ " is not listy." | | instance IsListy [a] where | isListy x = showType x ++ " is indeed listy." | ``` | | The Int and Bool instances are just for exposition -- they don't really | matter. | | The question here is: should the `IsListy [a]` instance compile? | (Spoiler: It does.) It seems at first that the instance should not | compile. For the definition of `isListy` to compile, GHC needs an | instance for `ShowType [a]`. But, we don't know what `a` is... so there | are two potential instances. Indeed, if we add the following definition | | ``` | topIsListy :: [a] -> String | topIsListy x = showType x ++ " is indeed listy." | ``` | | we get a "several potential instances" error. Yet, the instance | compiles. | | The reason is that GHC is a little cheeky when picking instances while | in the middle of an instance declaration: it skips the check for extra | instances that might match. To understand why this happens, imagine | adding the following declaration to our module: | | ``` | instance {-# OVERLAPPING #-} IsListy String where | isListy _ = "Strings sure are listy!" | ``` | | Such an instance makes sense in this context. Yet, if GHC did a full | overlap check when compiling the `IsListy [a]` instance, that instance | would fail, and we'd never get to write the nice, coherent set of | instances we see here (including the new overlapping string instance). | So, GHC skips the overlap check. | | The exact same scenario is happening with your Show instance. The new | orphans are overlapping, but GHC skips the overlap check in your Show | instance. PolyKinds is not at issue. | | Personally, I'm ambivalent on this skip-overlap-check-in-instances | behavior. I understand why it's there, but I find it somewhat | disturbing. If others do, too, I wouldn't be against opening a debate | about this design decision. | | I hope this is helpful! | Richard | | On Apr 12, 2015, at 3:33 PM, Gabor Greif wrote: | | > Hi all, | > | > I observe a strange "deriving Show" behaviour for my data type Foo | > that has proxies: | > | > data Foo :: k -> * where | > Foo :: Proxy t -> Foo t | > | > deriving instance Show (Foo t) | > | > This works as expected. But now I add | > | > instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: | > Symbol)) where show = ('#' :) . symbolVal instance {-# OVERLAPPING | > #-} KnownNat n => Show (Proxy (n :: Nat)) where show = ('#' :) . | show | > . natVal | > | > these orphan instances, and "deriving Show" won't pick them up. When | I | > go and specialise deriving instance {-# OVERLAPPING #-} KnownNat t => | > Show (Foo (t :: Nat)) deriving instance {-# OVERLAPPING #-} | > KnownSymbol s => Show (Foo (s :: Symbol)) | > | > then it seems to work allright. Is polykinded derivation so different | > from the monokinded one? Or is this simply a bug? | > | > (a more elaborate WIP example can be found here: | > | https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spe | > c=svn2465&r=2465) | > | > Cheers, | > | > Gabor | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From k-bx at k-bx.com Mon Apr 13 14:41:10 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Mon, 13 Apr 2015 17:41:10 +0300 Subject: GHC Trac down In-Reply-To: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net> References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net> Message-ID: It's down (well, timeouts) currently also. I recall someone asked for volunteers to help with trac problems and optimization. If this is still valid, I'd volunteer to help. Who should I contact? Thanks. On Mon, Apr 13, 2015 at 9:50 AM, Simon Peyton Jones wrote: > Is GHC?s Trac down again? It?s not working for me. > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Apr 14 00:38:41 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 14 Apr 2015 07:38:41 +0700 Subject: GHC Trac down In-Reply-To: References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Apr 13, 2015 at 9:41 PM, Kostiantyn Rybnikov wrote: > I recall someone asked for volunteers to help with trac problems and > optimization. If this is still valid, I'd volunteer to help. Who should I > contact? Herbert Valerio Riedel did some work installing the new spam filter on trac. Perhaps you might start with him? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.terei at gmail.com Tue Apr 14 01:18:02 2015 From: dave.terei at gmail.com (David Terei) Date: Mon, 13 Apr 2015 18:18:02 -0700 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Good advice. I'll set that up soon. On 13 April 2015 at 00:10, Simon Peyton Jones wrote: > David > > If you would like to lead a debate, and drive it to a conclusion, that would be most helpful. > > Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate. Otherwise you risk misunderstandings, with red herrings being discussed repeatedly. > > Thanks > > Simon > > | -----Original Message----- > | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of > | David Terei > | Sent: 12 April 2015 09:52 > | To: Simon Peyton Jones > | Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe > | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell > | > | On 10 April 2015 at 01:48, Simon Peyton Jones > | wrote: > | > | prefer, such as only exporting the Coerce instance if all the > | > | constructors are exported, it seems that the ship sailed on these > | > > | > Coercible is relatively recent; I don't think we should regard it as > | cast in stone. > | > > | > But yes, the Coerbible instance of a newtype is only available when > | the data constructor for the newtype is lexically in scope. > | > | Yes, so as you point out in the paper, this is done to preserve > | abstractions, but the same rule isn't applied to data types since some > | types like IORef don't even have constructors that can be in scope. > | > | Ideally I'd like to find a way forward that works for everyone and > | isn't just a Safe Haskell mode setting. > | > | I think the first question is, are there situations where you'd want to > | use `coerce` internally to a module but disallow it externally? The > | role mechanism is a little awkward as it doesn't allow this (although > | it does for newtype's). If yes, then I think we should start there. > | > | If it seems we don't need external vs internal control, then we could > | simply change the default to be that GHC sets referential type > | parameters to nominal and allows them to be weakened to referential > | through role annotations. We could use hackage to test how much > | breakage this would cause. > | > | The third option is something Safe Haskell specific, so probably > | applying the newtype constructor rule to data types. > | > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf > | > | Of David Terei > | > | Sent: 10 April 2015 09:38 > | > | To: Simon Peyton Jones > | > | Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org > | > | Subject: Re: Generalized Newtype Deriving not allowed in Safe > | > | Haskell > | > | > | > | I'll prepare a patch for the userguide soon. > | > | > | > | As for something better, yes I think we can and should. It's on my > | > | todo list :) Basically, the new-GND design has all the mechanisms > | > | to be safe, but sadly the defaults are rather worrying. Without > | > | explicit annotations from the user, module abstractions are > | broken. > | > | This is why we left GND out of Safe Haskell for the moment as it > | is > | > | a subtle and easy mistake to make. > | > | > | > | If the module contained explicit role annotations then it could be > | > | allowed. The discussion in > | > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions > | > | that I prefer, such as only exporting the Coerce instance if all > | > | the constructors are exported, it seems that the ship sailed on > | > | these bigger changes sadly. > | > | > | > | Cheers, > | > | David > | > | > | > | On 9 April 2015 at 00:56, Simon Peyton Jones > | > | > | > | wrote: > | > | > There is a long discussion on > | > | > https://ghc.haskell.org/trac/ghc/ticket/8827 > | > | > about whether the new Coercible story makes GND ok for Safe > | Haskell. > | > | > At a type-soundness level, definitely yes. But there are other > | > | > less-clear-cut issues like ?breaking abstractions? to consider. > | > | The > decision on the ticket > (comment:36) seems to be: GND > | stays > | > | out of Safe Haskell for now, but > there is room for a better > | > | proposal. > | > | > > | > | > > | > | > > | > | > I don?t have an opinion myself. David Terei and David Mazieres > | > | are in > the driving seat, but I?m sure they?ll be responsive to > | user input. > | > | > > | > | > > | > | > > | > | > However, I think the user manual may not have kept up with > | #8827. > | > | The > | > | > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate > | > | > constructor access control, by allowing untrusted code to > | > | manipulate > protected data types in ways the data type author did > | > | not intend, > breaking invariants they have established.? > | vanished > | > | from the 7.8 > user manual (links below). Maybe it should be > | restored. > | > | > > | > | > > | > | > > | > | > Safe Haskell aficionados, would you like to offer a patch for > | the > | > | manual? > | > | > And maybe also a less drastic remedy than omitting GND > | altogether? > | > | > > | > | > > | > | > > | > | > Simon > | > | > > | > | > > | > | > > | > | > From: Omari Norman [mailto:omari at smileystation.com] > Sent: 09 > | > | April 2015 02:44 > To: haskell Cafe > Subject: Generalized > | Newtype > | > | Deriving not allowed in Safe Haskell > > > > When compiling > | code > | > | with Generalized Newtype Deriving and the > -fwarn-unsafe flag, I > | > | get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe > | > | Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. > | > | > > | > | > > | > | > > | > | > I thought I remembered reading somewhere that GNTD is now part > | of > | > | the > safe language? The GHC manual used to state that GNTD is > | not > | > | allowed > in Safe > Haskell: > | > | > > | > | > > | > | > > | > | > > | > | > | https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- > | > | ha > | > | > skell.html#safe-language > | > | > > | > | > > | > | > > | > | > But this language on GNTD not being part of the safe language > | was > | > | > removed in the 7.8 manual: > | > | > > | > | > > | > | > > | > | > > | > | > | https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- > | > | ha > | > | > skell.html#safe-language > | > | > > | > | > > | > | > > | > | > The GHC release notes don't say anything about this one way or > | > | the other. > | > | > Thoughts? > | > | > > | > | > > | > | > _______________________________________________ > | > | > ghc-devs mailing list > | > | > ghc-devs at haskell.org > | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From asr at eafit.edu.co Tue Apr 14 04:24:25 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Mon, 13 Apr 2015 23:24:25 -0500 Subject: Phabricator as bug tracker system (off topic) Message-ID: Hi, (I apologise for this off topic message) >From the discussion started in https://mail.haskell.org/pipermail/ghc-devs/2014-June/005117.html, it seems GHC HQ didn't choose Phabricator as bug tracker system because migrating from Trac "...There's no real pressure to do so and it would be tons of work". Since Google is shutting down Google Code, we need to move Agda's bug tracker system from Google Code to something else. >From some preliminary investigation, it seems Phabricator bug tracker system (Maniphest) is more robust than GitHub one. I would appreciate some feedback related to Maniphest or other bug tracker system. Thanks, -- Andr?s From k-bx at k-bx.com Tue Apr 14 06:48:39 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Tue, 14 Apr 2015 09:48:39 +0300 Subject: GHC Trac down In-Reply-To: References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Yes, we started conversation in #haskell-infrastructure channel now, thank you. On Tue, Apr 14, 2015 at 3:38 AM, Kim-Ee Yeoh wrote: > > On Mon, Apr 13, 2015 at 9:41 PM, Kostiantyn Rybnikov > wrote: > >> I recall someone asked for volunteers to help with trac problems and >> optimization. If this is still valid, I'd volunteer to help. Who should I >> contact? > > > Herbert Valerio Riedel did some work installing the new spam filter on > trac. Perhaps you might start with him? > > -- Kim-Ee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Tue Apr 14 06:52:01 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 14 Apr 2015 08:52:01 +0200 Subject: Phabricator as bug tracker system (off topic) In-Reply-To: References: Message-ID: <201504140852.01752.jan.stolarek@p.lodz.pl> > we need to move Agda's bug tracker system from Google Code to something else. Finally! I disliked Google Code so much that if I found a bug in Agda I either mailed it to the discussion list or did not report it at all. And now on topic: - the only project I've been using Trac for is GHC. It seems to lack some more advanced features but from a developer's perspective it conatins everything necessary to do the job. It can be customized to the needs of a project. I think the only major downside of Trac is that a single installation can only run a single project. Probably not a problem for Agda. - GitHubs issue tracker lacks many fetures that might be essential for a larger project. For example you can't assign related issues or blocked issues. There is no way to add attachments or customize it in any way (eg. GHC Trac can list test names for a given ticket and connects tickets to phabricator). Still better than Google Code IMO. - I've been also using and administrating Redmine. It is feature rich and much more intuitive than Trac (at least for me). One instance can run multiple projects. Major downside: it starts slowly (ie. if no one was using it recently and someone visits it the instance must be started and that takes several seconds). - I've been also using Bugzilla, mostly to report bugs for some open-source project. For a pearson that only reports bugs it was OK. Not sure how it works for a developer. HTH Janek > > From some preliminary investigation, it seems Phabricator bug tracker > system (Maniphest) is more robust than GitHub one. > > I would appreciate some feedback related to Maniphest or other bug > tracker system. > > Thanks, --- 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 karel.gardas at centrum.cz Tue Apr 14 06:56:31 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 14 Apr 2015 08:56:31 +0200 Subject: Phabricator as bug tracker system (off topic) In-Reply-To: <201504140852.01752.jan.stolarek@p.lodz.pl> References: <201504140852.01752.jan.stolarek@p.lodz.pl> Message-ID: <552CBA1F.8050801@centrum.cz> On 04/14/15 08:52 AM, Jan Stolarek wrote: > And now on topic: > - the only project I've been using Trac for is GHC. It seems to lack some more advanced features > but from a developer's perspective it conatins everything necessary to do the job. It can be > customized to the needs of a project. I think the only major downside of Trac is that a single > installation can only run a single project. Probably not a problem for Agda. Jan, I'm using Trac for managing 5 independent internal projects without a problem and this is a single installation. Cheers, Karel From jan.stolarek at p.lodz.pl Tue Apr 14 06:58:07 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 14 Apr 2015 08:58:07 +0200 Subject: Phabricator as bug tracker system (off topic) In-Reply-To: <552CBA1F.8050801@centrum.cz> References: <201504140852.01752.jan.stolarek@p.lodz.pl> <552CBA1F.8050801@centrum.cz> Message-ID: <201504140858.07464.jan.stolarek@p.lodz.pl> > I'm using Trac for managing 5 independent internal projects without a > problem and this is a single installation. It looks like I'm not up to date with latest administrative Trac features. Sorry. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From austin at well-typed.com Tue Apr 14 17:47:30 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 14 Apr 2015 12:47:30 -0500 Subject: GHC Weekly News - 2015/04/14 Message-ID: (You can find a copy of this post online at https://ghc.haskell.org/trac/ghc/blog/weekly20150414) Hi *, It's been a few weeks since the last news bulletin - your editor apologizes about that. It's actually been a relatively slow few weeks here too, and busy-ness outside of GHC has attracted some of my attention. Despite that, GHC 7.10.1 was released, a new HP alpha is out, and things are moving along smoothly. Now that the release is done, things are quitely moving along in `HEAD` - with people committing code with reckless abandon, of course. This week, GHC HQ met up, but it's been very light since the 7.10.1 release. Currently there isn't anything pushing us to do a 7.10.2 release at least for a few more weeks it looks like - but see below. - We puzzled a bit about the release status of 7.10.2, and thought: it's only holding up people who are depending on it. So, who's depending on it, and what do they need fixed? See below for more. - We also talked a bit about performance - it seems the compiler has been getting much slower over time since the 7.8.x release series, and it's time to reign it in. Austin will be spending his week investigating a bit of this, and the causes. == 7.10.2 Status == So, you may be wondering when the 7.10.2 release is. The trick is it happens when you tell us it should happen! So far, taking a look at milestone:7.10.2, we've fixed about half the bugs we currently have marked down to fix. But we're probably going to punt some of those - and we're not sure all the ones that are there should be. So this is a call: **If you need something to be fixed during 7.10.2, please file a ticket, set the milestone, and alert us**. The sooner the better, because it'll inform us as to when we should release. Emailing `ghc-devs at haskell.org` is also a sure-fire way to get our attention. And remember: you can always find out the latest about the next release at the Status page (in this case, for 7.10.2) - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 == Call for help: DocBook to AsciiDoc == The GHC team needs some help. A few months ago, we put out a poll to convert our DocBook-based manual to AsciiDoc. The poll had a mostly lukewarm reception, with the idea that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. It looks like we still **want** to do this - but alas, many of us don't have time! So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just `pandoc`, but we need someone to finish it - and in return, we'll help along the way! == List chatter == - Austin Seipp announced GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html - Mark Lentczner announced an alpha Haskell Platform release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html - David Macek announced MSYS2 packages for GHC on Windows, and also asked for some help with continuous windows building - Windows hackers should help out! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html - Jan Stolarek reports about increased memory usage with GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html - Thomas Miedema chimed into a thread started by Karel Gardas about better parallelizing the GHC build - and hopefully we can get something good out of it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html - Austin Seipp made a call for help on working on and improving the GHC homepage, and luckily Sergey Bushnyak answered the call and has helped out! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html - Ozgun Ataman kicked off a thread about slower compilation times, with some nasty numbers. It's becoming more clear compiler performance should be a priority for 7.12, and we've let some things slip away from us: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html - A GHC user, Dave, asked the list about some questions with Cross Compilation, as he's attempting to get GHC to work natively inside the Open Embedded build environment. Unfortunately, things haven't been going well so far, and any input from enterprising hackers is appreciated: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html - Dan Aloni has started a discussion about improving GHC's error messages, spurred by a popular blog post he wrote and posted on Reddit about some Happy/GHC improvements he's made. This is a difficult area (error messages in general are hard) to work on, so thanks to Dan for helping! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html - Simon Peyton Jones started a discussion about `GeneralizedNewtypeDeriving` and Safe Haskell, in particular, whatever the current status, our documentation doesn't accurately reflect it! Perhaps someone could help out writing the documentation based on the current status quo? https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html - Tamar Christina started a thread about replacing `ghc-split`, an old Perl script inside GHC, but he wanted to know: what do we do about a regex replacement? Mikhail Glushenkov spoke up about a similar decision the LLVM developers used: to use the OpenBSD regex implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html - Alan Zimmerman has posted several questions and threads about the parser and the status of API annotations, which he's been furiously working on now that GHC 7.10 is being used on Hackage. Interested onlookers could learn a thing or two! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html - Gabor Greif has a question about some seemingly strange behavior regarding the interaction between poly-kinded `data` types and overlapping instances. Richard sez: this behavior is expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html == Noteworthy commits == - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the story around switch cases (with a code-size improvement) - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old `integer-gmp-0.5` source code. - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind information generation (fixes DWARF generation) - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug in the demand analyzer (with some nice compiler performance boosts). - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for multiple signature files in scope (Backpack). == Closed tickets == #10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236, #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252, #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188, #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286, #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232, #10274, #10275, #10195, and #10233. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From joehillen at gmail.com Tue Apr 14 19:07:57 2015 From: joehillen at gmail.com (Joe Hillenbrand) Date: Tue, 14 Apr 2015 12:07:57 -0700 Subject: GHC Weekly News - 2015/04/14 In-Reply-To: References: Message-ID: > == Call for help: DocBook to AsciiDoc == > > So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just `pandoc`, but we need someone to finish it - and in return, we'll help along the way! Do you have anymore information on this? Tickets? Current status? This is the first I've heard about the proposed conversion, and I follow ghc-devs@ pretty closely. On Tue, Apr 14, 2015 at 10:47 AM, Austin Seipp wrote: > (You can find a copy of this post online at > https://ghc.haskell.org/trac/ghc/blog/weekly20150414) > > Hi *, > > It's been a few weeks since the last news bulletin - your editor > apologizes about that. It's actually been a relatively slow few weeks > here too, and busy-ness outside of GHC has attracted some of my > attention. Despite that, GHC 7.10.1 was released, a new HP alpha is > out, and things are moving along smoothly. Now that the release is > done, things are quitely moving along in `HEAD` - with people > committing code with reckless abandon, of course. > > This week, GHC HQ met up, but it's been very light since the 7.10.1 > release. Currently there isn't anything pushing us to do a 7.10.2 > release at least for a few more weeks it looks like - but see below. > > - We puzzled a bit about the release status of 7.10.2, and thought: > it's only holding up people who are depending on it. So, who's > depending on it, and what do they need fixed? See below for more. > > - We also talked a bit about performance - it seems the compiler has > been getting much slower over time since the 7.8.x release series, and > it's time to reign it in. Austin will be spending his week > investigating a bit of this, and the causes. > > == 7.10.2 Status == > > So, you may be wondering when the 7.10.2 release is. The trick is it > happens when you tell us it should happen! > > So far, taking a look at milestone:7.10.2, we've fixed about half the > bugs we currently have marked down to fix. But we're probably going to > punt some of those - and we're not sure all the ones that are there > should be. > > So this is a call: **If you need something to be fixed during 7.10.2, > please file a ticket, set the milestone, and alert us**. The sooner > the better, because it'll inform us as to when we should release. > Emailing `ghc-devs at haskell.org` is also a sure-fire way to get our > attention. > > And remember: you can always find out the latest about the next > release at the Status page (in this case, for 7.10.2) - > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 > > == Call for help: DocBook to AsciiDoc == > > The GHC team needs some help. A few months ago, we put out a poll to > convert our DocBook-based manual to AsciiDoc. > > The poll had a mostly lukewarm reception, with the idea that it will > A) make life easier for people who frequently modify the users guide, > and B) make life easier for people who add things irregularly, as a > lower barrier to entry. > > It looks like we still **want** to do this - but alas, many of us > don't have time! > > So, we're asking the public: Is anyone willing to step up and help > here? For example, it may be possible to get a long ways with just > `pandoc`, but we need someone to finish it - and in return, we'll help > along the way! > > == List chatter == > > - Austin Seipp announced GHC > 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html > > - Mark Lentczner announced an alpha Haskell Platform > release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html > > - David Macek announced MSYS2 packages for GHC on Windows, and also > asked for some help with continuous windows building - Windows > hackers should help out! > https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html > > - Jan Stolarek reports about increased memory usage with GHC 7.10.1. > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html > > - Thomas Miedema chimed into a thread started by Karel Gardas about > better parallelizing the GHC build - and hopefully we can get > something good out of > it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html > > - Austin Seipp made a call for help on working on and improving the > GHC homepage, and luckily Sergey Bushnyak answered the call and > has helped out! > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html > > - Ozgun Ataman kicked off a thread about slower compilation times, > with some nasty numbers. It's becoming more clear compiler > performance should be a priority for 7.12, and we've let some > things slip away from us: > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html > > - A GHC user, Dave, asked the list about some questions with Cross > Compilation, as he's attempting to get GHC to work natively inside > the Open Embedded build environment. Unfortunately, things haven't > been going well so far, and any input from enterprising hackers is > appreciated: > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html > > - Dan Aloni has started a discussion about improving GHC's error > messages, spurred by a popular blog post he wrote and posted on > Reddit about some Happy/GHC improvements he's made. This is a > difficult area (error messages in general are hard) to work on, so > thanks to Dan for helping! > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html > > - Simon Peyton Jones started a discussion about > `GeneralizedNewtypeDeriving` and Safe Haskell, in particular, > whatever the current status, our documentation doesn't accurately > reflect it! Perhaps someone could help out writing the > documentation based on the current status quo? > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html > > - Tamar Christina started a thread about replacing `ghc-split`, an > old Perl script inside GHC, but he wanted to know: what do we do > about a regex replacement? Mikhail Glushenkov spoke up about a > similar decision the LLVM developers used: to use the OpenBSD > regex implementation. > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html > > - Alan Zimmerman has posted several questions and threads about the > parser and the status of API annotations, which he's been > furiously working on now that GHC 7.10 is being used on > Hackage. Interested onlookers could learn a thing or two! > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html > & > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html > & > https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html > > - Gabor Greif has a question about some seemingly strange behavior > regarding the interaction between poly-kinded `data` types and > overlapping instances. Richard sez: this behavior is > expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html > > == Noteworthy commits == > > - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the > story around switch cases (with a code-size improvement) > > - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old > `integer-gmp-0.5` source code. > > - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind > information generation (fixes DWARF generation) > > - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug > in the demand analyzer (with some nice compiler performance > boosts). > > - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for > multiple signature files in scope (Backpack). > > == Closed tickets == > > #10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236, > #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252, > #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188, > #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286, > #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232, > #10274, #10275, #10195, and #10233. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ozataman at gmail.com Tue Apr 14 19:56:00 2015 From: ozataman at gmail.com (Ozgun Ataman) Date: Tue, 14 Apr 2015 15:56:00 -0400 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: <55243283.3050506@gmail.com> References: <55243283.3050506@gmail.com> Message-ID: Hello all, Thank you for the comments and apologies that it took a bit of time to get back to you. My colleague Michael and I have taken a stab at a package demonstrating the slowdown. Our hypothesis was that the presence of type declarations, large values/literals, typeclass instantiations and engagement of TH caused at least some of the slowdown we were seeing in our app code. It turns out this was only partially true: - 500 random type declarations were a modest 10-25% slower. - Simply instantiating types with a given class did not contribute that much to the slowdown (around 5% on top of type declarations) - There was no notable slowdown on large values/literals (false hypothesis) - TH-enabled derivations were over 100% slower (lens and safecopy used as test subjects) - lens: ~100% slower - safecopy: ~125% slower - The slowdowns appeared to be super-linear in at least some cases. Doubling the declaration count to 1000 increased the % of the slowdown: - Declarations: 30% slower - lens TH slowdown: ~100% slower (stayed the same) - safecopy TH slowdown: ~140% slower I'd be happy to create a ticket if this is sufficient support material. It's hard to say these conclusively isolate *all* culprits for the full slowdown we observe in our codebase, but are hopefully at least a significant part. Here's the package: https://dl.dropboxusercontent.com/u/58525/ghc-slowdown.tar.gz Best, Oz On Tue, Apr 7, 2015 at 3:39 PM, Simon Marlow wrote: > Just a comment on this one point: > > On 05/04/2015 19:01, Ozgun Ataman wrote: > >> * With O0 and -j=N the overall wall-clock time is 40% higher, but the >> CPU time spent is a staggering 7.5X higher (!) >> > > When looking at Haskell programs executing in parallel, it's normal to see > a high CPU time, because the GC threads spin looking for work. The extra > CPU time is just time spent spinning, it doesn't imply that the compiler > was doing extra work. What matters is the overall wall-clock time - a > worse wall-clock time indicates that something has gone wrong. > > We should look at compile-time regression independently of performance > issues with -j. Parallel compilation is a new feature and mostly likely > needs a lot of tuning. Note that cabal's -j feature is different from > GHC's (and is likely to give much more reliable improvements) because it > runs multiple compiler instances in parallel. > > Cheers, > Simon > > > * With -O0, "cabal repl" load times have gone up by a staggering 2.5X >> (!) >> o 7.8.4: 3 min. 35 seconds >> o 7.6.3: 1 min. 2 seconds >> * Measuring compile times for individual modules, we see that those >> that are heavily loaded with lots of types, TH-facilitated type and >> typeclass derivations and those that contain large "blobs" of values >> directly at the top level now take much longer to compile: >> o We have 10 modules that each take over 10 seconds >> o We have 3 modules that each take over 35 seconds >> * Sidenote observation: In general, parallel builds with -j appear to >> cause a very significant overhead under the "system" part of timing: >> o Example with 7.6.3, O0: cabal build 140.57s user 13.25s system >> 100% cpu 2:33.70 total >> o Example with 7.8.4, O0: cabal build 507.83s user 655.43s system >> 549% cpu 3:31.59 total >> >> >> The main hurt here has been the infeasibility of using "cabal repl / >> ghci" fast-feedback style development (via emacs, vim, command-line, >> etc.), since: >> >> * Unlike "cabal build", "cabal repl" re-compiles from scratch with >> every invocation ":l App.Foo.Bar", which itself is the necessary >> first step when starting to hack on a module (we can then use :r to >> somewhat help the situation) >> * The slowdown is about 2.5X as stated above: What used to take a >> minute now takes 3.5 minutes. >> * cabal repl does not seem to benefit from -j at all >> * cabal repl 7.8.4 appears to be hurt particularly by the heavier >> modules >> * The heavier modules are often at the top of the compile tree (types, >> derivations, etc) and are practically loaded on the critical path >> all the time >> >> Let me know if I'm missing anything here and any/all feedback is much >> appreciated! >> >> Cheers, >> Oz >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Apr 14 19:58:04 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 14 Apr 2015 14:58:04 -0500 Subject: Help wanted: working on the GHC webpage In-Reply-To: <551E9EDA.40301@sigrlami.eu> References: <551E92A8.7020901@sigrlami.eu> <87y4m9conm.fsf@gmail.com> <551E9EDA.40301@sigrlami.eu> Message-ID: Hey Sergey, Sorry for the delay - thanks for all your changes! A few other people have stepped up. But we still need more help of course. :) I'm incorporating your changes into the main Git repository as we speak, and I greatly appreciate it! I'm also incorporating changes from others. Please watch the repo and let me know if you have questions! PS: As for Trac, I agree that at the minimum there should be some kind of syndication or something from the homepage to Trac... the Weekly News *is* user-focused, but the homepage has been severely lacking. I'd appreciate comments here - make an issue about it on the bug tracker! On Fri, Apr 3, 2015 at 9:08 AM, Sergey Bushnyak wrote: > >> Why would it be easier? What's difficult about publishing on >> https://ghc.haskell.org/trac/ghc/blog? > > I'm actually don't know how it's published on track. From my standpoint as > newcomer it's better to see what's happening from one place, with one > design, have some shared git repo where people contribute in markdown. >> >> Moreover, the GHC weekly news are intimately linked to Trac, as they >> reference Trac-tickets and Git commits, which Trac is able to annotate >> with meta-data (ticket-type, -status, and -title for Ticket references, >> as well as part of the Git commit msg for Git-commit refs). > > > Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about > annotation. > > Anyway, still can help on updating ghc home page. > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From asr at eafit.edu.co Tue Apr 14 20:32:49 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Tue, 14 Apr 2015 15:32:49 -0500 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: References: <55243283.3050506@gmail.com> Message-ID: On 14 April 2015 at 14:56, Ozgun Ataman wrote: > 500 random type declarations were a modest 10-25% slower. I don't think this is a modest percent by only adding type declarations. Is it an expected behaviour? -- Andr?s From joehillen at gmail.com Tue Apr 14 22:48:58 2015 From: joehillen at gmail.com (Joe Hillenbrand) Date: Tue, 14 Apr 2015 15:48:58 -0700 Subject: GHC Weekly News - 2015/04/14 In-Reply-To: References: Message-ID: Found the thread: https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html On Tue, Apr 14, 2015 at 12:07 PM, Joe Hillenbrand wrote: >> == Call for help: DocBook to AsciiDoc == >> >> So, we're asking the public: Is anyone willing to step up and help > here? For example, it may be possible to get a long ways with just > `pandoc`, but we need someone to finish it - and in return, we'll help > along the way! > > > Do you have anymore information on this? Tickets? Current status? This > is the first I've heard about the proposed conversion, and I follow > ghc-devs@ pretty closely. > From eir at cis.upenn.edu Wed Apr 15 00:20:47 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 15 Apr 2015 01:20:47 +0100 Subject: stack traces when debugging GHC In-Reply-To: References: <55298388.7040502@gmail.com> Message-ID: <2F8C959D-10F9-4C8A-AB3D-9D688CE60A6C@cis.upenn.edu> Posted as #10303. Comments welcome. On Apr 13, 2015, at 7:57 AM, Simon Peyton Jones wrote: > | I see you've added a reference buried in Debugging/Compiler. Why don't > | we just make traceStack the default? Perhaps with a flag to disable > | (or enable) the stack trace. > > Sounds desirable to me. It'll only work with profiling, though, of course. > > Would someone like to do this? At least make a ticket? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon > | Marlow > | Sent: 11 April 2015 21:27 > | To: Richard Eisenberg; ghc-devs at haskell.org Devs > | Subject: Re: stack traces when debugging GHC > | > | On 09/02/2015 02:51, Richard Eisenberg wrote: > | > Hi devs, > | > > | > I've just made a miraculous discovery and I want to share! > | > > | > It has happened many times that I create some bizarre error in GHC > | and have no clue where it comes from. In the past, I've ended up using > | pprTrace to label all calls of the failing function, sometimes > | recursively, until I get an idea of what's going on. This is terribly > | painful. And then, I noticed that the function Debug.Trace.traceStack > | (just in the `base` package, not part of GHC) will print out a stack > | trace, when profiling is enabled. So, I tried building a profiled build > | of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" > | section of build.mk). > | > > | > And then, voila, ASSERTs now print stack traces! And, with a small > | change in Outputable, I can get pprTrace to print stack traces, too! > | Hooray! > | > | I should have advertised this more widely, thanks for pointing it out. > | > | > I'd love to put this on the wiki. Any clue where this might be found? > | > | I see you've added a reference buried in Debugging/Compiler. Why don't > | we just make traceStack the default? Perhaps with a flag to disable > | (or > | enable) the stack trace. > | > | Cheers, > | Simon > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mle+hs at mega-nerd.com Wed Apr 15 06:04:31 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue, 14 Apr 2015 23:04:31 -0700 Subject: ghc-7.10 branch regression Message-ID: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> Hi all, It seems that commit 42448e3757 from git HEAD has been pulled into the ghc-7.10 branch as commit 07da52ce2d. This is problematic because that patch puts in a *requirement* for llvm-3.6 (which is good for git HEAD) but the llvm backend code in the ghc-7.10 branch does not compiler with llvm-3.6. Specifically, on armhf I get: /usr/bin/opt-3.6: /tmp/ghc16494_0/ghc16494_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} Furthermore, validating the ghc-7.10 branch on amd64-linis results in 16 unexpected failures (i'm currenty in the process of validating this branch with the problematic commit reverted). At this point we need to decide whether: a) Require llvm-3.6 for 7.10.2 and later. or b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use llvm-3.5 for the 7.10 series. For option a) we would need to do the following: * Pull in 5d5abdca31 from git HEAD that upgrades the LLVM backend to support llvm-3.6 only. * Pull in 485dba86 from git HEAD that updates the configure stuff and is really the second part of 42448e3757. For option b) we would need to do the following: * Revert 07da52ce2d from ghc-7.10 * Apply the patch mentioned here: https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11 At this point, my personal preference would be a). For me, git HEAD using llvm-3.6 has been working a lot better on armhf and arm64 than the ghc-7.10 branch. Ticket #10234 has been set to 'merge' status to refect this. Cheers, Erik PS : I would have raised another ticket about this, but I think the problem here was actually caused by too many tickets and too many commits being involved. Interesting tidbits in case anyone is interested: * On armhf, building the ghc-7.10 branch fails because we a generating LLVM IR code targeted for llvm-3.5 and trying to compile it with llcm-3.6. * The ghc-7.10 validates (with 16 unexpected failures) in x86 variants because validation uses the NCG to build the compiler and ignores the requirement for llvm-3.6, and then bindisttest compiler just uses "llc" and "opt" (in git HEAD this difference between the compiler configure script and the binary-dist configure script is fixed in 485dba86 and it is fixed in ghc-7.10 by the patch in https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11). -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From simonpj at microsoft.com Wed Apr 15 08:06:14 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 15 Apr 2015 08:06:14 +0000 Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) In-Reply-To: References: <55243283.3050506@gmail.com> Message-ID: <2a4196b73ecc40908433c03186ab6e9e@DB4PR30MB030.064d.mgd.msft.net> This is all very helpful Oz. Thanks. What would be even more helpful would be ticket(s) that focus on individual bad aspects, especially ones that are non-linear. Eg ?Here are modules with 500, 1000, 2000 declarations, and compile time goes up non-linearly?. The two big ones seem to be: ? Type declarations ? TH-enabled derivations (whatever they are) The simpler the better. Eg safecopy probably has fewer dependencies than lens. And maybe it?s nothing to do with safecopy, but any old derivation will do? What?s ideal is to be able to turn up the size knob, with a profiled compiler, and see which bits of the compiler are going non-linear. Thanks! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ozgun Ataman Sent: 14 April 2015 20:56 To: Simon Marlow Cc: michael.xavier at soostone.com; ghc-devs at haskell.org Subject: Re: Slower Compilation on GHC 7.8.4 (vs. 7.6.3) Hello all, Thank you for the comments and apologies that it took a bit of time to get back to you. My colleague Michael and I have taken a stab at a package demonstrating the slowdown. Our hypothesis was that the presence of type declarations, large values/literals, typeclass instantiations and engagement of TH caused at least some of the slowdown we were seeing in our app code. It turns out this was only partially true: * 500 random type declarations were a modest 10-25% slower. * Simply instantiating types with a given class did not contribute that much to the slowdown (around 5% on top of type declarations) * There was no notable slowdown on large values/literals (false hypothesis) * TH-enabled derivations were over 100% slower (lens and safecopy used as test subjects) * lens: ~100% slower * safecopy: ~125% slower * The slowdowns appeared to be super-linear in at least some cases. Doubling the declaration count to 1000 increased the % of the slowdown: * Declarations: 30% slower * lens TH slowdown: ~100% slower (stayed the same) * safecopy TH slowdown: ~140% slower I'd be happy to create a ticket if this is sufficient support material. It's hard to say these conclusively isolate *all* culprits for the full slowdown we observe in our codebase, but are hopefully at least a significant part. Here's the package: https://dl.dropboxusercontent.com/u/58525/ghc-slowdown.tar.gz Best, Oz On Tue, Apr 7, 2015 at 3:39 PM, Simon Marlow > wrote: Just a comment on this one point: On 05/04/2015 19:01, Ozgun Ataman wrote: * With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!) When looking at Haskell programs executing in parallel, it's normal to see a high CPU time, because the GC threads spin looking for work. The extra CPU time is just time spent spinning, it doesn't imply that the compiler was doing extra work. What matters is the overall wall-clock time - a worse wall-clock time indicates that something has gone wrong. We should look at compile-time regression independently of performance issues with -j. Parallel compilation is a new feature and mostly likely needs a lot of tuning. Note that cabal's -j feature is different from GHC's (and is likely to give much more reliable improvements) because it runs multiple compiler instances in parallel. Cheers, Simon * With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) o 7.8.4: 3 min. 35 seconds o 7.6.3: 1 min. 2 seconds * Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile: o We have 10 modules that each take over 10 seconds o We have 3 modules that each take over 35 seconds * Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing: o Example with 7.6.3, O0: cabal build 140.57s user 13.25s system 100% cpu 2:33.70 total o Example with 7.8.4, O0: cabal build 507.83s user 655.43s system 549% cpu 3:31.59 total The main hurt here has been the infeasibility of using "cabal repl / ghci" fast-feedback style development (via emacs, vim, command-line, etc.), since: * Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation) * The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes. * cabal repl does not seem to benefit from -j at all * cabal repl 7.8.4 appears to be hurt particularly by the heavier modules * The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time Let me know if I'm missing anything here and any/all feedback is much appreciated! Cheers, Oz _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Wed Apr 15 10:12:35 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 15 Apr 2015 03:12:35 -0700 Subject: ghc-7.10 branch regression In-Reply-To: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> Message-ID: <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com> Erik de Castro Lopo wrote: > At this point we need to decide whether: > > a) Require llvm-3.6 for 7.10.2 and later. I've done some testing on the ghc-7.10 branch (with a couple of patches cherry picked from master) with llvm-3.6 on amd64-linux. WIth this, there are 17 unexpected failures during validate: deriving/should_fail T7959 [stderr mismatch] (normal) deriving/should_fail drvfail005 [stderr mismatch] (normal) deriving/should_fail drvfail009 [stderr mismatch] (normal) indexed-types/should_fail SimpleFail14 [stderr mismatch] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) typecheck/should_compile T10195 [exit code non-0] (normal) typecheck/should_fail T2994 [stderr mismatch] (normal) typecheck/should_fail T3540 [stderr mismatch] (normal) typecheck/should_fail T7778 [stderr mismatch] (normal) typecheck/should_fail tcfail036 [stderr mismatch] (normal) typecheck/should_fail tcfail057 [stderr mismatch] (normal) typecheck/should_fail tcfail063 [stderr mismatch] (normal) typecheck/should_fail tcfail134 [stderr mismatch] (normal) typecheck/should_fail tcfail146 [stderr mismatch] (normal) typecheck/should_fail tcfail147 [stderr mismatch] (normal) typecheck/should_fail tcfail151 [stderr mismatch] (normal) typecheck/should_fail tcfail209 [stderr mismatch] (normal) All bit one oft these all seem to be stderr mismatches rather than actual problems. My validate run on armhf is still running. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From george.colpitts at gmail.com Wed Apr 15 12:00:55 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Apr 2015 09:00:55 -0300 Subject: ghc-7.10 branch regression In-Reply-To: <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com> References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com> Message-ID: I believe we need to do b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use llvm-3.5 for the 7.10 series. I think the plan is to require llvm-3.6 or a later version for 7.12.1 and later Ghc 7.10.1 only supports llvm 3.5 as stated in https://ghc.haskell.org/trac/ghc/ticket/9929 I filed a doc bug on this yesterday, https://ghc.haskell.org/trac/ghc/ticket/10302 On Wed, Apr 15, 2015 at 7:12 AM, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > At this point we need to decide whether: > > > > a) Require llvm-3.6 for 7.10.2 and later. > > I've done some testing on the ghc-7.10 branch (with a couple of patches > cherry picked from master) with llvm-3.6 on amd64-linux. WIth this, > there are 17 unexpected failures during validate: > > deriving/should_fail T7959 [stderr mismatch] (normal) > deriving/should_fail drvfail005 [stderr mismatch] (normal) > deriving/should_fail drvfail009 [stderr mismatch] (normal) > indexed-types/should_fail SimpleFail14 [stderr mismatch] (normal) > simplCore/should_compile spec-inline [stderr mismatch] (optasm) > typecheck/should_compile T10195 [exit code non-0] (normal) > typecheck/should_fail T2994 [stderr mismatch] (normal) > typecheck/should_fail T3540 [stderr mismatch] (normal) > typecheck/should_fail T7778 [stderr mismatch] (normal) > typecheck/should_fail tcfail036 [stderr mismatch] (normal) > typecheck/should_fail tcfail057 [stderr mismatch] (normal) > typecheck/should_fail tcfail063 [stderr mismatch] (normal) > typecheck/should_fail tcfail134 [stderr mismatch] (normal) > typecheck/should_fail tcfail146 [stderr mismatch] (normal) > typecheck/should_fail tcfail147 [stderr mismatch] (normal) > typecheck/should_fail tcfail151 [stderr mismatch] (normal) > typecheck/should_fail tcfail209 [stderr mismatch] (normal) > > All bit one oft these all seem to be stderr mismatches rather than > actual problems. > > My validate run on armhf is still running. > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Apr 15 12:20:10 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 15 Apr 2015 14:20:10 +0200 Subject: Building patches that change format of interface files Message-ID: <201504151420.10254.jan.stolarek@p.lodz.pl> GHC Devs, Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does not work if my code changes modify the format of interface files - the resulting compiler is unusable. In fact the only way to get a working compiler after interface format change that I am aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have to pass. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From ezyang at mit.edu Wed Apr 15 12:26:31 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 15 Apr 2015 13:26:31 +0100 Subject: Building patches that change format of interface files In-Reply-To: <201504151420.10254.jan.stolarek@p.lodz.pl> References: <201504151420.10254.jan.stolarek@p.lodz.pl> Message-ID: <1429100753-sup-4939@sabre> Technically, you can skip recompiling the stage1 compiler. But I never bother: all of the libraries must be rebuilt; you have, after all, changed the interface file format. Edward Excerpts from Jan Stolarek's message of 2015-04-15 13:20:10 +0100: > GHC Devs, > > Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does > not work if my code changes modify the format of interface files - the resulting compiler is > unusable. In fact the only way to get a working compiler after interface format change that I am > aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is > there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have > to pass. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. From adam at well-typed.com Wed Apr 15 12:33:25 2015 From: adam at well-typed.com (Adam Gundry) Date: Wed, 15 Apr 2015 13:33:25 +0100 Subject: Building patches that change format of interface files In-Reply-To: <201504151420.10254.jan.stolarek@p.lodz.pl> References: <201504151420.10254.jan.stolarek@p.lodz.pl> Message-ID: <552E5A95.9070807@well-typed.com> [oops, forgot to cc ghc-devs] Hi Janek, On 15/04/15 13:20, Jan Stolarek wrote: > Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does > not work if my code changes modify the format of interface files - the resulting compiler is > unusable. In fact the only way to get a working compiler after interface format change that I am > aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is > there a better way? I hit this problem quite often as well, but unfortunately don't know of a general solution other than rebuilding everything. > I'd like to test D841 but if this means rebuilding everything then I'll have to pass. In the case of D841, the interface file changes are very minor (specifically, a new tag is used when an empty closed type family is compiled, but of course none of them exist yet). Thus you might be able to get away without a full rebuild. (I think ./configure incorporates some git revision data into the interface file version number, so presumably you have to avoid that as well.) All the best, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From rwbarton at gmail.com Wed Apr 15 12:55:59 2015 From: rwbarton at gmail.com (Reid Barton) Date: Wed, 15 Apr 2015 08:55:59 -0400 Subject: ghc-7.10 branch regression In-Reply-To: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> Message-ID: On Wed, Apr 15, 2015 at 2:04 AM, Erik de Castro Lopo wrote: > > At this point we need to decide whether: > > a) Require llvm-3.6 for 7.10.2 and later. > Surely we're not going to do this. > or > > b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use > llvm-3.5 for the 7.10 series. > Why do we need to revert anything, can't we just make a one-character fix of 3.6 to 3.5 on the ghc-7.10 branch? Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Apr 15 15:52:09 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 15 Apr 2015 17:52:09 +0200 Subject: Building patches that change format of interface files In-Reply-To: <552E5A95.9070807@well-typed.com> References: <201504151420.10254.jan.stolarek@p.lodz.pl> <552E5A95.9070807@well-typed.com> Message-ID: <201504151752.09367.jan.stolarek@p.lodz.pl> > In the case of D841, the interface file changes are very minor > (specifically, a new tag is used when an empty closed type family is > compiled, but of course none of them exist yet). Thus you might be able > to get away without a full rebuild. Good point. Sadly, your patch conflicts with my work on injective type families so looks like I have no choice but to do a full rebuild. I'll post comments about things I wanted to test on Phab. Janek --- Politechnika ????dzka Lodz University of Technology Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. Je??eli nie jeste??cie Pa??stwo jej adresatem, b? d?? otrzymali??cie j? przez pomy??k?? prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From george.colpitts at gmail.com Wed Apr 15 16:44:50 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Apr 2015 13:44:50 -0300 Subject: ghc-7.10 branch regression In-Reply-To: References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> Message-ID: yes wrt b) making a one-character fix of 3.6 to 3.5 on the ghc-7.10 branch sound like the right thing to me. wrt a) my understanding is that for 7.10.2 we will also use llvm 3.5 as in 7.10.1 For 7.12.1 and forward we will also have one supported llvm version per release which right now for 7.12.1 is 3.6 but could become 3.7 The plan for llvm for 7.12.1and later is given in https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend. On Wed, Apr 15, 2015 at 9:55 AM, Reid Barton wrote: > On Wed, Apr 15, 2015 at 2:04 AM, Erik de Castro Lopo > wrote: > >> >> At this point we need to decide whether: >> >> a) Require llvm-3.6 for 7.10.2 and later. >> > > Surely we're not going to do this. > > >> or >> >> b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use >> llvm-3.5 for the 7.10 series. >> > > Why do we need to revert anything, can't we just make a one-character fix > of 3.6 to 3.5 on the ghc-7.10 branch? > > Regards, > Reid Barton > > _______________________________________________ > 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 bergey at teallabs.org Wed Apr 15 19:50:36 2015 From: bergey at teallabs.org (Daniel Bergey) Date: Wed, 15 Apr 2015 19:50:36 +0000 Subject: DocBook to AsciiDoc Message-ID: <87lhhtp3w3.fsf@chladni.home> I just read that GHC wants to convert the manual to asciidoc. If no one else has yet volunteered to do this, I hearby volunteer myself. I haven't contributed to the GHC manual before, nor to GHC. I guess that I will need to learn my way around Phabricator? I expect to be proof-reading sections that I haven't read before, about GHC features I don't use. I don't expect this to be a problem, since the goal is just to match the current HTML output. I do have some experience with DocBook, Asciidoc, and Pandoc, which should be helpful. Is there anything I should convert that isn't in under the users_guide folder?[1] It looks as though the users guide gets frequent commits.[2] Does one `arc diff` per file, approximately, sound reasonable, to keep merge conflicts manageable? Anything else I should know before I begin? Who to list as reviewers? A Trac ticket to link all the asciidoc commits together? Thanks, Daniel Footnotes: [1] http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide [2] http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide From mle+hs at mega-nerd.com Wed Apr 15 19:55:25 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 15 Apr 2015 12:55:25 -0700 Subject: ghc-7.10 branch regression In-Reply-To: References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> Message-ID: <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com> Reid Barton wrote: > Why do we need to revert anything, can't we just make a one-character fix > of 3.6 to 3.5 on the ghc-7.10 branch? Even with that one character change the LLVM detection is not complete or correct. Specifically, building the compiler will enforce the right llvm version, but the binary-dist configure script just uses "llc" and "opt". Furthermore, I am pretty sure that #10292 is causes by llvm-3.5 and that if we use llvm-3.6 buildng on Arm works. Unfortunately building and testing on Arm takes a long time and I am still in the process of verifying this. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From simonpj at microsoft.com Wed Apr 15 20:10:54 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 15 Apr 2015 20:10:54 +0000 Subject: [Haskell] Haskell on Windows instructions - is MinGHC version update needed? In-Reply-To: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com> References: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com> Message-ID: Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell at haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell From lonetiger at gmail.com Wed Apr 15 22:54:53 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Wed, 15 Apr 2015 22:54:53 +0000 Subject: =?utf-8?Q?Re:_[Haskell]_Haskell_on_Windows_instructions_-_is_MinGHC_versi?= =?utf-8?Q?on_update_needed=3F?= In-Reply-To: References: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com>, Message-ID: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com> Hi Simon, I have created a pull request to update the download links to 7.10.1 releases. https://github.com/haskell-infra/hl/pull/106 Regards, Tamar From: Simon Peyton Jones Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10 To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg Cc: GHC Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell at haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell _______________________________________________ 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 howard_b_golden at yahoo.com Wed Apr 15 23:11:57 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 15 Apr 2015 23:11:57 +0000 (UTC) Subject: [Haskell] Haskell on Windows instructions - is MinGHC version update needed? In-Reply-To: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com> References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com> Message-ID: <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com> Hi Windows Task Force, Rather than pointing to just the latest 7.10.1 release, please consider having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is designed for GHC-7.8.4. It seems to me that many Windows users would find that an attractive combination in addition to 7.10.1. Howard ________________________________ From: Tamar Christina To: Simon Peyton Jones ; Tamar Christina ; Roman Kuznetsov ; Kyrill Briantsev ; Darren Grant ; David Macek ; Michael Steele ; Andrew Klingenberg Cc: GHC Sent: Wednesday, April 15, 2015 3:54 PM Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version update needed? Hi Simon, I have created a pull request to update the download links to 7.10.1 releases. https://github.com/haskell-infra/hl/pull/106 Regards, Tamar From: Simon Peyton Jones Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10 To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg Cc: GHC Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell at haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From lonetiger at gmail.com Wed Apr 15 23:43:10 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Wed, 15 Apr 2015 23:43:10 +0000 Subject: =?utf-8?Q?Re:_[Haskell]_Haskell_on_Windows_instructions_-_is_MinGHC_versi?= =?utf-8?Q?on_update_needed=3F?= In-Reply-To: <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com> References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>, <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com> Message-ID: <552ef814.2508b40a.3737.2746@mx.google.com> Hi Howard, Ah, I was under the impression that there would be a download link from the LTS section on the download page. Since there isn?t one I have updated the pull request with a section for Haskell LTS which provides links to 7.8.4. It will look like https://github.com/Mistuke/hl/blob/update-windows-download-pages/static/markdown/windows-install.md Regards, Tamar From: Howard B. Golden Sent: ?Thursday?, ?April? ?16?, ?2015 ?01?:?11 To: Tamar Christina, Simon Peyton Jones, Tamar Christina, Roman Kuznetsov, kyra, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg Cc: GHC Hi Windows Task Force, Rather than pointing to just the latest 7.10.1 release, please consider having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is designed for GHC-7.8.4. It seems to me that many Windows users would find that an attractive combination in addition to 7.10.1. Howard ________________________________ From: Tamar Christina To: Simon Peyton Jones ; Tamar Christina ; Roman Kuznetsov ; Kyrill Briantsev ; Darren Grant ; David Macek ; Michael Steele ; Andrew Klingenberg Cc: GHC Sent: Wednesday, April 15, 2015 3:54 PM Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version update needed? Hi Simon, I have created a pull request to update the download links to 7.10.1 releases. https://github.com/haskell-infra/hl/pull/106 Regards, Tamar From: Simon Peyton Jones Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10 To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg Cc: GHC Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell at haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Apr 16 01:10:24 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 15 Apr 2015 21:10:24 -0400 Subject: ghc-7.10 branch regression In-Reply-To: <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com> References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com> <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com> Message-ID: <87pp74dgjj.fsf@gmail.com> Erik de Castro Lopo writes: > Reid Barton wrote: > >> Why do we need to revert anything, can't we just make a one-character fix >> of 3.6 to 3.5 on the ghc-7.10 branch? > > Even with that one character change the LLVM detection is not complete > or correct. Specifically, building the compiler will enforce the right > llvm version, but the binary-dist configure script just uses "llc" and > "opt". > > Furthermore, I am pretty sure that #10292 is causes by llvm-3.5 and that > if we use llvm-3.6 buildng on Arm works. Unfortunately building and > testing on Arm takes a long time and I am still in the process of > verifying this. > While I would love to see LLVM 3.6 rolled out soon as a GHC target (it is substantially more stable on ARM in my experience) I agree that doing this for 7.10.2 would be a bit of a large change for a minor release. If nothing else it would be surprising for users to find that their previously working LLVM/GHC combination needed to be upgraded upon moving to 7.10.2. In my experience LLVM 3.5 works reasonably well on ARM; it seems like this should be sufficient to carry us through to 7.12. 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 austin at well-typed.com Thu Apr 16 04:12:48 2015 From: austin at well-typed.com (Austin Seipp) Date: Wed, 15 Apr 2015 23:12:48 -0500 Subject: DocBook to AsciiDoc In-Reply-To: <87lhhtp3w3.fsf@chladni.home> References: <87lhhtp3w3.fsf@chladni.home> Message-ID: Hey Daniel, Thanks! Quick notes: 1) Yes, please file a ticket about this and refer to it in Phabricator when you make revisions. For this issue, I'd suggest just having one ticket, and every single commit references that one ticket. Adding a bunch of tickets just makes it all harder. 2) You can just add 'austin' and 'hvr' as reviewers. 3) You'll need to do some prodding with the build system: we need 'asciidoc' to be picked up by ./configure, etc. If you need help with this, just holler. I like the idea of one file at a time. If we can get by with that, I think we should. Thanks for helping! On Wed, Apr 15, 2015 at 2:50 PM, Daniel Bergey wrote: > I just read that GHC wants to convert the manual to asciidoc. If no one > else has yet volunteered to do this, I hearby volunteer myself. > > I haven't contributed to the GHC manual before, nor to GHC. I guess > that I will need to learn my way around Phabricator? I expect to be > proof-reading sections that I haven't read before, about GHC features I > don't use. I don't expect this to be a problem, since the goal is just > to match the current HTML output. I do have some experience with > DocBook, Asciidoc, and Pandoc, which should be helpful. > > Is there anything I should convert that isn't in under the users_guide > folder?[1] > > It looks as though the users guide gets frequent commits.[2] Does one > `arc diff` per file, approximately, sound reasonable, to keep merge > conflicts manageable? > > Anything else I should know before I begin? Who to list as reviewers? > A Trac ticket to link all the asciidoc commits together? > > Thanks, > Daniel > > Footnotes: > [1] http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide > > [2] http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From michael at snoyman.com Thu Apr 16 07:20:32 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 16 Apr 2015 07:20:32 +0000 Subject: [Haskell] Haskell on Windows instructions - is MinGHC version update needed? In-Reply-To: <552ef814.2508b40a.3737.2746@mx.google.com> References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com> <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com> <552ef814.2508b40a.3737.2746@mx.google.com> Message-ID: Just weighing in from the LTS side (and I guess MinGHC as well): having a link to 7.8.4 is definitely the right thing to do. LTS 2 will not compile with GHC 7.10 (see: https://github.com/fpco/stackage/issues/378 for more information). On Thu, Apr 16, 2015 at 2:45 AM Tamar Christina wrote: > Hi Howard, > > Ah, I was under the impression that there would be a download link from > the LTS section on the download page. > > Since there isn?t one I have updated the pull request with a section for > Haskell LTS which provides links to 7.8.4. > > It will look like > https://github.com/Mistuke/hl/blob/update-windows-download-pages/static/markdown/windows-install.md > > Regards, > Tamar > > *From:* Howard B. Golden > *Sent:* ?Thursday?, ?April? ?16?, ?2015 ?01?:?11 > *To:* Tamar Christina , Simon Peyton Jones > , Tamar Christina , Roman Kuznetsov > , kyra , Darren Grant > , David Macek , Michael > Steele , Andrew Klingenberg > > *Cc:* GHC > > Hi Windows Task Force, > > Rather than pointing to just the latest 7.10.1 release, please consider > having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is > designed for GHC-7.8.4. It seems to me that many Windows users would find > that an attractive combination in addition to 7.10.1. > > Howard > ________________________________ > From: Tamar Christina > To: Simon Peyton Jones ; Tamar Christina < > tamar at zhox.com>; Roman Kuznetsov ; Kyrill Briantsev < > kyrab at mail.ru>; Darren Grant ; David Macek < > david.macek.0 at gmail.com>; Michael Steele ; Andrew > Klingenberg > Cc: GHC > Sent: Wednesday, April 15, 2015 3:54 PM > Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version > update needed? > > > > > Hi Simon, > > I have created a pull request to update the download links to 7.10.1 > releases. > > https://github.com/haskell-infra/hl/pull/106 > > Regards, > Tamar > > > From: Simon Peyton Jones > Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10 > To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, > David Macek, Michael Steele, Andrew Klingenberg > Cc: GHC > > > > Fwding to the GHC Windows Task force, who will doubtless know what to do. > > Simon > > | -----Original Message----- > | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard > B. > | Golden > | Sent: 15 April 2015 17:51 > | To: haskell at haskell.org > | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version > | update needed? > | > | Hi, > | > | Currently, the Haskell website's Windows download page > | (https://www.haskell.org/downloads/windows) offers two alternatives, > | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- > | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this > | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want > | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. > | > | Howard > | _______________________________________________ > | Haskell mailing list > | Haskell at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Apr 16 14:19:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 16 Apr 2015 10:19:56 -0400 Subject: Trac is soul-extinguishingly slow Message-ID: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> Hi devs, Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to. If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.) Thanks, Richard From eir at cis.upenn.edu Thu Apr 16 14:42:45 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 16 Apr 2015 10:42:45 -0400 Subject: Trac is soul-extinguishingly slow In-Reply-To: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> Message-ID: Trac is bac. But is there anything we can do to improve reliability? Thanks! Richard On Apr 16, 2015, at 10:19 AM, Richard Eisenberg wrote: > Hi devs, > > Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to. > > If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.) > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From k-bx at k-bx.com Thu Apr 16 16:06:40 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Thu, 16 Apr 2015 19:06:40 +0300 Subject: Trac is soul-extinguishingly slow In-Reply-To: References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> Message-ID: Hi. I will soon (today or early tomorrow) get back to Herbert with two things: - profiling instructions - possible solution Also, he mentioned today in irc that he's going to add a tmp fix by restarting apache periodically, since problem starts after an hour of its work (not sure if I was supposed to talk about this :)). 16 ????. 2015 17:42 "Richard Eisenberg" ????: > Trac is bac. > > But is there anything we can do to improve reliability? > > Thanks! > Richard > > On Apr 16, 2015, at 10:19 AM, Richard Eisenberg wrote: > > > Hi devs, > > > > Trac isn't working again. In an entirely unscientific study, 4 out of > the last 5 sessions where I tried to access Trac, I was unable to. > > > > If ghc.haskell.org is getting slammed, is it possible to disconnect > Trac from that name and instead just publish some IP address until we have > things working better? (Apologies if that sentence doesn't make any sense > at all. I've dealt very little with these sorts of issues.) > > > > Thanks, > > Richard > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Fri Apr 17 17:52:01 2015 From: johnw at newartisans.com (John Wiegley) Date: Fri, 17 Apr 2015 10:52:01 -0700 Subject: Trac is soul-extinguishingly slow In-Reply-To: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> (Richard Eisenberg's message of "Thu, 16 Apr 2015 10:19:56 -0400") References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> Message-ID: >>>>> Richard Eisenberg writes: > If ghc.haskell.org is getting slammed, is it possible to disconnect Trac > from that name and instead just publish some IP address until we have things > working better? (Apologies if that sentence doesn't make any sense at all. > I've dealt very little with these sorts of issues.) I'm wondering if, in the interim, we couldn't do two things: 1. Make the public facing side of Trac read-only, by generating a static copy of the site nightly and exposing that via nginx. Bug data would be one day old at most, but it could still be searched, browsed, etc. Just not interacted with by non-GHC developers. 2. Give the GHC developers an SSH login to the machine running Trac, so that, by way of a port forward and an edit to /etc/hosts, they could have secure, direct access to the bug tracker. I realize this is sub-optimal in many ways, but it's relatively easy to setup and would cure all current problems until a better solution is found. John From metaniklas at gmail.com Fri Apr 17 18:07:06 2015 From: metaniklas at gmail.com (Niklas Larsson) Date: Fri, 17 Apr 2015 20:07:06 +0200 Subject: Trac is soul-extinguishingly slow In-Reply-To: References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> Message-ID: <55314bcc.6acf980a.2560.ffffe844@mx.google.com> How would non-developers file or comment on bugs in that scenario? BR, Niklas ----- Ursprungligt meddelande ----- Fr?n: "John Wiegley" Skickat: ?2015-?04-?17 19:52 Till: "Richard Eisenberg" Kopia: "ghc-devs at haskell.org Devs" ?mne: Re: Trac is soul-extinguishingly slow >>>>> Richard Eisenberg writes: > If ghc.haskell.org is getting slammed, is it possible to disconnect Trac > from that name and instead just publish some IP address until we have things > working better? (Apologies if that sentence doesn't make any sense at all. > I've dealt very little with these sorts of issues.) I'm wondering if, in the interim, we couldn't do two things: 1. Make the public facing side of Trac read-only, by generating a static copy of the site nightly and exposing that via nginx. Bug data would be one day old at most, but it could still be searched, browsed, etc. Just not interacted with by non-GHC developers. 2. Give the GHC developers an SSH login to the machine running Trac, so that, by way of a port forward and an edit to /etc/hosts, they could have secure, direct access to the bug tracker. I realize this is sub-optimal in many ways, but it's relatively easy to setup and would cure all current problems until a better solution is found. John _______________________________________________ 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 johnw at newartisans.com Sat Apr 18 18:12:29 2015 From: johnw at newartisans.com (John Wiegley) Date: Sat, 18 Apr 2015 11:12:29 -0700 Subject: Trac is soul-extinguishingly slow In-Reply-To: <55314bcc.6acf980a.2560.ffffe844@mx.google.com> (Niklas Larsson's message of "Fri, 17 Apr 2015 20:07:06 +0200") References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> <55314bcc.6acf980a.2560.ffffe844@mx.google.com> Message-ID: >>>>> Niklas Larsson writes: > How would non-developers file or comment on bugs in that scenario? They wouldn't, that being our incentive to get it fixed rather than allow this band-aid to remain. John From mail at joachim-breitner.de Sun Apr 19 07:44:18 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 19 Apr 2015 09:44:18 +0200 Subject: Branchless implementation for literal case =?UTF-8?Q?=E2=80=93?= is it worth it? Message-ID: <1429429458.1607.10.camel@joachim-breitner.de> Dear devs, in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that code like f :: Int -> Bool f a = case a of 1 -> True 5 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False {-# NOINLINE f #-} should not compile to a series of conditional jumps, but rather a branchless code akin to let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 `orI#` a ==# 11 `orI#` a ==# 19 case p of 1 -> do_something 0 -> do_something_else Subsequently, I refactored the way we produce Cmm code from STG, opening the possibility to implement this optimization at that stage?. But when I then added this implementation, I could not measure any runtime improvement, see https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 So my question to the general audience: Is such branchless code really better than the current, branching code? Can someone provide us with an example that shows that it is better? Do I need to produce different branchless assembly? If it is not better, I can again refactor the switch generation and simplify it a bit again. Hmm, only now I see that rwbarton has replied there. Not sure why I missed that. Anyways, more voices are welcome :-) Greetings, Joachim ? This should not preclude an implementation on the Core level, which SPJ preferred. But I improved other aspects of the code generation as well, so this is worthwhile on its own. -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From johan.tibell at gmail.com Sun Apr 19 12:56:26 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 19 Apr 2015 14:56:26 +0200 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: On Apr 19, 2015 09:44, "Joachim Breitner" wrote: > Dear devs, > > in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that > code like > > f :: Int -> Bool > f a = case a of > 1 -> True > 5 -> True > 8 -> True > 9 -> True > 11 -> True > 19 -> True > _ -> False > {-# NOINLINE f #-} > > should not compile to a series of conditional jumps, but rather a > branchless code akin to > > let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 > `orI#` a ==# 11 `orI#` a ==# 19 > case p of > 1 -> do_something > 0 -> do_something_else > > Subsequently, I refactored the way we produce Cmm code from STG, opening > the possibility to implement this optimization at that stage?. > > But when I then added this implementation, I could not measure any > runtime improvement, see > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 > > So my question to the general audience: Is such branchless code really > better than the current, branching code? Can someone provide us with an > example that shows that it is better? Do I need to produce different > branchless assembly? > > If it is not better, I can again refactor the switch generation and > simplify it a bit again. > > Hmm, only now I see that rwbarton has replied there. Not sure why I > missed that. Anyways, more voices are welcome :-) > > Greetings, > Joachim > > ? This should not preclude an implementation on the Core level, which > SPJ preferred. But I improved other aspects of the code generation as > well, so this is worthwhile on its own. > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Sun Apr 19 14:21:01 2015 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 19 Apr 2015 16:21:01 +0200 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: Em domingo, 19 de abril de 2015, Joachim Breitner escreveu: > Dear devs, > > in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that > code like > > f :: Int -> Bool > f a = case a of > 1 -> True > 5 -> True > 8 -> True > 9 -> True > 11 -> True > 19 -> True > _ -> False > {-# NOINLINE f #-} > > should not compile to a series of conditional jumps, but rather a > branchless code akin to > > let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 > `orI#` a ==# 11 `orI#` a ==# 19 > case p of > 1 -> do_something > 0 -> do_something_else I'd suggest to compile this particular case as a bittest in a 32-bit word. Gabor > > Subsequently, I refactored the way we produce Cmm code from STG, opening > the possibility to implement this optimization at that stage?. > > But when I then added this implementation, I could not measure any > runtime improvement, see > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 > > So my question to the general audience: Is such branchless code really > better than the current, branching code? Can someone provide us with an > example that shows that it is better? Do I need to produce different > branchless assembly? > > If it is not better, I can again refactor the switch generation and > simplify it a bit again. > > Hmm, only now I see that rwbarton has replied there. Not sure why I > missed that. Anyways, more voices are welcome :-) > > Greetings, > Joachim > > ? This should not preclude an implementation on the Core level, which > SPJ preferred. But I improved other aspects of the code generation as > well, so this is worthwhile on its own. > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? > http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: > 0xF0FBF51F > Debian Developer: nomeata at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sun Apr 19 14:41:47 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 19 Apr 2015 10:41:47 -0400 Subject: Branchless implementation for literal case =?utf-8?Q?=E2=80=93?= is it worth it? In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: <87pp70b2ok.fsf@gmail.com> Joachim Breitner writes: > Dear devs, > > in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that > code like > > f :: Int -> Bool > f a = case a of > 1 -> True > 5 -> True > 8 -> True > 9 -> True > 11 -> True > 19 -> True > _ -> False > {-# NOINLINE f #-} > > should not compile to a series of conditional jumps, but rather a > branchless code akin to > > let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 > `orI#` a ==# 11 `orI#` a ==# 19 > case p of > 1 -> do_something > 0 -> do_something_else > Hi Joachim, Thanks for trying this and I'm sorry to hear that the optimization hasn't yielded the improvement I would have expected. I've been a bit silent on the issue as I've been working on finishing up my PhD. Hopefully in a couple of months after I'm settled in Germany I'll have time to delve into this more deeply. > Subsequently, I refactored the way we produce Cmm code from STG, opening > the possibility to implement this optimization at that stage?. > > But when I then added this implementation, I could not measure any > runtime improvement, see > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 > > So my question to the general audience: Is such branchless code really > better than the current, branching code? Can someone provide us with an > example that shows that it is better? Do I need to produce different > branchless assembly? > Have you had a look at the Intel Optimization manual? I'll admit that I haven't looked myself but I'd imagine they'd probably have a few things to say about this. 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 carter.schonwald at gmail.com Mon Apr 20 01:31:33 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 19 Apr 2015 21:31:33 -0400 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <87pp70b2ok.fsf@gmail.com> References: <1429429458.1607.10.camel@joachim-breitner.de> <87pp70b2ok.fsf@gmail.com> Message-ID: the optimization manual ben mentions is http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html it does a very good job laying out the scope of both *generality* and *impact* for a huge range of systemsy tricks. there are certain conditions when that transformation can be a win, but they generally correspond with *inner loop* scenarios where bad branch prediction heavily impacts performance. One class of algorithms that might provide some grist for the optimization mill would be those in the hacker's delight book http://www.hackersdelight.org/ I have written some code that has that bit fiddling vs bad branch prediction encoding tradeoff before, i'll see if i can dig any of it up if you'd like! On Sun, Apr 19, 2015 at 10:41 AM, Ben Gamari wrote: > Joachim Breitner writes: > > > Dear devs, > > > > in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that > > code like > > > > f :: Int -> Bool > > f a = case a of > > 1 -> True > > 5 -> True > > 8 -> True > > 9 -> True > > 11 -> True > > 19 -> True > > _ -> False > > {-# NOINLINE f #-} > > > > should not compile to a series of conditional jumps, but rather a > > branchless code akin to > > > > let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 > > `orI#` a ==# 11 `orI#` a ==# 19 > > case p of > > 1 -> do_something > > 0 -> do_something_else > > > Hi Joachim, > > Thanks for trying this and I'm sorry to hear that the optimization > hasn't yielded the improvement I would have expected. I've been a bit > silent on the issue as I've been working on finishing up my > PhD. Hopefully in a couple of months after I'm settled in Germany I'll > have time to delve into this more deeply. > > > Subsequently, I refactored the way we produce Cmm code from STG, opening > > the possibility to implement this optimization at that stage?. > > > > But when I then added this implementation, I could not measure any > > runtime improvement, see > > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 > > > > So my question to the general audience: Is such branchless code really > > better than the current, branching code? Can someone provide us with an > > example that shows that it is better? Do I need to produce different > > branchless assembly? > > > Have you had a look at the Intel Optimization manual? I'll admit that I > haven't looked myself but I'd imagine they'd probably have a few things > to say about this. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 20 08:12:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 20 Apr 2015 08:12:07 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Friends We started this thread (below) a month ago, but it has once more run out of steam. The last contribution was from Vishal Agrawal I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. Can you review the proposal and give me suggestions. I don't feel qualified to drive this process, but I do think it's important to complete it. (I might be wrong about this too... please say so if so.) Nor do I understand why it's difficult to tie up the bow; the underlying infrastructure work is done. Duncan especially: how can we make progress? Do you think it's important to make progress, or are other things in cabal-land more important? My reason for thinking that it's important is that it appears to be the root cause of many people's difficulties with Haskell and Cabal. It might not be a panacea for all ills; but it might be a cheap remedy for a significant proportion of ills. And that would be a Good Thing. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Peyton Jones | Sent: 23 March 2015 08:46 | To: cabal-devel at haskell.org | Cc: haskell-platform at projects.haskell.org; haskell- | infrastructure at community.galois.com; Haskell Libraries; ghc- | devs at haskell.org | Subject: Cabal and simultaneous installations of the same package | | Dear Cabal developers | | You'll probably have seen the thread about the Haskell Platform. | | Among other things, this point arose: | | | Another thing we should fix is the (now false) impression that HP | | gets in the way of installing other packages and versions due to | cabal hell. | | People mean different things by "cabal hell", but the inability to | simultaneously install multiple versions of the same package, | compiled against different dependencies is certainly one of them, | and I think it is the one that Yitzchak is referring to here. | | But some time now GHC has allowed multiple versions of the same package | (compiled against different dependencies) to be installed | simultaneously. So all we need to do is to fix Cabal to allow it too, | and thereby kill of a huge class of cabal-hell problems at one blow. | | But time has passed and it hasn't happened. Is this because I'm | misunderstanding? Or because it is harder than I think? Or because | there are much bigger problems? Or because there is insufficient | effort available? Or what? | | Unless I'm way off beam, this "multiple installations of the same | package" thing has been a huge pain forever, and the solution is within | our grasp. What's stopping us grasping it? | | Simon | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Apr 20 14:29:12 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 20 Apr 2015 16:29:12 +0200 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: 2015-04-19 9:44 GMT+02:00 Joachim Breitner : > [...] So my question to the general audience: Is such branchless code really > better than the current, branching code? Can someone provide us with an > example that shows that it is better? Do I need to produce different > branchless assembly? [...] Just a few war stories regarding this from the trenches (= Chrome's JavaScript JIT): * Branchless code in itself is a non-goal. What you care about is performance and/or code size, but both don't have a direct relationship to using branches or not. * "Hacker's Delight" is a cool book, but don't use the bit fiddling tricks in there blindly. We actually reverted to straightforward code with branches from some seemingly "better" branchless code, because even with branches the performance was better. * Even within a processor family like x64, performance characteristics vary vastly. What can be a performance improvement for the modern beefy Xeon machine you're benchmarking on, can make things worse for a low-end Atom. The same holds in the other direction. * The same holds for different architectures, i.e. an "optimization" which makes things fast on most Intel cores could make things worse on e.g. ARM cores (and vice versa). * On more powerful cores with heavy out-of-order execution, it's hard to beat a well-predicted branch. * On Linux, the perf tool is your best friend. Without it you don't have a clue what's making your code slower than expected, it could be bad branch prediction, stalled units with the CPU, bad luck with caches, etc. * Micro-benchmarks can be highly misleading, e.g. due to totally different branching patterns, cache usage, etc. In a nutshell: If you don't know the details of the architecture you're compiling for, you simply don't know if the "optimization" you have in mind actually makes things better or worse. Therefore these kind of decision have to be pushed very far towards the end of the compiler pipeline. Having some kind of feedback about previous runs of the same code is very helpful, too, but this is a bit complicated in a batch compiler (but doable). From mail at joachim-breitner.de Mon Apr 20 14:41:00 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Apr 2015 16:41:00 +0200 Subject: Branchless implementation for literal case =?UTF-8?Q?=E2=80=93?= is it worth it? In-Reply-To: References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: <1429540860.1798.22.camel@joachim-breitner.de> Hi, Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne: > 2015-04-19 9:44 GMT+02:00 Joachim Breitner : > > [...] So my question to the general audience: Is such branchless code really > > better than the current, branching code? Can someone provide us with an > > example that shows that it is better? Do I need to produce different > > branchless assembly? [...] > > Just a few war stories regarding this from the trenches (= Chrome's > JavaScript JIT): thanks a lot. The conclusion I draw from your mail, at last for our case, is: Don?t bother (and keep the compiler code simple). Is that a correct reading? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From greg at gregorycollins.net Mon Apr 20 16:10:02 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 20 Apr 2015 09:10:02 -0700 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: I've gotten substantial speedups (>30%) in the past (e.g. in the hashtables package) by replacing search loops with branchless code, but the technique works best in situations where you have a long run of straight-line integer code for the CPU to chew on; for branchless to be a win you need to feed enough instructions into the pipeline such that the savings of getting 3 instructions per cycle and avoiding paying for branch mispredictions outweighs the savings you would get from not doing the work. I don't think the use case you posted falls into that category. On Sun, Apr 19, 2015 at 12:44 AM, Joachim Breitner wrote: > Dear devs, > > in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that > code like > > f :: Int -> Bool > f a = case a of > 1 -> True > 5 -> True > 8 -> True > 9 -> True > 11 -> True > 19 -> True > _ -> False > {-# NOINLINE f #-} > > should not compile to a series of conditional jumps, but rather a > branchless code akin to > > let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 > `orI#` a ==# 11 `orI#` a ==# 19 > case p of > 1 -> do_something > 0 -> do_something_else > > Subsequently, I refactored the way we produce Cmm code from STG, opening > the possibility to implement this optimization at that stage?. > > But when I then added this implementation, I could not measure any > runtime improvement, see > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 > > So my question to the general audience: Is such branchless code really > better than the current, branching code? Can someone provide us with an > example that shows that it is better? Do I need to produce different > branchless assembly? > > If it is not better, I can again refactor the switch generation and > simplify it a bit again. > > Hmm, only now I see that rwbarton has replied there. Not sure why I > missed that. Anyways, more voices are welcome :-) > > Greetings, > Joachim > > ? This should not preclude an implementation on the Core level, which > SPJ preferred. But I improved other aspects of the code generation as > well, so this is worthwhile on its own. > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Apr 20 16:16:22 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 20 Apr 2015 18:16:22 +0200 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: <1429540860.1798.22.camel@joachim-breitner.de> References: <1429429458.1607.10.camel@joachim-breitner.de> <1429540860.1798.22.camel@joachim-breitner.de> Message-ID: 2015-04-20 16:41 GMT+02:00 Joachim Breitner : > The conclusion I draw from your mail, at last for our case, is: > Don?t bother (and keep the compiler code simple). Is that a correct > reading? Yes, I think that's the right approach. Do simple things like e.g. a distinction between sparse cases (=> "if" cascade), lots of sparse cases (=> some kind of decision tree) and a non-trivial number of dense cases (jump table). For the jump table, consider computed jumps (e.g. to a table of relative jumps, which is a common implementation for PIC) and indirect jumps (the usual address table) in the backend. The former could be faster than the latter (for some ARM cores IIRC), which is not exactly intuitive. Your mileage may vary. :-) As I said: This is our experience in a JIT, so I'd be interested in other people's experience, too, especially for real-world programs, not micro-benchmarks. From mail at nh2.me Mon Apr 20 16:29:52 2015 From: mail at nh2.me (Niklas =?utf-8?b?SGFtYsO8Y2hlbg==?=) Date: Mon, 20 Apr 2015 16:29:52 +0000 (UTC) Subject: Backporting srcLoc to the GHC 7.10 branch References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: Hello everybody, I'm glad to announce that I performed the suggested backporting as part of my work for FP Complete! With the help of Eric (thanks for your support in #ghc!) we now have this patch for 7.10 and 7.8. As promised, here are the commits: * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip You can see in the history that I only needed to cherry-pick "Make the location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent commit, so the changes beyond the actual feature are fairly minimal. For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc instead of coercionToTcCoercion on wrapIP" commit. Regarding the commit of the feature itself, I had to do quite some merge resolution, especially due to the (lack of) the -fwarn-redundant- constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias "but it was Christmas, so I did some recreational programming that went much further"). However, the type checker had a strong opinion of what the right merge decision was, at least for the 7.10 backport; for 7.8 there was an ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which was resolved with Eric's help. Please be invited to review the two commits. We would like to make 7.8 and 7.10 binaries with this feature available as well, and will do so after getting a review! Niklas From greg at gregweber.info Mon Apr 20 17:07:34 2015 From: greg at gregweber.info (Greg Weber) Date: Mon, 20 Apr 2015 10:07:34 -0700 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: Thanks a lot! Is there any plan to make error or other partial functions in the base libraries use this feature? On Mon, Apr 20, 2015 at 9:29 AM, Niklas Hamb?chen wrote: > Hello everybody, > > I'm glad to announce that I performed the suggested backporting as part of > my work for FP Complete! > > With the help of Eric (thanks for your support in #ghc!) we now have this > patch for 7.10 and 7.8. > > As promised, here are the commits: > > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip > > You can see in the history that I only needed to cherry-pick "Make the > location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent commit, > so the changes beyond the actual feature are fairly minimal. > > For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc instead > of coercionToTcCoercion on wrapIP" commit. > > Regarding the commit of the feature itself, I had to do quite some merge > resolution, especially due to the (lack of) the -fwarn-redundant- > constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias "but > it > was Christmas, so I did some recreational programming that went much > further"). > However, the type checker had a strong opinion of what the right merge > decision was, at least for the 7.10 backport; for 7.8 there was an > ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which > was resolved with Eric's help. > > Please be invited to review the two commits. > > We would like to make 7.8 and 7.10 binaries with this feature available as > well, and will do so after getting a review! > > Niklas > > _______________________________________________ > 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 nicu at ionita.at Mon Apr 20 17:45:22 2015 From: nicu at ionita.at (Niculae Ionita) Date: Mon, 20 Apr 2015 19:45:22 +0200 Subject: =?windows-1252?Q?Fwd=3A_Re=3A_Branchless_implementation_?= =?windows-1252?Q?for_literal_case_=96_is_it_worth_it=3F?= In-Reply-To: <55351CA7.3080601@ionita.at> References: <55351CA7.3080601@ionita.at> Message-ID: <55353B32.3020206@ionita.at> Sorry, I forgot to answer to the list. If the code is already there and some architectures can profit of it, especially in inner loops - why not just make it an optimisation flag? Nicu Am 20.04.2015 um 16:41 schrieb Joachim Breitner: > Hi, > > Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne: >> 2015-04-19 9:44 GMT+02:00 Joachim Breitner: >>> [...] So my question to the general audience: Is such branchless code really >>> better than the current, branching code? Can someone provide us with an >>> example that shows that it is better? Do I need to produce different >>> branchless assembly? [...] >> Just a few war stories regarding this from the trenches (= Chrome's >> JavaScript JIT): > thanks a lot. > > The conclusion I draw from your mail, at last for our case, is: > Don?t bother (and keep the compiler code simple). Is that a correct > reading? > > Greetings, > Joachim > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Mon Apr 20 18:05:18 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Apr 2015 20:05:18 +0200 Subject: Fwd: Re: Branchless implementation for literal case =?UTF-8?Q?=E2=80=93?= is it worth it? In-Reply-To: <55353B32.3020206@ionita.at> References: <55351CA7.3080601@ionita.at> <55353B32.3020206@ionita.at> Message-ID: <1429553118.15613.2.camel@joachim-breitner.de> Hi, Am Montag, den 20.04.2015, 19:45 +0200 schrieb Niculae Ionita: > Sorry, I forgot to answer to the list. ah, and sorry for telling you so before looking on the list. > If the code is already there and some architectures can profit of it, > especially in inner loops - why not just make it an optimisation flag? Without even one good example where it is an improvement, this does not make sense. And even with an example: It degrades performance in other cases, so a module-wide flag would probably not cut it. Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From dan.doel at gmail.com Mon Apr 20 18:39:59 2015 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 20 Apr 2015 14:39:59 -0400 Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?= =?UTF-8?Q?s_it_worth_it=3F?= In-Reply-To: References: <1429429458.1607.10.camel@joachim-breitner.de> Message-ID: On Mon, Apr 20, 2015 at 10:29 AM, Sven Panne wrote: > * On more powerful cores with heavy out-of-order execution, it's > hard to beat a well-predicted branch. > ?With regard to this, I was wondering if we have a way of arranging for good branch prediction in GHC. For instance (and I think I've discussed this with Carter before), we've had issues filed against vector (I think) saying that we do branches for certain things that could be branchless. Bounds checks are the first thing that comes to mind, for instance (I.E. we don't use orI# for the lower and upper bound checks). However, so long as branch prediction decides that the bounds checks should succeed, I'd expect them to not be much of a cost anyway---and ideally it will always decide that, because we're inclined not to care about the performance when the checks fail and the program is bombing. However, from what I've read, there's basically no easy hinting that can ensure this. The heuristics require moving generated code around if you want to try and influence the branch predictor one way. And we also have no way of indicating to GHC that branches of a case should be preferred anyway. Unless writing things in a certain order accomplishes this? -- Dan ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 20 19:29:34 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 20 Apr 2015 19:29:34 +0000 Subject: =?Windows-1252?Q?RE:_Fwd:_Re:_Branchless_implementation_for_literal_case_?= =?Windows-1252?Q?=96_is_it_worth_it=3F?= In-Reply-To: <1429553118.15613.2.camel@joachim-breitner.de> References: <55351CA7.3080601@ionita.at> <55353B32.3020206@ionita.at> <1429553118.15613.2.camel@joachim-breitner.de> Message-ID: <55b328e14a3a4ac8b340e38728de21e5@DB4PR30MB030.064d.mgd.msft.net> | > If the code is already there and some architectures can profit of it, | > especially in inner loops - why not just make it an optimisation flag? | | Without even one good example where it is an improvement, this does not | make sense. And even with an example: It degrades performance in other | cases, so a module-wide flag would probably not cut it. Moreover code complexity in the compiler carries a real cost. Don't underestimate it! Simon From mail at nh2.me Tue Apr 21 16:33:17 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Wed, 22 Apr 2015 01:33:17 +0900 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: <55367BCD.7070009@nh2.me> Yes, I do have work in progress on using this feature in `error` and `undefined`. I will upload that as a Phabricator Diff soon, and mention the URL here. Niklas On 21/04/15 02:07, Greg Weber wrote: > Thanks a lot! Is there any plan to make error or other partial functions > in the base libraries use this feature? From dev at rodlogic.net Tue Apr 21 17:42:09 2015 From: dev at rodlogic.net (RodLogic) Date: Tue, 21 Apr 2015 13:42:09 -0400 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <55367BCD.7070009@nh2.me> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <55367BCD.7070009@nh2.me> Message-ID: Hi Niklas, Fyi: what about assert? Afaik, there is special treatment in the compiler for the assert that could be replaced by this (?). On Tuesday, April 21, 2015, Niklas Hamb?chen wrote: > Yes, I do have work in progress on using this feature in `error` and > `undefined`. > > I will upload that as a Phabricator Diff soon, and mention the URL here. > > Niklas > > On 21/04/15 02:07, Greg Weber wrote: > > Thanks a lot! Is there any plan to make error or other partial functions > > in the base libraries use this feature? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Tue Apr 21 18:03:59 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Wed, 22 Apr 2015 03:03:59 +0900 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <55367BCD.7070009@nh2.me> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <55367BCD.7070009@nh2.me> Message-ID: <5536910F.90402@nh2.me> On 22/04/15 01:33, Niklas Hamb?chen wrote: > I will upload that as a Phabricator Diff soon, and mention the URL here. Here it is: https://phabricator.haskell.org/D861 From mail at nh2.me Tue Apr 21 18:04:52 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Wed, 22 Apr 2015 03:04:52 +0900 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <55367BCD.7070009@nh2.me> Message-ID: <55369144.1060008@nh2.me> On 22/04/15 02:42, RodLogic wrote: > Fyi: what about assert? Afaik, there is special treatment in the > compiler for the assert that could be replaced by this (?). Yes, replacing the custom code for `assert` was also on Eric's plan, see the comment he just made: https://phabricator.haskell.org/D861#23250 From mail at nh2.me Tue Apr 21 18:27:00 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Wed, 22 Apr 2015 03:27:00 +0900 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: <55369674.7070706@nh2.me> On 21/04/15 01:29, Niklas Hamb?chen wrote: > We would like to make 7.8 and 7.10 binaries with this feature available as > well, and will do so after getting a review! Here's a 64-bit Linux binary distribution of 7.10 including this backport: https://github.com/nh2/ghc/releases/tag/ghc-7.10.1-release-srcloc-ip Please have a review of the backport still :) From afarmer at ittc.ku.edu Wed Apr 22 21:10:12 2015 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Wed, 22 Apr 2015 16:10:12 -0500 Subject: OS X bindist Message-ID: Forgive me if this has been answered somewhere, but is there an officially sanctioned bindist of 7.10.1 for OS X yet? The page I usually visit [1] doesn't list one yet. Thanks! Andrew [1] https://www.haskell.org/ghc/download_ghc_7_10_1 From bob at redivi.com Wed Apr 22 22:05:09 2015 From: bob at redivi.com (Bob Ippolito) Date: Wed, 22 Apr 2015 18:05:09 -0400 Subject: OS X bindist In-Reply-To: References: Message-ID: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2 is the build that http://ghcformacosx.github.io/ used. On Wed, Apr 22, 2015 at 5:10 PM, Andrew Farmer wrote: > Forgive me if this has been answered somewhere, but is there an > officially sanctioned bindist of 7.10.1 for OS X yet? The page I > usually visit [1] doesn't list one yet. > > Thanks! > Andrew > > [1] https://www.haskell.org/ghc/download_ghc_7_10_1 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Apr 23 00:23:47 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 22 Apr 2015 20:23:47 -0400 Subject: OS X bindist In-Reply-To: References: Message-ID: I can do one if folks want. On Wednesday, April 22, 2015, Andrew Farmer wrote: > Forgive me if this has been answered somewhere, but is there an > officially sanctioned bindist of 7.10.1 for OS X yet? The page I > usually visit [1] doesn't list one yet. > > Thanks! > Andrew > > [1] https://www.haskell.org/ghc/download_ghc_7_10_1 > _______________________________________________ > 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 eir at cis.upenn.edu Thu Apr 23 00:32:17 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 22 Apr 2015 20:32:17 -0400 Subject: OS X bindist In-Reply-To: References: Message-ID: Speaking of this, is it possible to get an official build put up on the page Andrew links to? In my opinion, we shouldn't announce a new release until binaries are available at haskell.org for all Tier-1 platforms. Thanks! Richard On Apr 22, 2015, at 5:10 PM, Andrew Farmer wrote: > Forgive me if this has been answered somewhere, but is there an > officially sanctioned bindist of 7.10.1 for OS X yet? The page I > usually visit [1] doesn't list one yet. > > Thanks! > Andrew > > [1] https://www.haskell.org/ghc/download_ghc_7_10_1 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mietek at bak.io Thu Apr 23 00:47:38 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Thu, 23 Apr 2015 01:47:38 +0100 Subject: OS X bindist In-Reply-To: References: Message-ID: The same 7.10.1 bindist is also available on the official downloads site; it?s just not linked from the GHC page yet: https://downloads.haskell.org/~ghc/7.10.1/ -- Mi?tek https://mietek.io On 2015-04-22, at 23:05, Bob Ippolito wrote: > https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2 is the build that http://ghcformacosx.github.io/ used. > > > On Wed, Apr 22, 2015 at 5:10 PM, Andrew Farmer wrote: > Forgive me if this has been answered somewhere, but is there an > officially sanctioned bindist of 7.10.1 for OS X yet? The page I > usually visit [1] doesn't list one yet. > > Thanks! > Andrew > > [1] https://www.haskell.org/ghc/download_ghc_7_10_1 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From eir at cis.upenn.edu Thu Apr 23 02:07:23 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 23 Apr 2015 02:07:23 -0000 Subject: Bug: GHC creates incorrect code which throws <> In-Reply-To: References: Message-ID: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu> Thanks for posting the bug and bringing it to our attention. The reason the report may not have gotten attention is that I believe this falls in Simon PJ's domain, and he's on holiday right now. I took a quick look, but I haven't a clue about this area of GHC, so there's not much I can contribute. Unless someone else out there knows much about black-holing, you may have to wait a bit. Sorry! Richard On Mar 31, 2015, at 9:48 PM, Yongqian Li wrote: > Hi all, > > I wanted to bring to your attention this bug, > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about > two days ago but hasn't gotten any replies to yet. > > > In my opinion, this is a rather serious bug since GHC is producing > incorrect code. While there is a workaround, it makes my program take > about 2 hours to compile. > > > Since reporting the bug, I've also seen "strange closure type" > exceptions, which I believe are also caused by this bug, although I do > not have a test case. Based on my limited understanding of GHC > internals, I suspect the problem lies in how type class dictionaries > are looked up at run time, as the problem disappears if GHC can fully > resolve the types. > > > Can others see if they can reproduce this bug? If there is any way I > can help, please let me know. > > > Sincerely, > Yongqian Li > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Apr 23 08:10:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 23 Apr 2015 08:10:17 +0000 Subject: Bug: GHC creates incorrect code which throws <> In-Reply-To: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu> References: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu> Message-ID: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net> #10218 is fully fixed, so are we good on this one now? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 01 April 2015 17:52 | To: Yongqian Li | Cc: ghc-devs at haskell.org | Subject: Re: Bug: GHC creates incorrect code which throws <> | | Thanks for posting the bug and bringing it to our attention. The reason | the report may not have gotten attention is that I believe this falls | in Simon PJ's domain, and he's on holiday right now. I took a quick | look, but I haven't a clue about this area of GHC, so there's not much | I can contribute. Unless someone else out there knows much about black- | holing, you may have to wait a bit. Sorry! | | Richard | | On Mar 31, 2015, at 9:48 PM, Yongqian Li | wrote: | | > Hi all, | > | > I wanted to bring to your attention this bug, | > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about | > two days ago but hasn't gotten any replies to yet. | > | > | > In my opinion, this is a rather serious bug since GHC is producing | > incorrect code. While there is a workaround, it makes my program take | > about 2 hours to compile. | > | > | > Since reporting the bug, I've also seen "strange closure type" | > exceptions, which I believe are also caused by this bug, although I | do | > not have a test case. Based on my limited understanding of GHC | > internals, I suspect the problem lies in how type class dictionaries | > are looked up at run time, as the problem disappears if GHC can fully | > resolve the types. | > | > | > Can others see if they can reproduce this bug? If there is any way I | > can help, please let me know. | > | > | > Sincerely, | > Yongqian Li | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Thu Apr 23 08:39:11 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 23 Apr 2015 10:39:11 +0200 Subject: Bug: GHC creates incorrect code which throws <> In-Reply-To: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net> References: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu> <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1429778351.1664.7.camel@joachim-breitner.de> HI, Am Donnerstag, den 23.04.2015, 08:10 +0000 schrieb Simon Peyton Jones: > #10218 is fully fixed, so are we good on this one now? note the date of Richard?s message: April 1st. Looks like it got stuck in the internets for a long time... (I was confused at first as well.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From yongqli at kerrmetric.com Thu Apr 23 09:00:40 2015 From: yongqli at kerrmetric.com (Yongqian Li) Date: Thu, 23 Apr 2015 02:00:40 -0700 Subject: Bug: GHC creates incorrect code which throws <> In-Reply-To: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net> References: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu> <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Yes, looks good. I haven't had a chance to test it yet though. On Thu, Apr 23, 2015 at 1:10 AM, Simon Peyton Jones wrote: > #10218 is fully fixed, so are we good on this one now? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 01 April 2015 17:52 > | To: Yongqian Li > | Cc: ghc-devs at haskell.org > | Subject: Re: Bug: GHC creates incorrect code which throws <> > | > | Thanks for posting the bug and bringing it to our attention. The reason > | the report may not have gotten attention is that I believe this falls > | in Simon PJ's domain, and he's on holiday right now. I took a quick > | look, but I haven't a clue about this area of GHC, so there's not much > | I can contribute. Unless someone else out there knows much about black- > | holing, you may have to wait a bit. Sorry! > | > | Richard > | > | On Mar 31, 2015, at 9:48 PM, Yongqian Li > | wrote: > | > | > Hi all, > | > > | > I wanted to bring to your attention this bug, > | > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about > | > two days ago but hasn't gotten any replies to yet. > | > > | > > | > In my opinion, this is a rather serious bug since GHC is producing > | > incorrect code. While there is a workaround, it makes my program take > | > about 2 hours to compile. > | > > | > > | > Since reporting the bug, I've also seen "strange closure type" > | > exceptions, which I believe are also caused by this bug, although I > | do > | > not have a test case. Based on my limited understanding of GHC > | > internals, I suspect the problem lies in how type class dictionaries > | > are looked up at run time, as the problem disappears if GHC can fully > | > resolve the types. > | > > | > > | > Can others see if they can reproduce this bug? If there is any way I > | > can help, please let me know. > | > > | > > | > Sincerely, > | > Yongqian Li > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Thu Apr 23 14:04:31 2015 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 23 Apr 2015 16:04:31 +0200 Subject: deriving Typeable and Nat kinds Message-ID: Hi devs, between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a strange regression with deriving Typeable for data with Nat-kinded indices. Something like this used to work (I cannot post the whole thing, unfortunately) {{{ data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, Typeable) }}} With my ghc-7.11.20150407 (and later) strange obligations of the form `Typeable p` appear, rendering my code uncompilable. But there is no way I can see how I can convince the type checker that the Nat index is indeed Typeable. I *do* have a `KnownNat p` constraint around, though. The relevant changes to mainline appear to be https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 both by Iavor. So now my questions: 1) Is this a regression on mainline? (I surely hope so!) How did this work before? 2) Should `KnownNat p` imply `Typeable p` for the ability to have my `Typeable (OTU p o)` 3) if 2) is answered with "NO", how am I supposed to satisfy those constraints? Thanks and cheers, Gabor PS: Sometimes I feel like a canary doing my research-like programming with GHC-HEAD, and it is a mostly positive experience, but events like this make me shiver... From iavor.diatchki at gmail.com Thu Apr 23 15:00:14 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 23 Apr 2015 08:00:14 -0700 Subject: deriving Typeable and Nat kinds In-Reply-To: References: Message-ID: Hello, Apologies if my changes caused difficulties with your work---we made the changes to `Typable` to preserve the soundness of the type system, hopefully the new behavior is exactly equivalent to the old in the safe cases. Could you post an example of the code where the unwanted `Typeable p` constraint appears? It seems entirely reasonable that if you want to solve `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not seeing the whole picture. To answer your question about `KnownNat p`---there is no relation between it and `Typeable`. You may think if a `KnownNat x` constraint as just the integer `x`. As it happens, the integer is closely related to the `Typeable` instance for the number, so I think we *could* make it work so that if you have `KnownNat p`, then you can get `Typeable p`, but this has never worked previosly, so perhaps there is another issue. -Iavor On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif wrote: > Hi devs, > > between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a > strange regression with deriving Typeable for data with Nat-kinded > indices. > > Something like this used to work (I cannot post the whole thing, > unfortunately) > > {{{ > data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, > Typeable) > }}} > > With my ghc-7.11.20150407 (and later) strange obligations of the form > `Typeable p` appear, rendering my code uncompilable. But there is no > way I can see how I can convince the type checker that the Nat index > is indeed Typeable. I *do* have a `KnownNat p` constraint around, > though. > > The relevant changes to mainline appear to be > https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 > https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 > > both by Iavor. > > So now my questions: > > 1) Is this a regression on mainline? (I surely hope so!) How did this > work before? > 2) Should `KnownNat p` imply `Typeable p` for the ability to have my > `Typeable (OTU p o)` > 3) if 2) is answered with "NO", how am I supposed to satisfy those > constraints? > > Thanks and cheers, > > Gabor > > > PS: Sometimes I feel like a canary doing my research-like programming > with GHC-HEAD, and it is a mostly positive experience, but events like > this make me shiver... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Apr 23 15:37:31 2015 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 23 Apr 2015 17:37:31 +0200 Subject: deriving Typeable and Nat kinds In-Reply-To: References: Message-ID: On 4/23/15, Iavor Diatchki wrote: > Hello, > Hi Iavor, > Apologies if my changes caused difficulties with your work---we made the > changes to `Typable` to preserve the soundness of the type system, > hopefully the new behavior is exactly equivalent to the old in the safe > cases. No need to apologize, I chose this way to be able to intervene fast when something breaks :-) The old behaviour might have been unsafe, though I cannot see why. > > Could you post an example of the code where the unwanted `Typeable p` > constraint appears? It seems entirely reasonable that if you want to solve > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not > seeing the whole picture. Here is a small example where an additional constraint surfaces: ------------------------------------------------------------------------------ {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, StandaloneDeriving #-} import GHC.TypeLits import Data.Typeable data Foo (n :: Nat) where Hey :: KnownNat n => Foo n deriving instance Show (Foo n) data T t where T :: (Show t, Typeable t) => t -> T t deriving instance Show (T n) {- ------------------- WITH ghci-7.11.20150407 (and newer) *Main> :t T Hey T Hey :: (Typeable n, KnownNat n) => T (Foo n) ------------------- WITH ghci-7.11.20150215 (old) *Main> :t T Hey T Hey :: KnownNat n => T (Foo n) -} ------------------------------------------------------------------------------ > > To answer your question about `KnownNat p`---there is no relation between > it and `Typeable`. You may think if a `KnownNat x` constraint as just the > integer `x`. As it happens, the integer is closely related to the > `Typeable` instance for the number, so I think we *could* make it work so Yes, this relation I was alluding to. > that if you have `KnownNat p`, then you can get `Typeable p`, but this has > never worked previosly, so perhaps there is another issue. Maybe with my example from above it might be easier to debug it. > > -Iavor Thanks, Gabor > > > > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif wrote: > >> Hi devs, >> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a >> strange regression with deriving Typeable for data with Nat-kinded >> indices. >> >> Something like this used to work (I cannot post the whole thing, >> unfortunately) >> >> {{{ >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, >> Typeable) >> }}} >> >> With my ghc-7.11.20150407 (and later) strange obligations of the form >> `Typeable p` appear, rendering my code uncompilable. But there is no >> way I can see how I can convince the type checker that the Nat index >> is indeed Typeable. I *do* have a `KnownNat p` constraint around, >> though. >> >> The relevant changes to mainline appear to be >> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 >> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 >> >> both by Iavor. >> >> So now my questions: >> >> 1) Is this a regression on mainline? (I surely hope so!) How did this >> work before? >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my >> `Typeable (OTU p o)` >> 3) if 2) is answered with "NO", how am I supposed to satisfy those >> constraints? >> >> Thanks and cheers, >> >> Gabor >> >> >> PS: Sometimes I feel like a canary doing my research-like programming >> with GHC-HEAD, and it is a mostly positive experience, but events like >> this make me shiver... >> > From iavor.diatchki at gmail.com Thu Apr 23 16:59:04 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 23 Apr 2015 09:59:04 -0700 Subject: deriving Typeable and Nat kinds In-Reply-To: References: Message-ID: Aha, I see what happened. What I said before was wrong---indeed the `Typeable` instance for type-nats (and symbols) used to be implemented in terms of `KnownNat` and `KnownSymbol`: instance KnownNat n => Typeable (n :: Nat) where ... When I updated the `Typeable` solver, I forgot about that special case---I'll have a go at a fix. -Iavor On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif wrote: > On 4/23/15, Iavor Diatchki wrote: > > Hello, > > > > Hi Iavor, > > > Apologies if my changes caused difficulties with your work---we made the > > changes to `Typable` to preserve the soundness of the type system, > > hopefully the new behavior is exactly equivalent to the old in the safe > > cases. > > No need to apologize, I chose this way to be able to intervene fast > when something breaks :-) The old behaviour might have been unsafe, > though I cannot see why. > > > > > Could you post an example of the code where the unwanted `Typeable p` > > constraint appears? It seems entirely reasonable that if you want to > solve > > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not > > seeing the whole picture. > > Here is a small example where an additional constraint surfaces: > > > ------------------------------------------------------------------------------ > {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, > StandaloneDeriving #-} > > import GHC.TypeLits > import Data.Typeable > > data Foo (n :: Nat) where > Hey :: KnownNat n => Foo n > > deriving instance Show (Foo n) > > data T t where > T :: (Show t, Typeable t) => t -> T t > > deriving instance Show (T n) > > {- > > ------------------- WITH ghci-7.11.20150407 (and newer) > *Main> :t T Hey > T Hey :: (Typeable n, KnownNat n) => T (Foo n) > > ------------------- WITH ghci-7.11.20150215 (old) > *Main> :t T Hey > T Hey :: KnownNat n => T (Foo n) > > -} > > ------------------------------------------------------------------------------ > > > > > > To answer your question about `KnownNat p`---there is no relation between > > it and `Typeable`. You may think if a `KnownNat x` constraint as just > the > > integer `x`. As it happens, the integer is closely related to the > > `Typeable` instance for the number, so I think we *could* make it work so > > Yes, this relation I was alluding to. > > > that if you have `KnownNat p`, then you can get `Typeable p`, but this > has > > never worked previosly, so perhaps there is another issue. > > Maybe with my example from above it might be easier to debug it. > > > > > -Iavor > > Thanks, > > Gabor > > > > > > > > > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif wrote: > > > >> Hi devs, > >> > >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a > >> strange regression with deriving Typeable for data with Nat-kinded > >> indices. > >> > >> Something like this used to work (I cannot post the whole thing, > >> unfortunately) > >> > >> {{{ > >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, > >> Typeable) > >> }}} > >> > >> With my ghc-7.11.20150407 (and later) strange obligations of the form > >> `Typeable p` appear, rendering my code uncompilable. But there is no > >> way I can see how I can convince the type checker that the Nat index > >> is indeed Typeable. I *do* have a `KnownNat p` constraint around, > >> though. > >> > >> The relevant changes to mainline appear to be > >> > https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 > >> > https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 > >> > >> both by Iavor. > >> > >> So now my questions: > >> > >> 1) Is this a regression on mainline? (I surely hope so!) How did this > >> work before? > >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my > >> `Typeable (OTU p o)` > >> 3) if 2) is answered with "NO", how am I supposed to satisfy those > >> constraints? > >> > >> Thanks and cheers, > >> > >> Gabor > >> > >> > >> PS: Sometimes I feel like a canary doing my research-like programming > >> with GHC-HEAD, and it is a mostly positive experience, but events like > >> this make me shiver... > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Thu Apr 23 17:00:07 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 23 Apr 2015 10:00:07 -0700 Subject: deriving Typeable and Nat kinds In-Reply-To: References: Message-ID: Could you please make a ticket for this, so that we have a reference and it does not get lost? On Thu, Apr 23, 2015 at 9:59 AM, Iavor Diatchki wrote: > Aha, I see what happened. What I said before was wrong---indeed the > `Typeable` instance for type-nats (and symbols) used to be implemented in > terms of `KnownNat` and `KnownSymbol`: > > instance KnownNat n => Typeable (n :: Nat) where ... > > When I updated the `Typeable` solver, I forgot about that special > case---I'll have a go at a fix. > > -Iavor > > > > > On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif wrote: > >> On 4/23/15, Iavor Diatchki wrote: >> > Hello, >> > >> >> Hi Iavor, >> >> > Apologies if my changes caused difficulties with your work---we made the >> > changes to `Typable` to preserve the soundness of the type system, >> > hopefully the new behavior is exactly equivalent to the old in the safe >> > cases. >> >> No need to apologize, I chose this way to be able to intervene fast >> when something breaks :-) The old behaviour might have been unsafe, >> though I cannot see why. >> >> > >> > Could you post an example of the code where the unwanted `Typeable p` >> > constraint appears? It seems entirely reasonable that if you want to >> solve >> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not >> > seeing the whole picture. >> >> Here is a small example where an additional constraint surfaces: >> >> >> ------------------------------------------------------------------------------ >> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, >> StandaloneDeriving #-} >> >> import GHC.TypeLits >> import Data.Typeable >> >> data Foo (n :: Nat) where >> Hey :: KnownNat n => Foo n >> >> deriving instance Show (Foo n) >> >> data T t where >> T :: (Show t, Typeable t) => t -> T t >> >> deriving instance Show (T n) >> >> {- >> >> ------------------- WITH ghci-7.11.20150407 (and newer) >> *Main> :t T Hey >> T Hey :: (Typeable n, KnownNat n) => T (Foo n) >> >> ------------------- WITH ghci-7.11.20150215 (old) >> *Main> :t T Hey >> T Hey :: KnownNat n => T (Foo n) >> >> -} >> >> ------------------------------------------------------------------------------ >> >> >> > >> > To answer your question about `KnownNat p`---there is no relation >> between >> > it and `Typeable`. You may think if a `KnownNat x` constraint as just >> the >> > integer `x`. As it happens, the integer is closely related to the >> > `Typeable` instance for the number, so I think we *could* make it work >> so >> >> Yes, this relation I was alluding to. >> >> > that if you have `KnownNat p`, then you can get `Typeable p`, but this >> has >> > never worked previosly, so perhaps there is another issue. >> >> Maybe with my example from above it might be easier to debug it. >> >> > >> > -Iavor >> >> Thanks, >> >> Gabor >> >> > >> > >> > >> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif wrote: >> > >> >> Hi devs, >> >> >> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a >> >> strange regression with deriving Typeable for data with Nat-kinded >> >> indices. >> >> >> >> Something like this used to work (I cannot post the whole thing, >> >> unfortunately) >> >> >> >> {{{ >> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, >> >> Typeable) >> >> }}} >> >> >> >> With my ghc-7.11.20150407 (and later) strange obligations of the form >> >> `Typeable p` appear, rendering my code uncompilable. But there is no >> >> way I can see how I can convince the type checker that the Nat index >> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around, >> >> though. >> >> >> >> The relevant changes to mainline appear to be >> >> >> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 >> >> >> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 >> >> >> >> both by Iavor. >> >> >> >> So now my questions: >> >> >> >> 1) Is this a regression on mainline? (I surely hope so!) How did this >> >> work before? >> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my >> >> `Typeable (OTU p o)` >> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those >> >> constraints? >> >> >> >> Thanks and cheers, >> >> >> >> Gabor >> >> >> >> >> >> PS: Sometimes I feel like a canary doing my research-like programming >> >> with GHC-HEAD, and it is a mostly positive experience, but events like >> >> this make me shiver... >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Apr 23 17:19:30 2015 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 23 Apr 2015 19:19:30 +0200 Subject: deriving Typeable and Nat kinds In-Reply-To: References: Message-ID: Here you go: https://ghc.haskell.org/trac/ghc/ticket/10348 Thanks for looking into this! Cheers, Gabor On 4/23/15, Iavor Diatchki wrote: > Could you please make a ticket for this, so that we have a reference and it > does not get lost? > > On Thu, Apr 23, 2015 at 9:59 AM, Iavor Diatchki > wrote: > >> Aha, I see what happened. What I said before was wrong---indeed the >> `Typeable` instance for type-nats (and symbols) used to be implemented in >> terms of `KnownNat` and `KnownSymbol`: >> >> instance KnownNat n => Typeable (n :: Nat) where ... >> >> When I updated the `Typeable` solver, I forgot about that special >> case---I'll have a go at a fix. >> >> -Iavor >> >> >> >> >> On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif wrote: >> >>> On 4/23/15, Iavor Diatchki wrote: >>> > Hello, >>> > >>> >>> Hi Iavor, >>> >>> > Apologies if my changes caused difficulties with your work---we made >>> > the >>> > changes to `Typable` to preserve the soundness of the type system, >>> > hopefully the new behavior is exactly equivalent to the old in the >>> > safe >>> > cases. >>> >>> No need to apologize, I chose this way to be able to intervene fast >>> when something breaks :-) The old behaviour might have been unsafe, >>> though I cannot see why. >>> >>> > >>> > Could you post an example of the code where the unwanted `Typeable p` >>> > constraint appears? It seems entirely reasonable that if you want to >>> solve >>> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not >>> > seeing the whole picture. >>> >>> Here is a small example where an additional constraint surfaces: >>> >>> >>> ------------------------------------------------------------------------------ >>> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, >>> StandaloneDeriving #-} >>> >>> import GHC.TypeLits >>> import Data.Typeable >>> >>> data Foo (n :: Nat) where >>> Hey :: KnownNat n => Foo n >>> >>> deriving instance Show (Foo n) >>> >>> data T t where >>> T :: (Show t, Typeable t) => t -> T t >>> >>> deriving instance Show (T n) >>> >>> {- >>> >>> ------------------- WITH ghci-7.11.20150407 (and newer) >>> *Main> :t T Hey >>> T Hey :: (Typeable n, KnownNat n) => T (Foo n) >>> >>> ------------------- WITH ghci-7.11.20150215 (old) >>> *Main> :t T Hey >>> T Hey :: KnownNat n => T (Foo n) >>> >>> -} >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> > >>> > To answer your question about `KnownNat p`---there is no relation >>> between >>> > it and `Typeable`. You may think if a `KnownNat x` constraint as >>> > just >>> the >>> > integer `x`. As it happens, the integer is closely related to the >>> > `Typeable` instance for the number, so I think we *could* make it work >>> so >>> >>> Yes, this relation I was alluding to. >>> >>> > that if you have `KnownNat p`, then you can get `Typeable p`, but this >>> has >>> > never worked previosly, so perhaps there is another issue. >>> >>> Maybe with my example from above it might be easier to debug it. >>> >>> > >>> > -Iavor >>> >>> Thanks, >>> >>> Gabor >>> >>> > >>> > >>> > >>> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif wrote: >>> > >>> >> Hi devs, >>> >> >>> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a >>> >> strange regression with deriving Typeable for data with Nat-kinded >>> >> indices. >>> >> >>> >> Something like this used to work (I cannot post the whole thing, >>> >> unfortunately) >>> >> >>> >> {{{ >>> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, >>> >> Typeable) >>> >> }}} >>> >> >>> >> With my ghc-7.11.20150407 (and later) strange obligations of the form >>> >> `Typeable p` appear, rendering my code uncompilable. But there is no >>> >> way I can see how I can convince the type checker that the Nat index >>> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around, >>> >> though. >>> >> >>> >> The relevant changes to mainline appear to be >>> >> >>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 >>> >> >>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 >>> >> >>> >> both by Iavor. >>> >> >>> >> So now my questions: >>> >> >>> >> 1) Is this a regression on mainline? (I surely hope so!) How did this >>> >> work before? >>> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my >>> >> `Typeable (OTU p o)` >>> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those >>> >> constraints? >>> >> >>> >> Thanks and cheers, >>> >> >>> >> Gabor >>> >> >>> >> >>> >> PS: Sometimes I feel like a canary doing my research-like programming >>> >> with GHC-HEAD, and it is a mostly positive experience, but events >>> >> like >>> >> this make me shiver... >>> >> >>> > >>> >> >> > From carter.schonwald at gmail.com Thu Apr 23 20:03:06 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 23 Apr 2015 16:03:06 -0400 Subject: validate failures for OSX on current head Message-ID: hey all, on ghc head today specifically commit a55bfabbed21f17064f863450f9d94d45db9c478 i did a run of ./validate --slow here are the following unexpected failures (i know the static pointer GHCI ones are expected, but i'm not sure about the rest). Could someone care to opine on which ones are truely unexpected? i'll be doing a bit of digging on some of these as I have time over the coming week, but i thought I should share this with everyone just in case something important is amidst them cheers -Carter Unexpected results from: TEST="tc165 retc001 dsrun014 DsStaticPointers GcStaticPointers ListStaticPointers T7919 retc002 tcrun024 tcrun025 T7861 T5751 T3500a T7126 tcrun037 readRun004 rn041 TH_StaticPointers recomp001 setnumcapabilities001 allocLimit4 ghci024 termination enum01 enum03 enum02 sigcabal01 sigcabal02 CgStaticPointers recomp014 qq007 qq008 mul2 quotRem2 add2 read029" OVERALL SUMMARY for test run started at Thu Apr 23 15:02:33 2015 EDT 0:20:10 spent to go through 4483 total tests, which gave rise to 14464 test cases, of which 2785 were skipped 267 had missing libraries 11140 expected passes 170 expected failures 0 caused framework failures 0 unexpected passes 102 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) cabal/sigcabal02 sigcabal02 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run setnumcapabilities001 [bad exit code] (threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/recomp001 recomp001 [bad stderr] (normal) driver/recomp014 recomp014 [bad stdout] (normal) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) gadt termination [exit code non-0] (optasm) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_compile read029 [exit code non-0] (optasm) parser/should_run readRun004 [bad exit code] (ghci) quasiquotation/qq007 qq007 [exit code non-0] (normal,hpc,optasm) quasiquotation/qq008 qq008 [exit code non-0] (normal,hpc,optasm) rename/should_compile rn041 [exit code non-0] (optasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_compile tc165 [exit code non-0] (optasm) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7861 [bad stdout or stderr] (ghci) typecheck/should_run tcrun024 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun024 [bad stdout or stderr] (ghci) typecheck/should_run tcrun025 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun025 [bad stdout or stderr] (ghci) typecheck/should_run tcrun037 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun037 [bad stdout or stderr] (ghci) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Apr 24 13:54:41 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 24 Apr 2015 14:54:41 +0100 Subject: Can we fix our Trac that doesn't lose new ticket text Message-ID: <1429883680-sup-8002@sabre> Steps to reproduce: 1. Click "New Ticket" 2. Type some text into the box 3. Press "Back" in your browser 4. Press "Forward" in your browser If you try this with an official Trac this doesn't happen, so either this was fixed in a new version, or we have a plugin installed which is causing this to happen. Current version of Trac is 1.0.5, we're currently running 1.0.1 Thanks, Edward From ecrockett0 at gmail.com Fri Apr 24 14:02:35 2015 From: ecrockett0 at gmail.com (Eric Crockett) Date: Fri, 24 Apr 2015 10:02:35 -0400 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: <1429883680-sup-8002@sabre> References: <1429883680-sup-8002@sabre> Message-ID: On the contrary, I did precisely that just a few days ago ( https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac *did* save my new ticket text. Perhaps this is a browser-specific issue? I'm using 64-bit Chrome 42.0.2311.90. On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > Steps to reproduce: > > 1. Click "New Ticket" > 2. Type some text into the box > 3. Press "Back" in your browser > 4. Press "Forward" in your browser > > If you try this with an official Trac this doesn't happen, so either > this was fixed in a new version, or we have a plugin installed which > is causing this to happen. > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > > Thanks, > Edward > _______________________________________________ > 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 ggreif at gmail.com Fri Apr 24 14:04:55 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 24 Apr 2015 16:04:55 +0200 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: References: <1429883680-sup-8002@sabre> Message-ID: On 4/24/15, Eric Crockett wrote: > On the contrary, I did precisely that just a few days ago ( > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac > *did* save my new ticket text. Perhaps this is a browser-specific issue? > I'm using 64-bit Chrome 42.0.2311.90. With a recent Firefox, I lost the text by clicking into "Formatting Hints" and surfing back. I was not amused. Cheers, Gabor > > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > >> Steps to reproduce: >> >> 1. Click "New Ticket" >> 2. Type some text into the box >> 3. Press "Back" in your browser >> 4. Press "Forward" in your browser >> >> If you try this with an official Trac this doesn't happen, so either >> this was fixed in a new version, or we have a plugin installed which >> is causing this to happen. >> >> Current version of Trac is 1.0.5, we're currently running 1.0.1 >> >> Thanks, >> Edward >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From ezyang at mit.edu Fri Apr 24 14:07:26 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 24 Apr 2015 15:07:26 +0100 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: References: <1429883680-sup-8002@sabre> Message-ID: <1429884427-sup-5668@sabre> Whatever the case, it affects me, it affects SPJ, so we ought to fix it! (Change your browser is not a good answer :) Edward Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100: > On the contrary, I did precisely that just a few days ago ( > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac > *did* save my new ticket text. Perhaps this is a browser-specific issue? > I'm using 64-bit Chrome 42.0.2311.90. > > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > > > Steps to reproduce: > > > > 1. Click "New Ticket" > > 2. Type some text into the box > > 3. Press "Back" in your browser > > 4. Press "Forward" in your browser > > > > If you try this with an official Trac this doesn't happen, so either > > this was fixed in a new version, or we have a plugin installed which > > is causing this to happen. > > > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > > > > Thanks, > > Edward > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From ecrockett0 at gmail.com Fri Apr 24 14:13:07 2015 From: ecrockett0 at gmail.com (Eric Crockett) Date: Fri, 24 Apr 2015 10:13:07 -0400 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: <1429884427-sup-5668@sabre> References: <1429883680-sup-8002@sabre> <1429884427-sup-5668@sabre> Message-ID: My Firefox also has this issue. So it seems the problem is the browser itself. How can this be fixed on the server side? On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang wrote: > Whatever the case, it affects me, it affects SPJ, so we ought to fix it! > (Change your browser is not a good answer :) > > Edward > > Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100: > > On the contrary, I did precisely that just a few days ago ( > > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac > > *did* save my new ticket text. Perhaps this is a browser-specific issue? > > I'm using 64-bit Chrome 42.0.2311.90. > > > > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > > > > > Steps to reproduce: > > > > > > 1. Click "New Ticket" > > > 2. Type some text into the box > > > 3. Press "Back" in your browser > > > 4. Press "Forward" in your browser > > > > > > If you try this with an official Trac this doesn't happen, so either > > > this was fixed in a new version, or we have a plugin installed which > > > is causing this to happen. > > > > > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > > > > > > Thanks, > > > Edward > > > _______________________________________________ > > > 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 fryguybob at gmail.com Fri Apr 24 14:15:37 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Fri, 24 Apr 2015 10:15:37 -0400 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: References: <1429883680-sup-8002@sabre> <1429884427-sup-5668@sabre> Message-ID: My very pessimistic rule of thumb is don't trust a form field unless the site actively saves a draft as you type. On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett wrote: > My Firefox also has this issue. So it seems the problem is the browser > itself. How can this be fixed on the server side? > > On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang wrote: > >> Whatever the case, it affects me, it affects SPJ, so we ought to fix it! >> (Change your browser is not a good answer :) >> >> Edward >> >> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100: >> > On the contrary, I did precisely that just a few days ago ( >> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, >> trac >> > *did* save my new ticket text. Perhaps this is a browser-specific issue? >> > I'm using 64-bit Chrome 42.0.2311.90. >> > >> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: >> > >> > > Steps to reproduce: >> > > >> > > 1. Click "New Ticket" >> > > 2. Type some text into the box >> > > 3. Press "Back" in your browser >> > > 4. Press "Forward" in your browser >> > > >> > > If you try this with an official Trac this doesn't happen, so either >> > > this was fixed in a new version, or we have a plugin installed which >> > > is causing this to happen. >> > > >> > > Current version of Trac is 1.0.5, we're currently running 1.0.1 >> > > >> > > Thanks, >> > > Edward >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs at haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Apr 24 14:20:35 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 24 Apr 2015 15:20:35 +0100 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: References: <1429883680-sup-8002@sabre> <1429884427-sup-5668@sabre> Message-ID: <1429885203-sup-4704@sabre> I've tried a few Firefox browser extensions which purport to "never lose your form text", but I find they just don't save frequently enough for my taste. I would love to know an extension that does this properly! Edward Excerpts from Ryan Yates's message of 2015-04-24 15:15:37 +0100: > My very pessimistic rule of thumb is don't trust a form field unless the > site actively saves a draft as you type. > > On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett > wrote: > > > My Firefox also has this issue. So it seems the problem is the browser > > itself. How can this be fixed on the server side? > > > > On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang wrote: > > > >> Whatever the case, it affects me, it affects SPJ, so we ought to fix it! > >> (Change your browser is not a good answer :) > >> > >> Edward > >> > >> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100: > >> > On the contrary, I did precisely that just a few days ago ( > >> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, > >> trac > >> > *did* save my new ticket text. Perhaps this is a browser-specific issue? > >> > I'm using 64-bit Chrome 42.0.2311.90. > >> > > >> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > >> > > >> > > Steps to reproduce: > >> > > > >> > > 1. Click "New Ticket" > >> > > 2. Type some text into the box > >> > > 3. Press "Back" in your browser > >> > > 4. Press "Forward" in your browser > >> > > > >> > > If you try this with an official Trac this doesn't happen, so either > >> > > this was fixed in a new version, or we have a plugin installed which > >> > > is causing this to happen. > >> > > > >> > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > >> > > > >> > > Thanks, > >> > > Edward > >> > > _______________________________________________ > >> > > ghc-devs mailing list > >> > > ghc-devs at haskell.org > >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > >> > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > From vagarenko at gmail.com Fri Apr 24 15:16:29 2015 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Fri, 24 Apr 2015 21:16:29 +0600 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: <1429885203-sup-4704@sabre> References: <1429883680-sup-8002@sabre> <1429884427-sup-5668@sabre> <1429885203-sup-4704@sabre> Message-ID: I don't know about an extension, but there is .js library https://github.com/simsalabim/sisyphus 2015-04-24 20:20 GMT+06:00 Edward Z. Yang : > I've tried a few Firefox browser extensions which purport to "never > lose your form text", but I find they just don't save frequently enough > for my taste. I would love to know an extension that does this > properly! > > Edward > > Excerpts from Ryan Yates's message of 2015-04-24 15:15:37 +0100: >> My very pessimistic rule of thumb is don't trust a form field unless the >> site actively saves a draft as you type. >> >> On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett >> wrote: >> >> > My Firefox also has this issue. So it seems the problem is the browser >> > itself. How can this be fixed on the server side? >> > >> > On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang wrote: >> > >> >> Whatever the case, it affects me, it affects SPJ, so we ought to fix it! >> >> (Change your browser is not a good answer :) >> >> >> >> Edward >> >> >> >> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100: >> >> > On the contrary, I did precisely that just a few days ago ( >> >> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, >> >> trac >> >> > *did* save my new ticket text. Perhaps this is a browser-specific issue? >> >> > I'm using 64-bit Chrome 42.0.2311.90. >> >> > >> >> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: >> >> > >> >> > > Steps to reproduce: >> >> > > >> >> > > 1. Click "New Ticket" >> >> > > 2. Type some text into the box >> >> > > 3. Press "Back" in your browser >> >> > > 4. Press "Forward" in your browser >> >> > > >> >> > > If you try this with an official Trac this doesn't happen, so either >> >> > > this was fixed in a new version, or we have a plugin installed which >> >> > > is causing this to happen. >> >> > > >> >> > > Current version of Trac is 1.0.5, we're currently running 1.0.1 >> >> > > >> >> > > Thanks, >> >> > > Edward >> >> > > _______________________________________________ >> >> > > ghc-devs mailing list >> >> > > ghc-devs at haskell.org >> >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > >> >> >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From k-bx at k-bx.com Fri Apr 24 17:15:47 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Fri, 24 Apr 2015 20:15:47 +0300 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: <1429883680-sup-8002@sabre> References: <1429883680-sup-8002@sabre> Message-ID: Not related to issue, but generally for Firefox I suggest an addon "Form History Control" (UI is not superb, but it does what it should do) https://addons.mozilla.org/uk/firefox/addon/form-history-control/ For Chrome, "Lazarus Form Recovery" used to work, but I'm not sure it still does, since it seemed abandoned. On Fri, Apr 24, 2015 at 4:54 PM, Edward Z. Yang wrote: > Steps to reproduce: > > 1. Click "New Ticket" > 2. Type some text into the box > 3. Press "Back" in your browser > 4. Press "Forward" in your browser > > If you try this with an official Trac this doesn't happen, so either > this was fixed in a new version, or we have a plugin installed which > is causing this to happen. > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > > Thanks, > Edward > _______________________________________________ > 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 Apr 24 17:17:45 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 24 Apr 2015 13:17:45 -0400 Subject: Can we fix our Trac that doesn't lose new ticket text In-Reply-To: <1429883680-sup-8002@sabre> References: <1429883680-sup-8002@sabre> Message-ID: At a guess, I recently had some websites start refreshing more than I thought they used to when using the back/forward buttons. From what I gather, this is due to the websites specifying no-cache or something similar in their HTTP (?) headers. I think reloading the page throws away entered text, while going back/forward to a stored page does not. Perhaps something the ghc trac is using is setting this? Or it could be something outside trac entirely? Also wouldn't surprise me if Chrome behaves differently with such a setting than Firefox. Not sure if that helps. On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang wrote: > Steps to reproduce: > > 1. Click "New Ticket" > 2. Type some text into the box > 3. Press "Back" in your browser > 4. Press "Forward" in your browser > > If you try this with an official Trac this doesn't happen, so either > this was fixed in a new version, or we have a plugin installed which > is causing this to happen. > > Current version of Trac is 1.0.5, we're currently running 1.0.1 > > Thanks, > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Apr 28 14:02:24 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 28 Apr 2015 16:02:24 +0200 Subject: API Annotations and 7.10.2 In-Reply-To: References: Message-ID: As you can see in the report below, there are a LOT of patches related to API Annotations. I am beginning to have difficulty keeping them up to date, as master moves ahead. I would like to request that as many of these as possible be merged into master sooner rather than later, subject to review approval. There can then be a secondary process to evaluate which of them actually belong in 7.10.2. If it would simplify things, I can collapse some of these into a mega patch. Regards Alan Report follows .... --------------------------------------------------------------- This is the current state of the patches proposed for 7.10.2 Landed in ghc-7.10 (thank you) #10207 D803 #10214 D806 Landed in master but not ghc-7.10 (also thank you) #10209 D813 #10256 D818 #10254 D822 #10255 D823 #10277 D829 Patches available #10269 D832 #10299 D840 * #10268 D825 * #10278 D833 * #10307 D842 * #10309 D848 * #10280 D834 #10287 D837 #10312 D846 #10354/#10315 D868 #10357 D869 #10358 D873 The ones marked with * form a dependent chain of merges Moved from 7.10.2 to 7.12 #10250 D815 The proposed patches all make minor changes to the Parser / RdrHsSyn, and do not affect the AST or Haddock, nor change the operation of the compiler. The one with the largest impact is D840, which corrects a conflict in the parser and now generates the correct type for '[] (`HsExplicitListTy` rather than `HsTyVar'). The merge process to produce https://github.com/alanz/ghc/tree/api-annotations is --------------------------- (2015-04-26) git checkout api-annotations git reset --hard master arc patch --nobranch D832 (cd libraries/Cabal && git checkout bda1ce6b757cdaca93f2eba4e1906a4658719537) to revert to the master libraries/Cabal submodule change) arc patch --nobranch D840 arc patch --nobranch D825 (manual fixup) arc patch --nobranch D833 (manual fixup) arc patch --nobranch D842 (manual fixup) arc patch --nobranch D848 (manual fixup) arc patch --nobranch D834 (manual fixup) arc patch --nobranch D837 (manual fixup) arc patch --nobranch D846 (manual fixup) arc patch --nobranch D868 (manual fixup) arc patch --nobranch D869 arc patch --nobranch D873 (manual fixup) On Fri, Apr 17, 2015 at 7:22 PM, Alan & Kim Zimmerman wrote: > This is the current state of the patches proposed for 7.10.2 > > Landed in ghc-7.10 (thank you) > #10207 D803 > #10214 D806 > > Landed in master but not ghc-7.10 (also thank you) > #10209 D813 > #10256 D818 > #10254 D822 > #10255 D823 > #10277 D829 > > Patches available > #10269 D832 > #10299 D840 * > #10268 D825 * > #10278 D833 * > #10307 D842 * > #10309 D848 * > #10280 D834 > #10287 D837 > #10312 D846 > > The ones marked with * form a dependent chain of merges > > Patches still to be finalised/provided > #10314 > #10315 > > Moved from 7.10.2 to 7.12 > #10250 D815 > > The proposed patches all make minor changes to the Parser / RdrHsSyn, and > do not affect the AST or Haddock, nor change the operation of the compiler. > > The one with the largest impact is D840, which corrects a conflict in the > parser and now generates the correct type for '[] (`HsExplicitListTy` > rather than `HsTyVar'). > > > The merge process to produce > https://github.com/alanz/ghc/tree/api-annotations is > > --------------------------- (2015-04-17) > git checkout -b api-annotations > arc patch --nobranch D832 > arc patch --nobranch D840 > arc patch --nobranch D825 (manual fixup) > arc patch --nobranch D833 > arc patch --nobranch D842 > arc patch --nobranch D848 (manual fixup) > arc patch --nobranch D834 (manual fixup) > arc patch --nobranch D837 (manual fixup) > arc patch --nobranch D846 (manual fixup) > -------------------------------------------------- > > I am really keen to get these landed, as being able to round-trip haskell > source using the annotations is the foundation of Matt Pickerings GSOC > proposal, and it would be a pity if it could not achieve its full potential. > > Regards > Alan > > > On Mon, Apr 13, 2015 at 12:14 AM, Alan & Kim Zimmerman < > alan.zimm at gmail.com> wrote: > >> This is the state of the nation for API Annotations for 7.10.2 >> >> The following are ready for merging, in the order proposed. The first >> four depend on each other. >> >> #10209 D813 >> #10256 D818 (depends D813) >> #10254 D822 (depends D818) >> #10269 D832 (depends D822) >> >> #10255 D823 >> >> #10268 D825 >> #10278 D833 (depends D825) >> >> #10280 D834 >> >> #10277 D829 >> >> #10287 D837 >> >> >> These are the commands I used to apply them to a freshly checked out ghc >> tree. The manual fixup is for Makefile, .gitignore, all.T, basically keep >> both legs each time. >> >> -------------------------- >> git checkout -b api-annotations >> arc patch --nobranch D832 >> arc patch --nobranch D823 (manual fixup) >> arc patch --nobranch D825 (manual fixup) >> arc patch --nobranch D834 (manual fixup) >> arc patch --nobranch D829 >> arc patch --nobranch D837 (manual fixup) >> arc patch --nobranch D833 (manual fixup) >> -------------------------- >> >> Once these are in, I do not think there will be anything else. >> >> Regards >> Alan >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecrockett0 at gmail.com Tue Apr 28 14:18:38 2015 From: ecrockett0 at gmail.com (Eric Crockett) Date: Tue, 28 Apr 2015 10:18:38 -0400 Subject: Fixing anchors in GHC docs Message-ID: I think I sent this out already, but never heard back. An issue was fixed in HsColour regarding HTML anchors in the GHC docs, documented here: https://github.com/haskell/hackage-server/issues/319 Apparently GHC devs upload their own documentation [to hackage], which means HsColour needs to be updated on your end so that anchors are correct the next time docs are generated. -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 30 15:14:38 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Apr 2015 15:14:38 +0000 Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr from local calls In-Reply-To: <20150430071014.3487.30528@phabricator.haskell.org> References: <20150430071014.3487.30528@phabricator.haskell.org> Message-ID: <7ba6366b5420439fa053eb3f90b1d337@DB4PR30MB030.064d.mgd.msft.net> Thanks! I've added a comment to the relevant Note to document the effect. Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 30 April 2015 08:10 | To: Simon Peyton Jones | Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr | from local calls | | nomeata added a subscriber: nomeata. | nomeata added a comment. | | Nice: -4% alloc in nofib/multiplier, -2.8% in nofib/minimax. ? | | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb61562feb876 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC | Cc: nomeata From d at davidterei.com Thu Apr 30 22:58:23 2015 From: d at davidterei.com (David Terei) Date: Thu, 30 Apr 2015 15:58:23 -0700 Subject: Roles, GND, Data.Coerce Message-ID: All, An issue that came up with GHC 7.8 was the design of Roles and Data.Coerce, with it's ability to break module abstractions by default, requiring programmers adopt explicit role annotations to enforce some types of invariants for abstract data types. Because of this issue, as of now, GND & Data.Coerce are still disabled in Safe Haskell. We'd like to change this but need feedback from everyone. I've written up a wiki page with lots of information on the issue: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles Please read, it has information on how Roles work, the problem it raises and subtleties in the current system. Possible paths forward are also there, but I'll include below. Please be aware that this discussion is about Roles in general, not specifically how when using -XSafe. Ideally we'd come up with a solution that works regardless of if using Safe Haskell or not. I personally like option (3), although it isn't clear to me how hairy the implementation would be. == Possible Paths Forward for Roles == 1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell. 2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe in Safe Haskell and warn users that they neednominal role annotations on ADTs. 3) In-scope constructor restriction for lifting instances -- The newtype constructor restriction for unwrapping instances could be extended to both data types, and the lifting instances of Data.Coerce. This is, GND & Coercing under a type constructor is allowed if (a) all involved constructors are in scope, or (b) the constructors involved have been explicitly declared to allow coercion without them being in scope. I.e., (b) allows library authors to opt-into the current GHC behavior. This would require new syntax, probably just an explicit deriving Coercible statement. 4) Change default role to nominal -- This will prioritize safety over GND, and the belief is that it may break a lot of code. Worse, that it will be an ongoing tax as role annotations will be needed to enable GND. 5) Nominal default when constructors aren't exported -- When a module doesn't export all the constructors of a data type, then the type parameters of the data type should default to nominal. This heuristic seems to capture somewhat the intention of the user, but given the practice of defining an Internal module that exports everything, it seems of limited use. 6) Nominal default in future -- Add a new extension, SafeNewtypeDeriving that switches the default role to nominal, but continue to provide a deprecated GND extension to help with the transition. The claims in support of representational roles as default though believe that nominal by default has an ongoing, continuous tax, not just a transition cost. So it isn't clear that any scheme like this satisfies that argument. 7) Safe Haskell Specific -- Many of the above approaches could be adopted in a Safe Haskell specific manner. This isn't ideal as it makes safe-inference harder and Safe Haskell less likely to remain viable going forward. Richard suggests one such idea. == The belief by many people seems to be that (4) and (6) would be too much of burden. I'd like to avoid (7) if possible. It isn't clear to me if (7) ends up better than (2). I'm going to try to setup some infastructure for compiling Hackage so that we can measure how impactful these changes would be. Cheers, David From dave.terei at gmail.com Thu Apr 30 22:58:48 2015 From: dave.terei at gmail.com (David Terei) Date: Thu, 30 Apr 2015 15:58:48 -0700 Subject: Generalized Newtype Deriving not allowed in Safe Haskell In-Reply-To: References: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Done, sent a new email thread out. Can find on wiki page here: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles On 13 April 2015 at 18:18, David Terei wrote: > Good advice. I'll set that up soon. > > On 13 April 2015 at 00:10, Simon Peyton Jones wrote: >> David >> >> If you would like to lead a debate, and drive it to a conclusion, that would be most helpful. >> >> Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate. Otherwise you risk misunderstandings, with red herrings being discussed repeatedly. >> >> Thanks >> >> Simon >> >> | -----Original Message----- >> | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of >> | David Terei >> | Sent: 12 April 2015 09:52 >> | To: Simon Peyton Jones >> | Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe >> | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell >> | >> | On 10 April 2015 at 01:48, Simon Peyton Jones >> | wrote: >> | > | prefer, such as only exporting the Coerce instance if all the >> | > | constructors are exported, it seems that the ship sailed on these >> | > >> | > Coercible is relatively recent; I don't think we should regard it as >> | cast in stone. >> | > >> | > But yes, the Coerbible instance of a newtype is only available when >> | the data constructor for the newtype is lexically in scope. >> | >> | Yes, so as you point out in the paper, this is done to preserve >> | abstractions, but the same rule isn't applied to data types since some >> | types like IORef don't even have constructors that can be in scope. >> | >> | Ideally I'd like to find a way forward that works for everyone and >> | isn't just a Safe Haskell mode setting. >> | >> | I think the first question is, are there situations where you'd want to >> | use `coerce` internally to a module but disallow it externally? The >> | role mechanism is a little awkward as it doesn't allow this (although >> | it does for newtype's). If yes, then I think we should start there. >> | >> | If it seems we don't need external vs internal control, then we could >> | simply change the default to be that GHC sets referential type >> | parameters to nominal and allows them to be weakened to referential >> | through role annotations. We could use hackage to test how much >> | breakage this would cause. >> | >> | The third option is something Safe Haskell specific, so probably >> | applying the newtype constructor rule to data types. >> | >> | > >> | > Simon >> | > >> | > | -----Original Message----- >> | > | From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf >> | > | Of David Terei >> | > | Sent: 10 April 2015 09:38 >> | > | To: Simon Peyton Jones >> | > | Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org >> | > | Subject: Re: Generalized Newtype Deriving not allowed in Safe >> | > | Haskell >> | > | >> | > | I'll prepare a patch for the userguide soon. >> | > | >> | > | As for something better, yes I think we can and should. It's on my >> | > | todo list :) Basically, the new-GND design has all the mechanisms >> | > | to be safe, but sadly the defaults are rather worrying. Without >> | > | explicit annotations from the user, module abstractions are >> | broken. >> | > | This is why we left GND out of Safe Haskell for the moment as it >> | is >> | > | a subtle and easy mistake to make. >> | > | >> | > | If the module contained explicit role annotations then it could be >> | > | allowed. The discussion in >> | > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions >> | > | that I prefer, such as only exporting the Coerce instance if all >> | > | the constructors are exported, it seems that the ship sailed on >> | > | these bigger changes sadly. >> | > | >> | > | Cheers, >> | > | David >> | > | >> | > | On 9 April 2015 at 00:56, Simon Peyton Jones >> | > | >> | > | wrote: >> | > | > There is a long discussion on >> | > | > https://ghc.haskell.org/trac/ghc/ticket/8827 >> | > | > about whether the new Coercible story makes GND ok for Safe >> | Haskell. >> | > | > At a type-soundness level, definitely yes. But there are other >> | > | > less-clear-cut issues like ?breaking abstractions? to consider. >> | > | The > decision on the ticket > (comment:36) seems to be: GND >> | stays >> | > | out of Safe Haskell for now, but > there is room for a better >> | > | proposal. >> | > | > >> | > | > >> | > | > >> | > | > I don?t have an opinion myself. David Terei and David Mazieres >> | > | are in > the driving seat, but I?m sure they?ll be responsive to >> | user input. >> | > | > >> | > | > >> | > | > >> | > | > However, I think the user manual may not have kept up with >> | #8827. >> | > | The >> | > | > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate >> | > | > constructor access control, by allowing untrusted code to >> | > | manipulate > protected data types in ways the data type author did >> | > | not intend, > breaking invariants they have established.? >> | vanished >> | > | from the 7.8 > user manual (links below). Maybe it should be >> | restored. >> | > | > >> | > | > >> | > | > >> | > | > Safe Haskell aficionados, would you like to offer a patch for >> | the >> | > | manual? >> | > | > And maybe also a less drastic remedy than omitting GND >> | altogether? >> | > | > >> | > | > >> | > | > >> | > | > Simon >> | > | > >> | > | > >> | > | > >> | > | > From: Omari Norman [mailto:omari at smileystation.com] > Sent: 09 >> | > | April 2015 02:44 > To: haskell Cafe > Subject: Generalized >> | Newtype >> | > | Deriving not allowed in Safe Haskell > > > > When compiling >> | code >> | > | with Generalized Newtype Deriving and the > -fwarn-unsafe flag, I >> | > | get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe >> | > | Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. >> | > | > >> | > | > >> | > | > >> | > | > I thought I remembered reading somewhere that GNTD is now part >> | of >> | > | the > safe language? The GHC manual used to state that GNTD is >> | not >> | > | allowed > in Safe > Haskell: >> | > | > >> | > | > >> | > | > >> | > | > >> | > | >> | https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- >> | > | ha >> | > | > skell.html#safe-language >> | > | > >> | > | > >> | > | > >> | > | > But this language on GNTD not being part of the safe language >> | was >> | > | > removed in the 7.8 manual: >> | > | > >> | > | > >> | > | > >> | > | > >> | > | >> | https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- >> | > | ha >> | > | > skell.html#safe-language >> | > | > >> | > | > >> | > | > >> | > | > The GHC release notes don't say anything about this one way or >> | > | the other. >> | > | > Thoughts? >> | > | > >> | > | > >> | > | > _______________________________________________ >> | > | > ghc-devs mailing list >> | > | > ghc-devs at haskell.org >> | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> | > | > >> | > _______________________________________________ >> | > ghc-devs mailing list >> | > ghc-devs at haskell.org >> | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs