- ghc-devs - Haskell.org

user001 failure
by Simon Peyton Jones 23 Sep '14

23 Sep '14

I'm getting a testsuite failure on Linux ../../libraries/unix/tests user001 [bad stdout] (normal) The error message is below. Does anyone have any ideas? Simon Actual stdout output differs from expected: --- ../../libraries/unix/tests/user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ../../libraries/unix/tests/user001.run.stdout 2014-09-23 11:06:06.300082329 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal)

2 1

How to catch errors/unsolved constraints from GHC type checker?
by Andreas Abel 22 Sep '14

22 Sep '14

Hi, I am stuck fixing issue #9582 https://ghc.haskell.org/trac/ghc/ticket/9582 I need to test whether one type is a subtype of another and throw a custom error if this is not the case. I tried (errMsgs, result) <- tryTcErrs $ tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty case result of Just _coercion -> return () Nothing -> badInstSigErr sel_name local_meth_ty However, it does not seem to do what I expect. It acts as if I had not tried to catch the error, it acts as just tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty My hypothetical explanations: 1. 'tryTcErrs' is not the correct function to catch errors in the type checker. Or, 2. 'tcSubType' does not generate errors, just postponed constraints, which are checked later in a clean-up phase. Thus, I do not get an error now I could handle, but the error is generated later during the constraint solving phase, where I do not have a handler in place. In this case, I would need something like Agda's noConstraints, tryTcErrs $ noConstraints $ tcSubType... which forces 'tcSubType' to check without generating new unification constraints. Any advice how to do is or where to continue searching? Thanks, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

2 1

Permitting trailing commas for record syntax ADT declarations
by Alexander Berntsen 22 Sep '14

22 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - From a lead-developer-who-merges-a-lot point of view, trailing commas in import lists are a godsend. import Foo ( fu, baz, quux, ) is brilliant. It lets me add a line, + foobar, and remove a line, - - fu, in a very neat manner. Annoying 3-way merges be gone! It would be *very* useful if the same behaviour existed for record syntax. I wish this existed on an almost daily basis, data Foo a b = MkFoo { fu :: a, ba :: b, } If there's not too much opposition to the idea, I would like to take a stab at implementing this. Any pointers on *how* to implement it, would be very useful as I'm not familiar with the codebase outside of libraries/base at all. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgE3kACgkQRtClrXBQc7WHLQD/V9bHhC9ekobxxB5j7ZwAVj8e G3pQr4jmLAOFHkdSs/EBAIybHdSVXQlQ1fFTpLUzB/EIDLpiHlKKlU4tG01hYUhp =A1Ky -----END PGP SIGNATURE-----

1 1

FFI library error building GHC
by David Feuer 20 Sep '14

20 Sep '14

I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not. Suggest removing libffi/stamp.ffi.static-shared.install. make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

2 2

Re: FFI library error building GHC
by member MP2E 20 Sep '14

20 Sep '14

Filed a bug under GHC Trac, #9620 On Sat, Sep 20, 2014 at 7:24 AM, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hello! > > Is there a ticket for that already on GHC Trac? If not, please create > one, and try to document everything we already know about this issue > > On 2014-09-20 at 14:25:56 +0200, member MP2E wrote: > > Symlinking lib64 to lib didn't seem to work, I think the directory is > > getting cleared before build. But if I copy the contents of lib64 to lib > > after the build fails and then type make again, ghc compiles! > > > > Thanks for the workaround, hopefully a real fix will be found soon > enough :) > > > > On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann <moritz(a)lichtzwerge.de > > > > wrote: > > > >> While this is not a proper fix. Assuming there is no no lib folder, and > >> the proper lib is in lib64, does: symlinking lib64 to lib and continuing > >> with make solve the issue? > >> > >> On Sep 20, 2014, at 12:32 PM, member MP2E <mp2e(a)archlinux.us> wrote: > >> > >> > Yep, I reported this same build error for NixOS on x86_64, > unfortunately > >> I haven't found any way to solve it. Reverting the commit that upgrades > to > >> libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > >> unable to do any development on GHC until it's fixed :( > >

