- ghc-devs - Haskell.org

More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Merijn Verstraaten 25 Nov '14

25 Nov '14

As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation. Unless there's any vehement objections, I'll produce a diff on fabricator asap. Cheers, Merijn

8 11

NOTE: The STABLE freeze is scheduled to occur TODAY.
by Austin Seipp 25 Nov '14

25 Nov '14

Hi friends, Today, I'm planning on trying to cut a new `ghc-7.10` branch for the stable freeze. That means I'm going to spend a lot of time merging patches and other things with several other developers because everything is crazy and so many things wow. If you have things you want me to review, then please: - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice') - Ping me on some medium like Skype (search for me). We can schedule a chat for a short time to figure things out. - I can also do something like G+ or whatnot. - I will of course be reading my email. Please note I would actually prefer to stay *away* from email I think, since it's a larger context switch for me, but I'll actively check it still just in case you want something and need to explain it. I'll likely be doing this most of the day, so let me know what happens. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

has anyone tested the llvm backend changes on OS X yet?
by Carter Schonwald 25 Nov '14

25 Nov '14

i'm trying to test out the llvm backend on OS X with ghc head plus llvm 3.5 and i'm seeing stuff like the following. Could someone help me undestand whats going on?! 2 <http://lpaste.net/115021#line2>3 <http://lpaste.net/115021#line3>4 <http://lpaste.net/115021#line4>5 <http://lpaste.net/115021#line5>6 <http://lpaste.net/115021#line6>7 <http://lpaste.net/115021#line7>8 <http://lpaste.net/115021#line8>9 <http://lpaste.net/115021#line9>10 <http://lpaste.net/115021#line10>11 <http://lpaste.net/115021#line11> *** Clang (Assembler):clang -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc89553_0/ghc89553_7.s -o TestFetch.o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc89553_0/ghc89553_7.s:3:2: error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly)

1 0

mask in waitQSem
by Yuras Shumovich 25 Nov '14

25 Nov '14

Hello, I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/… Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras

3 8

Diff grouping question
by Alan & Kim Zimmerman 24 Nov '14

24 Nov '14

I am picking up some minor updates required for the API annotations, relating to documentation inaccuracies, and some missing annotations needing to be captured in the parser. Should these go into separate Phab diffs, or can I just put them all in one? Alan

2 1

how to write a ghc primop that acts on an unevaluated argument?
by Carter Schonwald 23 Nov '14

23 Nov '14

Hey All, as part of trying to get some fixups for how prefetch works into 7.10, i'm adding a "prefetchValue" primop that prefetchs the memory location of a lifted heap value namely several operations of the following form primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp a -> State# s -> State# s with strictness = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] topRes } I'd like some feedback on the strictness information design by someone who's familiar with how that piece of GHC. the idea being that prefetchValue is lazy in its polymorphic argument (it doesn't force it, it just does a prefetch on the heap location, which may or may not be evaluated). https://phabricator.haskell.org/D350 is the code in question. And i *believe* i'm testing for being lazy in that argument correctly. thoughts? many thanks! -Carter

2 2

OS X breakage: make -j and 4 unexpected failures
by Merijn Verstraaten 23 Nov '14

23 Nov '14

Carter was having difficulty compiling on OS X 10.9 with Xcode 6.0, so I tried building head and ran into some issues. 1) I used to build using make -j, but this fails with cryptic errors now. ./validate (which uses -j) and "make" seem to work. The specific error (appearing somewhere during stage 2 build) is: Couldn't figure out C compiler information! Warning: Make sure you're using GNU gcc, or clang Furthermore, when trying to run ./validate --fast I run into 4 unexpected failures. If anyone can tell me how I can get the test suite to report the exact difference in output I will send those along. Unexpected results from: TEST="cabal01 T5435_dyn_asm subsections_via_symbols cabal06 T4801" OVERALL SUMMARY for test run started at Sat Nov 22 21:35:31 2014 PST 0:07:30 spent to go through 4230 total tests, which gave rise to 13843 test cases, of which 9956 were skipped 53 had missing libraries 3763 expected passes 66 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures 1 unexpected stat failures Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal06 cabal06 [bad stdout] (normal) llvm/should_run/subsections_via_symbols subsections_via_symbols [bad exit code] (normal) rts T5435_dyn_asm [bad stdout] (normal) Unexpected stat failures: perf/compiler T4801 [stat too good] (normal) Cheers, Merijn

2 1

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

22 Nov '14

