That makes 3 binding +1 votes and 3 non-binding +1 votes. The vote passes
and we'll add this to the spec.
Thanks everyone! I'll get the PR out of draft and merge once approved.
--Matt
On Fri, Jun 2, 2023, 3:57 PM Dewey Dunnington
wrote:
> I've already given my vote here, but wanted to share a
I've already given my vote here, but wanted to share a
proof-of-concept C implementation (== copy an arbitrary valid
ArrowArray to given a suitable device implementation) of the proposed
spec that includes Apple Metal [1] and could include CUDA as well (I
did Metal first since Matt already worked u
+1 (non-binding).
Thanks very much Matt for all the work you did here to solicit input from
other stakeholder communities.
On Mon, May 22, 2023 at 12:02 PM Matt Topol wrote:
> Hello,
>
> Now that there's a rough consensus and a toy example POC[1], I would like
> to propose an official enhanceme
+1 (binding). The current state of the draft seems quite good, including
the prose spec. Once third-party implementations appear (both producer
and consumer), we'll be able to remove the experimental tag, confident
that the spec is solid and useful.
Regards
Antoine.
Le 22/05/2023 à 18:02
+1 (non-binding)! Reading the discussion on that PR is illuminating as
to how difficult this can be...thank you!
On Fri, May 26, 2023 at 3:54 PM Benjamin Kietzman wrote:
>
> +1, thanks for all your work on this!
>
> On Fri, May 26, 2023 at 11:09 AM Matt Topol wrote:
>
> > That makes 1 binding an
+1, thanks for all your work on this!
On Fri, May 26, 2023 at 11:09 AM Matt Topol wrote:
> That makes 1 binding and one non-binding +1, as 3 binding votes are
> necessary I'm sending this to hopefully request more eyes here and get some
> more votes.
>
> Thanks all!
>
> On Thu, May 25, 2023 at 1
That makes 1 binding and one non-binding +1, as 3 binding votes are
necessary I'm sending this to hopefully request more eyes here and get some
more votes.
Thanks all!
On Thu, May 25, 2023 at 11:38 AM Felipe Oliveira Carvalho <
felipe...@gmail.com> wrote:
> +1 for me.
>
> The C structs are clean
+1 for me.
The C structs are clean and leave good room for extension.
--
Felipe
On Thu, May 25, 2023 at 12:04 PM David Li wrote:
> +1 for me.
>
> (Heads up: on the PR, there was some discussion since the last email and
> the meaning of 'experimental' was clarified.)
>
> On Tue, May 23, 2023, a
+1 for me.
(Heads up: on the PR, there was some discussion since the last email and the
meaning of 'experimental' was clarified.)
On Tue, May 23, 2023, at 16:56, Matt Topol wrote:
> To clarify:
>
>> Depends on what we're voting on?
>
> Voting on adopting the spec and adding it (while still leavi
To clarify:
> Depends on what we're voting on?
Voting on adopting the spec and adding it (while still leaving it labeled
as "experimental" in the docs) to the format.
--Matt
On Tue, May 23, 2023 at 3:29 PM Matthew Topol
wrote:
> @Antoine: I've updated the PR with a prose description of the C
@Antoine: I've updated the PR with a prose description of the C Device Data
interface. Sorry for the lack of that in the first place.
--Matt
On Tue, May 23, 2023 at 10:34 AM Antoine Pitrou wrote:
>
> Also, I forgot to say, but thanks a lot for doing this! We can hope this
> will drastically imp
Also, I forgot to say, but thanks a lot for doing this! We can hope this
will drastically improve interoperability between non-CPU data
frameworks and libraries.
Regards
Antoine.
Le 23/05/2023 à 16:32, Antoine Pitrou a écrit :
Depends on what we're voting on?
The C declarations seem fi
Depends on what we're voting on?
The C declarations seem fine to me (I'm a bit lukewarm on the reserved
bits, but I understand the motivation), however I've posted comments as
to how to document the interface. The current PR entirely lacks a prose
description of the C Device Data Interface.
13 matches
Mail list logo
