From mail at joachim-breitner.de Tue Mar 6 15:26:57 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 06 Mar 2018 10:26:57 -0500 Subject: How to highlighting subexpressions in dumped core? Message-ID: <1520350017.1105.10.camel@joachim-breitner.de> Hi, one of my plugins dumps core output to the user, and this core output contains “interesting subexpressions”. I would like to highlight them (for example, with `bold :: SDoc -> SDoc`). As far as I can see, I have these options: * I copy all, or most of PprCore, and extend ppr_expr to look for the subexpressions that I care about. Obviously not nice, because of a code copy. * I extend GHC to support that. One way would be to add a new constructor to `data Tickish id = … | Highlight` so that I can wrap the interesting subexpressions in `Tick Highlight e`. That’s a bit better, and could even be useful in GHC (e.g. a linter error could highlight the lint error location), but it’d mean waiting for new compiler versions until I can make use of that, and it is still limited to subexpressions – highlighting a binder would require yet another support. * Could we extend SDoc with an operation highlightIn :: SDoc -> SDoc -> SDoc or highlightIn :: Doc -> Doc -> Doc where `highlightIn doc1 doc2` is like doc2, but any subdocument that is “ismorphic to doc1” (for whatever that means) gets highlighted? Are there other options that I might not see right now? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Mar 7 12:14:42 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Mar 2018 12:14:42 +0000 Subject: How to highlighting subexpressions in dumped core? In-Reply-To: <1520350017.1105.10.camel@joachim-breitner.de> References: <1520350017.1105.10.camel@joachim-breitner.de> Message-ID: I'm not keen on adding more Tick complexity -- it's a bit out of hand already, and all transformations must "do the right thing". AnnExpr adds an annotation at every node. You could, I guess use that to annotate -- but then you'd need a pretty printer for it so you'd end up with duplication. Worth looking at #8809 and related tickets S | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 06 March 2018 15:27 | To: GHC users | Subject: How to highlighting subexpressions in dumped core? | | Hi, | | one of my plugins dumps core output to the user, and this core output | contains “interesting subexpressions”. I would like to highlight them | (for example, with `bold :: SDoc -> SDoc`). | | As far as I can see, I have these options: | | * I copy all, or most of PprCore, and extend ppr_expr to look for the | subexpressions that I care about. | | Obviously not nice, because of a code copy. | | * I extend GHC to support that. One way would be to add a new | constructor to `data Tickish id = … | Highlight` so that | I can wrap the interesting subexpressions in | `Tick Highlight e`. | | That’s a bit better, and could even be useful in GHC (e.g. a linter | error could highlight the lint error location), but it’d mean | waiting for new compiler versions until I can make use of that, | and it is still limited to subexpressions – highlighting a binder | would require yet another support. | | * Could we extend SDoc with an operation | | highlightIn :: SDoc -> SDoc -> SDoc | | or | | highlightIn :: Doc -> Doc -> Doc | | where `highlightIn doc1 doc2` is like doc2, but any subdocument that | is “ismorphic to doc1” (for whatever that means) gets highlighted? | | | Are there other options that I might not see right now? | | | | Cheers, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd3680548aafa49c82 | 7e708d58376c5e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636559468531 | 359492%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi | I6Ik1haWwifQ%3D%3D%7C- | 2&sdata=VodWxNvTtF4Asflj%2FeC7%2FbQy0FExq2zq53hvtWoF98s%3D&reserved=0 From mail at joachim-breitner.de Wed Mar 7 15:06:13 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 07 Mar 2018 10:06:13 -0500 Subject: How to highlighting subexpressions in dumped core? In-Reply-To: References: <1520350017.1105.10.camel@joachim-breitner.de> Message-ID: <1520435173.1932.1.camel@joachim-breitner.de> Hi, Am Mittwoch, den 07.03.2018, 12:14 +0000 schrieb Simon Peyton Jones via Glasgow-haskell-users: > I'm not keen on adding more Tick complexity -- it's a bit out of hand > already, and all transformations must "do the right thing". > > AnnExpr adds an annotation at every node. You could, I guess use > that to annotate -- but then you'd need a pretty printer for it so > you'd end up with duplication. > > Worth looking at #8809 and related tickets these are all for CoreExpr, right? I guess I can just copy the pretty-printer code for my maybe a bit peculiar needs, it’s not too big. (Although highlights in CoreLint output would be useful for all of use.) Thanks for your input, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Thu Mar 8 16:57:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 11:57:45 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released Message-ID: <87h8pq33p8.fsf@smart-cactus.org> The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From asyropoulos at aol.com Thu Mar 8 18:05:38 2018 From: asyropoulos at aol.com (asyropoulos at aol.com) Date: Thu, 8 Mar 2018 13:05:38 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released Message-ID: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> Hello, I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and compilation never starts because: checking target system type... i386-pc-solaris2.11 Build platform inferred as: i386-unknown-solaris2 Host platform inferred as: i386-unknown-solaris2 Target platform inferred as: i386-unknown-solaris2 Unknown OS solaris2.11 The configure script mentions Solaris... On my system I get $ uname -m i86pc $ uname -r 5.11 $ uname -s SunOS $ uname -v illumos-87446a5213 Any idea that migh help me go beyond this point? Thanks in advance! A.S. -- Apostolos Syropoulos Xanthi, Greece -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Mar 8 20:27:39 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 15:27:39 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> References: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> Message-ID: <878tb22tzb.fsf@smart-cactus.org> Apostolos Syropoulos via Glasgow-haskell-users writes: > Hello, > > I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and > compilation never starts because: > Can you try applying the attached patch? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-configure-Accept-version-suffix-in-solaris-name.patch Type: text/x-patch Size: 1295 bytes Desc: not available URL: From svenpanne at gmail.com Fri Mar 9 09:23:18 2018 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 9 Mar 2018 10:23:18 +0100 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: 2018-03-08 17:57 GMT+01:00 Ben Gamari : > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. [...] Just a few tiny remarks regarding "base": * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries says that the shipped "base" has version 2.1, I guess that should be 4.11.0.0. * https://wiki.haskell.org/Base_package needs an update. * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. Yes, there is https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, but Hackage is somehow the more canonical place to look up the package docs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From metaniklas at gmail.com Fri Mar 9 11:35:46 2018 From: metaniklas at gmail.com (Niklas Larsson) Date: Fri, 9 Mar 2018 12:35:46 +0100 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: Hi! It says on the download page that the Windows versions is “excluding the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste error from the release that fixed the Windows 10 CU bug. Regards, Niklas > 8 mars 2018 kl. 17:57 skrev Ben Gamari : > > > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. Binary and source distributions can be found > at > > https://downloads.haskell.org/~ghc/8.4.1/ > > This is the third major release in the GHC 8 series. As such, the focus > of this release is performance, stability, and consolidation. > Consequently numerous cleanups can be seen throughout the compiler > including, > > * Further refinement of TypeInType, including significant improvements > in error messages. > > * Improvements in code generation resulting in noticable performance > improvements in some types of programs. > > * Core library improvements, including phase 2 of the Semigroup/Monoid > proposal > > * Many improvements to instance deriving > > * The resolution of nearly 300 other tickets > > A more thorough list of the changes in this release can be found in the > release notes, > > https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html > > There are a few changes in release-engineering matters that should be > noted, > > * This is GHC's first release on it's new, accelerated release > schedule. From now on GHC will produce one release every six months. > > * While we typically strive to produce OpenBSD builds, the gcc shipped > with OpenBSD 6.1 is unfortunately too old to compile this release. > > * FreeBSD builds are still in progress > > This release has been the result of approximately six months of work by > over one hundred code contributors. Thanks to everyone who has helped in > writing patches, testing, reporting bugs, and offering feedback over the > last year. > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From ben at well-typed.com Fri Mar 9 13:47:30 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:47:30 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87k1ul1hu8.fsf@smart-cactus.org> Sven Panne writes: > 2018-03-08 17:57 GMT+01:00 Ben Gamari : > >> The GHC developers are very happy to announce the 8.4.1 release of >> Glasgow Haskell Compiler. [...] > > > Just a few tiny remarks regarding "base": > > * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries > > says that the shipped "base" has version 2.1, I guess that should be > 4.11.0.0. > Good catch; in principle this should now be automatically generated. I'll need to look at what has gone wrong here. I've opened #14906 to track this. > * https://wiki.haskell.org/Base_package needs an update. > Ahh, thanks; I've added this to the MakingReleases protocol [1] to ensure that this is done in the future. > * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. > Yes, there is > https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, > but Hackage is somehow the more canonical place to look up the package docs. Yes, the Hackage uploads have historically not been handled by me but rather Herbert. He know about the release and am certain has the task on his queue. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Mar 9 13:50:25 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:50:25 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87h8pp1hpd.fsf@smart-cactus.org> Niklas Larsson writes: > Hi! > > It says on the download page that the Windows versions is “excluding > the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste > error from the release that fixed the Windows 10 CU bug. > Oh dear, yes. Thank you for noticing this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From varosi at gmail.com Fri Mar 9 15:39:20 2018 From: varosi at gmail.com (Vassil Ognyanov Keremidchiev) Date: Fri, 9 Mar 2018 17:39:20 +0200 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pp1hpd.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> <87h8pp1hpd.fsf@smart-cactus.org> Message-ID: I saw there is ARM Aarch64 build, which is pretty cool! But will there be a ARMv7 (32bit build) as well? 2018-03-09 15:50 GMT+02:00 Ben Gamari : > Niklas Larsson writes: > > > Hi! > > > > It says on the download page that the Windows versions is “excluding > > the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste > > error from the release that fixed the Windows 10 CU bug. > > > Oh dear, yes. Thank you for noticing this. > > Cheers, > > - Ben > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Mar 9 17:15:13 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 12:15:13 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> <87h8pp1hpd.fsf@smart-cactus.org> Message-ID: <871sgt1883.fsf@smart-cactus.org> Vassil Ognyanov Keremidchiev writes: > I saw there is ARM Aarch64 build, which is pretty cool! But will there be a > ARMv7 (32bit build) as well? > I do hope so. There have been a number of false-starts but hopefully the build that is currently running will finish. Unfortunately getting a working ARMv7 build is rather tricky due to a number of linker bugs that bite under various circumstances. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From varosi at gmail.com Mon Mar 12 17:29:28 2018 From: varosi at gmail.com (Vassil Ognyanov Keremidchiev) Date: Mon, 12 Mar 2018 19:29:28 +0200 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <871sgt1883.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> <87h8pp1hpd.fsf@smart-cactus.org> <871sgt1883.fsf@smart-cactus.org> Message-ID: Great! Thanks a lot! 2018-03-09 19:15 GMT+02:00 Ben Gamari : > Vassil Ognyanov Keremidchiev writes: > > > I saw there is ARM Aarch64 build, which is pretty cool! But will there > be a > > ARMv7 (32bit build) as well? > > > I do hope so. There have been a number of false-starts but hopefully the > build that is currently running will finish. Unfortunately getting a > working ARMv7 build is rather tricky due to a number of linker bugs that > bite under various circumstances. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Wed Mar 14 09:51:48 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 14 Mar 2018 18:51:48 +0900 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: On 9 March 2018 at 01:57, Ben Gamari wrote: > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. Thanks! I have built it for Fedora and EPEL7 in a copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.1/ Cheers, Jens From asyropoulos at aol.com Thu Mar 15 18:39:38 2018 From: asyropoulos at aol.com (asyropoulos at aol.com) Date: Thu, 15 Mar 2018 14:39:38 -0400 Subject: "strange" error Message-ID: <1622af5d5bf-179f-84f7@webjas-vaa249.srv.aolmail.net> Hello, I have compiled the latest veersion of ghc under OpenIndiana (Solaris) and now I am trying to compile cabal. I downloaded the source code from https://www.haskell.org/cabal/download.html and I tried to compile. I used the bootstrap.sh script bit it failed: Configuring cabal-install-2.0.0.1... Setup: Encountered missing dependencies: HTTP >=4000.1.5 && <4000.4, async >=2.0 && <3, cryptohash-sha256 ==0.11.*, hackage-security >=0.5.2.2 && <0.6, hashable >=1.0 && <2, tar >=0.5.0.3 && <0.6 Error during cabal-install bootstrap: Configuring the cabal-install package failed. The script downloaded all these packages so I tried to see why they fail: $ cd HTTP-4000.3.7 $ ls CHANGES HTTP.cabal Network test dist LICENSE Setup.lhs $ runhaskell Setup configure Configuring HTTP-4000.3.7... Setup: Encountered missing dependencies: base >=4.3.0.0 && <4.11 Of course this package is already installed and this means that for some reason it cannot find it. It is quite possible that I am doing something stupid but I would like to know how can I proceed? Thanks in advance for your help/assistance. A.S. -- Apostolos Syropoulos Xanthi, Greece -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Mar 21 22:04:57 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 21 Mar 2018 15:04:57 -0700 Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance Message-ID: I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 Linux, PC: RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. >From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 Linux, PC: score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Fri Mar 23 00:20:05 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 22 Mar 2018 17:20:05 -0700 Subject: 8.4.1 ghci findings Message-ID: I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference.