August 2013 - ghc-devs

Committer list [was: Re: NOTICE: Gitolite migration is complete.]
by Austin Seipp 19 Aug '13

19 Aug '13

Sounds good to me. I've found the same info useful. In fact, just yesterday I had added the list of committers I assembled to the Contributors page: http://ghc.haskell.org/trac/ghc/wiki/Contributors I've gone ahead and created a Committers page with more info. It also lets people know who to contact (me) if they would like access, and should help people find out who to talk to when they need help. http://ghc.haskell.org/trac/ghc/wiki/Committers I went ahead and filled out most of the details on the people I'm aware of, except for email. I'm not sure what you'd like to publicly put out there on Trac. Developers - If you'd like, please take the time to fill in your email and amend anything I got wrong (e.g. I just put pretty much everyone's "committer date" as this month.) (Also, forgive me for looking into most peoples affiliations and listing them here, but it does help individual identification - and it's a decently diverse set of places, which is neat in its own right!) On Fri, Aug 16, 2013 at 5:54 AM, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > Herbert, Austin, Simon > > Thanks for taking charge of our git repos. Very very helpful! > > On the question of committers, there's always the danger that we give people commit permission, and several years later they've gone silent and we can barely remember who or why. I wonder if we should have a "Committers" wiki page, with a bullet for each person in this format: > > * Simon Peyton Jones, Microsoft Research, Cambridge, UK. Trac: simonpj; email: simonpj(a)microsoft.com. Added as a committer June 2013. Main areas of interest: renamer, type checker, optimiser. > > I often have trouble connecting people's Trac identity with their email; and it's quite helpful to know which country people are in and where they work. > > Do you think that would make sense? We could also establish the convention that if you don’t commit for a year you'll lose commit access; though it can be re-activated on request. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Austin > | Seipp > | Sent: 09 August 2013 23:20 > | To: ghc-devs(a)haskell.org > | Subject: NOTICE: Gitolite migration is complete. > | > | All, > | > | Push access is now restored and Gitolite is in place! This brings some > | nice updates: > | > | * There's now access to the 'git' protocol for cloning anonymously. > | This lets you clone even the biggest repos extremely quickly, and is > | the fastest method for getting a copy of the tree. > | * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, > | meaning it should be faster too! > | * We will soon have Gitweb available, once our git.haskell.org CNAME > | is in place. Eventually we'd like something akin to > | https://git.kernel.org/cgit/ possibly. > | * None of you have shell access to ghc.haskell.org anymore (well, > | this is a nice update for us administrators :) > | > | The following people have had their keys re-added, and should be able > | to push and pull from the new setup. > | > | * Andreas Voellmy > | * Austin Seipp > | * Ben Lippmeier > | * Iavor Diatchki > | * David Terei > | * David Waern > | * Dimitrios Vytiniotis > | * Duncan Coutts > | * Edsko de Vries > | * Erik de Castro Lopo > | * Edward Yang > | * Geoffrey Mainland > | * Gabor Greif > | * Herbert Valerio Riedel > | * Ian Lynagh > | * Ilya Sergey > | * Johan Tibell > | * José Pedro Magalhães > | * Jan Stolarek > | * Manuel Chakravarty > | * Max Bolingbroke > | * Nicholas Frisby > | * Paolo Capriotti > | * Richard Eisenberg > | * Roman Leshchinskiy > | * Ross Patterson > | * Simon Hengel > | * Simon Marlow > | * Simon Peyton Jones > | * Thomas Schilling > | > | The following people still have shell access for any administrative > | needs: > | > | * Austin Seipp (and the remaining haskell.org infrastructure team.) > | * Herbert Valerio Riedel > | * Ian Lynagh > | > | I have undoubtedly missed some people. Please talk to me and we'll get > | you set up! > | > | If you're a developer, please read about developer changes here: > | > | * http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan#Developerchanges > | > | TL;DR: if you have an old tree, run the following four commands from > | the root to fix the push/pull URLs. > | > | $ git checkout master > | $ git pull https://github.com/ghc/ghc.git master > | $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url origin > | $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin > | > | The reason you must get the latest-copy of ./sync-all is because > | Herbert made some last minute bug fixes. Technically, you could just > | download the latest copy and run it directly, but this is easier and > | fairly straight forward. > | > | Please direct any concerns to me, like if you need something off the > | server, need your shell account back, or need commit access. Over the > | next few days, I'll be cleaning up the wiki - updating references and > | guides on how to check out the source for users and developer. I also > | might be sending out some emails with questions while we refine the > | new setup in the next few days (there were some Trac integration > | changes.) > | > | Also, a gigantic applause for Herbert, who did a lot of the work here! > | > | -- > | Regards, > | Austin - PGP: 4096R/0x91384671 > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671

