- ghc-devs - Haskell.org

RE: concrete syntax for role annotations
by Simon Peyton-Jones 23 Aug '13

23 Aug '13

(Adding ghc-devs, who will, I hope, have opinions) I'm sympathetic to this. In general our story for pragmas {-# blah #-} is that they affect only optimisation (eg INLINE) or warnings (eg DEPRECATED). You can ignore/leave them out. But here you really can't. Well, I suppose leaving out the annotation does not risk soundness (as in run-time seg-fault); it just risks sets being ordered wrong. I don't have a strong opinion here. You could also imagine other syntaxes e.g. data Set a(role N) = ... I suppose. You are right that we need to get this nailed for 7.8, so we don't end up changing it later. Simon From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 23 August 2013 05:52 To: Simon Peyton-Jones; Dimitrios Vytiniotis; Stephanie Weirich Subject: concrete syntax for role annotations Hi all, On a Reddit discussion of my recent blog post on roles (http://www.reddit.com/r/haskell/comments/1kgivs/roles_a_new_feature_of_ghc_…) it was suggested that a better syntax is available for specifying role annotations. Currently, I've implemented > data Set a@N = ... to mark Set's parameter's role as N. The suggested syntax is > data Set a {-# ROLE N #-} = ... This suggested syntax is certainly much more verbose, but it's fully backwards-compatible, avoiding the need for preprocessing statements in libraries. These annotations should hopefully be few and far between, and I just think it's worth considering the backwards-compatible syntax before 7.8 is released and we're stuck. What do we think? Should I forward the question to glasgow-haskell-users, perhaps? Richard

1 0

Haskell platform
by Simon Peyton-Jones 23 Aug '13

23 Aug '13

Urk. The Haskell Platform claims to include Happy and Alex. http://www.haskell.org/platform/contents.html But 2013.2.0.0 doesn't. Is that intentional? That's a big problem for people using HP to build GHC. I'm installing 2012.4.0.0 in the hope that it does. No, nor does 2012.2 Am I just being stupid here? Simon

2 1

Re: Building on windows
by Kyle Van Berendonck 23 Aug '13

23 Aug '13

Additionally, if you're using the latest MinGW it ships with GCC 4.7 and fails with an error I reported and thoughtpolice replied here; http://ghc.haskell.org/trac/ghc/ticket/7056#comment:9 There's a patch that (with some hacking, namely, fixing the missing bracket) will bring GHC to build. It later faults again, though. http://lpaste.net/92097 Windows needs some love :(

1 0

HEADS UP: interface file change
by Austin Seipp 22 Aug '13

22 Aug '13

Hi all, I merged patches from #8144 into HEAD to fix nasty recompilation-checking behavior. As a result, the interface format has changed, so you'll need to clean your tree the next time you sync up. -- Regards, Austin - PGP: 4096R/0x91384671

1 0

Reproducible build recipes for GHC development VMs?
by Ryan Newton 22 Aug '13

22 Aug '13

Hi all, Returning to the topic discussed by Simon M. and others here: http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html This is my attempt at a script for bootstrapping a GHC-validating VM: http://parfunk.blogspot.com/2013/08/zero-to-ghc-development-in-ubuntu-vm-in… Let me know if there's a better way, or if you'd like to help get this kind of thing into an even more accessible form (Amazon AMI, Chef recipe, etc). Cheers, -Ryan

4 6

how to checkout proper submodules
by Kazu Yamamoto 22 Aug '13

22 Aug '13

Hi, Andreas and I found that the new IO manager is not working properly in the current GHC head. I'm sure that it worked well at least on May 7. We need to narrow the range of commits, so I did: % git checkout bb2795db36b36966697c228315ae20767c4a8753 % git submodule update But this does not checkout proper submodules. For instance, libraries/base has newer commits. And of cource, building fails. Please tell us how to checkout proper submodules against a specific GHC tree. --Kazu

21 43

Active Branches
by Austin Seipp 22 Aug '13

22 Aug '13

All, A while back, Nicolas Frisby compiled a small list of the currently active branches in the GHC tree. I would like to clean up a lot of the existing branches which are effectively dead (by deleting them.) At the same time, it's nice to take inventory and see what's currently out there, or 'in limbo'. http://ghc.haskell.org/trac/ghc/wiki/ActiveBranches I have kept up with *most* of the branches, and filled out a bunch of details above, greatly expanding the list. However, several are light on details and I'm not sure what's up with all of them, so I'd appreciate your input if you own a branch. I do however, believe all the 'dead' branches are accurate. If you're working on a branch, please note it here. I'd like for people to keep better track of this with a small note on this page; perhaps putting a link on the front of the wiki is a good idea. I'd like to be able to delete a lot of the defunct branches sometime soon, so just let me know in the mean time. -- Regards, Austin - PGP: 4096R/0x91384671

2 1

Re: [commit: testsuite] master: linker_unload fails when using dynamic GHCi. (a5875c4)
by Simon Marlow 22 Aug '13

22 Aug '13

On 22/08/13 19:24, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/testsuite > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516a… > >> --------------------------------------------------------------- > > commit a5875c4e4fb83993142c8e8294b47516adf6a77f > Author: Austin Seipp <aseipp(a)pobox.com> > Date: Thu Aug 22 13:22:22 2013 -0500 > > linker_unload fails when using dynamic GHCi. > > This is because dynamic GHCi can't load archive files, and linker_unload > explicitly does this via loadArchive(). Sigh. I've no idea why the linker has an explicit check for this, there's no reason why it can't work. I'll fix it. Cheers, Simon

2 1

Validate failures
by Austin Seipp 22 Aug '13

22 Aug '13

Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: =====> T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts && $MAKE -s --no-print-directory T7037 </dev/null >T7037.run.stdout 2>T7037.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr 2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST="atomicinc" ... =====> atomicinc(normal) 15 of 41 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main >atomicinc.comp.stderr 2>&1 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671

2 3

DPH tests
by Jan Stolarek 22 Aug '13

22 Aug '13

When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing. What would DPH team and others say to disabling these tests temporarily? I think that since February there hasn't been much going on in the DPH repository and compiler/vectorize folder. We'd have thhese tests enabled again when work on DPH picks up again. Janek

3 4