November 2014 - ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults
by David Macek 10 Nov '14

10 Nov '14

On 4. 11. 2014 1:30, Ray Donnelly wrote: > Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek

3 15

7.10 STABLE freeze date
by Austin Seipp 10 Nov '14

10 Nov '14

Hi all, After some deliberation, we've decided that the STABLE freeze for 7.10 will happen in approximately two weeks, on November 21st. We're hoping to stick to this date closely, but do read below. This is perhaps a short time to freeze, but right now, we've only got a couple things we're planning on focusing on for the next few weeks. And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Based on our discussions earlier this week, I think these all will make it just in time for the freeze. Nota bene: if there is *any* delay, it will be for these, as we picked them as the highest priority in our own views. It is unlikely we will delay any so people can sneak in a few other things. So, if you want something of yours in, you better get me, Simon & Simon, Herbert, etc's attention pronto! That way we'll have time to get it in first. To make things easier, we'll also be pushing the lhs->hs conversion pretty soon so cherry picking/merges are easier, and do some other cleanups. And outside of that, we've still been having a healthy flow of bug fixes falling into the tree, which is great. So if you're just bugfixing, please keep doing so - we'll be pulling bugfixes into the tree continuously. We will also be pulling in submodule/library updates continuously, like we did for the 7.8 branch. Let me know if you have questions, objections, or really really really want something - but I won't be as nice as last time I'm afraid. ;) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 12

Question about `validate` workflow
by Iavor Diatchki 10 Nov '14

10 Nov '14

Hello, I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. I am using CPUS=4 ./validate --fast Can I do something, to "validate continue", at least until I get a basic validate to pass? I don't mind redoing everything one final time to make sure things are OK, it is just that it seems wasteful while I am fixing things. -Iavor

5 7

Abstracting over constraints: Can this be implemented in GHC?
by Alexander Berntsen 10 Nov '14

10 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I want to be able to write essentially this function: f :: (a -> d) -> (b, c) -> (d, d) f g (x, y) = (g x, g y) What do we need here for this to work? Well, given 'g :: a -> d', we need 'a' ~ 'b' ~ 'c' from the constraints of 'g'. So let 'g = show', such that 'g :: Show a => a -> String'. We need that forall 'a'. 'Show a'. And from that, forall 'b' and 'c', 'Show b' and 'Show C'. f show (1.2, False) = ("1.2", "False") Another example, let 'g = (>2.0)'. Now 'g :: (Ord a, Fractional a) => a -> Bool'. So we need that forall 'a', 'Ord a, Fractional A'. From this we need that forall 'b' and 'c', 'Ord b, Fractional b', and 'Ord c, Fractional c'. f (>5.0) (15, 6/2) = (True, False) One last example, let 'g = id'. now 'g :: a -> a'. No constraints! f id (x, y) = (x, y) How close can we get to this today? Quite close. But the alternatives all feel emphatically wrong to me. λ :set -XRankNTypes λ :set -XConstraintKinds λ let f :: forall b c d k. (k b, k c) => (forall a. k a => a -> d) -> (b, c) -> (d, d); f g (x, y) = (g x, g y) λ (f :: (Show x, Show y) => (forall a. Show a => a -> d) -> (x, y) -> (d, d)) show (1.2, False) We need to specify k every time we use f. That's dreadful! While a nicer syntax (which is suggested, but I don't think it's being actively worked on right now) would allow us to write (f @Show) show (1.2, False) or similar -- it's still not quite right. (Though an obviously massive improvement over the status quo.) Of course, were we merely concerned with getting the job done, we would write either 'bimap g g', 'g *** g' or '\(x, y) -> (g x, g y)'. The former two may look obscure at first ("hmm, why don't they just use 'join'?"), so the latter might actually be best. But it's The Wrong Thing! At least *I* think so. So what do I want here? I guess kind-level forall for constraints, so that 'f' can infer the constraints on 'b' and 'c' from the constraints on 'a' imposed by 'g'. Is this implementable presently? Ever? :-] CC'ing you, SPJ, because, well, types. Also CC'ing you, ekmett, because you have an interesting library called Constraints, so maybe you have some related insight to offer. - -- 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/ iF4EAREIAAYFAlRbRUoACgkQRtClrXBQc7WYbQD+Icr54KvxNA90SKIzPpp726hI wZF4OUtuTXqyXPlU3UYBAIvg8J5uRX+UfNJKOI3PZubCfkJLuraNiW0EIgGD+hgd =fWFQ -----END PGP SIGNATURE-----

2 2

small `arc` victory -- commit message not changed
by Richard Eisenberg 10 Nov '14

10 Nov '14

