- ghc-devs - Haskell.org

Proposal: Longer Testing Cycle
by Harry . 20 Jan '16

20 Jan '16

"Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently announced, with a caveat that "This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon ... In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page." This leads me to wonder whether release management know what the words "release" and "candidate" mean! I would like to propose that the builds which are currently branded "release candidate" be rebranded as "beta", seeing as that is what they actually are. When the release manager has a build which s/he feels is ready for release, it should be published as a release candidate. If after a couple of weeks or so the same build is still considered suitable for release, it can be released as is, otherwise a new release candidate and testing period are required.

2 2

How to build profiled stage1?
by Ömer Sinan Ağacan 19 Jan '16

19 Jan '16

I'm trying to debug my stage1 compiler and as a last resort I'm trying to build stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS` during the stage2 build. I tried couple of things but they all failed in different ways. As far as I understand, both SRC_HC_OPTS and GhcStage1HcOpts are passed to system-wide installed ghc during the stage1 build and libraries. So I do one of these changes: SRC_HC_OPTS = -O -H64m -prof -fprof-auto GhcStage1HcOpts = -O0 -DDEBUG -prof -fprof-auto The second change I want to make is I want to pass `+RTS -xc -RTS` to ghc-stage1, for that I'm making this change: GhcLibHcOpts = -O -dcore-lint -prof -fprof-auto But, no matter what else I change, I can't get past this stage: "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-package-key ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0-960bf9ae8875cc30355e086f8853a049 -package-id base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d -package-id binary-0.8.0.0 -package-id bytestring-0.10.6.0-9a873bcf33d6ce2fd2698ce69e2c1c66 -package-id containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id ghc-boot-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.2.3.0-a22328103774f0499a990653944cbf99 -package-id template-haskell-2.11.0.0 -package-id time-1.5.0.1-1b9a502bb07a3e6f4d6935fbf9db7181 -package-id transformers-0.5.0.0 -package-id unix-2.7.1.0-bb54ee8f9f6b2600aae7a748eb88a610 -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing -O0 -DDEBUG -prof -fprof-auto -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Exception.hs -o compiler/stage1/build/Exception.o compiler/utils/Exception.hs:10:1: Failed to load interface for ‘Control.Monad.IO.Class’ Perhaps you haven't installed the profiling libraries for package ‘transformers-0.5.0.0’? Use -v to see a list of the files searched for. <<ghc: 24684488 bytes, 15 GCs, 1388900/2559496 avg/max bytes residency (2 samples), 46M in use, 0.000 INIT (0.001 elapsed), 0.003 MUT (0.005 elapsed), 0.015 GC (0.019 elapsed) :ghc>> I tried enabling library-profiling in my global Cabal config, but that didn't help. Any ideas how to do this? If it matters, I'm on Linux. NOTE: If I pass -v to GHC, it lists this place in the list of locations searched: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/build/Control/Monad/IO/Class.p_hi Indeed, the file is not there. When I look at all the command the build system run at this point, I see lines like this: "/usr/local/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/transformers/dist-boot/inplace-pkg-config Reading package info from "libraries/transformers/dist-boot/inplace-pkg-config" ... done. transformers-0.5.0.0: Warning: Unrecognized field abi on line 47 transformers-0.5.0.0: Warning: haddock-interfaces: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/doc/html/transformers/transformers.haddock doesn't exist or isn't a file transformers-0.5.0.0: cannot find any of ["Control/Applicative/Backwards.hi","Control/Applicative/Backwards.p_hi","Control/Applicative/Backwards.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Applicative/Lift.hi","Control/Applicative/Lift.p_hi","Control/Applicative/Lift.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Signatures.hi","Control/Monad/Signatures.p_hi","Control/Monad/Signatures.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Class.hi","Control/Monad/Trans/Class.p_hi","Control/Monad/Trans/Class.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Cont.hi","Control/Monad/Trans/Cont.p_hi","Control/Monad/Trans/Cont.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Except.hi","Control/Monad/Trans/Except.p_hi","Control/Monad/Trans/Except.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Error.hi","Control/Monad/Trans/Error.p_hi","Control/Monad/Trans/Error.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Identity.hi","Control/Monad/Trans/Identity.p_hi","Control/Monad/Trans/Identity.dyn_hi"] (ignoring) Then, after a while it's building transformers in a different way, using arguments like `-dep-makefile` etc. which are as far as I can see not documented in the GHC man page. When I look libraries/transformers I only see a directory named "dist-boot" with some weird files with ".haskell" extensions. I'm quite confused about how this is supposed to work. Can any of the build system experts help me here? This wiki page https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler#Addingdebuggingcod… says "if you have built a profiling compiler ..." but it doesn't say anything about how to actually build it. Thanks.

1 1

Fixing #11444 - OK-for-speculation check rejects valid program?
by Ömer Sinan Ağacan 19 Jan '16

19 Jan '16

I found one of the problems with #11444, but I don't know how to fix it. The problem is that the desugarer is generating this function: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Str=DmdType] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> == @ Int GHC.Classes.$fEqInt (case reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws of wild_00 { __DEFAULT -> GHC.Types.I# wild_00 }) (GHC.Types.I# 1#) } } Which is lint-safe. Then, the optimizer is transforming this into: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 71 0}] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws)) (I# 1#) } } The problem with this, according to the linter, is the argument of I# is not OK-for-speculation (the expression `reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws`). The reason is because arguments of `reallyUnsafePtrEquality#` are not OK-for-speculation, because their types are polymorphic, and variables with polymorphic types are not OK for speculation. However, I think this expression should be OK-for-speculation, because it can't fail, the primop is not out-of-line etc. I think all the requirements for being OK for speculation hold here. So my questions are: - Does that look like a correct optimization transformation? (it looked OK to me, but wanted to make sure) - Am I right that this expression should be OK for speculation? - What's a good way to make this code lint-safe? Thanks..

