- ghc-devs - Haskell.org

Re: Alex install failure
by Ara Adkins 19 Aug '17

19 Aug '17

NFS can be pretty dodgy with transient files due to latency. Sometimes the delete takes appreciable time after the command is issued so the lock file might just be persisting. I’d try installing into a cabal sandbox on a local drive and see if the same issue crops up. _ara > On 18 Aug 2017, at 23:43, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? > > Simon > > | -----Original Message----- > | From: Ben Gamari [mailto:ben@smart-cactus.org] > | Sent: 18 August 2017 13:05 > | To: Simon Peyton Jones <simonpj(a)microsoft.com>; ghc-devs <ghc- > | devs(a)haskell.org> > | Subject: Re: Alex install failure > | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: > | > | > 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. > | > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > | > | Cheers, > | > | - Ben > >

2 2

Re: Where to discuss the linear types extension of GHC?
by Boespflug, Mathieu 18 Aug '17

18 Aug '17

Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that it's not even good enough as a developer preview of all the basic features. It's an in-progress development branch, which is going to take time to stabilize. Furthermore, whether the feature makes it into GHC will depend on what the GHC proposals committee thinks about it. The current authors of the would-be extension have yet to draft a proposal and submit it to the committee. If we manage to write a proposal in time, based on a beta level implementation of linear types, and if the committee accepts the proposal, then maybe the feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. But it could also be never, if the committee rejects the proposal... Best, -- Mathieu Boespflug Founder at http://tweag.io. On 18 August 2017 at 22:55, Wolfgang Jeltsch <wolfgang-it(a)jeltsch.info> wrote: > Hi! > > I just read through the README. According to it, there are several crucial > things not implemented yet (case and let come to my mind), and there are > some fundamental bugs (which make it very easy to circumvent linearity > checks, making the whole extension pointless). Is the situation still like > this? > > What are your honest expectations regarding the future development of the > linear types feature and its integration into the official GHC? Is it > realistic to hope for this feature to be available in a stable GHC version > withing, say, the next 12 months? I would like to use linearity in some > project of mine, but at the moment, I am unsure whether it is really a good > idea to rely on this feature becoming available. > > All the best, > Wolfgang > > Am Mittwoch, den 19.07.2017, 08:52 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang, > > the updated README is live and can be found here > <https://github.com/tweag/ghc/tree/linear-types>! > > Cheers, > Edvard > > On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud <arnaud.spiwack(a)tweag.io> > wrote: > > I think the answer to both questions can be the same: the github issue of > Tweag's ghc repo: https://github.com/tweag/ghc/issues . > > Regarding this particular bug: it is a known bug indeed. I'll be fixing it > soon. We're expanding the README to include known bugs and usage > instruction. > > Thanks a lot for your time and interest, > Arnaud > > On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch < > wolfgang-it(a)jeltsch.info> wrote: > > Hi! > > Another question is where to submit bugs. I already found the first one 😉: > > GHCi> let dup :: a -> (a, a); dup x = (x, x) > > GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup > > GHCi> :type unsafeDup > > unsafeDup :: a ⊸ (a, a) > > GHCi> unsafeDup True > > (True,True) > > > All the best, > Wolfgang > > Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch: > > Hi! > > I think I will have several questions about the linear types extension > when trying to use it in the near future. Furthermore, I also want to give > feedback on the design of this extension. What is the appropriate forum for > discussing the linear types extension? The GHC developers mailing list > might be an option. However, I think that it would be better to contact you > more directly regarding these matters. Is there some issue tracker or > discussion platform I should use? > > All the best, > Wolfgang > > > > >

2 1

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