On 05/02/2019 4:49 AM, Ben Gamari wrote:> Yes, this is the cause and the import
does handle this; I just (yet
again) forgot to rerun this stage of the import. This should be fixed now.
For me, nothing seems to have changed on
https://gitlab.staging.haskell.org/ghc/ghc/issues/13497
Niklas Hambüchen writes:
> I find that commits aren't mentioned on the corresponding issues, for example
> there's no equivalent of
>
> https://ghc.haskell.org/trac/ghc/ticket/13497#comment:27
>
> on
>
> https://gitlab.staging.haskell.org/ghc/ghc/issues/13497
>
> I vaguely remember
I find that commits aren't mentioned on the corresponding issues, for example
there's no equivalent of
https://ghc.haskell.org/trac/ghc/ticket/13497#comment:27
on
https://gitlab.staging.haskell.org/ghc/ghc/issues/13497
I vaguely remember these "commit posts" being discussed before
Simon Peyton Jones via ghc-devs writes:
> Could we arrange that searching for the ticket number succeeds?
> Eg searching for 12088 fails, and 16013.
>
Yes, this is a bug [1]. I will bring it up with David.
Cheers,
- Ben
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/30974
signature.asc
There appears to be some impedance mismatches between GitLab's formatting
and Trac's formatting in certain places. For example, see the bottom of
this issue [1], which has a long, hyperlinked line with the phrase:
If you want your core to look at much like the source program as
possible then you could print `$WFoo` as just `Foo`?
The existence of wrappers is a crucial part of desugaring so perhaps
it's useful for users to see them in the output of your program if
it's intended to be educational?
Matt
On
There is this other issue though which explains that searching in the
issues view for a ticket number does fail.
https://gitlab.com/gitlab-org/gitlab-ce/issues/30974
https://gitlab.staging.haskell.org/ghc/ghc/issues?scope=all=%E2%9C%93=opened=%231234
So if you want to search for a ticket by
Thanks Ben, looks amazing.
I don't think the trac metadata boxes should always be visible. They
are unobtrusive now and tbh, I don't think I will be opening them up
much when looking at tickets.
Simon, I think if you start the query with a # then it "works". For
example, search for #12088
Could we arrange that searching for the ticket number succeeds?
Eg searching for 12088 fails, and 16013.
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
| Sent: 04 February 2019 16:07
| To: GHC developers ; glasgow-haskell-users-
| requ...@haskell.org
|
TL;DR. Have a look at this [2] test import of GHC's Trac tickets. Tell us
what issues you find.
Hello everyone,
As you likely know, we are currently in the process of consolidating
GHC's infrastructure on GitLab [1]. The last step of this process is to
migrate our tickets and wiki from
Hi,
I was trying to understand why some info tables that have no ptrs and nptrs like
GCD_CAF end up with 1 nptrs in the generated info table and found this code in
Constants.h:
/*
-
Minimum closure sizes
| is referred to by its wrapper, "$WS#". In general, I'd prefer if it Core
| always constructed the worker S# directly. It would reduce the number of
| cases I have to handle.
What do you mean by "constructed the worker directly"? How does that differ
from "call the wrapper, and then (in a
Hello,
On 04/02/2019 10:24, Tobias Dammers wrote:
The documentation already advises newcomers to only rebuild GHC itself;
I've updated it to use the symbolic stage2:exe:ghc-bin notation though
instead of the actual filename (_build/stage1/bin/ghc), assuming that
the former will work even when
On Fri, Feb 01, 2019 at 02:22:52PM -0500, Ben Gamari wrote:
> In the case of ghctags I wonder if we shouldn't just remove it. I don't
> know anyone who actually still uses it and there are better options at this
> point (e.g. I personally use hasktags when working in GHC).
Agree; even if there
14 matches
Mail list logo
