- ghc-devs - Haskell.org

GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
by Herbert Valerio Riedel 12 Mar '15

12 Mar '15

Hello *, The comment https://ghc.haskell.org/trac/ghc/ticket/5108#comment:16 made me aware the Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let xᵦ = 1 let xᵤ = 1 let xᵩ = 1 let xᵢ = 1 let xᵪ = 1 let xᵣ = 1 let xₙ = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). I wanted to raise attention to this, as this IMO deserves (at the very least) some release-note entry, or alternatively (if this is considered a regression) some workaround in the lexer to restore backward compatibility... Cheers, hvr

1 0

tyConHash -- quick fix?
by Simon Peyton Jones 12 Mar '15

12 Mar '15

data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, -- ^ @since 4.8.0.0 tyConPackage :: String, -- ^ @since 4.5.0.0 tyConModule :: String, -- ^ @since 4.5.0.0 tyConName :: String -- ^ @since 4.5.0.0 } Friends, Is tyConHash a good name here? Wouldn't tyConFingerprint be better? * Hash functions usually yield a Int. * tyConFingerprint :: TyCon -> Fingerprint makes the name match the type. * If we had fingerprintHash:: Fingerprint -> Int, then we might want tyConHash :: TyCon -> Int tyConHash = fingerprintHash . tyConFingerpring This is new in 7.10, so we could fix it now with no trouble. Simon

4 4

Porting to Haiku
by Jessica Hamilton 11 Mar '15

11 Mar '15

Hi, I (and one other) am working on porting GHC to Haiku; we've successfully got a working GHC cross-compiler running on Haiku, and now are able to also build GHC on Haiku from the cross-compiler when using the "quickest" profile in the mk/build.mk file. However, using the default build profile, we're running into a couple of issues. 1. A random segfault in ghc-stage1 (is probably an issue in Haiku, not entirely sure yet), with the following call stack: runCFinalizers + 0x3a runAllCFinalizers + 0x37 hs_exit_ +0x99 shutdownHaskellAndExit + 0x2f hs_main + 0xb1 .../ghc-7.8.3/inplace/lib/bin/ghc-stage1 + 0xc7b374 _start + 0x4b runtime_loader + 0x130 I can't really see anything obvious in the source code myself (although our debugger fails to enumerate the semaphores, and also needs to be killed). Restarting the build is sufficient to get past the issue, however. 2. A more pressing issue is with ghc-cabal. It fails with the error "resource exhausted" when running the following command: inplace/bin/ghc-cabal copy compiler stage2 This error is reproducible every time. I've tried setting up a profile build in the mk/build.mk file in order to get a stack trace from ghc-cabal; however, after rebuilding GHC from scratch, running ghc-cabal +RTS -xc, it still complains that the flag -xc requires the program to be built with -prof. Some advice would be handy before diving into another couple hours of rebuilding GHC to try and get a profiled build of ghc-cabal out of the build system ;-) Cheers, Jessica

2 1

RE: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723)
by Simon Peyton Jones 10 Mar '15

10 Mar '15

This test keeps wobbling because a unique id shows up in the pretty-printed Template Haskell output. Maybe it's a poorly designed test; or maybe there should be a way of suppressing these uniques. I'm not sure. It'd be great if someone wanted to take a look Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 10 March 2015 14:28 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : ghc-7.10 | Link : | http://ghc.haskell.org/trac/ghc/changeset/9f19723668b5ef012841012406d1ea4 | 2b618fb69/ghc | | >--------------------------------------------------------------- | | commit 9f19723668b5ef012841012406d1ea42b618fb69 | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Tue Mar 10 15:25:59 2015 +0100 | | fixup T10019 output yet again | | | >--------------------------------------------------------------- | | 9f19723668b5ef012841012406d1ea42b618fb69 | testsuite/tests/th/T10019.stdout | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/testsuite/tests/th/T10019.stdout | b/testsuite/tests/th/T10019.stdout | index 350338c..6345930 100644 | --- a/testsuite/tests/th/T10019.stdout | +++ b/testsuite/tests/th/T10019.stdout | @@ -1 +1 @@ | -"DataConI Ghci1.Some (ForallT [KindedTV a_1627391549 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391549)) (AppT (ConT Ghci1.Option) (VarT | a_1627391549)))) Ghci1.Option (Fixity 9 InfixL)" | +"DataConI Ghci1.Some (ForallT [KindedTV a_1627391544 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391544)) (AppT (ConT Ghci1.Option) (VarT | a_1627391544)))) Ghci1.Option (Fixity 9 InfixL)" | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

