- ghc-devs - Haskell.org

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

FW: Shaking up GHC
by Simon Peyton Jones 12 Jan '16

12 Jan '16

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 From: Andrey Mokhov [mailto:andrey.mokhov@newcastle.ac.uk] Sent: 12 January 2016 14:49 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Neil Mitchell <ndmitchell(a)gmail.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: RE: Shaking up GHC Hi Simon, Happy New Year! Indeed, as soon as my teaching was over I jumped on the project with double energy, and then several people joined as collaborators, so we are in a very good shape right now. I'm happy with the progress. We can already build GHC on Windows/Linux/OSX from scratch without relying on the old build system, but with some limitations (only vanilla way, no validation, command line flags not supported). Feel free to try! We are getting close to the first milestone `first-shake`: https://github.com/snowleopard/shaking-up-ghc/milestones. It should be ready in a week, and I think it would be a perfect timing to announce it on GHC devs mailing list. The only problem: I still can't post to the GHC devs mailing list. I tried several times, sent several requests to ghc-devs-owner(a)haskell.org<mailto:ghc-devs-owner@haskell.org> to whitelist my email, but no luck so far. Would you be the owner by any chance? Please let me in! :-) As soon as `first-shake` is released I'll start writing the ICFP paper. Thanks for pushing and willing to be a co-author! Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 12 January 2016 11:02 To: Andrey Mokhov Cc: Neil Mitchell; Simon Peyton Jones Subject: Shaking up GHC Andrey I’ve seen a few issue messages from #147 https://github.com/snowleopard/shaking-up-ghc (it says “you are receiving notifications because you were mentioned”). And I saw Neil yesterday. So it looks as though you are tremendously active and, better still, have several other collaborators. That’s fantastic! Would you like to send an update message to the GHC devs mailing list, to keep us all up to date? • what you are doing • who is involved • what help (if any) you want; e.g. alpha-testers • what you plan Finally, what about a paper for ICFP or, if rejected, the Haskell Symposium. I really want to get this written up, and ICFP is a useful forcing function. But you’d need to start writing now! I’d be a willing co-author. Happy new year! Simon

2 1

Pattern match checking
by Simon Peyton Jones 12 Jan '16

12 Jan '16

George I believe that your #1 priority on the GHC pattern matching front is to make it so that the pattern checker will give up if it examines more than 1,000 (or whatever, there should be a settable limit) cases in the pruner. This should cure all the performance problems at once, at the cost of giving up on the exhaustiveness check for that function. This is a small, local, single change; should not take long. When do you think you’ll be done with that? I am (very) ambitious to do a better job, and we discussed various approaches. But the First Thing is to stop GHC consuming infinite time. Thanks! Simon

1 0