- ghc-devs - Haskell.org

whitehole_spin: always 0?
by Patrick Palka 26 Jul '13

26 Jul '13

It seems that the value of the whitehole_spin counter (as viewable by +RTS -s) is always zero, which oddly suggests that there is never any contention on the particular atomic operation whitehole_spin is tracking (located in copyPart in Evac.c). This may be a symptom of a bug, or it may be the case that the atomic operation is not necessary. (Or perhaps contention is just very rare. But if contention is rare, why is this operation being counted in particular?) Either way, I think this is a bit strange and probably worth investigating. Patrick

2 3

T5321FD and T5321Fun performance improvements
by Jan Stolarek 26 Jul '13

26 Jul '13

T5321FD and T5321Fun are failing with HEAD - performance stat is too good. Looks like the allocation has decreased. Did anyone notice when this improvement happened? Janek

2 2

RE: [commit: base] master: Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning (365b9d8)
by Simon Peyton-Jones 25 Jul '13

25 Jul '13

Richard I am deeply suspicious of all these hs-boot files. Instances should preferably go EITHER with the data type declaration OR with the class declaration. In the case of Proxy, for example, why can't the Typeable instance for Proxy go in Data.Typeable.Internals? (And perhaps similarly for other instances.) Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | Richard Eisenberg | Sent: 24 July 2013 12:41 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Implement "TypeLevelReasoning" proposal at | wiki:TypeLevelReasoning (365b9d8) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/365b9d86d195dc483610a68836b4 | 063656602244 | | >--------------------------------------------------------------- | | commit 365b9d86d195dc483610a68836b4063656602244 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Wed Jul 24 12:38:50 2013 +0100 | | Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning | | This commit includes a propositional equality (:=:) in Data.Type.Equality, | a Proxy type in Data.Proxy, and has updates to Typeable. | | There is an unfortunate number of hs-boot files necessary, but that | seems cleaner than moving Typeable instances around willy-nilly. | | Data/Data.hs | 2 +- | Data/Proxy.hs | 129 | ++++++++++++++++++++++++++++++++++++++++ | Data/Proxy.hs-boot | 5 ++ | Data/Type/Equality.hs | 99 | ++++++++++++++++++++++++++++++ | Data/Type/Equality.hs-boot | 6 ++ | Data/Typeable.hs | 42 +++++++------ | Data/Typeable/Internal.hs | 5 +- | Data/Typeable/Internal.hs-boot | 3 +- | base.cabal | 2 + | 9 files changed, 269 insertions(+), 24 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 365b9d86d195dc483610a68836b4063656602244 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

haddock: internal error: synifyKind
by Simon Marlow 24 Jul '13

24 Jul '13

A validate today on x86_64/Linux is failing with haddock: internal error: synifyKind While haddocking the base package. Anyone know why? Cheers, Simon

2 2

RE: new-typeable, new cast?
by Simon Peyton-Jones 24 Jul '13

24 Jul '13