I just revised a Phab revision using `arc`, and it all worked swimmingly, doing exactly what I wanted, even though this was non-trivial. I describe the process below, and am happy to add to the Phab wiki page, but wanted to check here first to make sure I wasn't making an invisible dreadful mistake. Here's my story: - I had done a few edits in TcSplice and posted the (boring) revision D359. - Austin and Harbormaster both had good suggestions for me. - I spent a week completing other tasks. - I rebased my WIP branch against master. This worried me about what Phab might think. - I incorporated the suggestions. As is my usual workflow, I then rebased to integrate these changes into my original commits. As previously discussed, I think breaking a patch into separable commits is a Good Thing, and I curate these commits to be reader-friendly as I work. In the process, I de-Phabified my previous commit message, worried I was inviting demons, but determined to proceed. - I then updated my Phab revision with this: arc diff --allow-untracked --head HEAD --update D359 Explanation: --allow-untracked is because I have testsuite garbage floating in my working directory, and I'm never confident enough to modify .gitignore to ignore this garbage. `--head HEAD`, I think, is the magic bit. It specifies the *end* of the commit range to be included in the Phab diff. (The beginning was inferred to be origin/master, but can be specified without flags on the command line.) According to `arc help`, "This [flag] disables many Arcanist/Phabricator features which depend on having access to the working copy." Indeed, it was this warning which made me think `--head` was my friend. Of course, specifying `--head HEAD` on the command line seems redundant, but it still effectively stopped `arc` from touching my commits, thinking that this would break my git-ness. So, `arc` did the best job it could without touching my git information, which is exactly what I wanted. Results: My new code is now viewable and reviewable at D359. Despite all of my rebasing, the diffs are clean. You can even ask for the differences between my two revisions, and Phab does the right thing -- even though there's a week's worth of other commits that were rebased in. I'm sure Harbormaster is hard at work right now checking my changes. Fellow devs can offer nice feedback. And, I have retained control over my git structure. Hooray! Question: Have I done anything wrong here? By "wrong", I mean both in a technical sense (e.g., is Harbormaster now deeply confused?) and in a project-management sense (e.g., would this be a bad pattern for others to follow?). Should I put this workflow on the wiki? If no one tells me otherwise, I plan on using `--head` every time. Thanks, Richard

3 2

unexpected failure for scc001
by Joachim Breitner 10 Nov '14

10 Nov '14

Hi, it seems that adding the oneShot annotation to the interface causes scc001 to fail: Actual prof output differs from expected: --- ./profiling/should_run/scc001.prof.sample 2014-11-02 20:21:03.000000000 +0100 +++ ./profiling/should_run/scc001.prof 2014-11-02 20:46:39.000000000 +0100 @@ -1,28 +1,33 @@ - Fri Oct 14 16:27 2011 Time and Allocation Profiling Report (Final) + Sun Nov 2 20:46 2014 Time and Allocation Profiling Report (Final) scc001 +RTS -hc -p -RTS - total time = 0.00 secs (0 ticks @ 20 ms) - total alloc = 46,020 bytes (excludes profiling overheads) + total time = 0.00 secs (0 ticks @ 1000 us, 1 processor) + total alloc = 51,344 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc -MAIN MAIN 0.0 23.0 -CAF GHC.IO.Encoding.Iconv 0.0 1.3 -CAF GHC.IO.Handle.FD 0.0 74.2 +MAIN MAIN 0.0 1.9 +CAF GHC.IO.Encoding 0.0 5.4 +CAF GHC.Conc.Signal 0.0 1.3 +CAF GHC.IO.Handle.FD 0.0 67.3 +main Main 0.0 22.8 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc -MAIN MAIN 101 0 0.0 23.0 0.0 100.0 - CAF GHC.Show 141 0 0.0 0.3 0.0 0.3 - CAF GHC.IO.Handle.FD 128 0 0.0 74.2 0.0 74.2 - CAF GHC.IO.Encoding.Iconv 120 0 0.0 1.3 0.0 1.3 - CAF GHC.Conc.Signal 110 0 0.0 0.7 0.0 0.7 - CAF Main 107 0 0.0 0.4 0.0 0.4 - (...) Main 206 1 0.0 0.0 0.0 0.0 - h Main 205 1 0.0 0.0 0.0 0.0 - main Main 202 1 0.0 0.0 0.0 0.0 - g Main 204 1 0.0 0.0 0.0 0.0 - f Main 203 1 0.0 0.0 0.0 0.0 +MAIN MAIN 44 0 0.0 1.9 0.0 100.0 + main Main 89 0 0.0 22.8 0.0 22.8 + g Main 91 1 0.0 0.0 0.0 0.0 + f Main 90 1 0.0 0.0 0.0 0.0 + CAF Main 87 0 0.0 0.1 0.0 0.1 + (...) Main 93 1 0.0 0.0 0.0 0.0 + h Main 92 1 0.0 0.0 0.0 0.0 + main Main 88 1 0.0 0.0 0.0 0.0 + CAF GHC.IO.Handle.Text 84 0 0.0 0.2 0.0 0.2 + CAF GHC.IO.Encoding.Iconv 80 0 0.0 0.5 0.0 0.5 + CAF GHC.IO.Handle.FD 79 0 0.0 67.3 0.0 67.3 + CAF GHC.Show 77 0 0.0 0.6 0.0 0.6 + CAF GHC.Conc.Signal 74 0 0.0 1.3 0.0 1.3 + CAF GHC.IO.Encoding 72 0 0.0 5.4 0.0 5.4 *** unexpected failure for scc001(profasm) Now after reading some of the code it seems that the output is normalized considerably before comparing. But I’m not fully sure what is being checked here. So things change: Is that change a regression? An improvement? Or just an a wobble that should not worry me? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

