December 2014 - ghc-devs

ANNOUNCE: GHC 7.8.4 Release Candidate 1
by Austin Seipp 13 Dec '14

13 Dec '14

We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ This includes the source tarball and bindists for 64bit Linux. Binary builds for other platforms will be available shortly. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.8.4 release sometime in the next few weeks. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 18

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches
by Johan Tibell 13 Dec '14

13 Dec '14

Ben, Is this something that worked in cabal-install 1.18.0.5 and that stopped working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target a very few critical bugs. They are not attempts to backport all bugfixes from master. In 1.18 the critical fixes are: 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make list fields work like Flags. 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config file #1884 As for installing, after downloading the two tarballs to a temp dir this works for me: cabal install Cabal-1.18.1.5.tar.gz cabal-install-1.18.0.6.tar.gz -- Johan On Fri, Dec 12, 2014 at 4:52 AM, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > > Johan Tibell <johan.tibell(a)gmail.com> writes: > > > I've uploaded release candidates for Cabal/cabal-install patch releases > on > > the 1.18 and 1.20 branches: > > > > > https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz > > > https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-… > > > > > https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz > > > https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-… > > > > Please test, especially if one of your fixes are in this release. You can > > install both both lib and exe using: cabal install <Cabal URL> > > <cabal-install URL> > > > First I'll look at Cabal-1.18.1.5 and cabal-install-1.18.0.6. > > Unfortunately there still seems to be trouble invoking cabal in a tree > previously used by a previous Cabal version. For instance, > > $ tar -zxf cabal-install-1.18.0.6.tar.gz > $ cd cabal-install-1.18.0.6 > $ cabal install > $ cabal install --enable-tests > Warning: The package list for 'hackage.haskell.org' is 71 days old. > Run 'cabal update' to get the latest list of available packages. > Resolving dependencies... > Configuring cabal-install-1.18.0.6... > Building cabal-install-1.18.0.6... > cabal: dist/package.conf.inplace: inappropriate type > Failed to install cabal-install-1.18.0.6 > cabal: Error: some packages failed to install: > cabal-install-1.18.0.6 failed during the building phase. The exception > was: > ExitFailure 1 > > I have noticed this problem in the past as well. Deleting dist/ resolves > the issue. I seem to recall some discussion where it was claimed this > was fixed although I could be wrong. This was reproducible on x86_64 > (building with GHC 7.8.3 and 7.6.3) and ARM. > > After this was resolved I encountered the following, > > $ cabal install --enable-tests > ... > > Preprocessing test suite 'unit-tests' for cabal-install-1.18.0.6... > > Distribution/Client/Targets.hs:100:8: > Could not find module `Network.URI' > It is a member of the hidden package `network-2.4.2.2'. > Perhaps you need to add `network' to the build-depends in your > .cabal file. > It is a member of the hidden package `network-uri-2.6.0.1'. > Perhaps you need to add `network-uri' to the build-depends in your > .cabal file. > Use -v to see a list of the files searched for. > Failed to install cabal-install-1.18.0.6 > cabal: Error: some packages failed to install: > > This is fixed in master. It seems you should probably cherry-pick > 2826c97d11a495085008c4bddf499fcfd05e0df2 onto the release branch. > > After this I was able to run the testsuite. cabal-install was fine; > Cabal failed with, > > TestSuiteExeV10/TestWithHpc: > : [Failed] > expected: 'setup build' should succeed > output: "/opt/exp/haskell-packages/Cabal-1.18.1.5/tests/Setup > configure --user -w /opt/exp/ghc/root-ghc-7.8/bin/ghc --enable-tests > --enable-library-coverage" in PackageTests/TestSuiteExeV10 > Setup: Option --enable-library-coverage is obsolete! Please use > --enable-coverage instead. > > ... > > BuildTestSuiteDetailedV09: > : [Failed] > build failed! > expected: False > but got: True > > I didn't investigate into the cause of these any further. > > I also used the new cabal executable to install Yesod has progressed > quite (on the ARM, even) far and shows no sign failure. > > I'll take a look at the 1.20 releases tomorrow. > > Cheers, > > - Ben >

2 2

Fwd: Garbage collection
by Facundo Domínguez 13 Dec '14

13 Dec '14

Hello, While working in the StaticPointers language extension [1], we found we have some unusual CAFs which can be accessed after some periods of time where there is no reference to them. For instance, the following program when compiled contains no reference to `g`. `g` is actually looked up at runtime in symbol tables via the call to `deRefStaticPtr`. g :: String g = "hello" main = deRefStaticPtr (static g) >>= putStrLn Desugars to: g :: String g = "hello" main = deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn In principle, there is nothing stopping the garbage collector from reclaiming the closure of `g` before it is dynamically looked up. We are considering using StablePtrs to preserve `g`. So the code desugars instead to: g :: String g = "hello" main = deRefStaticPtr (let x = StaticPtr (StaticName "" "Main" "g") in unsafePerformIO $ newStablePtr g >> return x ) >>= putStrLn This solution could be temporal though, until we implement the so called static pointer table, which would keep the values alive. Would you have any comments about such a solution or maybe would you advice some other alternative? Thanks, Facundo [1] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

