- ghc-devs - Haskell.org

RE: Alex install failure
by Simon Peyton Jones 18 Aug '17

18 Aug '17

That's what I did. It then succeeds in installing one package, and fails in the same way on the next one. So I can install packages one at a time, by deleting the lock file manually each time. Bizarre. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 August 2017 11:59 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Alex install failure | | Try removing | | /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock | | | | On Fri, Aug 18, 2017 at 12:25 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > Friends | > | > I’m trying to update my installation of alex, on Unix (Ubuntu). But I | > get the dump below | > | > It’s complaining about a lock file being an invalid argument (see | > highlight below). | > | > If I manually remove the file I get past that, it successfully | > installs tf-random, but the same thing happens on the next package. | > So I can install packages one at a time, but that’s silly. | > | > Any ideas? | > | > Simon | > | > | > | > cabal install alex | > | > Resolving dependencies... | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Failed to install tf-random-0.5 | > | > Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): | > | > cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Preprocessing library tf-random-0.5... | > | > [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, | > dist/build/System/Random/TF/Gen.o ) | > | > [2 of 4] Compiling System.Random.TF.Init ( | > src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) | > | > | > | > src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] | > | > In the use of ‘bitSize’ (imported from Data.Bits): | > | > Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | > | > | | > | > 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 | not | > implemented" | > | > | ^^^^^^^ | > | > [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, | > dist/build/System/Random/TF.o ) | > | > [4 of 4] Compiling System.Random.TF.Instances ( | > src/System/Random/TF/Instances.hs, | > dist/build/System/Random/TF/Instances.o ) | > | > Creating package registration file: | > | > /tmp/pkgConf-tf-random-05965166491189641421.5 | > | > Installing library in | > | > /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3m | > XYlHUEE5hzgewx | > | > Registering tf-random-0.5... | > | > cabal: '/usr/local/bin/ghc-pkg' exited with an error: | > | > ghc-pkg: Couldn't open database | > | > /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: | > | > {handle: | > | > /home/simonpj/.ghc/x86_64-linux- | 8.2.1/package.conf.d/package.cache.lock}: | > | > hLock: invalid argument (Bad file descriptor) | > | > cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' | > | > cabal: Error: some packages failed to install: | > | > QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. | > | > alex-3.2.1 depends on tf-random-0.5 which failed to install. | > | > tf-random-0.5 failed during the final install step. The exception was: | > | > ExitFailure 1 | > | > simonpj@cam-05-unx:~/code/HEAD$ | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3f6ad797e3454147fa5e08d4e62 | 821e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386507413664213&sda | ta=ex4vc7sfwhYQsoTNUKSrtdKZtIkDxDWor0CEKN0M4Wk%3D&reserved=0 | >

1 0

Failing Test Cases in HEAD
by Shayan Najd 14 Aug '17

14 Aug '17

In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails. That is while `./validate` passes. I am rather new to GHC code base, and not so familiar with its build and testing system. So I was wondering whether this is an intended behaviour (e.g., some test cases are intentionally left out of `./validate`). Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, Alan also gets the similar result on his system. I am investigating this, since my development of Growable ASTs is stalled due to some "GHC panic bug" when validating. (In my repo[1], I can successfully build with steps (2)-(7) above but `./validate` (and `make test TEST="T13780c T13822"`) fails) Thanks, Shayan [1] https://github.com/shayan-najd/GrowableGHC

2 1

How does GHC handle TcPluginContradiction?
by Nicolas Frisby 06 Aug '17

06 Aug '17

