David Li
David Li
Also, linking to the C++ docs isn't applicable in all situations, they don't apply to Java for instance.
The same goes for Go. If we want to centralize things, we should think about where to do that. And then all the language docs can link there. (I think...
The Java docs link to the C++ docs - but the C++ docs don't apply to Java. The bit about allocations doesn't apply to Java at all, for instance.
Maybe we should consider a separate tutorial section then? Even if they're language-specific? (Well, 'tutorials and guides' or something…) The Flight tutorials could probably be made to work with the...
I didn't get to this today, should hopefully get to look at it this week
But those Input/OutputType instances are stored in the KernelSignature, so those references need to stay valid.
The semantics of this method in the interface are rather confusing, but I think this operation does not make sense to implement with the current design. The way it works...
Ok, thanks. In that case, it seems like we need the ability to associate the C Data reference manager with a Java allocator, and update APIs to require a BufferAllocator...
> > C Data Interface allocations need to get associated with an actual allocator, even if the allocator isn't actually doing the allocation. > > I guess this is reasonable...
C++ lets you specify local memory pools, but doesn't require it. It's like always having a static global BufferAllocator. Java is stricter about asking you to consider when and where...