Re: Reviews

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

Re: Reviews

> 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

RE: Reviews

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

RE: Reviews

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

Re: Reviews

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

RE: Reviews

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

RE: Reviews

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

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 code? How do I do that? > | > | I do that by going back to the "Discussion" tab and adding something at the > | bottom. > > But alas

RE: Reviews

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

Re: Reviews

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

Re: Reviews

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. >

RE: Reviews

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

Re: Reviews

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

Reviews

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

Re: GitLab: Cmd+Enter considered harmful on reviews

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

Re: GitLab: Cmd+Enter considered harmful on reviews

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"

GitLab: Cmd+Enter considered harmful on reviews

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

Re: Phabricator new behavior regarding submitting patches for reviews

> 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

Re: Phabricator new behavior regarding submitting patches for reviews

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

Re: Phabricator new behavior regarding submitting patches for reviews

Ö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

Re: first unboxed sums patch is ready for reviews

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

first unboxed sums patch is ready for reviews

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

Note: Phabricator can now build code reviews!

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

Re: Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]

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,

Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]

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

Re: request for reviews for my first patch -- ticket 7401

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

Re: request for reviews for my first patch -- ticket 7401

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

Re: request for reviews for my first patch -- ticket 7401

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

Re: request for reviews for my first patch -- ticket 7401

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

request for reviews for my first patch -- ticket 7401

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

Re: request for reviews for my first patch -- ticket 7401

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