September 2014 - ghc-devs

RE: cminusminus.org does not have a link to the spec
by Simon Peyton Jones 19 Jan '15

19 Jan '15

Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit "import" statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei

4 6

Status updates
by Austin Seipp 18 Dec '14

18 Dec '14

Hi *, Here are some status updates: - I've merged the Applicative Monad patchset! Yay! Many thanks to Nathan Howell for helping me out in the end there. Please let me know if anything explodes horribly (I hope not). - Gabor has set up some build documentation for us based on HEAD, hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix haskell.org/ghc to link to this properly (there may be other dead links, please let me know). - As I'm sure most of you were aware, it was a slow week due to ICFP & related events being most of last week. - As I'm also sure you were aware, Haskell.org suffered a lot of instability this past week. I've been focusing most of my efforts since about Thursday on this, since it's come and gone a lot and has needed some consistent monitoring. Unfortunately, it is not done yet, and there is still more work to be done. :( - ghc.haskell.org was migrated to a new server in the US as a part of this effort this weekend (send a thanks to Herbert). In general, you should notice nothing really new, but latency for UK citizens may be a bit higher than it was before now. - Now that Applicative/Monad is done, there are some more changes to 'base' that will happen (Bifunctors, Foldable/Traversable) that will need to happen. So I'm sure this discussion will start soon. - I still can't set up the Windows bot yet, sorry! Phabricator work is still not yet available upstream. Hopefully soon. - Sergei spent some time filing bugs that we should fix in the testsuite, because they fail --slow validate. I believe these are two of them: - https://ghc.haskell.org/trac/ghc/ticket/9567 - https://ghc.haskell.org/trac/ghc/ticket/9566 We'll probably need to fix these before we turn it on. Simon, these look like something up your alley... - For those who missed ICFP, Simon gave a nice status update for GHC, which is on YouTube: https://www.youtube.com/watch?v=Ex79K4lvJno&list=PL4UWOFngo5DW6nKDjK0UB5Oy9… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Trouble committing
by Andreas Voellmy 14 Dec '14

14 Dec '14