My TC plugin is identifying a contradiction, but that is not preventing the module from type checking, nor does GHC even raising a warning (with -Wall). This is not the behavior I was expecting. How confused am I? I've distilled the behavior that's confusing me down to the following example > module Test where > > class C a where f :: a -> () paired with a very silly plugin that always claims every constraint it sees is a contradiction. > module Contrarian (plugin) where > > import Plugins (Plugin(..),defaultPlugin) > import TcPluginM (tcPluginIO) > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) > > plugin :: Plugin > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } > > contrarianPlugin :: TcPlugin > contrarianPlugin = TcPlugin { > tcPluginInit = return () > , > tcPluginSolve = \() given derived wanted -> do > tcPluginIO $ putStrLn "Alternative facts!" > return $ TcPluginContradiction $ given ++ derived ++ wanted > , > tcPluginStop = \() -> return () > } Please review the following GHCi session. We start *without* the plugin. $ ghc --interactive Test.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Ok, 1 module loaded. *Test> f () <interactive>:1:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () That behavior meets my expectations. Now let's add the plugin to see what contradictions cause to happen --- my naive guess is that we should see the same thing. (I don't really know what contradictions *should* cause GHC to do *differently* than the above.) The following is a continuation of the same session. *Test> :set -fplugin=Contrarian *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: <interactive>:3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) *Test> :t f Alternative facts! f :: a -> () Interesting: claiming the constraint is a contradiction seems to convert the type error to a deferred type error. Let's see if we can disable that (since it's not the behavior I want). *Test> :set -fno-defer-type-errors *Test> :t f Alternative facts! f :: a -> () *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: <interactive>:3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) <interactive>:7:1: error: * No instance for (Show (a0 -> ())) arising from a use of `print' (maybe you haven't applied a function to enough arguments?) * In a stmt of an interactive GHCi command: print it *Test> I seems we can't disable this behavior. That makes it seem pretty fundamental. So I'm guessing I'm confused about something, probably what TcContradiction achieves in terms of the user experience. The behavior I want is for my plugin to identify (relevant) contradictions and incur a static type error as soon as possible. I thought contradictions would achieve that, but I seem to be wrong. What I should be expecting regarding contradictions? How should I achieve my desired behavior? Perhaps I should try "solving" the contradiction constraints via an appeal to a TypeError constraint instead. Or maybe I should just leave the identified contradictions unsolved? Thanks. -Nick PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably others) for the useful wiki pages, blog posts, and publications -- they've been a huge help for my learning about the typechecker via plugins! I'm very excited about this plugin, and I hope to share it soon, but I'd like to understand it better before I do.

2 3

Job opening: compiling to categories
by Conal Elliott 05 Aug '17

05 Aug '17

I have a job opening to work closely with me (at Target Digital) on the GHC plugin described in the paper *Compiling to Categories* <http://conal.net/papers/compiling-to-categories> as well as on applications, including machine learning. I’m especially looking for someone used to working inside of GHC and/or on GHC plugins. Mathematically oriented, solid background in programming language theory, denotationally inclined. Remote work is perfectly fine (and is what I do). – Conal

1 0

Debugging inside the typechecker knot
by Ryan Scott 04 Aug '17

04 Aug '17

Recently, I've found myself wanting to make changes to code that works inside code where TyCons are knot-tied [1]. But I've found myself unable to make much progress, since my ability to debug this code is severely limited by the fact that I can't seem to trace anything. That is, if I try tracing anything that comes from a knot-tied TyCon, GHC will go into an infinite loop! This prevents me from learning *anything* about the types floating around in the code I want to fix, which is hugely annoying. How do others work around this problem? There must be *some* way to glean information about the types inside a typechecker knot, since others seem to be able to work within this space. How do you do it? And will you consider sharing your secrets? Ryan S. ----- [1] See Note [Type-checking inside the knot] at http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78d0b765ea6…

3 4

Re: GHC release timing and future build infrastructure
by Ara Adkins 03 Aug '17

03 Aug '17

Heya, I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence. When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time. Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel. It's not all sunny, however, as having so many rapid releases means that it's sometimes difficult to rally the community around certain releases and feature sets. This is perhaps less of an issue due to the maturity of GHC and its ecosystem, but, like you say, it's important to find a good trade-off between release cadence and stability. Personally, I think Rust's cadence is a touch too short. On a related note, there's a 'checkpoints' initiative to build rallying releases that represent significant milestones in development [1]. This is, however, also tied into Rust's stability story, so only parts of it are relevant to GHC. In terms of automated tooling, I think there is significant benefit from it. Again, using rust as an example, there is cargobomb [2], a significant automated testing initiative that both combines packages on Cargo, and runs their test suites. I feel that a combination of the Stackage LTS and Nightly releases would provide a well-curated subset of Hackage that could possibly be used in a similar fashion. This hits on your item (b). Regarding your questions: - In comparison to rust it can feel like there's significant delay in being able to really use GHC's newest features. I feel like this delay can hinder adoption of the features as much of the enthusiasm for them has died down by the time they're properly available. - With the advent of tools such as `stack`, the compiler upgrade process has almost become trivial. While not everyone uses it, it requires no more work than upgrading to a new LTS release and running `stack setup`. Nevertheless, I could imagine four upgrades a year still being okay if it was manual. - The three release policy is an interesting case as the question of changing it really comes down to how we view the GHC stability story. Personally, I think we want to target a time-period of stability, rather than a number of releases. Whether that time period is 1.5 years (assuming a six-month release cadence), or 3 years (rounding the current release cadence) seems like a totally independent discussion to me. - I think I've covered incentives to contribute in my discussion of Rust above. I hope that's useful! Best, _ara [1] https://github.com/rust-lang/rfcs/pull/2052 [2] https://github.com/rust-lang-nursery/cargobomb > On 1 Aug 2017, at 03:19, Ben Gamari <ben(a)well-typed.com> wrote: > > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci > [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

5 7

Restructuring hsSyn
by Shayan Najd 03 Aug '17

03 Aug '17

Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some unnecessary dependencies), and expose them to the end-users. At this stage, I don't expect any changes outside hsSyn. /Shayan

3 2

Limited availability next week
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I will be travelling starting tomorrow through next week. During this time I'll still try to check in on things once a day to make sure nothing is burning down. However, I will be a bit less available. Still feel free to ping me via email or IRC, however. I'll try to get back to you. Cheers, - Ben

1 0

GHC release timing and future build infrastructure
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I just posted a pair of posts on the GHC blog [1,2] laying out some thoughts on the GHC release cycle timing [1] and how this relates to the in-progress Jenkins build infrastructure [2]. When you have a some time feel free to give them a read and comment (either here or on the Reddit thread [3]). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

3 2

Occurrence info on binders and STG
by Gabor Greif 02 Aug '17

02 Aug '17

Hi devs! I just had a short exchange with Joachim, he sent me to this place. Can anybody explain how occurrence info is used in STG? Cheers and thanks, Gabor ---------- Forwarded message ---------- From: Joachim Breitner <mail(a)joachim-breitner.de> Date: Tue, 01 Aug 2017 10:47:48 -0400 Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096) To: Gabor Greif <ggreif(a)gmail.com> Hi, feel free to CC the mailing list on such questions. I often don’t know things perfectly either. Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif: > > Loosely related question: Very loosely :-) > - when doing STG Cse, the occurrence info is not updated when a > wild(card)-binder is used. Is there a recommended way to re-run > occ-analysis on STG? (I fear there is not.) I fear that too. It the occ info used past that stage? > - I noticed that "wild"-binders sometimes do not appear at their > binding site (after "of" and "{") in STG dumps. Dumping gets > suppressed when they are deemed dead. Should STG consider occ-info at > all? Good questions. I remember that Simon commented on that before, but I don’t remember where… > oachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1