April 2013 - ghc-devs

[PATCH] Stage1Only only builds stage 1
by Trevor Elliott 19 Apr '13

19 Apr '13

Hi Everyone, I created a ticket that includes some changes to allow the Stage1Only flag to only build stage 1. This makes it easier to build cross compilers where the target won't be a suitable environment to actually host a stage 2 compiler. http://hackage.haskell.org/trac/ghc/ticket/7841 Thanks! --trevor

1 0

Per-generation lists of weak pointers
by Akio Takano 19 Apr '13

19 Apr '13

Hi, I'm working on implementing per-generation lists of weak pointers to speed up garbage collection in programs that allocate a lot of weak pointers. I have a patch [1] that validates and gives a 3x speed up on a benchmark. However I'd like to ask for some advise before finishing and submitting the patch. [1] https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386… The problem is that since my patch splits the weak pointer list between generations, it no longer maintains the right order of weak pointers. This could cause finalizers added with addForeignPtrFinalizer to run in the wrong order. I can think of one way to fix it; to make sure that when a WEAK object gets promoted, it is always added to the front of the new list. So my questions are: - Would it be a correct fix? - If so, is it an acceptable fix? For example, is it too fragile a reasoning to rely on? Thank you in advance, Takano Akio

3 5

GHC 7.8 release redux
by Ben Gamari 18 Apr '13

18 Apr '13

