Fwd: [hackage-server] Duplicate anchors in source code (#319)
I reported a bug in HsColour ( https://github.com/haskell/hackage-server/issues/319#issuecomment-76088047) which has been fixed in a new version. The HSColour dev thought it might be useful to mention this new version of HsColour to the GHC devs so that documentation for 7.10 will be marginally easier to reference. -Eric ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Typeable
This is now on Phab as https://phabricator.haskell.org/D757 I'll be making some comments there. On Mar 26, 2015, at 9:23 AM, Richard Eisenberg wrote: > I'll take a look in the next few days. I'm concerned about that performance > regression -- we'll need to get a handle on it. > > Enjoy your holiday! > > Richard > > On Mar 26, 2015, at 8:48 AM, Simon Peyton Jones wrote: > >> Iavor, Richard, and others >> >> We always thought it was the Right Thing to generate the runtime >> representation for a TyCon (used in Typeable type representations) at the >> definition site of the type, not “on the fly”. I thought I’d do this. >> >> But it was a LOT harder than I expected. I have spent a ridiculous amount >> of time on it over the last three weeks. Sigh. >> >> However (a) it’s done, (b) I did a lot of other tidying up (as usual). So >> I’m keen to use it. >> >> Would you like to take a look? It’s on branch wip/T9858-typeable-spj. >> Relevant log messages below. >> >> Unsurprisingly, some perf/compiler tests get a bit slower (see below). >> >> More surprisingly, there are two perf/should_run tests that get worse >> >>perf/should_run T5205 [stat not good enough] (normal) >> >>perf/should_run lazy-bs-alloc [stat not good enough] (normal) >> >> This is much more surprising: neither seems to have anything much to do with >> Typeable. But I can’t investigate before I go on holiday. Would anyone else >> like to? >> >> It’s all up to date wrt HEAD. >> >> Simon >> >> >> >> commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 >> Author: Simon Peyton Jones >> Date: Thu Mar 26 11:06:12 2015 + >> >> Remove a redndant 'return' >> >> commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 >> Author: Simon Peyton Jones >> Date: Mon Mar 23 14:53:53 2015 + >> >> Error message wibbles >> >> These are associated with >> - new instance reporting >> - typeable changes in -ddump-simpl output >> - -ddump-types being a bit less verbose >> - some renaming of type variables in debugger output (no idea why this >> happens) >> >> commit fe510d911b6cf61d6884b8b42d8771d4aea3229f >> Author: Simon Peyton Jones >> Date: Mon Mar 23 14:50:23 2015 + >> >> Generate Typeble info at definition sites >> >> This patch implements the idea floated in #9858, namely that we should >> generate type-representation information at the data type declaration >> site, rather than when solving a Typeable constraint. >> >> However, this turned out quite a bit harder than I expected. I still >> think it's the right thing to do, and it's done now, but it was quite >> a struggle. >> >> See particularly >> * Note [Grand plan for Typeable] in TcTypeable (which is a new module) >> * Note [The overall promotion story] in DataCon (clarifies existing >> stuff) >> >> The most painful bit was that to generate Typeable instances (ie >> TyConRepName >> bindings) for every TyCon is tricky for types in ghc-prim etc: >> - we need to have enough data types around to *define* a TyCon >> - many of these types are wired-in >> >> Also, to minimise the code generated for each data type, I wanted to >> generate >> pure data, not CAFs with unpackCString# stuff floating about. >> >> Performance >> ~~~ >> Three perf/compiler tests start to allocate quite a bit more. This isn't >> surprising, >> because they all allocate zillions of data types, with practically no >> other code, >> esp T1969 >> >>T1969: GHC allocates 30% more >>T5642: GHC allocates 14% more >>T9872d: GHC allocates 5% more >> >> I'm treating this as acceptable. The payoff comes in Typeable-heavy >> code. >> >> Remaining to do >> ~~~ >> * I think that "TyCon" and "Module" are over-generic names to use for >> the runtime type representations used in GHC.Typeable. Better might >> be "TrTyCon" and "TrModule". But I have not yet done this >> >> * Add more info the the "TyCon" e.g. source location where it was defined >> >> * Use the new "Module" type to help with Trac #10068 >> >> * It would be possible to generate TyConRepName (ie Typeable instances) >> selectively rather than all the time. We'd need to persist the >> information >> in interface files. Lacking a motivating reason I have not done this, >> but >> it would not be difficult. >> >> Refactoring >> ~~~ >> As is so often the case, I ended up refactoring more than I intended. >> In particular >> >> * In TyCon, >> - a type *family* (whether type or data) >> is repesented by a FamilyTyCon >> - a algebraic data type (including data/newtype instances) >> is represented by AlgTyCon >> This wasn't true before; a data family was represen
Re: Typeable
I'll take a look in the next few days. I'm concerned about that performance regression -- we'll need to get a handle on it. Enjoy your holiday! Richard On Mar 26, 2015, at 8:48 AM, Simon Peyton Jones wrote: > Iavor, Richard, and others > > We always thought it was the Right Thing to generate the runtime > representation for a TyCon (used in Typeable type representations) at the > definition site of the type, not “on the fly”. I thought I’d do this. > > But it was a LOT harder than I expected. I have spent a ridiculous amount of > time on it over the last three weeks. Sigh. > > However (a) it’s done, (b) I did a lot of other tidying up (as usual). So > I’m keen to use it. > > Would you like to take a look? It’s on branch wip/T9858-typeable-spj. > Relevant log messages below. > > Unsurprisingly, some perf/compiler tests get a bit slower (see below). > > More surprisingly, there are two perf/should_run tests that get worse > >perf/should_run T5205 [stat not good enough] (normal) > >perf/should_run lazy-bs-alloc [stat not good enough] (normal) > > This is much more surprising: neither seems to have anything much to do with > Typeable. But I can’t investigate before I go on holiday. Would anyone else > like to? > > It’s all up to date wrt HEAD. > > Simon > > > > > > commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 > Author: Simon Peyton Jones > Date: Thu Mar 26 11:06:12 2015 + > > Remove a redndant 'return' > > commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 > Author: Simon Peyton Jones > Date: Mon Mar 23 14:53:53 2015 + > > Error message wibbles > > These are associated with > - new instance reporting > - typeable changes in -ddump-simpl output > - -ddump-types being a bit less verbose > - some renaming of type variables in debugger output (no idea why this > happens) > > commit fe510d911b6cf61d6884b8b42d8771d4aea3229f > Author: Simon Peyton Jones > Date: Mon Mar 23 14:50:23 2015 + > > Generate Typeble info at definition sites > > This patch implements the idea floated in #9858, namely that we should > generate type-representation information at the data type declaration > site, rather than when solving a Typeable constraint. > > However, this turned out quite a bit harder than I expected. I still > think it's the right thing to do, and it's done now, but it was quite > a struggle. > > See particularly > * Note [Grand plan for Typeable] in TcTypeable (which is a new module) > * Note [The overall promotion story] in DataCon (clarifies existing > stuff) > > The most painful bit was that to generate Typeable instances (ie > TyConRepName > bindings) for every TyCon is tricky for types in ghc-prim etc: > - we need to have enough data types around to *define* a TyCon > - many of these types are wired-in > > Also, to minimise the code generated for each data type, I wanted to > generate > pure data, not CAFs with unpackCString# stuff floating about. > > Performance > ~~~ > Three perf/compiler tests start to allocate quite a bit more. This isn't > surprising, > because they all allocate zillions of data types, with practically no > other code, > esp T1969 > >T1969: GHC allocates 30% more >T5642: GHC allocates 14% more >T9872d: GHC allocates 5% more > > I'm treating this as acceptable. The payoff comes in Typeable-heavy code. > > Remaining to do > ~~~ > * I think that "TyCon" and "Module" are over-generic names to use for > the runtime type representations used in GHC.Typeable. Better might > be "TrTyCon" and "TrModule". But I have not yet done this > > * Add more info the the "TyCon" e.g. source location where it was defined > > * Use the new "Module" type to help with Trac #10068 > > * It would be possible to generate TyConRepName (ie Typeable instances) > selectively rather than all the time. We'd need to persist the > information > in interface files. Lacking a motivating reason I have not done this, > but > it would not be difficult. > > Refactoring > ~~~ > As is so often the case, I ended up refactoring more than I intended. > In particular > > * In TyCon, > - a type *family* (whether type or data) > is repesented by a FamilyTyCon > - a algebraic data type (including data/newtype instances) > is represented by AlgTyCon > This wasn't true before; a data family was represented as > an AlgTyCon. There are some corresponding changes in IfaceSyn. > > Also get rid of the (unhelpfully named) tyConParent. > > * In TyCon define 'Promoted', isomorphic to Maybe, used when things > are optionally promoted; and use it elsewhere in GHC. >
Typeable
Iavor, Richard, and others We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not "on the fly". I thought I'd do this. But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh. However (a) it's done, (b) I did a lot of other tidying up (as usual). So I'm keen to use it. Would you like to take a look? It's on branch wip/T9858-typeable-spj. Relevant log messages below. Unsurprisingly, some perf/compiler tests get a bit slower (see below). More surprisingly, there are two perf/should_run tests that get worse perf/should_run T5205 [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat not good enough] (normal) This is much more surprising: neither seems to have anything much to do with Typeable. But I can't investigate before I go on holiday. Would anyone else like to? It's all up to date wrt HEAD. Simon commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 Author: Simon Peyton Jones Date: Thu Mar 26 11:06:12 2015 + Remove a redndant 'return' commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 Author: Simon Peyton Jones Date: Mon Mar 23 14:53:53 2015 + Error message wibbles These are associated with - new instance reporting - typeable changes in -ddump-simpl output - -ddump-types being a bit less verbose - some renaming of type variables in debugger output (no idea why this happens) commit fe510d911b6cf61d6884b8b42d8771d4aea3229f Author: Simon Peyton Jones Date: Mon Mar 23 14:50:23 2015 + Generate Typeble info at definition sites This patch implements the idea floated in #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: - we need to have enough data types around to *define* a TyCon - many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp T1969 T1969: GHC allocates 30% more T5642: GHC allocates 14% more T9872d: GHC allocates 5% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, - a type *family* (whether type or data) is repesented by a FamilyTyCon - a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails type. They are used for debugging only, namely to suppress excessive output in -ddump-types. * Tidy up the generation of PrelInfo.knownKeyNames * Move newImplicitBinder from IfaceEnv to BuildTyCl
Re: quick report using GHC 7.10 RC3
On Thu, Mar 26, 2015 at 11:40 AM Erik Hesselink wrote: > On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner > wrote: > > > 7. Cabal incompatible API change > > In particular, the api that a custom Setup.hs uses. > > Distribution.Simple.UserHooks changed the type of a hook. It should not, > it > > should have added another to do what it wanted. The poblem is you can't > use > > CPP in Setup.hs. And so now anyone using the testHook hook is in a > pickle: > > Your Setup.hs can't work in both 7.10 and 7.8! > > It can, but it's a bit tricky. When this happened before, people used > a type class with two instances, where one of them filled in a default > argument, IIRC. I can't find the exact code now, perhaps others > remember this better. > > > I wrote a blog post in June of last year[1] and was told that some of those tricks are used to Cabal files. I also don't have a link to a real example, but the blog post may help. Michael [1] http://www.yesodweb.com/blog/2014/06/evil-conditional-compile ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: wither the Platform
Good plan. You didn’t mention a key point: · Make sure that installing the Platform doesn’t get in the way, if you subsequently want to upgrade libraries or whatever. I am un-clear about precisely what the problem(s) is/are here. I’m pretty sure they require infrastructure work (in Cabal) to achieve. Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 25 March 2015 14:25 To: Simon Peyton Jones Cc: Gershom B; Manuel M T Chakravarty; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick report using GHC 7.10 RC3
On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner wrote: > 7. Cabal incompatible API change > In particular, the api that a custom Setup.hs uses. > Distribution.Simple.UserHooks changed the type of a hook. It should not, it > should have added another to do what it wanted. The poblem is you can't use > CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: > Your Setup.hs can't work in both 7.10 and 7.8! It can, but it's a bit tricky. When this happened before, people used a type class with two instances, where one of them filled in a default argument, IIRC. I can't find the exact code now, perhaps others remember this better. Erik ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: wither the Platform
| 2. Less diversity in new GHC features: The GHC developers have generally | aimed new features at a future release, where the existence and stability | of new features has driven their incorporation. It was assumed that the | Platform would eventually catch up. If the GHC release and the | corresponding Platform release are simultaneous, then some GHC features | may need to be pushed out to the following release so there is time for | the Platform to be adapted. | 3. The GHC development process will need to become more phased: | Experimentation with new features will still be encouraged, but adoption | of the new features will need to be gated to correspond with what the | Platform can implement. (This is really another view of issue 2.) I'm not sure that's true. We try hard not to break backward compatibility with new features. So a new GHC/HP release might have new features in GHC that are simply un-exploited by the HP libraries. That's fine! By far the biggest backward-compat issues are related to changes in the libraries themselves, rather than new features. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
