July 2019 - ghc-devs - Haskell.org

Partial GitLab outage
by Ben Gamari 07 Jul '19

07 Jul '19

Hi everyone, For the past 12 hours or so the hosting provider which hosts haskell.org's infrastructure has been having issues [1] with their block storage infrastructure. Due to this outage the search and Docker registry functionality hosted by gitlab.haskell.org are currently unavailable. We hope that service will be restored by the end of the day. Cheers, - Ben [1] https://status.packet.com/

1 0

lint-submods-marge consistently failing when attempting to update Haddock
by Ryan Scott 06 Jul '19

06 Jul '19

I've noticed that Marge's most recent batch is consistently failing after repeated attempts. Each time, the failure is only in the lint-submods-marge job. Here is an excerpt from the most recent failure [1]: Submodule update(s) detected in 1cd22260c2467650dde8811cc58e89594a016f43: utils/haddock => 658ad4af237f3da196cca083ad525375260e38a7 *FAIL* commit not found in submodule repo or not reachable from persistent branches My understanding is that the lint-submods-marge job checks for any submodule updates, and if there is an update, it ensures that the new commit is actually present upstream. However, I have already pushed Haddock commit 658ad4af237f3da196cca083ad525375260e38a7 upstream on GitHub [2], and there has been enough time for this commit to also appear on the GitLab mirror [3]. Despite this, lint-submods-marge keeps failing, and I have no idea why. Does anyone know what to do from here? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/jobs/119054 [2] https://github.com/haskell/haddock/commit/658ad4af237f3da196cca083ad5253752… [3] https://gitlab.haskell.org/ghc/haddock/commit/658ad4af237f3da196cca083ad525…

1 0

Guarded Impredicativity
by Alejandro Serrano Mena 04 Jul '19

04 Jul '19

Dear all, We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [ https://www.microsoft.com/en-us/research/publication/guarded-impredicative-… ]. For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not. The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->). For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor. Just for reference, the best to get a working clone is to follow these steps: > git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc > cd impredicative-ghc > git remote add trupill git@gitlab.haskell.org:trupill/ghc.git > git fetch trupill > git checkout trupill master Thanks very much in advance, Alejandro

5 11

Weight field in issues too fine grained?
by Ömer Sinan Ağacan 02 Jul '19

02 Jul '19

Hi, One of the problems I'm having when triaging is that I think the "weight" field for issues is currently too fine grained. The triage protocol[1] gives some idea but it's still up to the person who's doing triaging to decide, for example, between 7 vs. 10 for a runtime crash. I think a better "weight" field would be what we had in trac: highest, high, normal etc. that way we don't have to decide whether a runtime panic is 8 or 9 or 10, we'd just mark it as "highest". Now if we had a lot of issues with weight 8, 9, 10 etc. perhaps we'd use the weight field to prioritize, but in my experience we usually have very little such issues and they all get fixed before the next release, so the distinction between e.g. 8 vs. 9 is not useful or meaningful. Is it possible to do switch to trac-style priority/weight field in Gitlab? Anyone else think that this would be good? Ömer [1]: https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#triage-protocol

5 10

What to do if your hadrian build starts failing (supportedLlvmVersion)
by Matthew Pickering 02 Jul '19

02 Jul '19

If you see this message: Exit code: 1 Stderr: compiler/llvmGen/LlvmCodeGen/Base.hs:192:36: error: • Couldn't match expected type ‘Int’ with actual type ‘(Integer, Integer)’ • In the first argument of ‘LlvmVersion’, namely ‘(7, 0)’ In the expression: LlvmVersion (7, 0) In an equation for ‘supportedLlvmVersion’: supportedLlvmVersion = LlvmVersion (7, 0) | 192 | supportedLlvmVersion = LlvmVersion sUPPORTED_LLVM_VERSION | ^^^^^ ) Then you need to delete the `includes/ghcautoconf.h` file. It is a file generated by the Make build system. Cheers, Matt

1 0

Workflow question (changing codegen)
by Ömer Sinan Ağacan 01 Jul '19

01 Jul '19

Hi all, I'm currently going through this torturous process and I'm hoping that someone here will be able to help. I'm making changes in the codegen. My changes are currently buggy, and I need a working stage 1 compiler to be able to debug. Basically I need to build libraries using the branch my changes are based on, then build stage 1 with my branch, so that I'll be able to build and run programs using stage 1 that uses my codegen changes. The changes are compatible with the old codegen (i.e. no changes in calling conventions or anything like that) so this should work. Normally I do this $ git checkout master $ git distclean && ./boot && ./configure && make $ git checkout my_branch $ cd compiler; make 1 This gives me stage 1 compiler that uses my buggy codegen changes, plus libraries built with the old and correct codegen. However the problem is I'm also adding a new file in my_branch, and the build system just doesn't register that fact, even after adding the line I added to compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix this that I could find was to run ./configure again, then run make for a few seconds at the top level, then do `make 1` in compiler/. Unfortunately even that doesn't work when the master branch and my_branch have different dates, because `make` in master branch produces a different version than the `make` in my_branch, so the interface files become incompatible. Anyone have any ideas on how to proceed here? Thanks, Ömer

4 7

User manual
by Simon Peyton Jones 01 Jul '19

01 Jul '19

I use this link to see the most up to date GHC user manual https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html But I think I'm seeing on from 13 June. It's labelled as GHC 8.9.0.20190613 User's Guide<https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html> How come it's so out of date? Simon

3 3

Re:
by chessai . 01 Jul '19

01 Jul '19

Copying on ghc-devs, since i think that's what you wanted. On Mon, Jul 1, 2019, 11:14 AM Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: > To get GHC to raise an exception from an inline primop, I presume that I'd > need to jump to stg_raisezh. None of the existing inline primops do > anything quite like this. I see things like emitMemcmpCall and > emitMemsetCall, but these ultimately just wrap emitForeignCall, which wraps > mkUnsafeCall, which wraps the data constructor CmmUnsafeForeignCall. I > think I want CmmCall instead, which is described by the comments as being > used for "a native call or tail call". Hmm... emitRtsCall might be what I > want. I'll try pursuing this route further. > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

Re: Cloning (Shayne Fletcher)
by Jost Berthold 01 Jul '19

01 Jul '19

Just on this detail in the previous mails: On 6/25/19 10:00 PM, ghc-devs-request(a)haskell.org wrote: >> More generally, I'm actually wondering, why GHC's .gitsubmodules use > relative paths. Why not make them absolute? > > I continue to wonder about that and if switching to absolute paths might > remove this wrinkle. Can anyone chime in? I remember the relative paths for submodules were added to make working with several clones of the GHC repo (to lower rebuild cost for simultaneous branches or similar) easier. With relative paths, one can make a second local clone from the first one and all references to all submodules will share local data. That said, this does get in the way sometimes. I changed back to absolute paths in my GHC fork quite a while back. / Jost

3 2