- ghc-devs - Haskell.org

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

Re: [commit: ghc] master: Fix a couple of inaccurate stack checks (3bebf3c)
by Joachim Breitner 07 Nov '14

07 Nov '14

Hi Simon, with Am Mittwoch, den 05.11.2014, 18:15 +0000 schrieb git(a)git.haskell.org: > commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Tue Nov 4 21:31:00 2014 +0000 > > Fix a couple of inaccurate stack checks I observe a 5% runtime performance regression in nofib’s "integer" benchmark: http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2… (The graph looks weird because codespeed doesn’t get the order of commits right.) Expected? Or worth looking into? 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

1 1

Problems compiling with llvm-3.5.0-2 on ARM
by Jarl Gunnar Flaten 07 Nov '14

07 Nov '14

Hello, (cf. reddit thread <http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedu…> ) I am trying to compile a simple "hello world" program (test.hs). When compiling I am notified: > [1 of 1] Compiling Main ( test.hs, test.o ) > You are using a new version of LLVM that hasn't been tested yet! > We will try though... > Linking test ... But it seems to finish compiling fine, without further errors. However, running the program (./test): > test: schedule: re-entered unsafely. > Perhaps a 'foreign import unsafe' should be 'safe'? Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related. Any ideas for solutions? Any commands or tests I can perform to give you more information? Thanks, Jarl Gunnar T. Flaten

4 4

How do I write multi-file test that are expected to fail?
by Jan Stolarek 07 Nov '14

07 Nov '14

I want to write a test where I import several modules into module Foo and expect that compilation of Foo fails. How do I do that? If I write: test('T6018fail', normal, compile_fail, ['']) I get en error: T6018fail.hs:5:1: Failed to load interface for `T6018Afail' Use -v to se a list of the files searched for. If I use multimod_compile instead of compile_fail then I get an error because compilation is expected to succeed. Help? Janek

2 3

Update Trac link 'Patches for review'
by Thomas Miedema 07 Nov '14

07 Nov '14

Dear Trac admins, on the left panel of the Trac wiki there is a link <https://ghc.haskell.org/trac/ghc/query?status=patch&ol=id&col=summary&col=o…> called 'Patches for review'. This shows a mix of tickets that have patches attached, and tickets that are being reviewed on Phabricator. Can someone change that link to only show the tickets that have patches attached, such that those are more easily found? You can do this by appending "&differential=" to the url. The list of open Phabricator reviews <https://phabricator.haskell.org/differential/> can be discovered on the Phabricator homepage, but I'm afraid the tickets <https://ghc.haskell.org/trac/ghc/query?status=patch&differential=&col=id&co…> that have patches attached are now sometimes overlooked. Thanks, Thomas

2 1

ANN: Updating flag description in the User's Guide
by Jan Stolarek 07 Nov '14

07 Nov '14

Devs, I have some important information for everyone. TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please make absolutely sure that your changes are described in the User's Guide. See Note [Updating flag description in the User's Guide] in DynFlags. TL;DR2 Your help is needed to update the User's Guide. I've spent last two days on updating the flag descriptions in the User's Guide (#9358). Saying that things were a complete mess would be an understatement. We had lots of flags that were not documented in the user's guide, we had documentation for flags that no longer exist, lots of flags were incorrectly labeled as static, etc. It seems that we don't have a habit of updating User's Guide when we change the code responsible for flags. I updated huge chunks of the documentation and things are in a better shape now. But if we forget to update documentation when we make changes then in 2 or 3 years things will most likely be as bad as they were before my clean-up. I added a Note and lots of references to it to remind us about that. If things go well we might even have a Herald rule to remind about updating User's Guide whenever DynFlags and StaticFlags are modified by a commit/revision [1]. However, the task of updating flag descriptions in the User's Guide is not finished. My main focus were the -f*/-fno-* optimisation flags described primarily in sections 4.10 and 4.19.15 (note that HEAD has different section numbers than 7.8.3). I updated what I could but there are still some descriptions missing - I'm not familiar with some of flags that we have. Here's where your help is required. These flags are currently completely missing from the User's Guide: -fbuilding-cabal-package -fflat-cache -fhpc-no-auto -fkill-absence -fkill-one-shot -fsimple-list-literals -fspecialise-aggressively -fuse-rpaths -fspec-constr-recursive -ffloat-lam-args -ffloat-all-lams If you can provide description for any of these flags please edit flags.xml and using.xml. I suspect that -fkill-absence might be related to demand analysis - CCing Nicolas Frisby. Following flags are listed in Flag Reference section (4.19) with a brief one sentence description but they don't have a detailed description in section 4.10 (using.xml): -fcall-arity (CCing Joachim) -funfolding-fun-discount -funfolding-dict-discount -funfolding-keeness-factor -frule-check (see #9776) Following flags have a detailed description but it is confusing: -fdo-eta-reduction -fdo-lambda-eta-expansion Follwoing flags have a description but it is too brief. We should have more details: -fdicts-cheap -fdicts-strict -fdmd-tx-dict-sel (Nicolas, can you update that?) -fmax-inline-memcpy-insns -fmax-inline-memset-insns -fmax-worker-args -fno-opt-coercion -fno-pre-inlining -fsimplifier-phases -fspec-constr-threshold -fspec-constr-count -fstrictness-before These flags were deliberately omitted from the User's Guide because they are deprectaed and will be removed: -fext-core -frewrite-rules For these flags Flag Reference section provides the description of their -fno-* version: -fembed-manifest -fgen-manifest -fghci-history -fghci-sandbox -fpre-inlining -fprint-bind-contents -fprof-count-entries -fshared-implib This seems to go against our convention of describing the flags. Should we revert to desribing their normal version (ie. ones that enable something, not disable)? As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases, which weren;t very useful. And I cleaned up DynFlags by putting some of the long lists of flags into alphabetical order. This change is a bit invasive - I'm sorry if it causes merge conflicts, but I believe that in the long run this is beneficial. As I already said I focused primarily on -f* flags. But we should also make sure that documentation of remaining flags is up to date, especially the -d* ones. I don't have more time to put into this so I'm asking for a collective effort to update the User's Guide, especially that we are moving closer to 7.10 release. Janek [1] https://phabricator.haskell.org/T52

4 6

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