Preliminary proposal: Monoidal categories in base and proc notation support
Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Preliminary proposal: Monoidal categories in base and proc notation support
On Mon, 2014-09-15 at 17:30 +1000, Sophie Taylor wrote: Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Hi Sophie, In your proposal draft, I am missing the rationale part. Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? Roman signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
I think it is best to fill in a bug report and attach a patch - I'm afraid this mail may have gone unnoticed :-) Janek Dnia piątek, 12 września 2014, Moritz Angermann napisał: Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on 2014-04-29 in commit: http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534 12b9877 In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a 8308e..HEAD:/includes/CodeGen.Platform.hs introducing a set of new ifdef/elif/endif pairs. Especially for MACHREGS_NO_REGS, namely: -#endif globalRegMaybe _= Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic globalRegMaybe not defined for this platform +#endif ARM.hs (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169 ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: #define MACHREGS_NO_REGS 0 #define MACHREGS_arm 1 where MACHREGS_arm 1 has no effect on the subsequently imported CodeGen.Platform.hs. Therefore I propose that a change to ARM.hs is made to set MACHREGS_NO_REGS to 1. Cheers, Moritz ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
Hi Janek, yea :) I think it went by unnoticed. Patch is already in Phab, https://phabricator.haskell.org/D208 Not sure how to speed up the review process, though ;-) Cheers, Moritz On Sep 15, 2014, at 11:13 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I think it is best to fill in a bug report and attach a patch - I'm afraid this mail may have gone unnoticed :-) Janek Dnia piątek, 12 września 2014, Moritz Angermann napisał: Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on 2014-04-29 in commit: http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534 12b9877 In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a 8308e..HEAD:/includes/CodeGen.Platform.hs introducing a set of new ifdef/elif/endif pairs. Especially for MACHREGS_NO_REGS, namely: -#endif globalRegMaybe _= Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic globalRegMaybe not defined for this platform +#endif ARM.hs (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169 ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: #define MACHREGS_NO_REGS 0 #define MACHREGS_arm 1 where MACHREGS_arm 1 has no effect on the subsequently imported CodeGen.Platform.hs. Therefore I propose that a change to ARM.hs is made to set MACHREGS_NO_REGS to 1. Cheers, Moritz ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Preliminary proposal: Monoidal categories in base and proc notation support
Hi Sophie, In your proposal draft, I am missing the rationale part. Yeah, I'm still writing it - I definitely need to expand that a bit mor. Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: cminusminus.org does not have a link to the spec
Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, won that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -Original Message- | From: Sergei Trofimovich [mailto:sly...@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit import statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Preliminary proposal: Monoidal categories in base and proc notation support
Sophie I’m guessing that the primary audience for your proposal is the Core Libraries Committee, rather than GHC itself. I’m cc’ing them. So far as GHC is concerned, there is a long-running ticket #7828 that your proposal may bear on. I am not satisfied with GHC’s treatment of arrows; it is complex and I do not fully understand it myself. If you were able to join in the effort to simplify and modularise the story, that would be great. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Sophie Taylor Sent: 15 September 2014 08:31 To: ghc-devs@haskell.org Subject: Preliminary proposal: Monoidal categories in base and proc notation support Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
Is there a Trac ticket too? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz | Angermann | Sent: 15 September 2014 10:19 | To: ghc-devs@haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Hi Janek, | | yea :) I think it went by unnoticed. Patch is already in Phab, | | https://phabricator.haskell.org/D208 | | Not sure how to speed up the review process, though ;-) | | Cheers, | Moritz | | On Sep 15, 2014, at 11:13 AM, Jan Stolarek jan.stola...@p.lodz.pl | wrote: | | I think it is best to fill in a bug report and attach a patch - I'm | afraid this mail may have gone | unnoticed :-) | | Janek | | Dnia piątek, 12 września 2014, Moritz Angermann napisał: | Hi, | | when trying to compile a ghc HEAD on LLVM ARM, I end up getting an | exception: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140911 for arm-apple-ios): | globalRegMaybe | | After some digging I found that a new call to globalRegMaybe was | introduced | here: | http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 | on | 2014-04-29 in commit: | | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 | 34 | 12b9877 | | In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs | was | changed: | | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd | 6a | 8308e..HEAD:/includes/CodeGen.Platform.hs | | introducing a set of new ifdef/elif/endif pairs. Especially for | MACHREGS_NO_REGS, namely: | | -#endif | globalRegMaybe _= Nothing | +#elif MACHREGS_NO_REGS | +globalRegMaybe _ = Nothing | +#else | +globalRegMaybe = panic globalRegMaybe not defined for this | platform | +#endif | | ARM.hs | | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 | 69 | ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: | | #define MACHREGS_NO_REGS 0 | #define MACHREGS_arm 1 | | where MACHREGS_arm 1 has no effect on the subsequently imported | CodeGen.Platform.hs. | | Therefore I propose that a change to ARM.hs is made to set | MACHREGS_NO_REGS to 1. | | Cheers, | Moritz | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
It's that time again (for the HCAR)
Hi *, It is that time again where once every 6 months, we write our entry for the Haskell Communities and Activities Report (HCAR), summarizing what exactly we're all doing. I say 'we' write this of course because I need everyone to write some stuff on what they're doing. :) I'll editorialize it before sending it in, but please feel free to add things. I've drafted a very basic page, based on the last one: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 I sort of selectively cherry-picked some things from the prior 7.10 updates. Again, please feel free to add things as you see fit. I eagerly await your edits! Let's try to get this one done on time. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
The build is broken on {32,64}-bit Windows
Hello there, For your information, the build has been failing for a few days now on both my Windows builders [1][2], basically in the same way. [...] librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Could somebody do something with this, or does anybody have hints on how to fix this? Looks like the culprit is the haskeline library. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: The build is broken on {32,64}-bit Windows
Grrr, this is my fault (AMP fallout). Fix incoming. On Mon, Sep 15, 2014 at 7:30 AM, Páli Gábor János pali.ga...@gmail.com wrote: Hello there, For your information, the build has been failing for a few days now on both my Windows builders [1][2], basically in the same way. [...] librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Could somebody do something with this, or does anybody have hints on how to fix this? Looks like the culprit is the haskeline library. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
Dear Simon, No, there is not. Should every patch in Phab, have an associated ticket as well? Cheers, Moritz On Sep 15, 2014, at 2:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: Is there a Trac ticket too? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz | Angermann | Sent: 15 September 2014 10:19 | To: ghc-devs@haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Hi Janek, | | yea :) I think it went by unnoticed. Patch is already in Phab, | | https://phabricator.haskell.org/D208 | | Not sure how to speed up the review process, though ;-) | | Cheers, | Moritz | | On Sep 15, 2014, at 11:13 AM, Jan Stolarek jan.stola...@p.lodz.pl | wrote: | | I think it is best to fill in a bug report and attach a patch - I'm | afraid this mail may have gone | unnoticed :-) | | Janek | | Dnia piątek, 12 września 2014, Moritz Angermann napisał: | Hi, | | when trying to compile a ghc HEAD on LLVM ARM, I end up getting an | exception: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140911 for arm-apple-ios): | globalRegMaybe | | After some digging I found that a new call to globalRegMaybe was | introduced | here: | http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 | on | 2014-04-29 in commit: | | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 | 34 | 12b9877 | | In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs | was | changed: | | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd | 6a | 8308e..HEAD:/includes/CodeGen.Platform.hs | | introducing a set of new ifdef/elif/endif pairs. Especially for | MACHREGS_NO_REGS, namely: | | -#endif | globalRegMaybe _= Nothing | +#elif MACHREGS_NO_REGS | +globalRegMaybe _ = Nothing | +#else | +globalRegMaybe = panic globalRegMaybe not defined for this | platform | +#endif | | ARM.hs | | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 | 69 | ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: | | #define MACHREGS_NO_REGS 0 | #define MACHREGS_arm 1 | | where MACHREGS_arm 1 has no effect on the subsequently imported | CodeGen.Platform.hs. | | Therefore I propose that a change to ARM.hs is made to set | MACHREGS_NO_REGS to 1. | | Cheers, | Moritz | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
OK, so we discussed this a bit on IRC this morning, so I'm going to continue the discussion here for people to raise some inputs, particularly for #1: 1. I think this would be OK, but I'm rather neutral. Herbert is concerned I think about the proliferation of fields for our tickets, but I think this is reasonable. Would anyone else want this? It's easy to add, at least. 2. I don't think we actually came to a conclusion on whether this is doable. 3. No, there aren't tooltips I'm afraid. I'm afraid navigating the UI is a bit trial and error sometimes, but I'd like to know what problems you had. 4. I think this is a minor bug we can solve by just rescanning the repository information from ghc.git. 5. Long term, I think Phabricator has some goals to try and do this with its Charting/Facts application, but there isn't really anything today I'm afraid that would be easy. We could have Phabricator submit information to Joachim's ghcspeed instance, but I'm not sure if it's really designed to handle that kind of workflow. Maybe we should write a custom tool after all, but right now I think this is going to take some more thinking first. On Wed, Sep 10, 2014 at 6:32 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Herbert, Austin, all, I have some questions and suggestions regarding our infrastructure: 1. Would it be possible to add a new custom field to Trac called Wiki page? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. 2. I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only has links to previous ticket/next ticket in the top right of the page. So to get to the index of wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki index appears in the top right of the page. Would it be possible to have link to wiki index also in the ticket view? 3. Is it possible to enable tooltips in Phabricator? I'm not yet all that familiar with the interface and having icons that have no text and no tooltip is problematic. I need to actually click on it to see what it does (or figure it out from the link target). 4. When browsing the code in diffusion I see that my name is not linked to my phabricator account, for example here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/ Why is that happening? 5. I was thinking that perhaps harbormaster could also measure performance changes resulting from a patch, eg. by running nofib. I'm not sure if that's easy to implement or not and whether we have enough computing power to do that but I thought it's worth sharing that idea. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News (was: Status updates)
Hi *, Note the title change. After some discussion with Simon last week, we decided to change up the name a bit, since we want the discussion on - As Gabor mentioned on the list earlier, I accidentally broke the Windows build. I'm sorry. :( We really need to get Phab building Windows too ASAP... I'm working on a fix this morning. (There are still a lot of upstream changes waiting to go into the Phabricator code base.) - I sent out the HCAR draft this morning. Please edit it! I think we have a few weeks of lead time however, so we're not in a rush like last time. But I will remind you. :) - The server migration for ghc.haskell.org seems to have gone pretty smoothly in the past week. It's had plenty of traffic so far. The full migration is still ongoing and I want to complete it this week. - I've finished reorganizing some of the Git and Repository pages after some discussion. We now have the Repositories[1] page, linked to on the left side, which details some notes on the repositories we use, and links to other various pages. I'm thinking of replacing this side-bar root with a link to the main Git[2] page, perhaps. - Miscellaneous: ghc.haskell.org and phabricator.haskell.org now sets the Strict-Transport-Security header. This just means you always use SSL now when you visit those pages (so you can't be connection-hijacked via a 503 redirect). - I'm merging some patches at the moment, although the windows fix is currently what I'll push first: D205, D204, D203, D199, D194, D179, D174. Do let me know if there's anything you want me to look at. - GHC works on Wine apparently for all you Linux users - thanks Mikolaj![3] - Jan had some questions about infrastructure which I just followed up on this morning. In particular: does anyone feel strongly about his first question?[4] - Herbert committed the first part of the Traversable/Foldable changes, by moving the typeclasses to Prelude. This is part of an ongoing series of patches. Things like adding Bifunctor will finally come after this.[5] Also, added bonus: we'll start including some of the tickets we closed this week. Closed tickets for the past week include: #9585, #9545, #9581, #6086, #9558, and #3658. Please let me know if you have any questions. [1] https://ghc.haskell.org/trac/ghc/wiki/Repositories [2] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [3] https://www.haskell.org/pipermail/ghc-devs/2014-September/006283.html [4] https://www.haskell.org/pipermail/ghc-devs/2014-September/006275.html [5] https://phabricator.haskell.org/D209 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
On Sep 15, 2014, at 9:22 AM, Austin Seipp aus...@well-typed.com wrote: On Wed, Sep 10, 2014 at 6:32 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: 1. Would it be possible to add a new custom field to Trac called Wiki page? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. 1. I think this would be OK, but I'm rather neutral. Herbert is concerned I think about the proliferation of fields for our tickets, but I think this is reasonable. Would anyone else want this? It's easy to add, at least. +1 from me ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
Hi, Am Montag, den 15.09.2014, 08:22 -0500 schrieb Austin Seipp: 5. Long term, I think Phabricator has some goals to try and do this with its Charting/Facts application, but there isn't really anything today I'm afraid that would be easy. We could have Phabricator submit information to Joachim's ghcspeed instance, but I'm not sure if it's really designed to handle that kind of workflow. Maybe we should write a custom tool after all, but right now I think this is going to take some more thinking first. A Phab-integrated, better solution that what ghcspeed uses would be nice. Maybe a quick hack would be to link to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=004c5f4fec78414943d788c2a8b42a4500272949 from appropriate places. But it would only work for revisions that have reached master, and even then only after a little while. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
To Austin: 2. I don't think we actually came to a conclusion on whether this is doable. After some more thinking I believe that doing 1) will deal with about 90% of my uses cases for 2). However, we could add link to the wiki index in the sidebar - that certainly is doable. 3. No, there aren't tooltips I'm afraid. I'm afraid navigating the UI is a bit trial and error sometimes, but I'd like to know what problems you had. I had no larger issues, more like wondering what are two icons in the top toolbar next to Phabricator logo. Or what is the difference between the icon with my avatar and the icon with tools (top toolbar on the left). Both icons suggest some sort of profile settings, but it's hard to figure out the difference between the two without actually clicking on them. Of course these problems will disappear over time. To Joachim: Maybe a quick hack would be to link to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=004c5f4fec78414943d788c2a8b42a4500272949 from appropriate places. But it would only work for revisions that have reached master, and even then only after a little while. My intention is to have performance tests for patches under review. Since the whole idea of having Phab is to review and improve code before it makes into master it would make a lot of sense to see what performance impact the patches have *before* we merge them. A side note: I just noticed that The GHC Team link on GHC homepage points to non-existing wiki page (Contributors). GHC homepage says that it is maintained by Simon Marlow. Is this still true? Becuase I'm not sure where to complain about this :-) Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
I just noticed that The GHC Team link on GHC homepage points to non-existing wiki page (Contributors). For whoever can fix this: please redirect [wiki:Contributors] to [wiki:TeamGHC], since there are other links to the old Contributors page around as well. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
the historical c-- page still lives where norman moved it www.cs.tufts.edu/~nr/c--/index.html (and has all the content still) On Mon, Sep 15, 2014 at 8:05 AM, Simon Peyton Jones simo...@microsoft.com wrote: Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, won that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -Original Message- | From: Sergei Trofimovich [mailto:sly...@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit import statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
Alright! Ticket is here, for everyone interested: https://ghc.haskell.org/trac/ghc/ticket/9593 Cheers, Moritz On Sep 15, 2014, at 6:12 PM, Simon Peyton Jones simo...@microsoft.com wrote: We don't yet have a firm policy, but my instinct is that. If they have a ticket, a milestone, a priority, they are less likely to get lost. It's also easier for people to say on a ticket is the design right? than it is on Phab which is optimised for *code* review. Simon | -Original Message- | From: Moritz Angermann [mailto:mor...@lichtzwerge.de] | Sent: 15 September 2014 13:51 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Dear Simon, | | No, there is not. Should every patch in Phab, have an associated ticket | as well? | | Cheers, | Moritz | | On Sep 15, 2014, at 2:17 PM, Simon Peyton Jones simo...@microsoft.com | wrote: | | Is there a Trac ticket too? | | Simon | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Moritz | | Angermann | | Sent: 15 September 2014 10:19 | | To: ghc-devs@haskell.org | | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to | globalRegMaybe | | | | Hi Janek, | | | | yea :) I think it went by unnoticed. Patch is already in Phab, | | | | https://phabricator.haskell.org/D208 | | | | Not sure how to speed up the review process, though ;-) | | | | Cheers, | | Moritz | | | | On Sep 15, 2014, at 11:13 AM, Jan Stolarek jan.stola...@p.lodz.pl | | wrote: | | | | I think it is best to fill in a bug report and attach a patch - I'm | | afraid this mail may have gone | | unnoticed :-) | | | | Janek | | | | Dnia piątek, 12 września 2014, Moritz Angermann napisał: | | Hi, | | | | when trying to compile a ghc HEAD on LLVM ARM, I end up getting an | | exception: | | | | ghc-stage1: panic! (the 'impossible' happened) | | (GHC version 7.9.20140911 for arm-apple-ios): | | globalRegMaybe | | | | After some digging I found that a new call to globalRegMaybe was | | introduced | | here: | | | http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 | | on | | 2014-04-29 in commit: | | | | | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 | | 34 | | 12b9877 | | | | In a similar timeframe (since 2014-05-02) | /include/CodeGen.Platform.hs | | was | | changed: | | | | | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd | | 6a | | 8308e..HEAD:/includes/CodeGen.Platform.hs | | | | introducing a set of new ifdef/elif/endif pairs. Especially for | | MACHREGS_NO_REGS, namely: | | | | -#endif | | globalRegMaybe _= Nothing | | +#elif MACHREGS_NO_REGS | | +globalRegMaybe _ = Nothing | | +#else | | +globalRegMaybe = panic globalRegMaybe not defined for this | | platform | | +#endif | | | | ARM.hs | | | | | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 | | 69 | | ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: | | | | #define MACHREGS_NO_REGS 0 | | #define MACHREGS_arm 1 | | | | where MACHREGS_arm 1 has no effect on the subsequently imported | | CodeGen.Platform.hs. | | | | Therefore I propose that a change to ARM.hs is made to set | | MACHREGS_NO_REGS to 1. | | | | Cheers, | | Moritz | | ___ | | ghc-devs mailing list | | ghc-devs@haskell.org | | http://www.haskell.org/mailman/listinfo/ghc-devs | | | | | | | | ___ | | ghc-devs mailing list | | ghc-devs@haskell.org | | http://www.haskell.org/mailman/listinfo/ghc-devs — Moritz Angermann +49 170 54 33 0 74 mor...@lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. München Amtsgericht München HRB 207882 Geschäftsführung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ ghc-devs mailing list ghc-devs@haskell.org
STM and GC write barrier
Hi All, I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Ryan [1]: https://github.com/ghc/ghc/commit/6d784c43592290ec16db8b7f0f2a012dff3ed497 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random infrastructure requests, questions and suggestions
For whoever can fix this: please redirect [wiki:Contributors] to [wiki:TeamGHC], since there are other links to the old Contributors page around as well. Fixed. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Compiling on Windows
Hi, At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I did so in the past about 5 years ago, and it was a painful experience. To help improve the path for those who come after me, I kept a log (which I'll share after I get a working build). My current state is that I get an error while running make while building stage2: inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O-this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Any idea how to overcome that? I note from the weekly update email that there was an email on Windows last night, but a ./sync-all pull doesn't make it go away. Thanks, Neil ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Compiling on Windows
Austin Seipp has taken responsibility for this failure (it's AMP related); he's working on a fix. Edward Excerpts from Neil Mitchell's message of 2014-09-15 16:13:23 -0400: Hi, At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I did so in the past about 5 years ago, and it was a painful experience. To help improve the path for those who come after me, I kept a log (which I'll share after I get a working build). My current state is that I get an error while running make while building stage2: inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O-this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Any idea how to overcome that? I note from the weekly update email that there was an email on Windows last night, but a ./sync-all pull doesn't make it go away. Thanks, Neil ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Building ghc on Windows with msys2
Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email http://www.haskell.org/pipermail/ghc-devs/2014-September/006251.html in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Shake based build system for GHC
Hello SPJ (cc Neil Mitchell), on IRC it was brought up that there will be someone at GHC headquarters working on a Shake based build system. Can you tell us a little bit more about these plans. I wanted to try implementing this as well, but am happy to work on something else. Kind regards, Thomas Miedema ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
in ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it
In ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it. ghc-pkg check shows I have no issues, e.g.: bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ ghc-pkg check bash-3.2$ Other packages that have this problem include alex, and an example of a package that doesn't have this problem is vector. Should I file a bug? bash-3.2$ ghc --info [(Project name,The Glorious Glasgow Haskell Compilation System) ,(GCC extra via C opts, -fwrapv) ,(C compiler command,/usr/bin/gcc) ,(C compiler flags, -m64 -fno-stack-protector) ,(C compiler link flags, -m64) ,(Haskell CPP command,/usr/bin/gcc) ,(Haskell CPP flags,-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs) ,(ld command,/usr/bin/ld) ,(ld flags, -arch x86_64) ,(ld supports compact unwind,YES) ,(ld supports build-id,NO) ,(ld supports filelist,YES) ,(ld is GNU ld,NO) ,(ar command,/usr/bin/ar) ,(ar flags,clqs) ,(ar supports at file,NO) ,(touch command,touch) ,(dllwrap command,/bin/false) ,(windres command,/bin/false) ,(libtool command,libtool) ,(perl command,/usr/bin/perl) ,(target os,OSDarwin) ,(target arch,ArchX86_64) ,(target word size,8) ,(target has GNU nonexec stack,False) ,(target has .ident directive,True) ,(target has subsections via symbols,True) ,(Unregisterised,NO) ,(LLVM llc command,llc) ,(LLVM opt command,opt) ,(Project version,7.8.3) ,(Booter version,7.6.3) ,(Stage,2) ,(Build platform,x86_64-apple-darwin) ,(Host platform,x86_64-apple-darwin) ,(Target platform,x86_64-apple-darwin) ,(Have interpreter,YES) ,(Object splitting supported,YES) ,(Have native code generator,YES) ,(Support SMP,YES) ,(Tables next to code,YES) ,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn) ,(Support dynamic-too,YES) ,(Support parallel --make,YES) ,(Dynamic by default,NO) ,(GHC Dynamic,YES) ,(Leading underscore,YES) ,(Debug on,False) ,(LibDir,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3) ,(Global Package DB,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d) ] bash-3.2$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d: Cabal-1.18.1.4 GLURaw-1.4.0.1 GLUT-2.5.1.1 HTTP-4000.2.10 HUnit-1.2.5.2 OpenGL-2.9.2.0 OpenGLRaw-1.5.0.0 QuickCheck-2.6 array-0.5.0.0 async-2.0.1.5 attoparsec-0.10.4.0 base-4.7.0.1 bin-package-db-0.0.0.0 binary-0.7.1.0 rts-1.0 bytestring-0.10.4.0 case-insensitive-1.1.0.3 containers-0.5.5.1 deepseq-1.3.0.2 directory-1.2.1.0 fgl-5.5.0.1 filepath-1.3.0.2 (ghc-7.8.3) ghc-prim-0.3.1.0 hashable-1.2.2.0 haskeline-0.7.1.2 haskell-src-1.0.1.6 (haskell2010-1.1.2.0) (haskell98-2.0.0.3) hoopl-3.10.0.1 hpc-0.6.0.1 hscolour-1.20.3 html-1.0.1.2 integer-gmp-0.5.1.0 mtl-2.1.3.1 network-2.4.2.3 old-locale-1.0.0.6 old-time-1.1.0.2 parallel-3.2.0.4 parsec-3.1.5 pretty-1.1.1.1 primitive-0.5.2.1 process-1.2.0.0 random-1.0.1.1 regex-base-0.93.2 regex-compat-0.95.1 regex-posix-0.95.2 split-0.2.2 stm-2.4.2 syb-0.4.1 template-haskell-2.9.0.0 terminfo-0.4.0.0 text-1.1.0.0 time-1.4.2 transformers-0.3.0.0 unix-2.7.0.1 unordered-containers-0.2.4.0 vector-0.10.9.1 xhtml-3000.2.1 zlib-0.5.4.1 /Users/gcolpitts/.ghc/x86_64-darwin-7.8.3/package.conf.d: Cabal-1.20.0.2 MonadRandom-0.3 aeson-0.6.2.1 auto-update-0.1.1.2 bifunctors-4.1.1.1 blaze-builder-0.3.3.3 cmdargs-0.10.9 comonad-4.2.2 conduit-1.2.0.2 contravariant-1.2 cpphs-1.18.5 data-ordlist-0.4.6.1 distributive-0.4.4 djinn-ghc-0.0.2.2 djinn-lib-0.0.1.2 dlist-0.7.1 either-4.3.1 exceptions-0.6.1 free-4.9 ghc-mod-5.0.1.2 ghc-paths-0.1.0.9 ghc-syb-utils-0.2.2 haskell-src-exts-1.15.0.1 hasktags-0.69.0 hlint-1.9.4 hoogle-4.2.34 http-date-0.0.4 http-types-0.8.5 io-choice-0.0.5 json-0.7 lifted-base-0.2.3.0 mmorph-1.0.4 monad-control-0.3.3.0 monad-journal-0.2.3.2 mwc-random-0.13.2.0 nats-0.2 polyparse-1.9 prelude-extras-0.4 profunctors-4.2.0.1 resourcet-1.1.2.3 safe-0.3.8 scientific-0.3.3.1 semigroupoids-4.2 semigroups-0.15.3 shake-0.13.2 simple-sendfile-0.2.17
Re: Shake based build system for GHC
Hello Simon, Andrey Mokhov http://www.ncl.ac.uk/eee/staff/profile/andrey.mokhov, from the University of Newcastle, will be visiting MSR during his sabbatical, starting around 1 Oct. I’ve suggested to him that working on a Shake-based build system for GHC would be a good project: useful to us, and interesting to him. Neil is happy to act as adviser, as is Simon Marlow who wrote the current build system. Great. I’m sure Andrey would be very happy to work with others on this, if you have time and expertise to contribute. Would you be interested? I have plenty of time, and no expertise, so that is a yes :) Kind regards, Thomas Miedema ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Cleaning up rather silly static arguments
Aside from anything having to do with the foldrW/buildW stuff, I decided to
try a little experiment using fusing scanl and reverse (implementations at
http://lpaste.net/2416758997739634688 )
When I define
scanr f b = reverse . scanl (flip f) b . reverse
I get this:
scanr1
scanr1 = \ @ a_akP _ eta_Xb - eta_Xb
scanr
scanr =
\ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -
letrec {
go_amb
go_amb =
\ ds_amc eta1_Xa eta2_B2 eta3_Xc -
case ds_amc of _ {
[] - eta1_Xa eta2_B2 eta3_Xc;
: y_amh ys_ami -
go_amb
ys_ami
(\ x_an9 eta4_Xj -
let {
b'_ana
b'_ana = f_ah8 y_amh x_an9 } in
eta1_Xa b'_ana (: b'_ana eta4_Xj))
eta2_B2
eta3_Xc
}; } in
go_amb eta_B1 (scanr1) b_ah9 (: b_ah9 ([]))
go_amb takes four arguments, two of which, eta2_B2 and eta3_Xc, are static.
What makes this seem particularly silly is that we already have all the
structure we need to get rid of them—all that remains is to actually delete
them and replace them with the values they take:
scanr1
scanr1 = \ @ a_akP _ eta_Xb - eta_Xb
scanr
scanr =
\ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -
let {
listend
listend = : b_ah9 ([])} in
letrec {
go_amb
go_amb =
\ ds_amc eta1_Xa -
case ds_amc of _ {
[] - eta1_Xa b_ah9 listend;
: y_amh ys_ami -
go_amb
ys_ami
(\ x_an9 eta4_Xj -
let {
b'_ana
b'_ana = f_ah8 y_amh x_an9 } in
eta1_Xa b'_ana (: b'_ana eta4_Xj))
}; } in
go_amb eta_B1 (scanr1)
Now I certainly wouldn't claim this is particularly *good* code, but it
seems significantly more reasonable than before.
If I were to try to find a way to get rid of these things, should I try
hacking on the static argument transformation, or would it fit better in
the simplifier, or somewhere else?
David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
