On Wed, Jan 23, 2019 at 12:54:51PM -0500, Ben Gamari wrote:
> >
> Sounds like we are largely in agreement. Let's start on this after the
> Trac migration is finished.
I can in fact start working on this already while the migration is
pipelined. It's just markdown in git, so writing a draft and the
> Alright, I believe I have found the issue: you are a member of
> the GHC group and GitLab's default notification behavior is that
> you will receive notifications for all events of repositories in
> groups to which you belong.
OK thanks, that's helpful.
When you say "repository" could you al
There is a check in `RnSplice` which errors on the following program
with nested brackets.
```
prog = [| [| True |] |]
T.hs:4:11: error:
• Template Haskell brackets cannot be nested (without intervening splices)
• In the Template Haskell quotation [| True |]
In the Template Haskell
Simon Peyton Jones via ghc-devs writes:
>> Alright, I believe I have found the issue: you are a member of
>> the GHC group and GitLab's default notification behavior is that
>> you will receive notifications for all events of repositories in
>> groups to which you belong.
>
> OK thanks, that's
Matthew Pickering writes:
> There is a check in `RnSplice` which errors on the following program
> with nested brackets.
>
It might be good to explicitly include Geoff Mainland in this thread.
I'm not sure he'll see it otherwise.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
I think Geoff was primarily concerned with typed Template Haskell, not the
untyped variety.
I, too, have wondered if there was a technical reason behind this restriction,
or if merely it was assumed that nested brackets were not worthwhile.
One question: how would staging work between nesting l
Hi Ben,
The pipeline for a recent patch
(https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:
HC [stage 1] compiler/stage2/build/TcForeign.o
HC [stage 1] compiler/stage2/build/TcRules.o
/tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device)
compiler/ghc.mk:445: recipe
Richard Eisenberg writes:
> Hi Ben,
>
> The pipeline for a recent patch
> (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:
>
> HC [stage 1] compiler/stage2/build/TcForeign.o
> HC [stage 1] compiler/stage2/build/TcRules.o
> /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space l
Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got
off the ground.
> On Jan 24, 2019, at 1:21 PM, Ben Gamari wrote:
>
> Richard Eisenberg writes:
>
>> Hi Ben,
>>
>> The pipeline for a recent patch
>> (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:
>>
>> H
A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807
The failures are just some output changes. I could delicately use the log to
extract the changes and commit them, but it would be better to have direct
access to, say, the *.run.stderr files and then commit those. Is this
Richard Eisenberg writes:
> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got
> off the ground.
>
It is possible that you pushed a rebase? This error generally means that
the commit is no longer accessible which may happen when you push a
rebase.
I believe I cited the
Richard Eisenberg writes:
> A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807
>
> The failures are just some output changes. I could delicately use the
> log to extract the changes and commit them, but it would be better to
> have direct access to, say, the *.run.stderr f
Ah, yes -- I did push a rebase. OK: good to know that this is expected behavior
after rebasing (makes sense).
Thanks,
Richard
> On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote:
>
> Richard Eisenberg writes:
>
>> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got
>> o
| Ah, yes -- I did push a rebase. OK: good to know that this is expected
| behavior after rebasing (makes sense).
Does not make sense (yet) to me.
Can someone explain (and perhaps document) the workflow here?
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Richard
| Eisenberg
Rebase is more or less stashing and removing all local commits, upgrading
the underlying branch to current, then re-applying the local commits. This
changes the commit hashes for any re-applied commit that lands on a change
to the underlying branch, meaning that old commit hashes can be invalid
aft
Um, also this seems to have jumped threads; the subject of this message was
a different issue, about disk space. Is that part of the confusion?
On Thu, Jan 24, 2019 at 5:53 PM Brandon Allbery wrote:
> Rebase is more or less stashing and removing all local commits, upgrading
> the underlying bran
Dear GHC developers,
Summary: You should try to use Hadrian as the GHC build system, because it will
(hopefully!) become the default around GHC 8.8.
What is Hadrian and how can I try it?
=
Hadrian is a new build system for GHC written in Haskell. It lives in
As suggested, I'm trying out Hadrian. I have a few questions.
- After building GHC the first time, I often go into the /ghc directory and
then do `make 2` to build just the stage-2 compiler. Is that now the same as
`build --freeze1`? It would seem not (I haven't tested), because running `make
In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do
this with devel2, and I'd prefer Hadrian didn't, too.
Maybe I'm not really on the devel2 flavor?
> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg wrote:
>
> As suggested, I'm trying out Hadrian. I have a few questions
19 matches
Mail list logo