RE: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section to document the principles of kind inference
by Simon Peyton Jones 10 Mar '15

10 Mar '15

Guys I'm seeing this validate failures on TH_Roles2 -Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.0.0, +Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.1.0, And similarly safePkg01 -package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.5.0* deepseq-1.4.0.0 ghc-prim-0.3.1.0 integer-gmp-0.5.1.0 +package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.6.0* deepseq-1.4.1.0 ghc-prim-0.3.1.0 integer-gmp-1.0. Could someone fix? Do we want tests that depend on version numbers in this fragile way. They are almost bound to fail repeatedly over time. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 05 March 2015 23:03 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section | to document the principles of kind inference | | Harbormaster failed to build B3285: rGHCb833bc2767d7: User manual section | to document the principles of kind inference! | | USERS | simonpj (Author) | GHC - Documentation (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb833bc2767d7 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Documentation

3 2

GHC Weekly News - 2013/03/10
by Austin Seipp 10 Mar '15

10 Mar '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150310) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. - Today, GHC HQ mostly talked about 7.10 bugs; HEAD is steaming along as usual with no impediments, but we've got several critical bugs we plan on landing fixes for this week; see milestone:7.10.1 for more. But we've also had a little more list activity this week than we did before: - Joachim Breitner asks: how do I extend the blocks in a C-- graph? Jan popped in with advice, but it looks like Joachim found a rather simple solution himself. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008467.html - Karel Gardas wrote to the list about how to better parallelize the GHC build. For background, he's using a UltraSPARC T1-CPU/T2000 server with 32 hardware threads over 8 cores, where parallelism is a bigger win than raw single-threaded performance. But despite that, the performance is of the parallel GHC build is relatively abysmal - and Karel wants help brainstorming ideas to fix it. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008474.html - Herbert Valerio Riedel noted that there are new git hooks in place for all developers on `git.haskell.org`, which will reject new kinds of pushes. In particular, Herbert took the time to implement commit message validation, and whitespace validation. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008480.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit eb3661f2b9f8472f3714774126ebe1183484dd85 - Re-export `<$>` from Prelude (#10113) - Commit 479523f3c37894d63352f1718e06696f3ed63143 - Re-export `<$` from Prelude (#10113) - Commit b359c886cd7578ed083bcedcea05d315ecaeeb54 - Custom `Typeable` solver, that keeps track of kinds (#9858) - Commit 76b1e11943d794da61d342c072a783862a9e2a1a - Improve core linter so it catches `unsafeCoerce` problems (#9122) - Commit 7a2d65a4d93273c89fbb1d19e282d5933c67c7ca - Define proper `MINIMAL` pragma for `class Ix` (#10142) Closed tickets the past week include: #7854, #10118, #10119, #3321, #10132, #9987, #10126, #9707, #10142, #10147, #10113, #9524, #10058, #10100, #2991, #10140, and #9122. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: [Haskell-cafe] ghc -O2 out of memory
by Carter Schonwald 10 Mar '15

10 Mar '15

there SHOULD be a 32bit 7.8.4 build available somewhere for windows, and if not , thats a real problem! I'm gonna shift this thread to ghc-devs, because that *should* get addressed @ghc-devs, how can we help this user get ahold of a 32bit windows 7.8.4 build? (eg, why do we not have one available yet?) -Carter On Mon, Mar 9, 2015 at 4:13 AM, Kees Bleijenberg <K.Bleijenberg(a)lijbrandt.nl > wrote: > Thanks for your answer. > > I also use ghc to create 32 bits dll’s. 7.8.4 is 64 bits GHC and can’t > create 32 bits dll’s (?). This means I have to install 7.8.3 and 7.8.4 on > the same Windows machine. Is this possible? > > > > Kees > > *Van:* Carter Schonwald [mailto:carter.schonwald@gmail.com] > *Verzonden:* zaterdag 7 maart 2015 20:02 > *Aan:* Kees Bleijenberg > *Onderwerp:* Re: [Haskell-cafe] ghc -O2 out of memory > > > > Upgrade to ghc 7.8.4, theres some known bugs in O2 optimization that > resulted in excessive memory usage that are fixed in 7.8.4 > > You'll still have painful compilation times with a 30kloc module , but > memory usage should be physically possible after the upgrade. > > On Mar 7, 2015 10:58 AM, "Kees Bleijenberg" <K.Bleijenberg(a)lijbrandt.nl> > wrote: > > I’ve written a program that reads a Excel file, parses the contents and > generates a haskell module. Every cell in the xls has it’s own function in > the module. This worked fine. > > Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines > haskell code (without comment). I created a testprogram test.hs that > calculates and prints one cell. > > I did ghc --make test.hs and everything works fine. The generated > execuatable is very slow. > > I did ghc --make –O2 test.hs. The compilations takes 15 minutes and aborts > with ‘ghc: out of memory’. I’am working on Win 7 64 bits , ghc version = > 7.8.3. > > > > What can I do to fix this? I do need –O2. I found with smaller xls’s that > optimization speeds up the executable dramatically. > > Before I start experimenting, does it help to split up the xls .hs in > seperate files? I.e. the cells that refer to other cells and cells that > don’t refer to other cells. Or will I still get ‘out of memory’ because the > optimization is global? > > > > Kees > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5751 / Virus Database: 4299/9258 - Release Date: 03/09/15 >

2 1

HEADS-UP: new Git hook linters for whitespace & commit msgs
by Herbert Valerio Riedel 09 Mar '15

09 Mar '15

Hello GHC devs, I finally got to finish reworked Git hook validations[1] which are active effective immediately for the ghc.git repo: - A new whitespace linter that enforces 3 separate in variants for files with the suffixes .hs .hsc .lhs .cabal .c .h .lhs-boot .hs-boot .x .y the 3 invariants (i.e. if the particular invariant held before the commit, it ought to hold afterwards as well): 1. no TABs 2. no trailing whitespaces (NEW) 3. no missing final EOL (NEW) - A new commit msg linter The rationale is explained in http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html TLDR: The structural conventions enforced by the new linter avoid messing up the output of Git tooling; Editors with support for commit-msg syntax-coloring like Vim or Emacs also follow these conventions. This linter has soft (-> warnings) and hard limits (-> error/rejection) The most important hard limits are: - subject line (i.e. 1st line) 80-char max length (& 8-chars min len) - 2nd line must be empty (if it exists) - body lines (i.e. 3rd+ lines) 100-char max length For more details about additional checks see actual code in [1]; the linter tries to give verbose error/warning messages and pointing exactly to the offending lines. Comments/suggestions/debate/pull-requests/etc welcome! PS: the new validators can easily be tested locally on a Git tree (although I've only tested this on Linux): usage: validate-whitespace <git-dir> [<commit-id>+] and you can pass symbolic refs such as 'HEAD' for the <commit-id>, e.g. validate-whitespace ~/Work/ghc-tree/.git HEAD Cheers, hvr [1]: https://github.com/haskell-infra/git-haskell-org-hooks/tree/master/src

3 3

Trac slow again
by Simon Peyton Jones 09 Mar '15

09 Mar '15

Is it just me, or is GHC's Trac taking multiple seconds just to serve up a web page? Simon

2 1

Pattern matching and GADTs
by Simon Peyton Jones 09 Mar '15

09 Mar '15

GHC developers You may be interested in this paper, submitted to ICFP GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness<http://research.microsoft.com/%7Esimonpj/papers/pattern-matching>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios Vytiniotis. It describes a GADT-aware algorithm for detecting missing and redundant patterns. The implementation is not yet up to production quality, but it will be! If you feel able to give us any feedback about the paper itself, that would be incredibly useful. Thanks Simon

2 4