- ghc-devs - Haskell.org

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

Trac internal error
by Edward Z. Yang 18 Jan '16

18 Jan '16

When I posted the (attached) POST request to newticket, I got the following error. It did correctly add the ticket to the database. I've elided the form token from this. Trac detected an internal error: AttributeError: 'NoneType' object has no attribute 'split' Here's the contents of the POST request (my guess is that I put something bad in the CC field): field_summary=Turn+on+SplitSections+by+default field_reporter=ezyang field_description=This+is+a+general+tracking+bug+for+what+is+blocking+us+from+turning+on+`SplitSections`+by+default,+implemented+in+#8405.+Fixing+this,+and+mandating+use+of+the+gold+linker,+will+help+solve+#11285+(split+objects+make+linking+slow),+and+will+make+ghc-split+unnecessary,+mooting+#9832. I+encountered+some+misinformation+while+talking+to+people+about+this+featur… So,+can+we+turn+on+this+feature+by+default?+Does+it+subsume+split-objs?+Does+it+work+on+all+the+tier-1+platforms?+It+would+be+nice+if+bgamari,+olsner+and+co+could+weigh+in+here.+Thanks! field_type=task field_priority=normal field_milestone=8.2.1 field_component=Build+System field_version=8.0.1-rc1 field_keywords field_cc=bgamari,+olsner field_os=Unknown/Multiple field_architecture=Unknown/Multiple field_failure=None/Unknown field_testcase field_blockedby field_blocking=#11285 field_related field_differential field_wikipage field_owner=<+default+> sfp_email sfph_mail submit=Create+ticket

1 0

Re: issues on Glasgow Haskell Compiler 8.0.1, release candidate 1
by George Colpitts 16 Jan '16

16 Jan '16

Hi Ben Yes this fixes the issue I found on the Mac. Although it seems there is a minor problem that I encountered: sudo make install ... /usr/bin/install -c -m 644 docs/users_guide/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 bash-3.2$ rm /usr/local/share/man/man1/ghc.1 Also, again minor, with either source or binary distribution I am seeing the following warnings: Warning: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/pkgConf-data-ordlist-0.4.78235644401115438165.0: Unrecognized field abi on line 15 when doing cabal installs, e.g. cabal install data-ordlist I believe somebody else asked, do we intend to distribute llvm with 8.0.1. If so I will wait for the next release candidate to test llvm otherwise I will install llvm 3.7 and test llvm Thanks George On Fri, Jan 15, 2016 at 11:11 AM, Ben Gamari <ben(a)well-typed.com> wrote: > George Colpitts <george.colpitts(a)gmail.com> writes: > > > installs fine on mac but cabal install vector fails on primitive, looks > to > > me like gmp library is not provided > > > I have built a new OS X binary [1] which should be linked against the > in-tree libgmp, fixing this issue (which we've been tracking as Trac > #11423). > > I have also pushed a 32-bit Windows build. > > Perhaps those affected by this issue could try this distribution? > > Cheers, > > - Ben > > > [1] > http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-appl… > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

2 1

Explanation of a core-lint warning (Bad getNth)
by Jan Bracker 16 Jan '16

16 Jan '16

Hi, I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv <Reader>_N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <Unit Reader>_N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? Thank you! Jan [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26… [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26… [3] https://github.com/jbracker/polymonad-plugin

4 12

Warnings, -Wall, and versioning policy
by Simon Marlow 13 Jan '16

13 Jan '16

Hi folks, We haven't described what guarantees GHC provides with respect to -Wall behaviour across versions, and as a result there are some differing expectations around this. It came up in this weeks' GHC meeting, so we thought it would be a good idea to state the policy explicitly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in the User's Guide for future releases) There are no other guarantees. In particular: - In a new major release, GHC may introduce new warnings into -Wall, and/or change the meaning of existing warnings such that they trigger (or not) under different conditions. - GHC may generate different warnings on different platforms. (examples of this are -fwarn-overflowed-literals and -fwarn-unsupported-calling-conventions) Some rationale: - We consider any change to the language that GHC accepts to be a potentially code-breaking change, and subject to careful scrutiny. To extend this to warnings would be a *lot* of work, and would make it really difficult to introduce new warnings and improve the existing ones. - Warnings can be based on analyses that can change in accuracy over time. The -fwarn-unused-imports warning has changed a lot in what it rejects, for example. - We often introduce new warnings that naturally belong in -Wall. If -Wall was required to be a fixed point, we would have to start introducing new flags, and versioning, etc. and even keep the old implementation of warnings when they change. It would get really messy. There are some consequences to this. -Wall -Werror is useful for keeping your code warning-clean when developing, but shipping code with these options turned on in the build system is asking for trouble when building your code with different GHC versions and platforms. Keep those options for development only. Hackage already rejects packages that include -Wall for this reason. One reason we're raising this now is that it causes problems for the 3-release policy (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which requires that it be possible to write code that is Wall-clean with 3 major releases of GHC. GHC itself doesn't guarantee this, so it might be hard for the core libraries committee to provide this guarantee. I suggest this requirement be dropped from the policy. Cheers, Simon

3 4

Reify and separating renamer+TH from type-checking
by Edward Z. Yang 13 Jan '16

13 Jan '16

I implemented the refactoring to run the renamer and TH splices all first before doing any type-checking, but actually there's a problem: Template Haskell splices can call 'reify', which needs the type information in order to supply the information about the identifiers in question. I can't think of any good way around this problem. Edward

5 4

Re: FW: Shaking up GHC
by Andrey Mokhov 13 Jan '16

13 Jan '16

Many thanks Eric, I think you solved the mystery! I changed my address on the ghc-devs mailing list from andrey.mokhov(a)ncl.ac.uk to andrey.mokhov(a)newcastle.ac.uk (it's the same mailbox really). Hopefully this will go through this time. Cheers, Andrey From: Eric Seidel <eric(a)seidel.io> To: ghc-devs(a)haskell.org Subject: Re: FW: Shaking up GHC I'm pretty sure you can only post to the list with the address you used to subscribe. According to https://mail.haskell.org/cgi-bin/mailman/roster/ghc-devs it looks like Andrey is subscribed with andrey.mokhov at ncl.ac.uk but the email you forwarded is from andrey.mokhov at newcastle.ac.uk So that may be the issue. Eric On Tue, Jan 12, 2016, at 08:20, Simon Peyton Jones wrote: > Dear ghc devs > Can someone figure out how to help Andrey be able to post to this mailing > list (ghc-devs)? I thought anyone subscribed can post, but perhaps not. > Thanks! > Simon >

1 0

Inlining of methods (dictionary accessors) in GHC 7.10?
by Conal Elliott 13 Jan '16

13 Jan '16

Did something about change with method inlining between GHC 7.8.2 and 7.10.3? I don't mean methods attached to instances, but rather the method name itself, which I understand is defined as simple field accessors into a dictionary. I do inlining indirectly via HERMIT, and the method names are no longer successfully inlining to the accessors. The dictionaries themselves inline fine, as do field accessors for algebraic types with named fields. -- Conal

3 4

Cabal status for GHC 8.0.1
by Ben Gamari 12 Jan '16

12 Jan '16

Hello everyone, As you likely know the GHC 8.0.1 release is quickly approaching. The release candidate should be out any moment now and we anticipate a final release in mid-February. Consequently, we should start thinking about how we will manage the Cabal release. Duncan has said that his nix-local-builds branch should be in good enough shape to be included as a technology preview with the GHC 8.0 release. Within what timeframe in particular do you think we'll be able to have a release tagged and (and ideally released)? Is late January possible? Cheers, - Ben

2 1