Open drauschenbach opened 15 hours ago
I think there needs to be a proper assessment of APIs that currently use usize and would need to switch to u64, e.g. null counts, ArrowNativeType, etc... This would be a fairly disruptive and involved breaking change and so would require getting a group together to properly action this.
There are also a lot of APIs that assume performant u64, e.g. bitmap processing, I'm not sure if these would need to be changed.
Unfortunately I do not have the capacity to help drive this and am unlikely to for the foreseeable future
This discussion aims to outline what would be required to add comprehensive support for the arm32v7 hardware architecture. Because it was in the top 3 best-selling computers of all time, and edge hardware is likely to remain in service for quite some time, and because edge is a particularly strong use case for Arrow.
And secondarily, consider how that might also benefit independent efforts to support WASM32.
Here are some of my own ideas:
#[cfg(target_pointer_width = "64")]
around the test function). The POC at #6678 outlines most of these.DecimalType
,Decimal128Type
andDecimal256Type
which do not work on armhf.Time64MicrosecondType
andTime64NanosecondType
, which do not work on armhf.