A similar issue happens in terms of rendering time if you look at a giant
change set, the caching seems pretty minimal on a lot of the rendering
steps in gitlab.
On Fri, Jan 11, 2019 at 11:05 AM Richard Eisenberg
wrote:
>
>
> On Jan 11, 2019, at 4:49 AM, Simon Peyton Jones
> wrote:
>
> When I
> On Jan 11, 2019, at 4:49 AM, Simon Peyton Jones wrote:
>
> When I try that, it starts by displaying the code from the file. No rotating
> circles or anything. But if I wait ten seconds, suddenly the comments appear.
> So:
> rendering seems terribly slow
> there is no indication that it
he
recent changes.
How sad!
Simon
From: Richard Eisenberg
Sent: 10 January 2019 19:05
To: Ben Gamari
Cc: Simon Peyton Jones ; Evan Laforge
; ghc-devs
Subject: Re: Reviews
While we're whinging:
- I'm looking at the Discussion page for an MR
(https://gitlab.haskell.org/ghc/ghc/merge_r
bars that
flash occasionally. Then it renders.
Simon
From: Richard Eisenberg
Sent: 10 January 2019 19:05
To: Ben Gamari
Cc: Simon Peyton Jones ; Evan Laforge
; ghc-devs
Subject: Re: Reviews
While we're whinging:
- I'm looking at the Discussion page for an MR
(https://gitlab.has
While we're whinging:
- I'm looking at the Discussion page for an MR
(https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904) and I see a
comment Simon made, beginning with "No, I am not!". I wanted a bit more
context. So I click on the filename above the Discussion and am warped to
Simon Peyton Jones writes:
> | Another issue is that apparently GitLab still sends one email per comment
> | instead of one comment per batch. This will evidently be fixed in GitLab
> | 11.6 [1].
>
> yes that is TERRIBLE. When does 11.6 land?
>
It is the next release. I will poke our contact
i
| Sent: 10 January 2019 17:46
| To: Simon Peyton Jones ; Evan Laforge
|
| Cc: ghc-devs
| Subject: RE: Reviews
|
| Simon Peyton Jones via ghc-devs writes:
|
| > | > When submitting a review, I often want to add an overall comment,
| > | not related to a particular line of
Simon Peyton Jones via ghc-devs writes:
> | > When submitting a review, I often want to add an overall comment, not
> | related to a particular line of code? How do I do that?
> |
> | I do that by going back to the "Discussion" tab and adding something at the
> | bottom.
>
> But alas
To return to the original question, how do I add an overall comment for a
(multi-comment) review?
Simon
| -Original Message-
| From: Ben Gamari
| Sent: 10 January 2019 17:41
| To: Evan Laforge ; Simon Peyton Jones
|
| Cc: ghc-devs
| Subject: Re: Reviews
|
| Evan Laforge
eally have a concept of a
> review, it's just big pile of disconnected comments... or rather,
> they're just all connected to the MR.
This isn't quite true. Transactional reviews were added in GitLab 11.4
[1]. That being said, the connection between the comments in a review is
a bit looser than it was
On Tue, Jan 8, 2019 at 8:54 PM Simon Peyton Jones wrote:
> | > When submitting a review, I often want to add an overall comment, not
> | related to a particular line of code? How do I do that?
> |
> | I do that by going back to the "Discussion" tab and adding something at the
> | bottom.
>
view, landing as a single email.
It becomes a separate, disconnected comment.
Simon
| -Original Message-
| From: Evan Laforge
| Sent: 08 January 2019 12:48
| To: Simon Peyton Jones
| Cc: ghc-devs
| Subject: Re: Reviews
|
| On Tue, Jan 8, 2019 at 6:01 PM Simon Peyton Jones via gh
On Tue, Jan 8, 2019 at 6:01 PM Simon Peyton Jones via ghc-devs
wrote:
>
> When reviewing a MR, I sometimes want to look at (and even add comments to)
> code that isn’t displayed in the MR window. With Phab there was a “show 20
> more lines” link, and even “show the whole file”. How do I do
When reviewing a MR, I sometimes want to look at (and even add comments to)
code that isn't displayed in the MR window. With Phab there was a "show 20
more lines" link, and even "show the whole file". How do I do that in GitLab?
When submitting a review, I often want to add an overall
I'm on Firefox.
It doesn't matter all that much, really. I was hoping that a review was its own
thing. But GitLab doesn't do that: a review is just a set of comments all
delivered at the same time. Now that I've posted my review, my comments have
become 49 separate "discussions". Oof.
Richard
Richard Eisenberg writes:
> PSA: When reviewing an MR on GitLab, every comment has two buttons:
> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine
> at least), does option (2), even though option (1) is bold and green.
> This is not what I wanted. (By the way, "comments"
PSA: When reviewing an MR on GitLab, every comment has two buttons: (1) add to
review, and (2) add comment now. Cmd+Enter (on my machine at least), does
option (2), even though option (1) is bold and green. This is not what I
wanted. (By the way, "comments" actually open these things called
> I assume you worked this out? I think you can just "request review" in
> the actions menu at the bottom of the page.
This seems to work, although it's still one extra step compared to the
previous version.
Ömer
2018-03-30 21:04 GMT+03:00 Ben Gamari :
> Ömer Sinan Ağacan
h the recent Phabricator update is that we can no
>> longer
>> submit a patch for reviews until the build bot successfully builds it. I
>> can't
>> even ping people in the comment section until the patch builds. It says:
>>
>>> These changes have not finished build
Ömer Sinan Ağacan <omeraga...@gmail.com> writes:
> Hi,
>
> One of the changes with the recent Phabricator update is that we can no longer
> submit a patch for reviews until the build bot successfully builds it. I can't
> even ping people in the comment section until the
I just got Simon's approval and I'm going to push it tomorrow (need to
add some more documentation) if no one asks for more things.
2016-07-09 12:55 GMT+00:00 Ömer Sinan Ağacan <omeraga...@gmail.com>:
> Hi all,
>
> I'm almost done with the unboxed sums patch and I'd like to g
Hi all,
I'm almost done with the unboxed sums patch and I'd like to get some reviews at
this point.
https://phabricator.haskell.org/D2259
Two key files in the patch are UnariseStg.hs and RepType.hs.
For the example programs see files in testsuite/tests/unboxedsums/
In addition to any comments
Hi *,
Quick notice: I spent some time hacking to get Phabricator to build
code reviews you publish against the GHC repository. It luckily was
not that hard to do so - hooray!
Go here for an example:
https://phabricator.haskell.org/D64
Look at the top set of information, and find 'Build Status
StandaloneDeriving always struck me as a really heavyweight way to write those
instances. EmptyDataDecls in many ways should have been in all along while
StandaloneDeriving is a rather peculiar ghc'ism.
I'm personally in favor of just making EmptyDataDecls work better here.
-Edward
On Aug 14,
On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
My proposal below doesn't really give different behavior for EmptyDataDecls
in the two scenarios… the available constructs are the same under either H98
or H2010. It's just that the distance from the spec is
Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if
EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to make
sure that we're conforming to the Haskell standard. But, if the user has
specified EmptyDataDecls, then we're not bound to that requirement
Technically, EmptyDataDecls is part of Haskell 2010, so it is standard
these days (and H2010 is our default in GHC.)
As far as I know, the 2010 standard doesn't address this point about
deriving for empty data decls, but I agree with your reasoning here.
It's more consistent to have it apply to
According to the Haskell 2010 report
(http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
a datatype with no constructors cannot derive any instances.
But, instead of creating a new extension for this feature, what about just
co-opting EmptyDataDecls? More
On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
According to the Haskell 2010 report
(http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
a datatype with no constructors cannot derive any instances.
You're quite right! I should have
True
it :: ()
ghci
Leaving GHCi.
However, if you want (==) implementation in this case to be `error
Void (==)`, I think I can also do that by first fixing the code
generated by StandaloneDeriving extension and then fixing my current
patch.
Any comments and reviews would
by StandaloneDeriving extension and then fixing my current
patch.
Any comments and reviews would be appreciated!
---
Ömer Sinan Ağacan
http://osa1.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
31 matches
Mail list logo