- ghc-devs - Haskell.org

How to build the user guide?
by Jan Stolarek 25 Sep '14

25 Sep '14

Is there a way to build the user guide without having to build everything? The wiki [1] suggests cd docs/users_guide make html stage=0 FAST=YES but that doesn't seem to work. Janek [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Docs

2 1

Re: ghc-devs Digest, Vol 133, Issue 40
by David Feuer 24 Sep '14

24 Sep '14

Simon Peyton Jones wrote: > anywhere, I think. You might want a new HsSyn data type for "list with > possible leading or trailing commas": > > data HsCommadList a > = HCL > Int -- Number of leading commas > [a] > Int -- Number of trailing commas > If we're going to go to the trouble of supporting extra leading and trailing commas, why not also support extra commas in the middle? That way, #include "theseexports" , #include "thoseexports" doesn't have to worry about how these and those exports are listed. David

2 1

Re: FoldrW/buildW issues
by David Feuer 24 Sep '14

24 Sep '14

On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> wrote: > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. One nice thing about this idea (which sounds like it must be related to the "state hack", but is more explicit) is that it presumably applies also to similar situations in the State and ST monads, when a state transformer is only used once. Could you explain, perhaps, what compiler transformation this enables, and how you implemented it? It would be nice if the compiler could figure this out for itself, but I'm sure that's much too big a project for 7.10, whereas making sure foldl, scanl, mapAccumL, foldM, sum, etc., work really reliably seems important. And yes, I do think such a thing would probably work for scanl and such, assuming GHC's analysis can use the information properly—they're just state-transforming list producers. David

2 1

Re: Building ghc on Windows with msys2
by Thomas Miedema 24 Sep '14

24 Sep '14

Hello msys2 users, I came across ticket #8842 <https://ghc.haskell.org/trac/ghc/ticket/8842>: "Make sure msys2 builds non emulating binaries". Maybe it is of interest to you, it mentions something about emulation functions being really slow. Please close it if it is not relevant. Cheers, Thomas On Mon, Sep 15, 2014 at 11:33 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Thank you! Indeed Neil Mitchell is also acting as “guinea pig” at the > moment. It would be **great** if together you were able to clean up the > “how to build on Windows” page, remove out of date or misleading > information, and yes I think we should focus on msys2. > > > > Great stuff > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Gintautas > Miliauskas > *Sent:* 15 September 2014 21:58 > *To:* ghc-devs(a)haskell.org > *Subject:* Building ghc on Windows with msys2 > > > > Hello, > > > > I have been messing around a little bit with building GHC from source on > Windows, and found the msys2 wikipage > <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2> quite > useful, but somewhat outdated. Quite a few steps in those instructions are > no longer necessary and can be omitted. I am working on cleaning up that > wikipage right now and should be done in a day or two. > > > > I've found a recent email > <http://www.haskell.org/pipermail/ghc-devs/2014-September/006251.html> in > the middle of updating the wikipage about other people planning to do the > same, so I thought I'd shoot an email to make sure that work is not being > duplicated. > > > > msys2 seems to be in good shape and should probably be promoted to the > primary suggested method to build ghc on Windows. Let's look into that once > the new build instructions have been proofread and verified. > > > > Best regards, > > -- > Gintautas Miliauskas > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

1 0

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