I apologize. I did plan on working on this but it's taken a back seat
for a while. I would still recommend shying away from a standalone
UI. You will end up making a lot of requests (and possibly running
into Github throttles) if you want detailed PR information for all of
the PRs. To work
Ah. Sorry, my mistake! there's a separate `ExecNonNull()` method!
On Tue, Jun 29, 2021 at 12:00 PM Antoine Pitrou wrote:
>
> Le 29/06/2021 à 17:58, Niranda Perera a écrit :
> > So, FWIU, in vector selection, the output array would always have a
> > non-null validity buffer, isn't it?
>
> Why?
Le 29/06/2021 à 17:58, Niranda Perera a écrit :
So, FWIU, in vector selection, the output array would always have a
non-null validity buffer, isn't it?
Why?
On Tue, Jun 29, 2021 at 11:54 AM Antoine Pitrou wrote:
Le 29/06/2021 à 17:49, Niranda Perera a écrit :
Hi all,
I'm looking
Le 29/06/2021 à 15:25, Wes McKinney a écrit :
On Tue, Jun 29, 2021 at 3:10 PM Andrew Lamb wrote:
The thing that would make me more efficient reviewing PRs is figuring out
which one of the open reviews are ready for additional feedback.
Yes, I think this would be the single most
So, FWIU, in vector selection, the output array would always have a
non-null validity buffer, isn't it?
On Tue, Jun 29, 2021 at 11:54 AM Antoine Pitrou wrote:
>
>
> Le 29/06/2021 à 17:49, Niranda Perera a écrit :
> > Hi all,
> >
> > I'm looking into this now, and I feel like there's a potential
Le 29/06/2021 à 17:49, Niranda Perera a écrit :
Hi all,
I'm looking into this now, and I feel like there's a potential memory
corruption at the very end of the out_data_ array.
algo:
bool advance = BitUtil::GetBit(filter_data_, filter_offset_ + in_position);
BitUtil::SetBitTo(out_is_valid_,
Hi all,
I'm looking into this now, and I feel like there's a potential memory
corruption at the very end of the out_data_ array.
algo:
bool advance = BitUtil::GetBit(filter_data_, filter_offset_ + in_position);
BitUtil::SetBitTo(out_is_valid_, out_offset_ + out_position_, advance);
I review a decent number of PRs for Apache Beam, and I've built some of my
own tooling to help keep track of open PRs. I wrote a script that pulls
metadata about all relevant PRs and uses some heuristics to categorize them
into:
- incoming review
- outgoing review
- "CC'd" - where I've been
I just had a quick chat over the ASF's slack with Daniel Gruno from the
infra team and they are rolling out the "triage role" [1] for
non-committers, which AFAIK offers useful tools in this context:
* add/remove labels
* assign reviewees
* mark duplicates
* close, open and assign to issues and
On Tue, Jun 29, 2021 at 3:10 PM Andrew Lamb wrote:
>
> The thing that would make me more efficient reviewing PRs is figuring out
> which one of the open reviews are ready for additional feedback.
Yes, I think this would be the single most significant quality-of-life
improvement for reviewers.
>
The thing that would make me more efficient reviewing PRs is figuring out
which one of the open reviews are ready for additional feedback.
I think the idea of a webapp or something that shows active reviews would
be helpful (though I get most of that from appropriate email filters).
What about a
+1 (binding)
On Mon, Jun 28, 2021 at 10:57 PM Neal Richardson
wrote:
>
> +1
>
> On Mon, Jun 28, 2021 at 1:29 PM Andrew Lamb wrote:
>
> > +1
> >
> > On Mon, Jun 28, 2021 at 1:13 PM QP Hou wrote:
> >
> > > +1 (non binding)
> > >
> > > Really exciting stuff, amazing work Jorge.
> > >
> > > On
hi folks,
I've noted that the volume of PRs for Arrow has been steadily
increasing (and will likely continue to increase), and while I've
personally had less time for development / maintenance / code reviews
over the last year, I would like to have a discussion about what we
could do to improve
13 matches
Mail list logo