I'd suggest using "WithinType" as the argument to synifyType that's currently an error call in Haddock.Convert line 356 Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 23 July 2013 15:12 | To: Edward Kmett | Cc: José Pedro Magalhães; Dimitrios Vytiniotis; Simon Peyton-Jones; Stephanie | Weirich; josepedromagalhaes(a)gmail.com; libraries(a)haskell.org; Conor McBride | Subject: Re: new-typeable, new cast? | | Well, there was another surprise. Haddock can't deal with Proxy for some | reason. (It dies with the error "synifyKind". I looked but couldn't | figure out what was going on there.) I've posted a bug report on the | haddock Trac (http://trac.haskell.org/haddock/ticket/242) but | validation currently fails on the branch (data-proxy) with this work in | it. So, I can't merge with master. | | At this point, I'm going to wait until the haddock folks fix that bug, | then assuming all is well, I will merge. | | Richard | | | | On 2013-07-23 09:59, Richard Eisenberg wrote: | > I think that we really only need (eqT :: (Typeable a, Typeable b) => | > Maybe (a :=: b)). All of the gcasts can be defined in terms of that | > function. | > | > However, I concretely propose (and plan to do) this: Leave gcast1 and | > gcast2 in and undeprecated. Simon is right that there is an infinite | > family of gcasts, and there may be no great reason to have gcast1 and | > gcast2 and none of the others, but there also doesn't seem to be a | > compelling reason to remove them (or deprecate them) and break code. | > In any case, this debate doesn't seem to be a good reason to hold up | > wrapping the rest of these details up, because we can always revisit | > and add or remove functions in the coming weeks. I'm not trying to | > ramrod my ideas through here, just trying to favor action over | > inaction -- anyone can feel free to come back and make edits after I | > push. | > | > Barring another surprise, I believe I'll push before lunch (in the UK). | > | > Richard | > | > On 2013-07-23 03:04, Edward Kmett wrote: | >> If we have gcast1 then can't the others just be applications of that | >> under various wrappers? | >> | >> In practice we should be able to implement gcast2 by working on a | >> single argument with a product kind, and so on and so forth, but we | >> need at least gcast1 as a base case. | >> | >> In theory this is the more fundamental operation, and gcast is | >> defineable in terms of gcast1 with a wrapper with a unit-kinded | >> argument, but I wouldn't want to invert the relationship. | >> | >> This is based on the same trick that Conor uses to show that a single | >> (poly-kinded) type argument is enough for all of the indexed monad | >> machinery, no matter how complicated it gets. | >> | >> TL;DR We only need gcast1, the others are window-dressing. | >> | >> -Edward | >> | >> On Mon, Jul 22, 2013 at 9:31 PM, Simon Peyton-Jones | >> <simonpj(a)microsoft.com> wrote: | >> | >>> Harump. There is *still* an infinite family going on here, isn't | >>> there? | >>> | >>> gcast :: forall a b c. (Typeable a, Typeable b) => c a -> Maybe (c | >>> b) | >>> | >>> but what about this | >>> | >>> gcast_2 :: forall a b c d e. (Typeable a, Typeable b, Typeable d, | >>> Typeable e) | >>> => c a b -> c d e | >>> | >>> Then, as you point out, we have gcast1 and 2 (etc). And there are | >>> more. What about | >>> | >>> gcast1' :: forall c t a a'. (Typeable a, Typeable a') | >>> => c (t a) -> Maybe (c (t a')) | >>> | >>> One could imagine all sorts of combinations of bits that stay the | >>> same (and hence do not need to be Typeable) and bits that change | >>> (and hence do need to be Typable). | >>> | >>> As Edward says, all these functions can be polykinded, which makes | >>> them more useful, but there still seem too many of them. | >>> | >>> I wonder if we could instead make a combinatory library that lets | >>> us build these functions easily. It think we are going to offer a | >>> function that computes an equality witness: | >>> | >>> mkEqWit :: (Typable a, Typeable b) => Maybe (EQ a b) | >>> | >>> Now we need to be able to compose witnesses: | >>> | >>> appEqWit :: Eq a b -> Eq c d -> Eq (a c) (b d) | >>> reflEqWit :: Eq a a | >>> | >>> Now, I think you can make all those other casts. | >>> | >>> Would that do the job better? | >>> | >>> Simon | >>> | >>> | -----Original Message----- | >>> | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | >>> | Sent: 22 July 2013 10:20 | >>> | To: José Pedro Magalhães | >>> | Cc: Dimitrios Vytiniotis; Simon Peyton-Jones; Stephanie | >>> Weirich; | >>> | josepedromagalhaes(a)gmail.com; libraries(a)haskell.org; Conor | >>> McBride | >>> | Subject: Re: new-typeable, new cast? | >>> | | >>> | >>> | There seems to be a small tangle. The proposal includes | >>> deprecating | >>> | gcast1 and gcast2 in favor of the poly-kinded gcast. But, there | >>> is a | >>> | small discrepancy between these. Here are the type signatures: | >>> | | >>> | > gcast :: forall a b c. (Typeable a, Typeable b) => c a -> | >>> Maybe (c b) | >>> | > gcast1 :: forall c t t' a. (Typeable (t :: * -> *), Typeable | >>> t') | >>> | > => c (t a) -> Maybe (c (t' a)) | >>> | | >>> | The difference is that gcast1 does *not* require the variable | >>> `a` to be | >>> | Typeable, whereas defining gcast1 = gcast does require this. | >>> Not | >>> | requiring `a` to be Typeable seems correct to me, as the type | >>> signature | >>> | of gcast1 requires both uses of `a` to be the same. But, gcast | >>> isn't | >>> | smart enough to know that. Here are some ideas of how to | >>> proceed: | >>> | | >>> | - Keep gcast1 and gcast2 undeprecated. | >>> | - Require clients to add more Typeable constraints (for | >>> example, in | >>> | Data.Data) to get their code to compile with gcast. | >>> | - Come up with some other workaround, but none is striking me | >>> at the | >>> | moment. | >>> | | >>> | Thoughts? | >>> | | >>> | Richard | >>> | | >>> | On 2013-07-22 09:44, Richard Eisenberg wrote: | >>> | > I was waiting to respond to Shachaf's email saying "pushed", | >>> but | >>> | > instead, I have to say "currently validating". | >>> | > | >>> | > Expect this by the end of the day. Sorry it's taken so long! | >>> | > | >>> | > Richard | >>> | > | >>> | > On 2013-07-22 09:23, José Pedro Magalhães wrote: | >>> | >> Thanks for bringing this up again. This was started in my | >>> data-proxy | >>> | >> branch of base [1], | >>> | >> but never really finished. We definitely want to have this | >>> in 7.8, and | >>> | >> I think there's | >>> | >> only some minor finishing work to do (check if we have all | >>> the | >>> | >> instances we want, | >>> | >> document, etc.). Perhaps you can look through what's there | >>> already, | >>> | >> and what you | >>> | >> think is missing? I'm more than happy to accept contributing | >>> patches | >>> | >> too :-) | >>> | >> | >>> | >> Thanks, | >>> | >> Pedro | >>> | >> | >>> | >> On Sun, Jul 21, 2013 at 3:09 AM, Shachaf Ben-Kiki | >>> <shachaf(a)gmail.com> | >>> | >> wrote: | >>> | >> | >>> | >>> On Mon, Mar 4, 2013 at 11:12 AM, José Pedro Magalhães | >>> | >>> <jpm(a)cs.uu.nl> wrote: | >>> | >>>> Hi, | >>> | >>>> | >>> | >>>> On Mon, Mar 4, 2013 at 4:51 PM, Richard Eisenberg | >>> | >>> <eir(a)cis.upenn.edu> wrote: | >>> | >>>>> | >>> | >>>>> Unless I'm missing something, this all looks very | >>> | >>> straightforward. The | >>> | >>>>> implementation is there, already, in the guise of (gcast | >>> Refl). | >>> | >>> We would | >>> | >>>>> just shuffle the definitions around a bit. Am I indeed | >>> missing | >>> | >>> something? | >>> | >>>> | >>> | >>>> | >>> | >>>> I think that is the case indeed. Though I agree that it | >>> would be | >>> | >>> a nice | >>> | >>>> addition to Data.Typeable. | >>> | >>>> | >>> | >>>> | >>> | >>> | >>> | >>> This thread is a few months old now, but it looks like | >>> people were | >>> | >>> generally in favor of adding (gcast Refl) to Data.Typeable. | >>> I've | >>> | >>> used | >>> | >>> it in real code in at least one place since then (where I | >>> just | >>> | >>> defined | >>> | >>> it locally). It doesn't look like it's actually been added, | >>> though | >>> | >>> -- | >>> | >>> is it planned to go into HEAD eventually? | >>> | >>> | >>> | >>> Shachaf | >>> | >> | >>> | >> | >>> | >> | >>> | >> Links: | >>> | >> ------ | >>> | >> [1] https://github.com/ghc/packages-base/tree/data-proxy [1] | >>> | > | >>> | > _______________________________________________ | >>> | > Libraries mailing list | >>> | > Libraries(a)haskell.org | >>> | > http://www.haskell.org/mailman/listinfo/libraries [2] | >>> | >>> _______________________________________________ | >>> Libraries mailing list | >>> Libraries(a)haskell.org | >>> http://www.haskell.org/mailman/listinfo/libraries [2] | >> | >> | >> | >> Links: | >> ------ | >> [1] https://github.com/ghc/packages-base/tree/data-proxy | >> [2] http://www.haskell.org/mailman/listinfo/libraries | > | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries

2 1

Repo permissions broken
by Simon Marlow 24 Jul '13

24 Jul '13

I tried and failed to push to the testsuite repo today. $ git push Counting objects: 12, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 695 bytes, done. Total 7 (delta 5), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To simonmar@darcs.haskell.org:/srv/darcs/testsuite.git ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'simonmar@darcs.haskell.org:/srv/darcs/testsuite.git' It looks like we're not setting group write permission correctly after commits: simonmar@ghc:/home/darcs/testsuite.git/objects$ ls -l total 136 drwxr-sr-x 2 ezyang darcs 4096 Jul 20 22:53 02 drwxr-sr-x 2 simonmar darcs 4096 Jul 22 09:51 0a drwxr-sr-x 2 ezyang darcs 4096 Jul 20 18:13 0f I vaguely recall that we used to do this with a post-commit hook to do a 'chmod g+w -R' on the tree. Could someone look into this please? Cheers, Simon

4 6

Future plans
by Ian Lynagh 24 Jul '13

24 Jul '13

Friends, For a number of reasons, I have decided to move on to new challenges, and so from the end of the month the GHC maintenance work will be taken over by other people within Well-Typed. I hope not to disappear completely, but in any case if there is anything you think only I might know, please tell me and I'll try to document it! A couple of topical items: First, I've written a brief summary of the GHC 7.8 release plans here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Please feel free to edit it if there's anything I've left out, or if there are any other errors. Second, there's been a bit of discussion recently about moving over to using git submodules for more repos, or using git subrepos instead, or merging some of our repos together. We didn't feel that there was a consensus on what to do, so we plan to do nothing for now, but this is an area that might want to be revisited after the 7.8 release. Finally, I would like to everyone at Well-Typed, the Simons, and too many other community members to list, for a fantastic seven years. It's been a pleasure working with you all, and I look forward to finding out where the future takes us. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

7 6

RE: ANNOUNCE: ghci-ng package
by Simon Peyton-Jones 24 Jul '13

24 Jul '13

Herbert, it certainly sounds like a good thing to me. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] | On Behalf Of Herbert Valerio Riedel | Sent: 20 July 2013 10:42 | To: glasgow-haskell-users(a)haskell.org | Subject: ANNOUNCE: ghci-ng package | | Hello GHC HQ, | | I wanted to inform you that I created the `ghci-ng` package | | http://hackage.haskell.org/package/ghci-ng-7.6.3.3 | | which essentially is the ghc/* folder from the GHC source-tree with a | ghci-ng.cabal file put in place (and some dummy .h files) to make the | interactive-mode GHC front-end compilable w/o requiring the full GHC | source-tree. | | The reason I created ghci-ng was to be able to backport features from | GHC HEAD so that Haskell user not living on the bleeding edge (such as | Haskell Platform users) don't have to wait for half a year or so till | they can use new features[1]. On the other hand, this might also allow | to expose new work-in-progress features to users in production | environments to play with before those features find their way into a | final GHC release, and thus help with developing new GHCi features in a | more "agile" way by getting feedback from potential users earlier. | | So ghci-ng is *not* supposed to replace ghci, but rather provide an | testing ground for evaluating new/experimental features which may get | merged into upstream GHCi eventually if they prove useful. | | Please let me know what you think of this. | | [1]: The killer-feature right now being the new `:complete` command | which allows the latest (unreleased) haskell-mode to provide | REPL-completion from within the Emacs buffer. | | Cheers, | hvr | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Adding constant folding for Integer div and mod
by Jan Stolarek 22 Jul '13

22 Jul '13

It seems that currently there are no built-in constant folding rules for Integer div and mod. I plan on adding those rules, but before I do that I wanted to ask whether there is a good reason that these rules don't exist? Janek

4 4

git push failure
by Simon Marlow 22 Jul '13

22 Jul '13

I got this from a git push today: $ git push Counting objects: 17, done. Delta compression using up to 8 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (11/11), 1.20 KiB, done. Total 11 (delta 6), reused 0 (delta 0) remote: Traceback (most recent call last): remote: File "/home/local/bin/git-notifier", line 388, in <module> remote: Config = GitConfig(sys.argv[1:]) remote: File "/home/local/bin/git-notifier", line 102, in __init__ remote: self.log = open(self.log, "a") remote: IOError: [Errno 13] Permission denied: 'ghc-notifier.log' remote: Host key verification failed. remote: fatal: The remote end hung up unexpectedly To simonmar@darcs.haskell.org:/srv/darcs/packages/base.git 5c37ca9..0b02a2e master -> master Anyone know what's wrong? I think the push went through.

3 2