- ghc-devs - Haskell.org

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 10 Nov '14

10 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

RE: RFC: Dropping Windows XP support
by Tamar Christina 08 Nov '14

08 Nov '14

I don't think we should worry about windows server 2003. Unless I'm mistaken the support Microsoft still provides is mostly maintenance. The older version of GHC won't suddenly stop working on 2003, as such all programs will continue to run just fine. >From a development standpoint removing <= NT 5 support from would be very beneficial. For those on the older platforms, they can use the older GHCs, which I think is the policy most companies have taken w.r.t. Xp/2003. Regards, TamarFrom: Gershom B Sent: ‎08/‎11/‎2014 01:20 To: Austin Seipp; ghc-devs(a)haskell.org; glasgow-haskell-users(a)haskell.org Subject: Re: RFC: Dropping Windows XP support One concern here is that even with XP falling out of support, Windows Server 2003 remains supported through July 2015, and so we should give it a little chunk of time after that falls out of support from Microsoft before we stop supporting that. I think the limitations in Server 2003 are roughly the same as XP. http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ However, the next Windows Server (2008) should share all Vista features. Cheers, Gershom On November 7, 2014 at 1:16:39 PM, Austin Seipp (austin(a)well-typed.com) wrote: > Hi all, > > This is a quick discussion about the current system requirements for > Windows builds. > > Spurred by a recent[1] LLVM discussion, I'd like to raise the question > of dropping support for Windows XP, and bumping the minimum required > version to Windows Vista or even Windows 7. > > For one, Microsoft doesn't support XP anymore, so most people are > moving off it anyway. 'Soon' even XP Embedded will be obsoleted. > > But second, Vista and beyond introduced useful new APIs we could use. > I was digging through the LLVM thread and two came out to me: > > 1) We could switch to using slim reader/writer locks, which in some > workloads may work out better than critical sections (they'll win on > more read-heavy workloads). The downsides is there's no recursive > locking but we don't use that anyway (and recursive locks are > considered bad by many anyway[2]). > > 2) We could probably use an actual condition variables API that was > introduced with Vista. Currently we use a giant EVENT object to > emulate the API, which could be replaced with the real deal. > > Both of these could be nice wins for simplicity and performance I think. > > I know there are some corporate users out there who this may impact, > and users as well. I'd like to know what people think. Particularly > what version we should standardize on. > > FWIW, I don't plan on changing any of this until the 7.12 release at least. > > [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 > [2] http://www.zaval.org/resources/library/butenhof1.html > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

GHC Weekly News - 2014/11/07
by Austin Seipp 07 Nov '14

07 Nov '14

Hello *, It's that time again, so get ready for some good ol' fashion news about your favorite compiler. - Austin announced the 7.10 STABLE freeze date earlier today, which is two weeks from the time of this posting: November 21st, 2014. If you're a developer and have a feature you want, you'd better get it reviewed and checked soon! https://www.haskell.org/pipermail/ghc-devs/2014-November/007206.html - 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 - This past week, Simon PJ, Austin, Gintautas Miliauskas, and several others met over a video chat to discuss the future of windows builds. And it went pretty well! We've scribed up some notes, and sort of laid out what we think will be happening for Windows in the near future. https://www.haskell.org/pipermail/ghc-devs/2014-October/006897.html - Gergo Erdi opened up an RFC about type signatures for pattern synonyms, which is one of the last pieces of the pattern synonyms implementation we've been missing. https://www.haskell.org/pipermail/ghc-devs/2014-November/007066.html - Simon PJ pushed a major overhaul of the constraint solver, just in time for GHC 7.10. This was the result of a few months of work that Simon has been glad to get off his plate, and hopefully should make the type checker faster, leaner, and more modular (as usual). - Jan Stolarek talked about his planned improvements to the users guide, which is ticket #9358. Hopefully for 7.10 the resulting documentation will be *much* more clear and up to date. https://www.haskell.org/pipermail/ghc-devs/2014-November/007169.html - Alan Zimmerman has got some more patches up for adding annotations to the GHC Abstract Syntax Tree (AST). The hope is this new representation will make it much easier for tools to enrich the AST with their own custom metadata. Alan has been working on this for several weeks now, so a good review is in order! https://www.haskell.org/pipermail/ghc-devs/2014-November/007133.html - Mateusz Lenik, a new contributor, has discussed improving the 'Ticky Ticky' profiling code and resurrecting some of the older features; luckily Jan inspired this work and had some comments. Thanks Mateusz! https://www.haskell.org/pipermail/ghc-devs/2014-November/007078.html - Alexander Berntsen asked an question about abstracting over constraints in GHC. Richard replied, but it seems this work might be quite difficult! https://www.haskell.org/pipermail/ghc-devs/2014-November/007165.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 And this weeks closed tickets include quite a long list, thanks to everyone cleaning up the bug tracker: #9747, #9236, #9753, #9752, #9262, #8953, #9084, #9738, #8571, #8295, #8261, #9754, #110, #9345, #8849, #8819, #9658, #8960, #9395, #9705, #9433, #9633, #9359, #9081, #8482, #3376, #9712, #9739, #9211, #9728, #9750, #9768, #9773, #9741, #9284, #9774, #9771, #9001, #8626, #8986, #9268, #8975, #8962, #8921, #8089, #8843, #8829, #9295, #7913, #2528, #9779. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Reviving the LTS Discussions (ALT: A separate LTS branch)
by Austin Seipp 07 Nov '14

07 Nov '14

Hi *, I want to draw attention to a topic that's come up a few times before, spurred by discussion a few weeks ago by John Lato, and more frequently (in other forms) by people like Gintautaus, with people taking more mindshare in merging and getting patches and features flowing. The basic problem boils down to: what do we do about long term releases for GHC, how can we manage them, and what sort of effort would be required to maintain something like that? The problem with GHC has always been one of time allocation for humans. And we're really aggressive about fixing problems and addressing things, with frequent updates and improvements to lots of our core features. That's fantastic! I am constantly amazed that despite almost all of our contributions being major volunteer work. But that comes as a cost in other ways: 1) We have very little resources dedicated to maintaining things like a long term branch. I certainly cannot do it alone while having enough time to sensibly manage everything else I do. 2) High rates of churn often 'leave people in the dust'. When you refactor a big ball of code, and you improve it, you often don't want to think about the old ball of code. And having to remember the old ball of code from 6 months ago can be a significant undertaking, even for the best of us. 3) High rates of churn can introduce new bugs. While in my personal and professional experience I think Haskell is exceptional at preventing bugs, and we have lots of tests for GHC to catch regressions, we can often break things. The rate of this is not clear because it's got a significant amount of variables attached. 1 and 3 hurt users. 2 hurts developers. All of them are unfortunate. There are a lot of these kinds of issues in various forms but the specifics can be discussed later. So what does this have to do with John's email he sent me. Well, he had a helpful idea that's been picked up by most other people: we should have a separated stable team that deals with longer term maintenance. The pattern of a separated stable/longterm team is actually one that's common in a lot of older and higher profile FOSS projects, where people maintaining long term versions are dedicated developers, but simply on a different schedule than others. It's just two teams on one project: same goal, different priorities and needs. The question is who's going to do it of course - but I'm hoping our volunteer streak will kick in. :) There are some advantages to this: 1) We can pick a stable branch, and we can have a separated group of people maintain it. 2) Most developers workflows won't change in the majority of cases, and we can keep on humming along. 3) Users can have an 'endorsed' version that we delegate as a stable compiler for a designated period of time, based on the LTS Team's projections. But there are still some more difficulties: 1) We need to decide how to pick a LTS branch, and when. The current release cycle *roughly speaking* dedicates about a year to each release, while HEAD steams along. Do we turn each major release into an LTS branch, and give it over to the LTS team, or do we only consider every other release, or do we pick and choose? 2) We need to define a scope of things an LTS branch would address. For example, API stability, what kind of bugfixes we get in (simple mitigations vs thorough fixes that may be more substantial). 3) We probably need some policies on working conventions. For example, using the bug tracker, how to assign people to bugs, and how to make sure everyone is on the same page. 4) We need to decide who's going to do what. So, to be clear, I would suggest having a separate group of committers who can follow a designated long term branch, and maintain it. These people do not necessarily need to contribute upstream features or massive things, but do need to show pretty clear commitment and stewardship. I think if we start this, we'll have to sort of do self nominations the first time, since there may be new-but-interested-GHC-hackers who might want to help. Beyond that, as mentioned above, we need to define scope, and some technical procedures. But this can all be hashed over VoIP, the lists, etc etc. I've tried to think up a good start to this conversation, and I think John's suggestion is a good one - so I'm eager to see where it goes this time. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1 and GHC 7.8.3
by George Colpitts 07 Nov '14