3 6

runghc on 32bit
by Kazu Yamamoto 18 Aug '13

18 Aug '13

Hi, The following code should print string anyway. https://gist.github.com/kazu-yamamoto/6265119/raw/1da32b8740222076e612373a7… But if I execute it with "runghc" on 32 bit Mac and 32 bit Linux, it terminates silently. If complied, it works. If I execute it with "runghc" on 64 bit Linux, it works. Does anyone reproduce this? I'm using GHC 7.7.20130814. --Kazu

1 0

Help needed: exporting pattern synonyms
by Dr. ERDI Gergo 16 Aug '13

16 Aug '13

Hi, As you can see in http://ghc.haskell.org/trac/ghc/ticket/5144#comment:18, my implementation of pattern synonyms is now feature complete for the first two sections of http://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms, namely, simple pattern synonyms and pattern-only synonyms. Bidirectional pattern synonyms using 'where' will also be easy to add and will be part of my initial submission. The current version of my code is at https://github.com/gergoerdi/ghc/compare/pattern-synonyms However, the one part I am struggling with is implementing exporting of pattern synonyms. The pipeline is pretty clear to get the pattern synonym definitions to the ModGuts, but I get lost there. Since they are a completely compile-time thing, there's nothing to put in the CgGuts (well, I guess the wrapper (i.e. the patsyn-in-an-expression-context) should be put there). However, when I look at existing stuff in ModIface/ModDetails, I don't really see a pattern for storing actual definitions there. Could someone help me with this part please? Would it make sense to put something like https://raw.github.com/gergoerdi/ghc/pattern-synonyms/compiler/basicTypes/P… in the interface? Or put the "psPatDef" and the "fmap snd psWrapper" parts in the CgGuts and the rest in the interface? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------'

1 0

FW: Building GHC on Mac stops
by Simon Peyton-Jones 15 Aug '13

15 Aug '13

Austin This looks like a make-system bug, based on a cursory read. Worth a ticket? Do you know enough about the build system to fix it? It's clearly annoying! Simon Marlow and/or Ian Lynagh may well be able to help Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu Yamamoto Sent: 06 August 2013 13:00 To: ghc-devs(a)haskell.org Subject: Re: Building GHC on Mac stops Hi Nicolas, My guess is here: libraries/integer-gmp/configure generates "gmp.h". Building mkGmpDerivedConstants starts in parallel. Since "configure" takes time, "mkGmpDerivedConstants" is build before "gmp.h" is created. How can we ensure that these two jobs are carried out sequentially? --Kazu > I never determined how to fix this. Here's the notes I developed: > > tl;dr For some reason, it seems gmp.h is not recognized as a dependency of > mkGmpDerivedConstants.o > > HTH > > ----- > > If I run > > $ perl boot; ./configure; make -j4 > > I tend to see a build failure. Immediately running make -j4 again succeeds. > > In the following snippet from the log, > FILE=libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c > > {{{ > "/usr/bin/gcc" -m64 -fno-stack-protector > -Ilibraries/integer-gmp/gmp > -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist > -c FILE -o > libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o > > FILE:15:17: error: gmp.h: No such file or directory > FILE: In function ¡main¢: > FILE:68: error: ¡MP_INT¢ undeclared (first use in this function) > FILE:68: error: (Each undeclared identifier is reported only once > FILE:68: error: for each function it appears in.) > FILE:69: error: expected expression before ¡)¢ token > FILE:69: error: expected expression before ¡)¢ token > FILE:70: error: expected expression before ¡)¢ token > FILE:70: error: expected expression before ¡)¢ token > FILE:71: error: expected expression before ¡)¢ token > FILE:71: error: expected expression before ¡)¢ token > make[1]: *** > [libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o] > Error 1 > make[1]: *** Waiting for unfinished jobs.... > }}} > > Some 1677 lines later, I see the line > >> cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/ > > Which is I suppose why make -j4 succeeds the second time around. > > I also see > >> libraries/integer-gmp/mkGmpDerivedConstants/ghc.mk:20: > libraries/integer-gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm: No > such file or directory > > many lines above. > > On Mon, Aug 5, 2013 at 9:26 PM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > >> Hi, >> >> I'm using GHC head (32bit) on Mac. Recently, building GHC head >> stops: >> >> ---- >> % make maintainer-clean; perl boot; ./configure --prefix=/ghc-head; make >> -j3 >> ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols >> ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols >> ranlib: file: .libs/libgmp.a(obvprintf.o) has no symbols >> ranlib: file: .libs/libgmp.a(obprntffuns.o) has no symbols >> ranlib: file: .libs/libgmp.a(repl-vsnprintf.o) has no symbols >> libtool: link: rm -fr .libs/libgmp.lax >> libtool: link: ( cd ".libs" && rm -f "libgmp.la" && cp -p "../libgmp.la" " >> libgmp.la" ) >> cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/ >> cp libraries/integer-gmp/gmp/gmpbuild/.libs/libgmp.a >> libraries/integer-gmp/gmp/ >> inplace/bin/mkdirhier libraries/integer-gmp/gmp/objs >> cd libraries/integer-gmp/gmp/objs && /usr/bin/ar x ../libgmp.a >> ranlib libraries/integer-gmp/gmp/libgmp.a >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(mp_clz_tab.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprintf.o) has no symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obvprintf.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprntffuns.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(repl-vsnprintf.o) has no >> symbols >> make: *** [all] Error 2 >> % >> ---- >> >> One more "make -j3" finishes the building. I'm sure that this does not >> happen before. >> >> Are there any guys who get this problem? >> >> --Kazu >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

