While we're on the topic, is there any plan to get rid of all those
panics? AFAICS they are entirely unnecessary: we should just use an
empty datatype for unused constructor extension points, then we can
eliminate it to get whatever we like. See #15247.
Adam
On 12/02/2019 15:40, Shayan Najd
Yes, on a quiet day she will idly wait for the opportunity to merge
two MRs rather than try and merge just one.
I don't think this is a bad default as her CI cycle has proved to be
quite long so only 2-3 batches happen per day at most.
Matt
On Tue, Feb 12, 2019 at 6:36 PM Alan & Kim Zimmerman
> Every 30 minutes whilst idle she will try to find new MRs to batch
> together. If she finds at least two MRs to batch together then she
> creates a batch as a new merge request. A batch is the series of MRs
> rebased on top of each other from oldest to newest.
Does this mean that on a quiet
Yes there are two others I use frequently.
/approve - Approves a Merge request
/assign - Assign a user
and I imagine I will use /label and /relabel frequently when we have labels.
It's also useful to know that the ! autocomplete for merge requests
can be filtered by name of MR. The user
> On Feb 12, 2019, at 10:51 AM, Matthew Pickering
> wrote:
>
> This can be quickly toggled on/off by typing the /wip quick command in
> a comment.
This is an interesting aside. I understand this to mean: If I make a comment
(the same place that I would write a comment for humans) that
WIP merge requests have "WIP:" at the front of the title.
I have been marking MRs as WIP is they are not ready to merge to try
to keep track of things that need to be added to the merge queue or
not.
This can be quickly toggled on/off by typing the /wip quick command in
a comment.
Cheers,
Matt
> Someone could easily call rnPatAndThen when they should call rnLPatAndThen.
> This would cause a panic.
With Solution A, there shouldn't be two functions `rnLPatAndThen` and
`rnPatAndThen` anyways. There should be only `rnPatAndThen` with an
extra case for the wrapper node.
> There's also the
That's true, but how would it play out in practice? For example, take a look at
RnPat. There is a rnLPatAndThen which uses wrapSrcSpanCps to extract the
location and then call rnPatAndThen. rnPatAndThen, in turn, just panics if it
sees the extension point, because that's an unexpected
> [Richard:] I disagree here. If we add locations to a node twice, then we'll
> have to use dL twice to find the underlying constructor. This is another case
> there the type system offers the producer flexibility but hamstrings the
> consumer.
Depends on the semantics of `dL`: currently (for
> My problem, though, is that this is just a convention -- no one checks it. It
> would be easy to forget.
I am not sure if I understand: shouldn't the totality checker warn if
there is no pattern for the wrapper constructor (hence enforce the
convention)?
On Tue, 12 Feb 2019 at 15:19, Richard
> On Feb 12, 2019, at 5:19 AM, Shayan Najd wrote:
>
> About the new code, the convention is straightforward: anytime you
> destruct an AST node, assume a wrapper node inside (add an extra
> case), or use the smart constructors/pattern synonyms.
Aha! This, I did not know. So, you're saying
> One way to think of it is this: we can now put SrcSpans where they make
> sense, rather than everywhere.
I claim an SrcSpan makes sense everywhere, so this is not a useful
distinction. Think about it as code provenance, an AST node always
comes from somewhere: a user-written .hs file, a GHCi
One way to think of it is this: we can now put SrcSpans where they make sense,
rather than everywhere. We can still say (Located t) in places where we want
to guarantee a SrcSpan.
Yes, this lets us add more than one; that's redundant but not harmful.
Simon
| -Original Message-
|
Hi Richard,
> [Richard:]
> It seems to me, though, that this move makes us *less typed*.
> [and]
> However, worse, we might forget to *add* a location when downstream functions
> expect one.
We had a more sophisticated version of TTG that could support the
ping-pong style (and hence typed
I just did this now, it was quite disconcerting that my code continued
to compile after applying `cL loc` to the return value of one of my
functions.
On Sat, Feb 9, 2019 at 5:40 PM Vladislav Zavialov wrote:
>
> I wholly share this concern, which is why I commented on the Phab diff:
>
> > Does
Hi all,
I think I have finally managed to stablise the merge bot (Marge).
If you have a patch ready to merge then
1. Make sure that CI shows as passing
2. Make sure it has been approved by at least one person
3. Make sure it is not marked as WIP
Once these three conditions are met, assign the
16 matches
Mail list logo
