Perhaps Gandiva does not handle sliced arrays properly? This would be
worth investigating
On Mon, Jul 27, 2020 at 7:43 PM Matt Youill wrote:
>
> Managed to track down the issue (sort of).
>
> I removed a call to set_chunksize on TableBatchReader where the chunk
> size was less than the number of
The new website looks very nice. Looking around for a bit, some areas where
extra content might be helpful
A search feature in the top bar
More info, more prominence for Parquet, Gandiva, Plasma, others?
A vision and or current roadmap for the project. The analysis / computation
aspects
On Tue, Jul 28, 2020 at 8:49 AM Jorge Cardoso Leitão
wrote:
>
> Thanks for the summary,
>
> So, someone discloses a 0 day vulnerability on a dependency from arrow/js,
> and the maintainers release a new backward-compatible fix, but they do a
> major release instead (1.9.3 to 2.0.0). Since npm
That's funny after reading the comments from the 1.0 release on HN last night I
have been researching on this too. It really is the main feature users want so
we should prioritize it. Personally, I have avoided this as I remember living
without specialization (macros) but as Andy noted I
I've tried a few approaches, including the auto-ref based one [1], but no
luck so far. I'm thinking to explore std::any and downcast_ref and see if
that is more promising.
[1]:
https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md
On Tue, Jul 28, 2020 at 10:48 AM
Yes, that is my understanding too (specialization being the main blocker).
I will start experimenting with removing one of the specializations over
the next few days and see what I learn. It would be good if others want to
try this too and we can swap notes.
On Tue, Jul 28, 2020 at 11:37 AM
Thanks Andy for starting the thread. Agree that supporting stable Rust
should be one of the top priorities.
Instead of creating a new crate, I'd prefer to make the switch in-place in
the current crate if possible. A major part of the current code base, such
as compute kernels, ipc, etc., is built
After seeing more feedback on this topic recently, I've been thinking about
this some more and wanted to make a proposal for how we can start to
address this.
It seems that we do have some code today that we could relatively easily
support on stable Rust, such as the Buffer struct. What if we
Some benchmarks would be good as long as they are well-defined,
reproducible, and not misleading (or "as not misleading as possible").
For example, people are often mentioning Arrow and Parquet in the same
breath (e.g. "Arrow/Parquet" in your e-mail) when these are distinct
technologies, but
Thanks for the summary,
So, someone discloses a 0 day vulnerability on a dependency from arrow/js,
and the maintainers release a new backward-compatible fix, but they do a
major release instead (1.9.3 to 2.0.0). Since npm uses semver, we must bump
it on our package.json (i.e. ^1.9.3 to ^2.0.0).
Generally this sounds fine to me. At some point it would be good to
add 32-bit and 64-bit decimal support but this can be done in the
future.
On Tue, Jul 28, 2020 at 7:28 AM Fan Liya wrote:
>
> Hi Micah,
>
> Thanks for opening the discussion.
> I am aware of some scenarios where decimal requires
Hi Micah,
Thanks for opening the discussion.
I am aware of some scenarios where decimal requires more than 16 bytes, so
I think it would be beneficial to support this in Arrow.
Best,
Liya Fan
On Tue, Jul 28, 2020 at 11:12 AM Micah Kornfield
wrote:
> Hi Arrow Dev,
> ZetaSQL (Google's open
Arrow Build Report for Job nightly-2020-07-28-0
All tasks:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-07-28-0
Failed Tasks:
- debian-buster-arm64:
URL:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-07-28-0-travis-debian-buster-arm64
-
13 matches
Mail list logo
