- ghc-devs - Haskell.org

Shake based build system for GHC
by Thomas Miedema 15 Sep '14

15 Sep '14

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

2 2

in ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it
by George Colpitts 15 Sep '14

15 Sep '14

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 streaming-commons-0.1.4.2 strict-0.3.2 stylish-haskell-0.5.10.2 tagged-0.7.2 tagsoup-0.13.2 text-1.2.0.0 transformers-base-0.4.3 transformers-compat-0.3.3.4 uniplate-1.6.12 unix-compat-0.4.1.3 unordered-containers-0.2.5.0 utf8-string-0.3.8 vault-0.3.0.3 vector-0.10.11.0 vector-algorithms-0.6.0.3 void-0.6.1 wai-3.0.1.1 warp-3.0.1.1 yaml-0.8.9.1 bash-3.2$

1 0

Compiling on Windows
by Neil Mitchell 15 Sep '14

15 Sep '14

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

2 1

Random infrastructure requests, questions and suggestions
by Jan Stolarek 15 Sep '14

15 Sep '14

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

5 6

Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
by Moritz Angermann 15 Sep '14

15 Sep '14

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… In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a… 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/23892440032fcab8a6a753916d506857674169e…) 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

3 6

Preliminary proposal: Monoidal categories in base and proc notation support
by Sophie Taylor 15 Sep '14

15 Sep '14

>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.

3 4

Re: Preliminary proposal: Monoidal categories in base and proc notation support
by Edward Kmett 15 Sep '14

15 Sep '14

The current categories package tries to let you reuse bifunctors of the form c * d -> e across base categories, so that e.g. Kleisli m can use (,) for its product, etc. (in general it isn't a real product for Kleisli m, but let's pretend) this means we have to adopt a 3 for 2 policy wrt the categories involved. c e -> d, c d -> e, d e -> c, but when inferring from first or second you usually only know one, but also only need one other, but can't know the third from context, since no arrow is supplied. It is underdetermined. Hask avoids this by presupposing a single set of categories for every Bifunctor, but it is a conceit of the package that this is enough in practice, not something I know, and we pay a measurable price for this. A lot of stuff is more complex there! The current hask design, as opposed to the one I gave a talk on and the design of categories loses a lot of what powers lens and the like in exchange for this simpler story. I don't make that change lightly and I'd hesitate to make that change across the entire ecosystem. It hasn't proved it is worth the burden yet. In exchange for this complexity it is able to find simplicity elsewhere, e.g. Bifunctor in hask is a derived concept from a Functor to a Functor category, which models the curried nature of the arguments to a Bifunctor. My main point is there are a lot of points in the design space, and I don't think we're equipped to find a clear winner right now. Sent from my iPad > On Sep 15, 2014, at 3:53 PM, Sophie Taylor <sophie(a)traumapony.org> wrote: > > Oh darn, really? That is so disappointing. Why can't it maintain inference? :\ > >> On 15 September 2014 23:44, Edward Kmett <ekmett(a)gmail.com> wrote: >> I find PFunctor/QFunctor finer grained than is tasteful. Alas, they are necessary for inference for first/second in practice unless you require the Bifunctor to determine the category of both of its arguments. The hask package is exploring other ways to maintain inference. >> >> If you try to actually use the current categories package without them, well, nothing infers. >> >> Sent from my iPad >> >>> On Sep 15, 2014, at 11:32 AM, Sophie Taylor <sophie(a)traumapony.org> wrote: >>> >>> >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(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

GHC Weekly News (was: Status updates)
by Austin Seipp 15 Sep '14

15 Sep '14

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/

1 0

The build is broken on {32,64}-bit Windows
by Páli Gábor János 15 Sep '14

15 Sep '14

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

2 1

It's that time again (for the HCAR)
by Austin Seipp 15 Sep '14

15 Sep '14

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/

1 0