1 0

Fwd: FFI library error building GHC
by member MP2E 20 Sep '14

20 Sep '14

Yep, I reported this same build error for NixOS on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann <moritz(a)lichtzwerge.de> wrote: > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer <david.feuer(a)gmail.com> wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as > suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build -static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ————————————————— > Moritz Angermann > +49 170 54 33 0 74 > moritz(a)lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. München > > Amtsgericht München HRB 207882 > Geschäftsführung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

2 2

Where can I stick a dead code elimination rule for quotRemInt#?
by David Feuer 19 Sep '14

19 Sep '14

As I describe in #9617, GHC's CSE in 7.9 seems to be good enough to let Int and Integer use quot x y = fst (x `quotRem` y) rem x y = snd (x `quotRem` y) And actually get good results in code that uses both the quotient and the remainder. I believe the only thing left to be able to actually implement this is a simple rule to turn a match on quotRemInt# into one on quotInt# or remInt# if only the quotient or only the remainder is used. My question is where I could stick such a rule. Can anyone advise me? All I know is that it has to happen after CSE.

1 0

RE: Volatile T4801 test
by Simon Peyton Jones 19 Sep '14

19 Sep '14

Agreed. Let's remove the max_bytes_used threshold from the test. Simn | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 19 September 2014 16:02 | To: Simon Peyton Jones; Austin Seipp | Subject: Volatile T4801 test | | Hello! | | If you look at | | https://phabricator.haskell.org/diffusion/GHC/history/ | | the four of the recent commits failed mostly due to the volatilness of | T4801; I've seen it fail myself in Phab code-revisions as well... | | What shall we do about T4801, it seems to create unnecessary noise, as | any build-failure raises alarm flags for no good reason (imho)... | | Cheers, | hvr

1 0

Re: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44)
by Gabor Greif 19 Sep '14

19 Sep '14

Dear devs, I must admit I screwed this up again, I wanted to push on my branch git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative but muscle memory betrayed me and I pushed like this: git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master Sorry for the messup. How can I repair this? I did not intend to "merge" my work yet. It is not totally wrong though. It has three failures, but they are okay. I have a commit in my tree for that, but my firewall won't let them out (they are more than a kilobyte :-( The changes should be reviewed on the branch, and some changes are still expected. Second thought, how could this happen? Was this just a fast-forward of "master" ? Git seems to be a dangerous tool. Cheers and all help welcome, (also review comments regarding this WIP), remorsefully, Gabor On 9/19/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > Branch 'master' now includes: > > e12a6a8 Propositional equality for Datatype meta-information > 0a8e6fc Make constructor metadata parametrized (with intended parameter > <- datatype) > f097b77 Implement sameConstructor > cc618e6 get roles right and fix a FIXME > 79c7125 Actually parametrize the Constructor with the Datatype > 7bd4bab Supply a reasonable name (should be derived from d_name tho) > 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) > 4d90e44 Add default case (fixes -Werror) > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 4

Problems with updating Phab revision using arcanist
by Jan Stolarek 19 Sep '14

19 Sep '14

Hi all, I have a question to Phab gurus about using arcanist. I created a git branch, hacked a bit and then submitted a review using `arc diff`. Then I make a few more commits and want to update my revision. Running `arc diff` opens up an editor where I can create a new revision. Obviously, that's not what I want so I follow the suggestion from the comment in the editor to use `--update`: # arc diff --update D202 Exception Can't parse an empty diff! (Run with --trace for a full exception trace.) That's not what I want either. I'm left with manually specifying the base commit: arc diff 1719c42 and that works. But that's not really convenient. Any ideas why neither `arc diff` nor `arc diff --update <rev>` don't work (I believe they should)? Janek

1 0