Recently I tried to parse the flurry of activity in the "GHC 7.8 release?" thread which started in early February[1]. This was quite a long thread with a number of different facets. To avoid losing points in the noise, I thought it might be useful to summarize the major points (please comment if I've missed something major), * More steeping time was necessary for a stable 7.8 release * Core APIs change too quickly, we need to try harder to decouple API-breaking releases from releases with core compiler functionality * The solution for this might be the three channel approach proposed by Mark[2] * Splitting base further might help the reduce unnecessary breakages[3]. Work has continued in this direction since the thread concluded[4]. * Tracking performance regression with periodic runs of nofib would be useful[5] Quite a productive thread for a week of wallclock time. That being said, if I'm not mistaken one matter is notably absent: what is the plan for 7.8? Will it admit API breakage? Should we establish a timeframe for getting work in before a formal release candidate is cut? Of course, "let's just wait and see" is a perfectly reasonable response but it would be nice to see it clearly set down in writing to avoid future confusion. Cheers, - Ben [1] http://www.haskell.org/pipermail/ghc-devs/2013-February/000309.html [2] http://www.haskell.org/pipermail/ghc-devs/2013-February/000386.html [3] http://www.haskell.org/pipermail/ghc-devs/2013-February/000451.html [4] http://hackage.haskell.org/trac/ghc/wiki/SplitBase [5] http://www.haskell.org/pipermail/ghc-devs/2013-February/000332.html

2 1

Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
by Ian Lynagh 17 Apr '13

17 Apr '13

Hi Simon, On Tue, Apr 16, 2013 at 03:55:16PM -0000, GHC wrote: > #7436: Derived Foldable and Traversable instances become extremely inefficient due > to eta-expansion > > Comment(by simonpj): > > This one is fixed, just awaiting merging into 7.6.3 My suggestion was that we only fix #7748 in 7.6.3, as that seems to be a show-stopper. There are several other fixes that we would ordinarily merge into 7.6.3, but every change has a risk of causing a regression (after all, 7.6.2 made #7748 worse), and we want to get 7.6.3 out as quickly as possible (so as not to hold up the HP release) so we don't have the luxury of being able to have a long testing/RC phase. But if you think it's important enough, and the fix safe enough, please let me know and I'll merge it. Thanks Ian

2 1

Re: HP 2013.2 and GHC 7.6.2
by Mark Lentczner 17 Apr '13

17 Apr '13

Can anyone comment on the state of cabal, and in particular the version that was shipped with 7.6.2? We should only consider bumping that version if, like with 7.6.2, there is a major bug in it that will affect the Platform's users. If there is, we'll want to consider a point release in preference to a major bump to the "latest-n-greatest". Let's try to keep this last minute bumping to a minimum! On Tue, Apr 16, 2013 at 5:17 PM, Ivan Lazar Miljenovic < ivan.miljenovic(a)gmail.com> wrote: > On 16 April 2013 23:17, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > > Thanks for all the switft work. Here's my understanding of the situation: > > > > 7.6.2 has a bug (#7748) in it, which also appears in a lesser form in > 7.6.1. > > SPJ has a fix, that works for the minimal code given in the bug report. > > Others are now trying to verify it fixes the bug as it was discovered in > the > > wild, in the hets package. > > Assuming it does fix, Ian will prepare a 7.6.3 release which is just this > > bug fix as a delta from 7.6.2. > > Can we please get the version of Cabal bumped as well? > > > > > If that is the state of the world, then we'll delay the HP 2012.2.0.0 a > week > > for 7.6.3. > > > > - Mark > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic(a)gmail.com > http://IvanMiljenovic.wordpress.com >

7 11

Re: HP 2013.2 and GHC 7.6.2
by Carter Schonwald 16 Apr '13

16 Apr '13

Ivan, do you mean a cabal 1.18 release or...? On Tue, Apr 16, 2013 at 8:17 PM, Ivan Lazar Miljenovic < ivan.miljenovic(a)gmail.com> wrote: > On 16 April 2013 23:17, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > > Thanks for all the switft work. Here's my understanding of the situation: > > > > 7.6.2 has a bug (#7748) in it, which also appears in a lesser form in > 7.6.1. > > SPJ has a fix, that works for the minimal code given in the bug report. > > Others are now trying to verify it fixes the bug as it was discovered in > the > > wild, in the hets package. > > Assuming it does fix, Ian will prepare a 7.6.3 release which is just this > > bug fix as a delta from 7.6.2. > > Can we please get the version of Cabal bumped as well? > > > > > If that is the state of the world, then we'll delay the HP 2012.2.0.0 a > week > > for 7.6.3. > > > > - Mark > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic(a)gmail.com > http://IvanMiljenovic.wordpress.com > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Build faliing on Windows
by Simon Peyton-Jones 16 Apr '13

16 Apr '13

Argh! Again! The Windows build is failing. Here's the error: libraries\base\System\Posix\Types.hs:179:23: Not in scope: type constructor or class `CMode' make[1]: *** [libraries/base/dist-install/build/System/Posix/Types.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Indeed base/includes/HsBaseConfig.h says /* Define to Haskell type for mode_t */ /* #undef HTYPE_MODE_T */ which means CMode doesn't get defined. The config.log file looks suspicious, note the line in red. I'm stuck Simon configure:13967: checking Haskell type for mode_t configure:13974: c:/code/HEAD/inplace/mingw/bin/gcc.exe -o conftest.exe -Wall -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c >&5 configure:13974: $? = 0 configure:13974: ./conftest.exe configure:13974: $? = 0 configure:14230: c:/code/HEAD/inplace/mingw/bin/gcc.exe -o conftest.exe -Wall -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c >&5 c:/code/HEAD/inplace/mingw/bin/ld.exe: cannot open output file conftest.exe: Permission denied collect2: ld returned 1 exit status configure:14230: $? = 1 configure: program exited with status 1 configure: failed program was:

2 2

[PATCH] md5.c: fix a typo in the size argument of memset
by Michal Terepeta 16 Apr '13

16 Apr '13

Hi, Apparently GCC 4.8 has some new warnings that caught a typo in a memset call in libraries/base/cbits/md5.c. Patch attached. Cheers, Michal

2 1

RE: Haskell Platform 2013.2 Proposal Status
by Simon Peyton-Jones 16 Apr '13

16 Apr '13

I think we just need someone who is prepared to simultaneously build (a) ghc, (b) hets, to test my fix. My fix certainly fixes #7748. Simon | -----Original Message----- | From: Christian Maeder [mailto:Christian.Maeder@dfki.de] | Sent: 16 April 2013 09:32 | Cc: Simon Peyton-Jones; Mark Lentczner; ghc-devs(a)haskell.org | Subject: Re: Haskell Platform 2013.2 Proposal Status | | It is the changeset | http://trac.informatik.uni-bremen.de:8080/hets/changeset/17857 that | toggles the bug. | | C. | | Am 15.04.2013 18:02, schrieb Christian Maeder: | > Am 15.04.2013 16:43, schrieb Simon Peyton-Jones: | >> Bother. Which version of hets? How can I reproduce? | > | > A student added some (innocent) code and did not notice that it | > <<loop>>s for ghc-7.6.2. He used ghc-7.0.3 initially. | > | > He said that he found the spot where he needs to add a type signature | > to a local function. | > | > Accidentally, I've reverted our hets code in Rev. 17852 to avoid the | > broken code. | > | > reproducing the problem: | > | > svn co https://svn-agbkb.informatik.uni-bremen.de/Hets/trunk Hets | > svn co https://svn-agbkb.informatik.uni-bremen.de/Hets-lib/trunk | > Hets-lib | > cd Hets | > svn cat -r 17851 Proofs/AbstractState.hs > Proofs/AbstractState.hs | > cabal install # I hope this works for you | > make | > ./hets ../Hets-lib/Datatypes.hpf | > | > | > Analyzing library Datatypes | > Analyzing spec Datatypes#Nat | > Analyzing spec Datatypes#List | > Analyzing spec Datatypes#Partial_Order Analyzing spec | > Datatypes#Total_Order Analyzing spec | > Datatypes#ProblematicDefinitionOfSelectors | > Analyzing spec Datatypes#Char | > Analyzing spec Datatypes#String | > Analyzing spec Datatypes#StringList | > Analyzing spec Datatypes#UnboundedBranchingTree Adding comorphism | > hets: <<loop>> | > | > | > The worst thing is that "if it compiles it usually runs" is now less | > valid. There may be <<loop>>s lurking in hackage packages, that have | > not been hit by runtime tests. | > | > Christian | > | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: haskell-platform-bounces(a)projects.haskell.org | >> | [mailto:haskell- platform-bounces(a)projects.haskell.org] On Behalf | >> | Of Christian Maeder | >> | Sent: 12 April 2013 10:26 | >> | To: Mark Lentczner | >> | Cc: haskell-platform(a)projects.haskell.org; Haskell Libraries | >> | Subject: Re: Haskell Platform 2013.2 Proposal Status | >> | | >> | Hi, | >> | | >> | I just spoiled my day by | >> http://hackage.haskell.org/trac/ghc/ticket/7748 | >> | with ghc-7.6.2 in our large project: | >> | | >> | hets: <<loop>> | >> | | >> | hets works fine with ghc-7.6.1 (and older versions). I haven't | >> | located the error yet, though. | >> | | >> | Yet, I therefore conclude, GHC 7.6.2 ist not suited for the | >> | official | >> HP. | >> | | >> | Cheers Christian | >> | | >> | Am 11.04.2013 07:33, schrieb Mark Lentczner: | >> | > Well, I admit I am a bit tardy with this, and a few dates in the | >> | > schedule have come and gone. But have no fear, I think we'll be | okay. | >> | > | >> | > /*All: */ | >> | > Updated the time line the 2013.2 release: | >> | > | >> | > * *Today* - Call for proposals ends (no more proposals | considered) | >> | > * *April 15th* - Proposals decided, Initial version list | >> | > * *April 22th* - First candidates | >> | > * *April 29th* - Open issues resolved, Second candidates | >> | > * *May 6th* - Final release candidates | >> | > | >> | > /*Proposals:*/ | >> | > These are the proposals being considered for 2013.2, and my | >> | > current assessment of the "rough consensus": | >> | > | >> | > * *case-insensitive:* general consensus for including | >> | > * *attoparsec: *general consensus for including | >> | > * | >> | > * *unordered-containers:* general consensus for including | >> | > * *hashable:* while there has been much discussion about what | to do | >> | > going forward, I see general consensus that accepting version | 1.1 | >> | > into the platform (which is required by other proposals here) | >> | > * *OpenGL *&* GLUT:* these have been repackaged by Jason to | >> | > meet | >> all | >> | > the concerns of the community. They include two new lower- | level | >> | > packages *OpenGLRaw* and *GLURaw*. General consensus | >> | > for continuing to include, with the lower level packages, and | >> | > upgraded to latest versions (yay!) | >> | > * *JuicyPixels:* people like the idea of having a library like | this | >> | > one, perhaps even this one, but there is concern that this | API | >> | > hasn't baked enough. There is not enough consensus for | including. | >> | > | >> | > I give you all until Monday for any further discussion, and then | >> we'll | >> | > call it. | >> | > | >> | > /*Versions*/ | >> | > I now call it official: HP 2013.2 will use GHC 7.6.2. Library | >> | > maintainers: Please get ready to answer my e-mail when it come | >> | > a'knockin' on your inbox with the version of your lib we should | >> | > ship in this release. | >> | > | >> | > - Mark "Chief Haskell Gift-Wrapper" Lentczner | >> | > | >> | > | >> | > | >> | > | >> | > _______________________________________________ | >> | > Libraries mailing list | >> | > Libraries(a)haskell.org | >> | > http://www.haskell.org/mailman/listinfo/libraries | >> | > | >> | | >> | | >> | _______________________________________________ | >> | Haskell-platform mailing list | >> | Haskell-platform(a)projects.haskell.org | >> | http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platfo | >> | rm | >> | >> | >

2 1

Re: HP 2013.2 and GHC 7.6.2
by Ian Lynagh 16 Apr '13

16 Apr '13

On Tue, Apr 16, 2013 at 03:18:01PM +0200, Christian Maeder wrote: > Am 16.04.2013 14:29, schrieb Richard Eisenberg: > > > >git clone http://darcs.haskell.org/ghc.git; cd ghc; ./sync-all --testsuite get; perl boot; ./configure; make > > Thanks, for this. Do I need to give a branch name (which one?) to > the "git clone" command (option -b)? Yes, you need to add "-b ghc-7.6" to both the clone and the sync-all command. Docs are here: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Getting… Thanks Ian

1 0