Hi *, To get things back on track, we have a short post following up the earlier one this week. It's been busy today so I'll keep it short: - The STABLE freeze Austin announced two weeks ago is happening now, although at this point a few things we wanted to ship are just 98% ready. So it may wait until Monday. - HEAD has been very busy the past two days as many things are now trying to merge as closely to the window as possible. Some notes follow. - Gergo Erdi merged the implementation of pattern synonym type signatures: https://www.haskell.org/pipermail/ghc-devs/2014-November/007369.html - HEAD now has support for using the 'deriving' clause for arbitrary classes (see #5462). - HEAD now has a new flag `-fwarn-missing-exported-sigs`, which fixes #2526. See https://phabricator.haskell.org/D482 - HEAD now has 64bit iOS and SMP support for ARM64, thanks to Luke Iannini. See #7942. - HEAD no longer ships `haskell98`, `haskell2010`, `old-locale` or `old-time`, per our decision to drop support for `haskell98` and `haskell2010`. GHC 7.10 compatible releases of `old-locale` and `old-time` have been released on hackage. See https://www.haskell.org/pipermail/ghc-devs/2014-November/007357.html and https://www.haskell.org/pipermail/ghc-devs/2014-November/007383.html - `base` now exports a new module for Natural numbers called `Numeric.Natural` following Herbert Valerio Riedel's recent proposal. - HEAD should finally be compatible with LLVM 3.5, AKA #9142. The patch from Ben Gamari is at https://phabricator.haskell.org/D155 - Your author has been busy and delayed due to some bad travel experiences the past week, so the 7.8.4 RC1 hasn't landed this past week. Hopefully it will be out by the end of this week still. Since the last update was only a few days ago, you'd think we haven't closed a lot of tickets, but we have! Thomas Miedema has been very very persistent about closing tickets and cleaning them up, which is greatly appreciated: #9810, #8324, #8310, #9396, #9626, #9776, #9807, #9698, #7942, #9703, #8584, #8968, #8174, #9812, #9209, #9220, #9151, #9201, #9318, #9109, #9126, #8406, #8102, #8093, #8085, #8068, #8094, #9590, #9368, #2526, #9569, #8149, #9815, #5462, #9647, #8568, #9293, #7484, #1476, #9824, #9628, #7942 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RE: [commit: ghc] master: Add T7220a.stderr (6265f1c)
by Simon Peyton Jones 21 Nov '14

21 Nov '14

Thanks Joachim. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 21 November 2014 20:56 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Add T7220a.stderr (6265f1c) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6265f1c3162a192220ec03d888e1c1e | f686b2732/ghc | | >--------------------------------------------------------------- | | commit 6265f1c3162a192220ec03d888e1c1ef686b2732 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Fri Nov 21 21:55:37 2014 +0100 | | Add T7220a.stderr | | which presumably was just forgotten when creating the testcase in | commit 7b1a856. | | | >--------------------------------------------------------------- | | 6265f1c3162a192220ec03d888e1c1ef686b2732 | testsuite/tests/typecheck/should_compile/T7220a.stderr | 14 | ++++++++++++++ | 1 file changed, 14 insertions(+) | | diff --git a/testsuite/tests/typecheck/should_compile/T7220a.stderr | b/testsuite/tests/typecheck/should_compile/T7220a.stderr | new file mode 100644 | index 0000000..4be503d | --- /dev/null | +++ b/testsuite/tests/typecheck/should_compile/T7220a.stderr | @@ -0,0 +1,14 @@ | + | +T7220a.hs:17:6: | + Could not deduce (C a b) | + from the context (C a0 b, TF b ~ Y) | + bound by the type signature for f :: (C a0 b, TF b ~ Y) => b | + at T7220a.hs:17:6-44 | + Possible fix: | + add (C a b) to the context of | + the type signature for f :: (C a0 b, TF b ~ Y) => b | + In the ambiguity check for the type signature for ‘f’: | + f :: forall a. (forall b. (C a b, TF b ~ Y) => b) -> X | + To defer the ambiguity check to use sites, enable | AllowAmbiguousTypes | + In the type signature for ‘f’: | + f :: (forall b. (C a b, TF b ~ Y) => b) -> X | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Re: [commit: ghc] master: Be consistent with placement of Safe Haskell mode at top of file (2a523eb)
by Herbert Valerio Riedel 21 Nov '14

21 Nov '14

Hello David, On 2014-11-21 at 22:03:23 +0100, git-4Dsf34iY/NkouOHNgZ69ag(a)public.gmane.org wrote: [...] > commit 2a523ebf091478aea39deef28073320bed628434 > Author: David Terei <code-A0igW9AEfH2M2ScGVVA7yQ(a)public.gmane.org> > Date: Wed Nov 19 18:29:51 2014 -0800 > > Be consistent with placement of Safe Haskell mode at top of file Why is that necessary? Fwiw, I'm afraid that's gonna be hard to retain; it's more obvious/easier to keep all LANGUAGE pragmas in alphabetic order (I've probably done that a couple of times in `base` deliberately myself) than to introduce such an artificial ordering on the language pragmas. The reason is, you can instruct an editor to select the first paragraph which comprises the block of one-per-line language-pragmas is, and have it sorted it alphabetically. That's just a few keystrokes. But it's rather difficult to teach the editor to use an ordering relation other than the usual alphabetic/lexicographic ordering. Cheers, hvr

2 1