- ghc-devs - Haskell.org

Using cabal-install with GHC HEAD?
by Stephen Paul Weber 01 Oct '14

01 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm running cabal-install 1.20.0.3 -- when I try to install packages for my cross-compiler built from GHC HEAD I get: > ghc-stage1: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create > the database with the correct format. So, do I need an even newer version of cabal-install (HEAD maybe?)? Or does cabal-install just not support GHC HEAD yet at all yet? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJULCK/AAoJENEcKRHOUZzeoigP/0ScPQUxO4lPp7zr2yNz/Vvu fXAyAnEfKssFvCgnXNvaRhj4mGvIb+aRMDT5xs2bCMkx2ZJr1jWOVJrRX1wYmI5M PM6pMQYxJxr4avhPNra388lkkYLf/A7OA/dXvv3Z93TpPWJ6wTwNf0kmnysWo5/j ZLD8qKAMgFjrw6j55gM/gyb9eYKA5eMssVBvlK9YWrHR1InoVmP+Ua+ru50ClP2b WTbH8GFSKcijli1EKPzYzGAvmwcEGTmua+DEo6BvBAciaqDrd1a0FbxYze3IkLq9 frb4PuK71ehd+uQgGrRMqaS+Zty1Rj7lV1NBhHKiL/eT5WBNXuotfDgp9/GT+ch6 ULg3JSTTJ3KEJJ87vmGwgt92RXcJhLHSzWl+3gY10wFvSCt0mHQwFuo+u7nQ+yuG PRBKMN7osnPJR1DjSzIYcGBgSPhMFdBUouiVUiiacEoZF8ukdSO2xXoOB6z3OihB XDVv5tqvp2dbDzHTyJQWl0O381JiDC6Lwogb0Q+G6+rA3CAkh2D+8ryda/zWTze2 DCuu40+MQa6YjO5rXn+eQtXaXVXZUBY1P8VFE7oRfkgxjA78ahT46rpNgtzwlNp0 bPEnBh6lVq3eGwuv/dqtonASOZp3/MEaySBdi6ZCokbZhKagLEY660eHFHY6aURu 6gT+FZFLIOzzl+Xhka/T =A0vd -----END PGP SIGNATURE-----

2 1

Is there a way to add a dynamic library to every link with GHC automatically?
by Stephen Paul Weber 01 Oct '14

01 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm working with my qnx-nto-arm cross-compiler again. I still have the issue where I get link errors about __aeabi_memcpy and similar. I am able to solve this problem by always adding -lcaps to ghc invocations. I'm still not sure if that library should be required, but it does fix the problem. So now I'm wondering if there's a way to tell my GHC build that when it is built for this platform it should just always link against libcaps as well as whatever else? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJUK06LAAoJENEcKRHOUZzekNYQAMMVMpXE1hG0UxFDvKcDzBrD xbK5woDC/7LRhGsXNntG7PM76/vaL51KYenCrPuejYD3xAJXVZY9FifR6yx77qQg ysqX3IZzOQXxAiGDXkkYdf/G2NRIBKhCyCZacY4eCOfRSLVLO58bNbsZI96enrSN j4BTtWoeM/l2wGavV+5QtkDYXrPF7Lg16q1A4w3a7wPLH3YLqeql81gG1qdi55sc nVegs1+Bnr3AzqaMr5n0p5hX0Q+OklNUGVEPRtX6Dh8q7z5MmjKgswXZbukzFUEU wxCSmZYmuQXjYCa0aJkW5J8/2BYBNAkHwTZzZ2GyCtcigCaeaXGppBfEdHk5FHT1 YbyiAheOBJ2ZsTIYdIJEwCGT8KHlxQvruWX3y03LDzV62CX5aMqlISY7oSGY9WM6 ZclMP0mM7whScCdpX2yDsJQV2orSEaWd/9nCF+yVSq4SNpC3fQSzR/aT5PlEpdLh dSnPvPfrDOPdWKF3mITj4P2/oDBO8+iWd6vIUWXjyHrG/iZS5tfeuN9yD8SSudFI l9jiOTPOvOZSyVCXaVEJ0nheUteCM5yAXFN9ipQAuLA10QpH2vt/QpcJ8bvuaMN3 tS+SHr31zV29OZ5nnTaz+Cn8kXaMSSHlgyK/zUjhs2KJAw4XakdzayYS+aLV1Zpz kcs3y8hA/EMu2lTDKYC3 =yv6N -----END PGP SIGNATURE-----

1 1

RE: mkCoreConApps vs. mkConApp
by Simon Peyton Jones 01 Oct '14

01 Oct '14