3 3

Change return type for Int64# and Word64# comparisons?
by Luite Stegeman 15 Aug '13

15 Aug '13

Hi all, With the recent change of comparison primops to return Int# instead of Bool, the 64 bit operations were also changed, to return Int64# or Word64#: https://github.com/jstolarek/packages-ghc-prim/commit/07920f03d76dbaec64e38… It seems a bit wasteful to me to return a value bigger than a machine word for just a boolean. Changing the type to Int# would make the same optimizations possible as for the native-sized primops (though for me personally Bool would be even better since they map to JavaScript bools in GHCJS). thoughts? luite

4 4

NOTICE: Gitolite migration is complete.
by Austin Seipp 15 Aug '13

15 Aug '13

All, Push access is now restored and Gitolite is in place! This brings some nice updates: * There's now access to the 'git' protocol for cloning anonymously. This lets you clone even the biggest repos extremely quickly, and is the fastest method for getting a copy of the tree. * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, meaning it should be faster too! * We will soon have Gitweb available, once our git.haskell.org CNAME is in place. Eventually we'd like something akin to https://git.kernel.org/cgit/ possibly. * None of you have shell access to ghc.haskell.org anymore (well, this is a nice update for us administrators :) The following people have had their keys re-added, and should be able to push and pull from the new setup. * Andreas Voellmy * Austin Seipp * Ben Lippmeier * Iavor Diatchki * David Terei * David Waern * Dimitrios Vytiniotis * Duncan Coutts * Edsko de Vries * Erik de Castro Lopo * Edward Yang * Geoffrey Mainland * Gabor Greif * Herbert Valerio Riedel * Ian Lynagh * Ilya Sergey * Johan Tibell * José Pedro Magalhães * Jan Stolarek * Manuel Chakravarty * Max Bolingbroke * Nicholas Frisby * Paolo Capriotti * Richard Eisenberg * Roman Leshchinskiy * Ross Patterson * Simon Hengel * Simon Marlow * Simon Peyton Jones * Thomas Schilling The following people still have shell access for any administrative needs: * Austin Seipp (and the remaining haskell.org infrastructure team.) * Herbert Valerio Riedel * Ian Lynagh I have undoubtedly missed some people. Please talk to me and we'll get you set up! If you're a developer, please read about developer changes here: * http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan#Developerchanges TL;DR: if you have an old tree, run the following four commands from the root to fix the push/pull URLs. $ git checkout master $ git pull https://github.com/ghc/ghc.git master $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url origin $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin The reason you must get the latest-copy of ./sync-all is because Herbert made some last minute bug fixes. Technically, you could just download the latest copy and run it directly, but this is easier and fairly straight forward. Please direct any concerns to me, like if you need something off the server, need your shell account back, or need commit access. Over the next few days, I'll be cleaning up the wiki - updating references and guides on how to check out the source for users and developer. I also might be sending out some emails with questions while we refine the new setup in the next few days (there were some Trac integration changes.) Also, a gigantic applause for Herbert, who did a lot of the work here! -- Regards, Austin - PGP: 4096R/0x91384671

