I agree that this should be a separate project, so that this can be used by
other databases written in rust, not only datafusion. Let's start with an
implementation by binding with gandiva, and build pure rust implementation
later.
On Sat, May 11, 2019 at 10:28 PM Andy Grove wrote:
> Hi Renjie,
Hi Renjie,
I have not started on this but I would be interested in helping you with
it.
At a high level I think there are two main parts to this work:
1. Translating DataFusion expressions to Gandiva protobuf
2. Implementing the code to make the native C call to Gandiva
I could help with #1 pre
Hi:
@Andy Grove Are you developing this? I'm interested
in this and want to join development.
On Tue, Jan 8, 2019 at 3:18 PM Praveen Kumar wrote:
> Agree with Wes, the protobuf based interface should be the language neutral
> way to build expressions with Gandiva.
>
> On Mon, Jan 7, 2019 at 8:3
Agree with Wes, the protobuf based interface should be the language neutral
way to build expressions with Gandiva.
On Mon, Jan 7, 2019 at 8:30 PM Andy Grove wrote:
> This makes sense to me know that I understand a little more about Gandiva.
> This also fits well with my proposal to donate DataFu
This makes sense to me know that I understand a little more about Gandiva.
This also fits well with my proposal to donate DataFusion in the other
thread. DataFusion can manage the overall logical query plan in Rust and
potentially delegate some subset of expression evaluation to Gandiva via
protobu
Gandiva supports a Protobuf-based interface -- this is how Java
interacts with it via JNI. Rust could do the same -- that would
probably be easier than wrapping the C++ class structure. It would
also help drive new feature requirements in the serialized
projection/filter expression trees
- Wes
On
I'm not sure, that a binding is a good idea. Both Arrow and Parquet
already have their own rust implementation, and a interfacing with
cpp isn't as easy and straightforward than it is with C. Otherwise
We could simply just maintain bindings for all of the cpp libraries,
rather than of having a hybr
I have a patch up for Gandiva on Windows:
https://github.com/apache/arrow/pull/3295
It would be great to have the subgraph compiler available in Rust. You
should decide whether you want to require a C++ library that depends
on LLVM into all applications that use Rust and Arrow and need to
compute
Hey Andy,
I am very interested in this, I’m also looking into adding explicit SIMD to our
existing “array_ops”.
Maybe we can plan out what is needed on the developer wiki so that we can all
help out where we are able.
I’ve seen it mentioned here and there but what it the current state of gandi
Krisztian and I have been working together on a native Rust implementation
of Arrow and have been exploring some different approaches.
I thought it was probably time to update everyone on this mailing list and
open this up to some more opinions.
I have filed a JIRA (https://issues.apache.org/jira
Krisztián,
This is great research. I totally agree on using a Vec abstraction and
using traits over enums.
I know you have some working code already (albeit mostly just API) and I
would suggest you create a PR to get that submitted as a starting point for
us all to start contributing.
I'm excite
Hey!
I've done a little research about implementing arrow in rust and I'd like to
share
my thoughts. Please Andy correct me if I'm wrong, still hiking rust's learning
curve.
My first plan was to re-implement iron-arrow and mirror the cpp api as close as
possible, but realized that rust can prov
Just "rust" would be fine for the top-level directory, I think.
On Fri, Mar 23, 2018 at 12:09 PM, Andy Grove wrote:
> OK I would be happy with that. How should I get started? Should I just
> create a PR to add a `rust` or `rust-native` root level directory with some
> starting code? I could do th
OK I would be happy with that. How should I get started? Should I just
create a PR to add a `rust` or `rust-native` root level directory with some
starting code? I could do that this weekend.
Thanks,
Andy.
On Fri, Mar 23, 2018 at 10:04 AM, Wes McKinney wrote:
> > Wes - if we continue developin
> Wes - if we continue developing an a separate repo for now to prove
> commitment levels and get this further along does that actually make the IP
> clearance procedure harder with more individual contributors involved?
Yes, this will make things harder (since we will have to chase down
ICLA's
I probably shouldn't have used the term binding. I am primarily interested
in a native Rust implementation but it should be possible to have traits
defining the interface and two implementations - one native and one using
FFI to call C. Rust has zero overhead when calling C code typically. I need
t
Not knowing the Rust ecosystem very well, I'm interested in the
pros/cons of building and maintaining Rust bindings vs. a native Rust
implementation, or some hybrid of the two. Seems like both bindings
and native implementation could be part of the same codebase
potentially.
If we decide to import
My personal view (and I think I've seen others state this already here) is
that we should bring it into the repo sooner rather than later and work on
it there. The version is 0.1.0 so I think that sets peoples expectations
about how complete it is.
I think it is better for people to see it in the
Hi Andy/Paddy,
I also want to get involved in contributing towards rust bindings.
Request you to please add me also.
Regards,
Tarush
On Fri, 23 Mar 2018 at 8:14 PM, paddy horan wrote:
> Hi Andy,
>
> I’m looking to get involved in contributing to the Rust implementation
> also, would love to s
Hi Andy,
I’m looking to get involved in contributing to the Rust implementation also,
would love to see it in the arrow repo sooner rather than later.
Should we identify what needs to be added to iron-Arrow before it’s ready to be
donated to the Apache repo?
Thanks,
Paddy
Get Outlook for iOS
20 matches
Mail list logo