mkConApp assumes the let/app invariant holds, and hence does not need to carry around, decompose, or test the function type. Hence slightly more efficient. My instinct is to make mkConApp have ASSERT checks for the let/app invariant (and indeed the function having enough (->) arrows), but under #ifdef DEBUG. And rename it "mkLazyConApp" to stress that there's an invariant involved. In contrast mkCoreConApp must carry round the types in order to generate a Case sometimes. Do you feel like doing that? (In HEAD.) Or shall I? Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 29 September 2014 20:05 | To: Simon Peyton Jones | Subject: mkCoreConApps vs. mkConApp | | Hi Simon, | | I ran into a core-lint error on my branch which led me to wonder: when | should anyone use CoreSyn.mkConApp instead of MkCore.mkCoreConApps? | They appear to do roughly the same thing, but mkCoreConApps does more | checks (specifically, in my case, the let/app invariant check) and | claims to be more efficient. mkConApp even tells you to use | mkCoreConApps "if possible". When isn't this possible? | | To fix my error, I changed all uses of mkConApp in MkCore to | mkCoreConApps. Problem solved. But it's all a bit of a mystery why the | problem was there to begin with. Can you shed any light? | | Thanks! | Richard | | PS: The reason this happened on my branch is because of different | handling of making unboxed tuples, thanks to levity-polymorphism.

1 0

GHC Weekly news
by Austin Seipp 01 Oct '14

01 Oct '14

Hi *, Here's the latest weekly news post: https://ghc.haskell.org/trac/ghc/blog/weekly20140930 Included verbatim for those too lazy to open new tabs: ---------------- Hi *, Here's some news for y'all! Apologizes about the unavailability last week; the internet wasn't exactly a very fun place for a system administrator... So without delay, here's the current recap of the past two weeks: - Lots of merged code and code reviews have gone in, and a lot of commits: in the past two weeks since the last update, `ghc.git` has seen just over 100 commits, from about a dozen different developers. - As part of those patches, a significant amount of them have gone towards implementing the "Burning Bridges Proposal" or BBP for the `base` library. This is a set of changes to `base` that have generalized many parts of the API, by putting `Traversable` and `Foldable` in the Prelude. This required a bit of shoveling by Herbert, but now this is all now in GHC HEAD, and will be part of 7.10: - `Prelude` combinators, like `mapM`, have been generalized to the `Traversable` and `Foldable` classes. - Several other modules, like `Control.Monad` and `Data.List`, have been generalized to `Traversable` and `Foldable` where applicable. - `Control.Monad` combinators generalized to `Applicative` where possible. - Similarly, `MonadPlus` combinators like `guard` are generalized to `Alternative`. - `Foldable` has been extended with new methods, like `length` and `null`. - But also, GHC's compiler is now tab-free! That's right, after what seemed like a million years, a very large portion of the code has been detabbed, and `-fwarn-tabs` is now on by default in the GHC build. - There are an assortment of other changes: GHC's linker is not as loud[1], and various documentation improvements. - The windows build is broken *again* unfortunately, this time due to what seems to be a Cabal update, I think. Austin is once again on the case. - The HCAR draft for October has seen some nice improvements. If you're a developer, please amend things. If you're a user, read with eager anticipation of all the new features![2] - It turns out the new Applicative/Monad changes have unfortunately broken the `haskell98` and `haskell2010` packages, with an unclear migration strategy for the future: see #9590. For GHC 7.10, it seems the `haskell2010` packages will need to change to accomodate these standard deviations. If any users of the `haskell98` or `haskell2010` packages would speak up to help, that would be fantastic. The discussion will surely continue for a little bit - 7.10 is still a ways off. In miscellaneous news: - ghc.haskell.org may have been temporarily unavailable during this weekend due to an emergency downtime with our provider for a security update, but the window was quite small. - Relatedly (but not the exact same scenario), the internet also caught fire in several other places, requiring quite a lot of careful watching and remediation after the Bash "ShellShock" bug hit last week. And I think that sums it up quite nicely, folks! Closed tickets for the past two weeks include (there are a lot of them!): #9650, #7068, #5190, #5880, #8374, #9603, #3303, #3470, #3509, #781, #8115, #9641, #9191, #9515, #9326, #7987, #9634, #9576, #9612, #9635, #8593, #7544, #8529, #9338, #5794, #9535, #3646, #617, #8026, #8480, #8881, #9366, #8251, #7673, #8983, #8369, #8897, #8070, #9550, #9057, #9629, #8836, #8960, #8941, #9565, #9589, #5248, #8918, #9568, #9620, #1042, #9557, #7863, #5647, #9610, #5395, #9580, #9529, #4426, #9607, #9592, #8097, #9559, #9560, #4218, #9602, #9528, #9530, #9423, #9400, #1407, #9598, #9597. I'd like to mention that for the above tickets, a *huge* amount of them were closed by one of our newest contributors, **Thomas Miedema**, who went through the bug tracker and confirmed or closed a large majority of them. I lost track of how many. Thanks Thomas! [1] https://github.com/ghc/ghc/commit/9f7e3633c692dce75c27607131bd386178fb0fcf [2] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

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