November 2014 - ghc-devs

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

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