07 Nov '14

Hi I was previously able to build using Builder <https://ghc.haskell.org/trac/ghc/wiki/Builder> on my Mac using 10.9, Xcode 6.0 and ghc 7.8.3. Currently with 10.10 and Xcode 6.1 I am getting the following error using Builder. Has anybody been able to build HEAD on Mac with Yosemite wtih Xcode 6.1 and GHC 7.8.3? make test_bindist bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output <command line>: can't load .so/.DLL for: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib, 9): no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib: mach-o, but wrong filetype) make[1]: *** [test_bindist] Error 1 make: *** [test_bindist] Error 2 Thanks George

2 2

Phabricator guidance
by Simon Peyton Jones 07 Nov '14

07 Nov '14

I suppose I will have to look at this. But I have no clue how to do so. D202 itself seems to be a very small patch (only ten lines or so), so presumably it applies on top of some other patch? But what? Someone said I could use arc patch D202 to apply the patch in my own tree, which is crucial for reproducing the error that Jan is stuck on. BUT the patch presumably applies to a particular commit, NOT the head of my current tree. But what is the base commit to which it applies? Does arc patch check out the base commit before applying? I can't find any documentation of 'arc patch'. Can anyone else? It would be good to document this workflow, since it's a very useful one. Thanks Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 06 October 2014 10:12 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | Bump. Austin put this on feature list for GHC 7.10 and I'd really like | to this feature to make it into the next stable version of GHC. | Currently I'm not making *any* progress because of the "Not in scope" | errors. I've spent time looking at the code, seeing how things are | done in other places but none of this got me closer to solving the | problem :-/ Help? | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, austin, simonpj | Cc: thomie, goldfire, simonmar, ezyang, carter

4 5