April 2014 - ghc-devs

Git problem
by Simon Peyton Jones 17 Apr '14

17 Apr '14

Friends I'm stuck with Git. Help please! Simon I tried to do a 'git stash pop', having just done a 'git pull' from the master repo. I got this: simonpj@cam-05-unx:~/code/HEAD-2$ git stash pop warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) Auto-merging utils/haddock CONFLICT (submodule): Merge conflict in utils/haddock Auto-merging compiler/typecheck/TcRnMonad.lhs Now git status says simonpj@cam-05-unx:~/code/HEAD-2$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: compiler/typecheck/TcMType.lhs # modified: compiler/typecheck/TcRnMonad.lhs # modified: compiler/typecheck/TcSimplify.lhs # modified: compiler/typecheck/TcUnify.lhs # # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: utils/haddock The modified files are right. It's the "both modified utils/haddock" that is messing me up. I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying # modified: utils/haddock (new commits)

4 4

Link failure
by Simon Peyton Jones 17 Apr '14

17 Apr '14

On 64-bit Linux I'm getting this in the link step for the template-haskell library: /usr/bin/ld: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: relocation R_X86_64_PC32 against undefined symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so] Error 1 make[1]: *** [all_libraries/template-haskell] Error 2 make[1]: Leaving directory `/5playpen/simonpj/HEAD-1' My compiler is not vanilla HEAD, but I have changed only stuff in the Core simplifier, nothing in the back end. Does anyone have the faintest idea what is going on? It's extremely annoying because I can't make progress without working around it somehow. Thanks Simon

1 1

ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable)
by Alain O'Dea 17 Apr '14

17 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get the following error every time I run the ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) This appears to be the kernel returning EAGAIN (non-fatal) on an IO request. I'm not sure why it crashes the builder-client. I would expect hGetLine to retry in this case. I'm running this on SmartOS, which is an Illumos (OpenSolaris 10 compatible) distro. Here's a log of an entire run: https://gist.github.com/AlainODea/12a74a05b52c334614d9 Here's a snippet around the problem: Running "touching clean-check files" Running "setting version date" Running "booting" builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) [2014-04-17 02:21:08] [smartos-x86-head] Sending: "UPLOAD 14 1" Received: "202 Send name" Received: "202 Send subdir" Received: "202 Send program" Has anyone seen something like this before? Thanks, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTT0ApAAoJEP0rIXJNjNSAFbcH/29X7XvvMjGg/DWocap7D40f QOrVNTAipRcRSvEeCQh61hAAouabC2MkXts/8qM171xSghHArlYqe5XLkeKUDpo+ RiuyQER2t5fiZU1u8TywdMOm0NegxySiltEKooKpWzIzDzZHX7ggDUQlWTVzFgmR S50OsF8z9i3t8EF4N23J/Y78qca97iTn+Rw9qYl8Nc4vbhd+1Mqrsd25KDBK73Vk 5Hzy+HFy6yaJIEF3Rpda1Wr1CYKT4mwW6wAoTOeAK3obogwWX1mBzpV4MDt/5NBZ 9qet+2n59jkk0aaXJszXqNz4T0MTpMXgummjiLghyxtFJu71bvv3Xs6FXwgP23I= =6fKZ -----END PGP SIGNATURE-----

1 0

7.8.2 bugs and beyond
by Austin Seipp 16 Apr '14

16 Apr '14

Hello all, 7.8.1 is out. Yay! Now, on to the next thing. Here's the very preliminary 7.8.2 buglist: - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 Note that this list has effectively received zero curation so far. I plan on fixing that soon, and in the process I am probably going to touch a lot of trac tickets (so I apologize in advance for the mail spam, because y'all are probably going to get a lot of it). This will include re-prioritizing these bugs, so take things with a grain of salt right now. Note that the bug tracker now has 7.8.1 as the default version - if you're filing bugs, please be sure to try it first of course. :) And don't forget to set the milestone to 7.8.2 if you think it qualifies for a fix. There are already a couple of things in the merge queue. There's currently no expected date for 7.8.2. Should it arrive quickly? Or slowly? Simon, Simon and I are inclined to just let things play out for a while of course, which is the traditional way things are done. But this release window has been especially awkward, so we'll see what happens. This of course leaves timeline questions for 7.10 open - but before we decide that, now's a time to just get some hacking done I suppose... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 6

The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
by Páli Gábor János 15 Apr '14

15 Apr '14

