- ghc-devs - Haskell.org

Where can I stick a dead code elimination rule for quotRemInt#?
by David Feuer 19 Sep '14

19 Sep '14

As I describe in #9617, GHC's CSE in 7.9 seems to be good enough to let Int and Integer use quot x y = fst (x `quotRem` y) rem x y = snd (x `quotRem` y) And actually get good results in code that uses both the quotient and the remainder. I believe the only thing left to be able to actually implement this is a simple rule to turn a match on quotRemInt# into one on quotInt# or remInt# if only the quotient or only the remainder is used. My question is where I could stick such a rule. Can anyone advise me? All I know is that it has to happen after CSE.

1 0

RE: Volatile T4801 test
by Simon Peyton Jones 19 Sep '14

19 Sep '14

Agreed. Let's remove the max_bytes_used threshold from the test. Simn | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 19 September 2014 16:02 | To: Simon Peyton Jones; Austin Seipp | Subject: Volatile T4801 test | | Hello! | | If you look at | | https://phabricator.haskell.org/diffusion/GHC/history/ | | the four of the recent commits failed mostly due to the volatilness of | T4801; I've seen it fail myself in Phab code-revisions as well... | | What shall we do about T4801, it seems to create unnecessary noise, as | any build-failure raises alarm flags for no good reason (imho)... | | Cheers, | hvr

1 0

Re: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44)
by Gabor Greif 19 Sep '14

19 Sep '14

Dear devs, I must admit I screwed this up again, I wanted to push on my branch git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative but muscle memory betrayed me and I pushed like this: git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master Sorry for the messup. How can I repair this? I did not intend to "merge" my work yet. It is not totally wrong though. It has three failures, but they are okay. I have a commit in my tree for that, but my firewall won't let them out (they are more than a kilobyte :-( The changes should be reviewed on the branch, and some changes are still expected. Second thought, how could this happen? Was this just a fast-forward of "master" ? Git seems to be a dangerous tool. Cheers and all help welcome, (also review comments regarding this WIP), remorsefully, Gabor On 9/19/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > Branch 'master' now includes: > > e12a6a8 Propositional equality for Datatype meta-information > 0a8e6fc Make constructor metadata parametrized (with intended parameter > <- datatype) > f097b77 Implement sameConstructor > cc618e6 get roles right and fix a FIXME > 79c7125 Actually parametrize the Constructor with the Datatype > 7bd4bab Supply a reasonable name (should be derived from d_name tho) > 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) > 4d90e44 Add default case (fixes -Werror) > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 4

Problems with updating Phab revision using arcanist
by Jan Stolarek 19 Sep '14

19 Sep '14

Hi all, I have a question to Phab gurus about using arcanist. I created a git branch, hacked a bit and then submitted a review using `arc diff`. Then I make a few more commits and want to update my revision. Running `arc diff` opens up an editor where I can create a new revision. Obviously, that's not what I want so I follow the suggestion from the comment in the editor to use `--update`: # arc diff --update D202 Exception Can't parse an empty diff! (Run with --trace for a full exception trace.) That's not what I want either. I'm left with manually specifying the base commit: arc diff 1719c42 and that works. But that's not really convenient. Any ideas why neither `arc diff` nor `arc diff --update <rev>` don't work (I believe they should)? Janek

1 0

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