5 6

D538 and compiler performance spec
by Alan & Kim Zimmerman 13 Dec '14

13 Dec '14

For API annotations I am working in the details of RdrNames, which come in a bewildering variety of syntactic forms. My latest change causes perf/compiler to fail, with bytes allocated value is too high: Expected parsing001(normal) bytes allocated: 587079016 +/-5% Lower bound parsing001(normal) bytes allocated: 557725065 Upper bound parsing001(normal) bytes allocated: 616432967 Actual parsing001(normal) bytes allocated: 704940512 Deviation parsing001(normal) bytes allocated: 20.1 % I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens. Is this a problem? The alternative would be to add a SourceText field to RdrName. Alan

2 4

Typechecker plugins and 7.10
by Adam Gundry 12 Dec '14

12 Dec '14

Hi Austin, devs, I'm not sure what stage the 7.10 branch split and RC have got to, but if possible I'd like to get Phab:D553 included (my special pleading is that it makes relatively small, self-contained changes that will make it slightly harder to shoot oneself in the foot when writing a plugin). I realise you have to say "no" at some point though! More generally, at Richard's suggestion I propose that (at least for 7.10) we explicitly make no guarantees about the stability of the TcPluginM API, and advertise that we may choose to make breaking changes between minor GHC releases. After all, this feature is highly experimental and tightly coupled to GHC itself. All the best, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Serialising evidence generated by typechecker plugins
by Adam Gundry 12 Dec '14

12 Dec '14

Hi folks, I've just discovered tcIfaceCoAxiomRule, which is used when typechecking a coercion from an interface file. It turns out that CoAxiomRules are represented in interface files by their names, so tcIfaceCoAxiomRule looks up this name in a map containing all the built-in typeNatCoAxiomRules. Unfortunately, this lookup fails when a plugin has defined its own CoAxiomRule (as both uom-plugin and type-nat-solver do)! This means that if a module uses a plugin and exports some of the evidence generated via an unfolding, importing the module may result in a tcIfaceCoAxiomRule panic. At the moment, both plugins generate fake CoAxiomRules that can prove the equality of any types, so one workaround would be to expose this ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In the future, however, it would be nice if plugins could actually generate bona fide evidence based on their own axioms (e.g. the abelian group laws, for uom-plugin). We can't currently serialise CoAxiomRule directly, because it contains a function in the coaxrProves field. Could we support an alternative first-order representation that could be serialised? This probably wouldn't be as expressive, in particular it might not cover the built-in axioms that define type-level comparison functions and arithmetic operators, but it would allow plugins to axiomatize algebraic theories. Any thoughts? Adam P.S. I've updated https://phabricator.haskell.org/D553 with the TcPluginM changes we discussed. -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

Typechecker tests failures
by Yuras Shumovich 12 Dec '14

12 Dec '14

Hello, I was working on #9605, and found a number of failed tests: Unexpected failures: should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) They seem to be unrelated to my work, and they are skipped when "fast" is enabled. T7891 and tc124 fail with Core Lint errors. Looks like Phabricator uses "fast" way to validate revisions, so the failures were not noticed. Thanks, Yuras

2 2

Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches
by Johan Tibell 11 Dec '14

11 Dec '14

I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-… https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-… Please test, especially if one of your fixes are in this release. You can install both both lib and exe using: cabal install <Cabal URL> <cabal-install URL> Changelogs: Cabal-1.18.1.5: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. cabal-install-1.18.0.6: 79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number to 1.18.0.6 97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of https://github.com/snoyberg/cabal into 1.18 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make list fields work like Flags. 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config file #1884 Cabal-1.20.0.3 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to 1.20.0.3 cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org moved b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when GHC is using dynamic libraries. 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. 343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/ cabal-install-1.20.0.4 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in frozen constraints b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of https://github.com/snoyberg/cabal into 1.20 1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network constraint" 58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network constraint a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6 5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make list fields work like Flags. 13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config file #1884 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file as UTF-8

1 1

Including Cabal-1.18.1.5 in GHC 7.8.4
by Johan Tibell 11 Dec '14

11 Dec '14

I'm going to make a bugfix release on the Cabal 1.18 branch the next few days. The release candidate is already out. Here are the commits: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. The only one of interest is that we now pass -fPIC when needed. Should we include this bugfix release in the GHC release? It's quite difficult for some users to upgrade from the Cabal version that ships with GHC so included the newest one makes sense. P.S. I'm looking to make a 1.22 release soon as well, for inclusion in GHC 7.10. -- Johan

1 0

RE: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles from constraint-solver improvements
by Simon Peyton Jones 10 Dec '14

10 Dec '14

This is a single stat failure in haddock.base; doesn't happen for me. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 10 December 2014 18:48 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements | | Harbormaster failed to build B2572: rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC37b3646c9da4 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

2 1