The failing command: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140414 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Interface/Create.hs -o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/src/Haddock/Interface/Create.hs:367:44: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a1, Located (HsBind id))' Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) Actual type: TyClDecl Name -> LHsBinds Name Relevant bindings include defs :: [Located (HsDecl id)] (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) In the second argument of '(.)', namely 'tcdMeths' In the second argument of '(.)', namely 'bagToList . tcdMeths' utils/haddock/src/Haddock/Interface/Create.hs:393:22: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a0, Located (HsBind Name))' Expected type: HsValBindsLR Name Name -> [(a0, Located (HsBind Name))] Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] In the first argument of '(.)', namely 'valbinds' In the second argument of '(.)', namely 'valbinds . hs_valds' gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 gmake: *** [all] Error 2 Please consult the details at http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html

7 6

Help with coercion & roles?
by Conal Elliott 14 Apr '14

14 Apr '14

I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) "tpl"#) `cast` (<LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) ∷ LambdaCCC.Lambda.EP (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin <LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal

3 7

Re: [commit: ghc] master: Fix linked list manipulation code (buggy on consecutive deletion) (e3938f3)
by Simon Marlow 14 Apr '14

14 Apr '14

Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please? Cheers, Simon On 13/04/2014 07:37, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244c… > >> --------------------------------------------------------------- > > commit e3938f3adac0093b23694fd347774244ce121478 > Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> > Date: Sat Apr 12 23:02:13 2014 -0700 > > Fix linked list manipulation code (buggy on consecutive deletion) > > Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> > > >> --------------------------------------------------------------- > > e3938f3adac0093b23694fd347774244ce121478 > rts/CheckUnload.c | 3 ++- > rts/Linker.c | 6 ++++-- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c > index f1f454c..98f184b 100644 > --- a/rts/CheckUnload.c > +++ b/rts/CheckUnload.c > @@ -298,7 +298,7 @@ void checkUnload (StgClosure *static_objects) > // marked as unreferenced can be physically unloaded, because we > // have no references to it. > prev = NULL; > - for (oc = unloaded_objects; oc; prev = oc, oc = next) { > + for (oc = unloaded_objects; oc; oc = next) { > next = oc->next; > if (oc->referenced == 0) { > if (prev == NULL) { > @@ -312,6 +312,7 @@ void checkUnload (StgClosure *static_objects) > } else { > IF_DEBUG(linker, debugBelch("Object file still in use: %" > PATH_FMT "\n", oc->fileName)); > + prev = oc; > } > } > > diff --git a/rts/Linker.c b/rts/Linker.c > index af26d74..ab235e9 100644 > --- a/rts/Linker.c > +++ b/rts/Linker.c > @@ -3016,8 +3016,8 @@ unloadObj( pathchar *path ) > IF_DEBUG(linker, debugBelch("unloadObj: %" PATH_FMT "\n", path)); > > prev = NULL; > - for (oc = objects; oc; prev = oc, oc = next) { > - next = oc->next; > + for (oc = objects; oc; oc = next) { > + next = oc->next; // oc might be freed > > if (!pathcmp(oc->fileName,path)) { > > @@ -3075,6 +3075,8 @@ unloadObj( pathchar *path ) > /* This could be a member of an archive so continue > * unloading other members. */ > unloadedAnyObj = HS_BOOL_TRUE; > + } else { > + prev = oc; > } > } > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Has the behavior of -fno-ghci-sandbox changed with ghc-7.8.2?
by Dominick Samperi 13 Apr '14

13 Apr '14

I ticket #8371 I reported a problem using embedded R with ghci (no problem when application is compiled with ghc). The work-around was to use the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting a new thread (R is not thread-safe). This worked fine with pre-release ghci 7.7 (built from source using BuildFlavour = quick), but now I get a segfault on startup using ghci 7.8.2, suggesting that the behavior of -fno-ghci-sandbox may have changed, perhaps because of the way the Linux binary distribution was built. Has the behavior of -fno-ghci-sandbox changed, or could it have been changed because of the way the Linux binary distribution was built? BTW, I would have posted this as a follow-up to the ticket but I forgot my password. How does one reset the password on the ticket tracker site? Thanks, Dominick

1 1

Validation failures on master
by Dr. ERDI Gergo 12 Apr '14

12 Apr '14

The ultimate case of 'the pot calling the kettle black'[*]: I'm seeing validation errors on 'master' 7233638: Unexpected passes: arrows/should_fail arrowfail001 (normal) lib/integer integerConstantFolding (normal) [*] just to be clear, I mean me being the pot in this case:)

1 0

Defined but not used in TcPatSyn
by Joachim Breitner 12 Apr '14

12 Apr '14

Hi, someone introduced a validate error recently: compiler/typecheck/TcPatSyn.lhs:324:19: Warning: Defined but not used: `lit' compiler/typecheck/TcPatSyn.lhs:325:17: Warning: Defined but not used: `n' Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 4