7 14

Yet Another Hoopl Question
by Jan Stolarek 15 Aug '13

15 Aug '13

I have yet another Hoopl question. One of my rewrites allocates a new unique local register and this register is later added as a fact. So I have Cmm code that looks like this: I32[(old + 4)] = complicated_expr which is rewritten to: newReg1 = complicated_expr I32[(old + 4)] = newReg1 and then I add { I32[(old + 4)] = newReg1 } as a fact. When Hoopl reaches end of the iteration it realizes it has learned some new facts, so it keeps the facts (including fact about a new unique register) and discards rewritten graph (including said new register). In the next iteration it performs the rewrite again, allocating a different new register and adding fact about this different register. At the end of this iteration same thing happens again: facts are kept, rewrite is discarded. And so my code falls into an infinite loop, because every time I'm allocating a different register and every time hoopl thinks it learned sth new and discards the rewritten graph. How can I perform this rewrite and avoid falling into a loop? Janek

4 5

RE: [GHC] #7574: Register allocator chokes on certain branches with literals
by Simon Peyton-Jones 15 Aug '13

15 Aug '13

Austin thanks for adding the test. But don't forget to populate the "Test case" field of the ticket; I've done it for this one. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC | Sent: 14 August 2013 07:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7574: Register allocator chokes on certain branches with | literals | | #7574: Register allocator chokes on certain branches with literals | ---------------------------------------+----------------------------------- | Reporter: thoughtpolice | Owner: thoughtpolice | Type: bug | Status: new | Priority: highest | Milestone: 7.8.1 | Component: Compiler (NCG) | Version: 7.7 | Resolution: | Keywords: ncg, codegen | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time crash | Unknown/Multiple | Test Case: | Difficulty: Unknown | Blocking: | Blocked By: 7573 | | Related Tickets: #7571,#7534 | ---------------------------------------+----------------------------------- | | Comment (by Austin Seipp <aseipp@…>): | | In [changeset:647875eacb313b97af5525dc92df98ec32171d16/testsuite]: | {{{ | #!CommitTicketReference repository="testsuite" | revision="647875eacb313b97af5525dc92df98ec32171d16" | Add a failing test, see #7574. | | Signed-off-by: Austin Seipp <aseipp(a)pobox.com> | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7574#comment:19> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

Re: primitive package with new Int# primops
by Jan Stolarek 14 Aug '13

14 Aug '13

Hi Luite, I applied my patches only to primitive package stored as a boot library in GHC repositories. My changes should probably be ported upstream to main repo of primitive package, but I admit I don't know what the workflow for this is. If you desperately need latest version of primitive working with GHC HEAD you can port my changes manually - it's only three lines of code! Janek Dnia środa, 14 sierpnia 2013, napisałeś: > hi Jan and Roman, > > I'm trying to install the primitive package with the latest GHC HEAD, > however the version available at > > https://github.com/ghc/packages-primitive > > which includes the primops changes, appears to be based on version 0.4 and > is missing setByteArray. The code.haskell.org repository does have > setByteArray but not the primops updates. Is there an updated version 0.5 > somewhere available? > > cheers, > > Luite

2 1

config.status: error: cannot find input file: `include/HsTimeConfig.h.in'
by Peter Simons 14 Aug '13

14 Aug '13

Hi guys, I have trouble building recent snapshots of the compiler, despite the fact that the build bot says they ought to build fine. The error I'm getting is this one: configure: creating ./config.status config.status: error: cannot find input file: `include/HsTimeConfig.h.in' make[1]: *** [libraries/time/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 A complete build log is at <http://hydra.cryp.to:8080/build/7563/nixlog/2/>. Is this a known issue? Best regards, Peter

2 1