Re: Rust IPC and Integration Testing
The author of the Rust version of FlatBuffers is now working on a public
fork and seems to be making good progress. I just wanted to send a quick
update on this since I am now back onto working on Arrow IPC in Rust (I'm
sure this is going to take quite a while though so don't want to get
anyones hopes up too much). For anyone that is interested, here is the
FlatBuffers branch: https://github.com/rw/flatbuffers/tree/2018-02--rust
On Sat, May 19, 2018 at 4:05 PM Wes McKinney <wesmckinn@xxxxxxxxx> wrote:
> Sorry to hear, it's a bit of a rough situation with Flatbuffers and
> Rust. One possibility is to build an interface to the Flatbuffers data
> via flatcc (https://github.com/dvidelabs/flatcc) -- I wonder if these
> bindings are header-only like C++ and if that makes things any easier
> for you.
> If you defined an API in Rust for reading and writing the Arrow
> metadata that does not expose any Flatbuffers-specific details, then
> once there is a production-grade Rust implementation of Flatbuffers,
> the implementation details could be swapped out without disruption.
> > my recent attempts at contacting the author have been unsuccessful
> Have you e-mailed the author directly or only pings on GitHub? Pings
> may not be making it to their inbox.
> Appreciate your efforts on this; I think we'll see a lot more work in
> data processing in Rust in the coming years.
> - Wes
> On Fri, May 18, 2018 at 9:21 AM, Andy Grove <andygrove73@xxxxxxxxx> wrote:
> > Hi,
> > Now that the refactor I've been working on has been merged, the next
> > priority for me personally with the Rust implementation is getting IPC
> > integration testing working.
> > Unfortunately the official Flatbuffers Rust version is not available yet
> > and my recent attempts at contacting the author have been unsuccessful
> so I
> > have started working with this fork of Flatbuffers which has Rust
> > https://github.com/josephDunne/flatbuffers.
> > I was able to generate code from Schema.fbs but it doesn't compile and
> > started filing issues and debugging this.
> > Working with this fork isn't ideal but I don't see what other choice I
> > have, other than just waiting for the official project to support Rust.
> > I'm interested to hear if anyone has any alternate suggestions. I know it
> > would be possible to wrap C code but I'd like to keep the Rust
> > implementation as a pure Rust project if possible.
> > Thanks,
> > Andy.