Hi GHCers, I just fixed a bug (#9423) and went through the Phab workflow. Then I did a fresh checkout from git and ran: $ git checkout master $ arc patch --nobranch D129 $ git push origin master as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on the last command I get this error: fatal: remote error: access denied or repository not exported: /ghc.git Maybe I just no longer have commit access to ghc? If so, could someone restore my access? Or I'd be happy if someone else can push the patch. Thanks, Andi

4 4

STM and GC write barrier
by Ryan Yates 06 Nov '14

06 Nov '14

Hi All, I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Ryan [1]: https://github.com/ghc/ghc/commit/6d784c43592290ec16db8b7f0f2a012dff3ed497

2 2

Core libraries bug tracker
by Simon Peyton Jones 02 Nov '14

02 Nov '14

Edward, and core library colleagues, This came up in our weekly GHC discussion * Does the Core Libraries Committee have a Trac? Surely, surely you should, else you'll lose track of issues. * Would you like to use GHC's Trac for the purpose? Advantages: o People often report core library issues on GHC's Trac anyway, so telling them to move it somewhere else just creates busy-work --- and maybe they won't bother, which leaves it in our pile. o Several of these libraries are closely coupled to GHC, and you might want to milestone some library tickets with an upcoming GHC release * If so we'd need a canonical way to identify tickets as CLC issues. Perhaps by making "core-libraries" the owner? Or perhaps the "Component" field? * Some core libraries (e.g. random) have a maintainer that isn't the committee. So that maintainer should be the owner of the ticket. Or the CLC might like a particular member to own a ticket. Either way, that suggest using the "Component" field to identify CLC tickets * Or maybe you want a Trac of your own? The underlying issue from our end is that we'd like a way to * filter out tickets that you are dealing with * and be sure you are dealing with them * without losing track of milestones... i.e. when building a release we want to be sure that important tickets are indeed fixed before releasing Simon

4 8

old-time.git/tests/time004.hs is DST-sensitive :-/
by Herbert Valerio Riedel 26 Oct '14

26 Oct '14

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e. length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 2012" Does anyone happen to know what the rationale behind this 'time004' unit test was? Cheers, hvr

1 1

I'm going to disable DPH until someone starts maintaining it
by Austin Seipp 15 Oct '14

15 Oct '14

Everyone, I'm still working on the AMP, and of course, things aren't going as planned. Why is that? I'm attempting to update `vector` to the latest version from GitHub, as it has some fixes we need for AMP. Mostly, it has some instances we need. Unfortunately, this is basically impossible because dph is locked into a vector fork of ours that we have been maintaining for *months*, and doesn't work with the latest vector upstream (0.11) due to changes in the stream representation. This means I can either: 1) Fix everything in DPH to work with vector 0.11, which is probably going to take a lot of work. 2) Merely fix our fork of vector and let things continue working. This is much easier than #1. Now, you might say that #2 is clearly a preferable solution, and it's very easy - so just do that, Austin! But I don't want to do it. You could say this is the straw that has broken the camel's back. Why? Because I'm afraid I just don't have any more patience for DPH, I'm tired of fixing it, and it takes up a lot of extra time to build, and time to maintain. In fact I'm the only person who's committed to it in *months*, and that has only been to fix breakage. The hackage packages are out of date and sync with what's in the repository (I can't upload them, nor can anyone else besides Ben I believe). So - why are we still building it, exactly? We had a conversation about this months ago. The concern was that things would break and we don't want it to fall out of sync. We're at that point right now - things are breaking, it's out of sync, and it's a pain to keep fixing it, and the actual *benefits* we get from doing so are completely unclear to me. It basically just seems like extra work for nothing, honestly. Unless someone speaks[1] up *very* soon, I'm going to disable DPH during ./validate and the regular build. It will be possible to build it with a '--dph' flag (the dual of the current '--no-dph' flag), although it will be broken very soon with these incoming changes. Providing someone starts fixing it, I'm completely, 100% open to re-enabling it in ./validate by default. But I'm personally tired of fixing it. I'm CC'ing Manuel, Geoff & Ben for their inputs. [1] And by 'speak up', I mean I'd like to see someone actively step forward address my concerns above in a decisive manner. With patches. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 9

Building ghc on Windows with msys2
by Gintautas Miliauskas 13 Oct '14

13 Oct '14

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

11 35

RE: ExtraCommas
by Simon Peyton Jones 13 Oct '14

13 Oct '14

| What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where No. I'm proposing this. Insetad of data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int have this: data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a) So that HsCommaList a is very like [a] but can express precisely where the extra commas appear. Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things. The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified. Does that help? Simon | -----Original Message----- | From: Alexander Berntsen [mailto:alexander@plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | 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/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE-----

3 2

FFI: c/c++ struct on stack as an argument or return value
by Yuras Shumovich 07 Oct '14

07 Oct '14

Hi, Right now ghc's FFI doesn't support c/c++ structures. Whenever we have foreign function that accepts or returns struct by value, we have to create wrapper that accepts or returns pointer to struct. It is inconvenient, but actually not a big deal. But there is no easy workaround when you want to export haskell function to use it with c/c++ API that requires structures to be passed by value (Usually it is a callback in c/c++ API. You can't change it's signature, and if it doesn't provide some kind of "void* userdata", then you are stuck.) I'm interested in fixing that. I'm going to start with 'foreign import "wrapper" ...' stuff. Calling conventions for passing c/c++ structures by value are pretty tricky and platform/compiler specific. So initially I'll use libffi for that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see rts/Adjustor.c). It will allow me to explore design space without bothering about low level implementation details. Later it could be implemented for native (non-libffi) adjustors. Is anybody interested it that? I appreciate any comments/ideas. Right now I don't have clear design. It would be nice to support plain haskell data types that are 1) not recursive, 2) has one constructor and 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any ideas are welcome. An example how to use libffi with structures: http://www.atmark-techno.com/~yashi/libffi.html#Structures Thanks, Yuras

7 19