- ghc-devs - Haskell.org

RE: Implicit Locations in GHC
by Simon Peyton Jones 15 Dec '14

15 Dec '14

Eric I'd love to see it happen. High payoff, low pain. See https://ghc.haskell.org/trac/ghc/ticket/9049 No existing branch that I know of. I'm copying some other people who might be interested. Let me know how I can help. Simon | -----Original Message----- | From: Eric Seidel [mailto:eric@seidel.io] | Sent: 12 December 2014 22:11 | To: Simon Peyton Jones | Subject: Implicit Locations in GHC | | Hi Simon, | | I just noticed your wiki page | | | https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocati | ons | | Interestingly, I talked to Iavor a few weeks back about the exact same | idea, and briefly started working on a branch before being consumed by | various work things.. | | Anyway, I think I may have some extra free time coming up, and I'd be | happy to throw some of it at implementing this proposal. Is there an | existing branch that I should look at? | | Eric

1 0

performance regressions
by Richard Eisenberg 15 Dec '14

15 Dec '14

Hi devs, Phab has shown up some performance regressions in my recent commits. See https://phabricator.haskell.org/harbormaster/build/2607/. The failures except for haddock.base are new, and evidently my fault. They didn't show up on Travis. Will look into it shortly, but I doubt over the weekend. I don't think this should hold up the 7.10 fork, however. I have a suspicion as to what caused the problem -- the reimplementation of TcInteract.matchFam. That reimplementation was solely to reduce code repetition between TcInteract.matchFam and FamInstEnv.reduceTyFamApp_maybe. It can safely be rolled back -- just use the implementation of matchFam that existed before my commits. I'll look into this Monday at the latest, but if a remedy is needed sooner, try the technique above. Why would these failures show up on Phab but not on Travis? Sorry about the bother! Thanks, Richard

3 7

Program runs out of memory using GHC 7.6.3
by David Spies 14 Dec '14

14 Dec '14

I have a program I submitted for a Kattis problem: https://open.kattis.com/problems/digicomp2 But I got memory limit exceeded. I downloaded the test data and ran the program on my own computer without problems. Eventually I found out that when compiling with GHC 7.6.3 (the version Kattis uses) rather than 7.8.3, this program runs out of memory. Can someone explain why it only works on the later compiler? Is there a workaround so that I can submit to Kattis? Thanks, David

3 7

Trouble committing
by Andreas Voellmy 14 Dec '14

14 Dec '14

Hi GHCers, I just fixed a bug (#9423) and went through the Phab workflow. Then I did a fresh checkout from git and ran: $ git checkout master $ arc patch --nobranch D129 $ git push origin master as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on the last command I get this error: fatal: remote error: access denied or repository not exported: /ghc.git Maybe I just no longer have commit access to ghc? If so, could someone restore my access? Or I'd be happy if someone else can push the patch. Thanks, Andi

4 4

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