September 2014 - ghc-devs

Should we occasionally merge haddock master into ghc-head?
by Edward Z. Yang 19 Sep '14

19 Sep '14

Hello Mateusz and all, With ghc-head and master being developed concurrently, I am wondering if GHC developers should be allowed to occasionally merge in changes from master. Seems like a good service which would help Mateusz out a bit when it comes time to update master for the next version GHC. Or is there some reason we shouldn't do this? Cheers, Edward

2 2

RE: D202: Injective type families
by Simon Peyton Jones 18 Sep '14

18 Sep '14

Dear GHC devs I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? If Phabs were branches in the GHC repo I could say Git checkout phab/D202 That would be cool. I know how to do that. But I don't think they are. So what do I do? Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 18 September 2014 09:35 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | I made two important adjustments: | | - first of all I removed the `result` from the parser and lexer. | Instead of `result` I'm planning to use type variable introduced by | the user for the result (as described in [[ | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 | | Proposal 7 ]] on the wiki. | | - following Richard's suggestion I changed `InjectivityInfo` to | contain `[Located name]` instead of `[LHsType name]`. But I keep | getting "Not in scope" errors. When I try to compile: | ``` | type family F a :: r | r -> a where | F a = a | ``` | I get errors that `r` and `a` are not in scope. According to my | tracing line 1149 of RnSource.lhs is responsible for this. I looked at | other code in this module and it seems to me that `bindHsTyVars` | should bring these variables into scope when renaming `r -> a`. I have | no idea why this does not happen. Simon, help? | | Also, build error reported by Harbormaster is nonsense. | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, simonpj, austin | Cc: goldfire, simonmar, ezyang, carter

2 1

Equality check for types that respects type families? (#9582)
by Andreas Abel 18 Sep '14

18 Sep '14

Looking at bug #9582 Associated Type Synonyms do not unfold in InstanceSigs https://ghc.haskell.org/trac/ghc/ticket/9582 I found that the given type in an instance signature is compared to the expected type using Type.eqType, which does not seem to know about type families. https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs -- Check that any type signatures have exactly the right type check_inst_sig hs_ty@(L loc _) = setSrcSpan loc $ do { sig_ty <- tcHsSigType (FunSigCtxt sel_name) hs_ty ; inst_sigs <- xoptM Opt_InstanceSigs ; if inst_sigs then unless (sig_ty `eqType` local_meth_ty) (badInstSigErr sel_name local_meth_ty) ... https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs eqType :: Type -> Type -> Bool -- ^ Type equality on source types. Does not look through @newtypes@ or -- 'PredType's, but it does look through type synonyms. -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] Question: Is there a (monadic) function for checking type equality which knows about the current type family rules in scope and honors them? Maybe the better question is where to find it, since there should be such a beast (used in the type checker somewhere to compare expected with inferred types). Cheers, Andreas (new to the GHC source code) -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

1 1

Re: Remove special casing of singleton strings, split all strings, Re: Implement `decodeDouble_Int64#` primop
by Joachim Breitner 17 Sep '14

17 Sep '14

Hi, Am Dienstag, den 16.09.2014, 12:59 +0000 schrieb git(a)git.haskell.org: > commit fe9f7e40844802443315ef2238c4cdefda756b62 > Author: Thijs Alkemade <thijsalkemade(a)gmail.com> > Date: Tue Sep 16 07:55:34 2014 -0500 > > Remove special casing of singleton strings, split all strings. > > Summary: > exprIsConApp_maybe now detects string literals and correctly > splits them. This means case-statemnts on string literals can > now push the literal into the cases. if you are curious: This improves the runtime of the binary-trees nofib benchmark by 6% and reduces the size of the parstof nofib benchmark by 4.6%, although on average, binary sizes are increased by a very small amount (0.12%). There is a notable increase in allocations in bspt, cacheprof and gg (>3%). Details: http://ghcspeed-nomeata.rhcloud.com/changes/?rev=fe9f7e4084&exe=2&env=1 Am Mittwoch, den 17.09.2014, 15:58 +0000 schrieb git(a)git.haskell.org: > commit b62bd5ecf3be421778e4835010b6b334e95c5a56 > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Wed Sep 17 17:54:20 2014 +0200 > > Implement `decodeDouble_Int64#` primop > > The existing `decodeDouble_2Int#` primop is rather inconvenient to use > (and in fact is not even used by `integer-gmp`) as the mantissa is split > into 3 components which would actually fit in an `Int64#` value. > > However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2` > re-implementation (see #9281). > > Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the > IEEE representation which can be replaced by a combination of the > portable standard C99 `scalbn(3)` and `frexp(3)` functions. This commit undoes the improvement of binary-trees’s runtime (4.6% regression), but no other notable changes. Again, I leave it to the respective commiters to decide if any of this is worth investigating. See http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2… for the history of that particular benchmark. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata(a)joachim-breitner.de

1 0

Cleaning up rather silly static arguments
by David Feuer 16 Sep '14

16 Sep '14

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

2 1

Building on Windows
by Neil Mitchell 16 Sep '14

16 Sep '14

Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google "build ghc on windows", which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows "The instructions are current for GHC 7.6" - so they are not current. "Other documentation for Windows includes:" - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said "MSYS2" works well, so I clicked that one. Even though it appears to be the "wrong" one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. "It should get you running in ~5 minutes, modulo download speeds." - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. "Do not install python, python2 or gcc!" - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better "check" step, e.g. run "gcc --version", "ghc --version" and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the && commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x250000) != child(0x7C0000) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran "autorebase.bat" from msys32, and restarted my shell, then it worked - I have no idea which fixed it. "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 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)) I fixed that by applying the patch from https://ghc.haskell.org/trac/ghc/ticket/9598. With that, I could build to completion. An empty build (nothing to do) takes 1m50s which is a bit sad, but it does work. After all this there are exactly two things I want to know (both of which would be useful links from the bottom of the building on Windows page): * How do I update to the next day, resync and rebuild. In particular, should i sync-all or not (a link to another page is fine) * How do I run the tests.

1 0

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