1 0

Birthday greetings
by Simon Peyton Jones 19 Jan '16

19 Jan '16

Dear GHC devs (all 600+ of you), It’s my birthday (well it was a few minutes ago, but I became distracted by #11379). I am 58. GHC is alive and well and, happily, so am I. However, of late I have found that my GHC inbox, which I used to be able to keep under control, just grows and grows. Mostly this is good; it reflects the fact that GHC has lots of users, that they vigorously expand up to (and often well beyond) the limits of what GHC can do, and that increasingly GHC a lot of developers contributing actively to its code base. But it has its downsides. I used to be able to keep up with the Trac and email traffic. Trusty techniques like “delete anything mentioning ‘dynamic linking’ or ‘Unicode’” would cut the traffic in half. But that doesn’t work any more. Too many interesting things are happening. So this email is to say three things: · First, thank you to the increasingly large number of you who are contributing actively to GHC’s development. GHC is a big system, and no one person can be on top of all of it. GHC no longer depends on one of two people: it depends on all of you. You know who you are – thank you. · Second, apologies to anyone who is stuck waiting for me. Although there are large chunks of GHC that I know little about, there are other parts that are dear to my heart: the renamer, typechecker, Core, optimisation, and so on. I write code most days and enjoy it. So I do want to continue to play a very active supporting and reviewing role, as well as authoring, in these parts. But I’m conscious that doing so puts me in a lot of critical paths. Here’s a suggestion: if you are blocked on something from me, email me directly. By all means copy ghc-devs if you want others in the conversation, but make it clear that you need my input. That’ll work better than putting up a Phab review, or a Trac comment, and hoping I’ll see it. I probably will, but it won’t stick out from other 20 Phab reviews that I would like to do. I don’t promise to turn everything around fast, but it’ll increase the chances! · Third, in a vain attempt to at least keep some kind of handle on the state of play, I keep an ill-organised page of tickets that I’m interested in<https://ghc.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets>. A cursory glance will confirm that there is zero chance that I will attend to them all. So please do pick up some of them and dig in. Not many are trivial; most require some investigation, some design work, some discussion of alternatives, etc. But most of them would benefit from love and attention. If you are looking for suggestions for things to do, that might be a good place to start. Thanks! Simon

6 5

Serialized module
by Simon Marlow 19 Jan '16

19 Jan '16

As part of the recent Remote GHCi changes, I moved the module Serialized from the ghc package to ghc-boot. This is because it is shared by the ghci package and ghc itself. The only way to arrange that it was available to both ghc in stage1 and the ghci package (which is not a dependency of the stage1 ghc), was to put it in ghc-boot. Unfortunately this introduces some breakage because some external code import Serialized. I just ran across hint which fails to compile. I can fix this by re-introducing a Serialized module that re-exports module GHC.Serialized. But is that the right thing to do? Serialized is also re-exported by GhcPlugins. Should we be asking people to import that instead? Cheers, Simon

1 0

Re: equality relations: user-facing pretty-printing question
by Ryan Scott 18 Jan '16

18 Jan '16

In my ideal world, GHC would remember as much as what the user wrote as possible in printing error messages. So if the user writes: f :: Int ~ Char => ... Then GHC would remember that the context was written with a single tilde, and print out Int ~ Char in the error message explicitly wherever the full type signature of f is printed. What it sounds like, though, is that deep in the guts of the type inferencer, there's a chance that single-tilde equality might turn into double-tilde or tilde-hash equality at some point. In those cases, printing out the particular brand of tilde might get confusing. In such cases, we might compromise and print out something neutral like "is equal to". I suppose this would always be the case if you didn't explicitly write a ~ b and had to infer it. I'm not sure about the technical details of this though, i.e., if GHC actually remembers a ~ b all the way through the typechecking/inferencing pipeline. Ryan S.

6 8

Phab failing to apply patches
by Jan Stolarek 18 Jan '16

18 Jan '16

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

4 11

equality relations: user-facing pretty-printing question
by Richard Eisenberg 18 Jan '16

18 Jan '16

Hi devs, I've recently made a design decision for GHC 8.0 that I may wish to revisit, and I'd love some feedback. GHC 7.x has but one user-visible type equality relation, ~. The constraint (ty1 ~ ty2) is well-kinded only when ty1 and ty2 have the same kinds. And the solver works in terms of this very same equality, so error messages simply talk about ~. GHC 8.0, on the other hand, has three equality relations that might potentially appear to users. It retains ~. But it also has ~~, which is heterogeneous type equality, meaning that (ty1 ~~ ty2) is well-kinded even when ty1 and ty2 have different kinds. And it has ~#, which is the unlifted equality used in the solver. It turns out that ~~ and ~ are just wrappers around ~#. Because of all of this, GHC sometimes ends up thinking about ~~ or ~# even when the user has said ~. (See the definition of ~ in Data.Type.Equality, for example.) And it naively would print ~# a bunch in error messages. So, I put a little pretty-printing magic in that prints ~, ~~, and ~# all as ~ in user-facing output, unless the user writes -fprint-equality-relations. This design decision has kept error messages pretty. But it will be awfully confusing when someone intentionally uses ~~ and sees ~ in their output. And there's nothing to suggest -fprint-equality-relations. These sorts "hide the scary plumbing!" decisions irk me to no end when I find them in my operating system. But now I've done the same thing in GHC... which is why I want to re-examine this. What do you think? Do you see a better way to handle this? Thanks! Richard

1 0

Multiple GHC sessions
by Alan & Kim Zimmerman 18 Jan '16

18 Jan '16

At the moment there are issues with having multiple GHC API sessions in a single executable, which boil down to GHC having global variables. A quick grep over the GHC sources shows the following instances compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... Of these the v_unsafeGlobalDynFlags can probably be ignored, as they are intended to be used in very specific, limited circumstances only. So, would it be possible to create a structure housing the remaining ones, and somehow make it possible to access these in some kind of session? Or preferably get rid of them, or move them into existing structures such as DynFlags. This is an exploratory email, more to get a handle on what has been done/considered already in this space. The issue does have a major impact on tooling developers though. Regards Alan

5 7

Plugin from ghci REPL?
by Conal Elliott 18 Jan '16

18 Jan '16

Is it possible to have GHC plugins get invoked from the ghci *REPL* (in addition to loaded source modules)? I'm doing some monomorphization-based transformation, and currently I write scads of trivial monomorphic specialization definitions like > sumt6 = sum :: Tree 6 Int -> Int I'd instead love to enter "let sumt6 = sum :: Tree 6 Int -> Int" or (better) just "sum :: Tree 6 Int -> Int" into the REPL and have my plugin run, without having to keep monkeying with a source file and reloading. As I understand it, an expression is turned into "let it = ...", so maybe the expression option would come for free with the ability to run plugins on in-REPL definitions. -- Conal

1 0