Re: Reviving the LTS Discussions (ALT: A separate LTS branch)
by David Feuer 09 Nov '14

09 Nov '14

GHC is an open source project. People work on it because 1. They enjoy it and find it interesting, 2. They need it to work well to support their own software, 3. They're trying to write a paper/get a degree/impress their peers, or, in very rare cases, 4. Someone pays them to do it. People are also willing to do some kinds of minor maintenance work because 5. They feel a sense of obligation to the community but this is not likely, on its own, to keep many people active. What does this have to do with LTS releases? The fact is that having people who want an LTS release does not necessarily mean that anyone else should do much of anything about it. If they don't really care, they're likely to half-build an LTS process and then get sidetracked. So what do I think should be done about this? I think "GHC headquarters" should make a standing offer to any person, group, or company interested in producing an LTS release: an offer of Trac, and Phabricator, and Harbormaster, and generally all the infrastructure that GHC already uses. Also an offer of advice on how to manage releases, deal with common issues, etc. But a promise of programming power seems likely to be an empty one, and I don't see the point of trying to push it. If someone wants an LTS release, they need to either make one themselves or pay someone to do the job.

2 1

`arc` changes my commit messages
by Richard Eisenberg 09 Nov '14

09 Nov '14

Hi all, Is there a way to put `arc` into a read-only mode? Frequently while working on a patch, I make several commits, preferring to separate out testing commits from productive work commits and non-productive (whitespace, comments) commits. Sometimes each of these categories are themselves broken into several commits. These commits are *not* my internal workflow. They are intentionally curated by rebasing as I'm ready to publish the patch, as I think the patches are easy to read this way. (Tell me if I'm wrong, here!) I've resolved myself not to use `arc land`, but instead to apply the patch using git. Yet, when I call `arc diff`, even if I haven't amended my patch during the `arc diff`ing process, the commit message of the tip of my branch is changed, and without telling me. I recently pushed my (tiny, uninteresting) fix to #9692. Luckily, my last commit happened to be the meat, so the amended commit message is still wholly relevant. But, that won't always be the case, and I was surprised to see a Phab-ified commit message appear in the Trac ticket after pushing. I know I could use more git-ery to restore my old commit message. But is there a way to stop `arc` from doing the message change in the first place? Thanks! Richard

5 4

Fw: Long term support - in general and Windows XP specifically
by Howard B. Golden 09 Nov '14

09 Nov '14

Hi, I am combining the two topics because the issues are both support-related. First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by "plain users" (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community. LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach. Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the "plain user" will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement. I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded. The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer? I hope my perspective is of value to the developers. Regards, Howard Northridge, CA, USA ----- Original Message ----- From: Austin Seipp <austin(a)well-typed.com> To: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Cc: Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News - 2014/11/07 [Excerpt] - Austin also opened a discussion about a possible LTS branch for GHC, spawned off from a suggestion by John Lato a few weeks email. This discussion has been brought up several times before this, but for the most part has fizzled out a bit. But maybe with a different focus - on a separate branch with a team of maintainers - we can hash out a plan of action, and just give it a whirl. https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html - Austin Seipp brought up a question about Windows support: can we officially drop support for XP, now that Microsoft has done the same? And what minimum version requirements should we endorse? Vista or Windows 7 would give improvements due to API improvements, with Windows 7 offering even more. If you're a GHC on Windows user, please let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html

4 3

Wiki: special namespace for proposals?
by Yuras Shumovich 08 Nov '14

08 Nov '14

Hello, Would it be better to organize proposals under one namespace? Right now they belongs to root namespace, so title index ( https://ghc.haskell.org/trac/ghc/wiki/TitleIndex ) is hard to use. I was going to start new page describing language extension, but I don't want do increase entropy even more. What about creating special namespace, e.g. "Proposals"? Probably makes sense to divide if farther? Thanks, Yuras

9 11