- ghc-devs - Haskell.org

Build time regressions
by Joachim Breitner 30 Sep '14

30 Sep '14

Hi, the attached graph shows a noticable increase in build time caused by Update Cabal submodule & ghc-pkg to use new module re-export types author Edward Z. Yang <ezyang(a)cs.stanford.edu> https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176… and only halfway mitigated by Update `binary` submodule in an attempt to address #9630 author Herbert Valerio Riedel <hvr(a)gnu.org> https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bff… I am not sure if the improvement is related to the regression, but in any case: Edward, was such an increase expected by you? If not, can you explain it? Can it be avoided? Or maybe Cabal just became much larger... +38% in allocations when running haddock on it seems to confirm this. 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 0

Re: Aliasing current module qualifier
by John Meacham 30 Sep '14

30 Sep '14

You don't need a new language construct, what i do is: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglongLongModuleName as M I think ghc would need to be extended a little to make this convienient as it doesn't handle recursive module imports as transparently. John On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel <hvr(a)gnu.org> > wrote: > >> Now it'd be great if I could do the following instead: >> >> module AnnoyinglyLongModuleName (M.length, M.null) where >> >> import AnnoyinglyLongModuleName as M -- <- does not work >> > > I think if I wanted this syntax, I'd go for: > > module AnnoyinglyLongModuleName as M where ... > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- John Meacham - http://notanumber.net/

3 3

Aliasing current module qualifier
by Herbert Valerio Riedel 29 Sep '14

29 Sep '14

Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr

5 5

Re: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa)
by Joachim Breitner 29 Sep '14

29 Sep '14

Hi, Am Samstag, den 27.09.2014, 21:07 +0000 schrieb git(a)git.haskell.org: > commit f636faa7b2b7fc1d0663f994ad08f365d39a746d > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Sat Sep 27 22:55:19 2014 +0200 > > Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` > > This is made possible by the AMP, as we don't need the `WrappedMonad` > helper for that anymore. according to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=f636faa7b2b7fc1d0663f994ad… this has caused a 11% regression in fibheaps allocation: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/allocs/fibheaps&env… 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: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a)
by Joachim Breitner 29 Sep '14

29 Sep '14

Hi, Am Sonntag, den 28.09.2014, 13:07 +0000 schrieb git(a)git.haskell.org: > commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Sun Sep 28 13:02:53 2014 +0200 > > Extend `Foldable` class with `length` and `null` methods > > This completes the `Foldable` class by two important operations which > this way can be optimised for the underlying structure more easily. > > A minor fix for the `containers` submodule was needed to due name clash > > Addresses #9621 > > Reviewed By: ekmett, dfeuer, austin > > Differential Revision: https://phabricator.haskell.org/D250 this broke nofib: ==nofib== para: time to compile Main follows... /data1/ghc-builder/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -c Main.lhs -o Main.o Main.lhs:517:32: No instance for (Foldable t0) arising from a use of ‘step’ The type variable ‘t0’ is ambiguous Relevant bindings include par1' :: [t0 a] -> [[t0 a]] (bound at Main.lhs:516:2) Note: there are several potential instances: instance Foldable ((,) a) -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ instance Foldable (Either a) -- Defined in ‘Data.Foldable’ ...plus three others In the first argument of ‘fold1’, namely ‘step’ In the second argument of ‘(.)’, namely ‘fold1 step start’ In the second argument of ‘(.)’, namely ‘minWith cost . fold1 step start’ <<ghc: 93451064 bytes, 44 GCs, 4435640/8217616 avg/max bytes residency (4 samples), 31M in use, 0.001 INIT (0.001 elapsed), 0.051 MUT (0.056 elapsed), 0.057 GC (0.057 elapsed) :ghc>> 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

tar --help is failing on Solaris.
by Karel Gardas 27 Sep '14

27 Sep '14

Hello Mikhail, you are the author of the patch eaf2aae18603965ff668384b391fcaa14de19823 in libraries/Cabal which you have merged into GHC HEAD on September 25 in the patch 4be50969491aa471d6c9ab3b9339036a355d45c6 The problem is that your patch breaks build on Solaris, here is the log from the Solaris/x86 builder: http://haskell.inf.elte.hu/builders/solaris-x86-head/178/10.html Could you be so kind and revert this patch or fix it to also work on Solaris? For Solaris the change should be easy, simply if you invoke Solaris' tar with --help, it'll fail with exit code 1 and help message printed into the stderr. If you are curious if it supports --format, then no. Please let me know if you are able to push fix or revert during next week or if I shall deal with it myself. I can't just fix that now myself since I'm overloaded with other tasks till Wednesday night... Thanks! Karel

3 3

HEADS UP: Running cabal install with the latest GHC
by Edward Z. Yang 27 Sep '14

27 Sep '14

Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in HEAD. So, how do you get a version of cabal-install (and Cabal) which is new enough to do what you need it to? The trick is to compile Cabal using your /old/ GHC. Step-by-step, this involves cd'ing into libraries/Cabal/Cabal and running `cabal install` (or install it in a sandbox, if you like) and then cd'ing to libraries/Cabal/cabal-install and cabal install'ing that. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward

5 8

Re: Permitting trailing commas for record syntax ADT declarations
by Alexander Berntsen 26 Sep '14

26 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forwarding this & my reply to the ML as well, On 22/09/14 14:27, David Luposchainsky wrote: > +1. While you're at it, you may also want to consider allowing > leading commas for the folks that write their exports/records "the > other way round" Sure. Both styles are common in the wild, so that makes sense. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgFo4ACgkQRtClrXBQc7Xz1QEAn5rLEoUuHPGRkJIEy/ZKHuiM xxIF+i/E8X1Y5cdd5HQA/jski9JOlu7LdY1ieucpSMe2KgF3v0VHO+aO+q7QZ93x =v9Ba -----END PGP SIGNATURE-----

13 44

REMINDER: Please review the HCAR entry for GHC!
by Austin Seipp 26 Sep '14

26 Sep '14

Hi *, Just a regularly scheduled reminder: please double-check the latest HCAR entry so we can make sure it's great for the October edition: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 The current page looks good, but we're missing some things like: - Backpack updates - Information on the BBP from Herbert. - We've implemented some new optimizations since last time, like Call Arity, and some other improvements. - Other things: AArch64 support, probably other stuff. I'm sure you all remember what you did. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Linux failures
by Simon Peyton Jones 26 Sep '14

26 Sep '14

I am getting one persistent failure on Linux: =====> user001(normal) 5 of 29 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd . && ./user001 >user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) This is in libraries/unix/tests. I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 @@ -0,0 +1 @@ +ghc-stage2: ioManagerWakeup: write: Bad file descriptor I don't think these can be caused by my commits, but they should be fixed.... Any offers? Simon

4 4