You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey there, cool project! I am interested in using vdb-rs to create a WASM loader for NanoVDB and learning Rust and VDB in more depth along the way. 👍
When trying to build vdb-rs for wasm32, I see the following issue(s):
$ cargo check --target wasm32-unknown-unknown
...
error[E0277]: the trait bound `u64: bitvec::store::BitStore` is not satisfied
--> src/reader.rs:560:25
|
560 | value_mask.as_bitslice(),
| ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `bitvec::store::BitStore` is not implemented for `u64`
|
= help: the following other types implement trait `bitvec::store::BitStore`:
u16
u32
u8
usize
note: required by a bound in `bitvec::slice::BitSlice`
I found an identical issue laid out here but wondering if there are other options for resolving this rather than tearing out bitvec, which seems aggressive. With the WASM Memory64 proposal still nascent, maybe there is something else we can do to target wasm32 in the meantime?
The text was updated successfully, but these errors were encountered:
I think this should be fixed by making bitvec work on 32 bit CPUs, since it also seems to be holding back other projects. Maybe they can live with something slightly less optimal for the sake of compatibility?
I'm not super interested in removing bitvec from this crate since I expect it to be a relatively sizable change.
Hey there, cool project! I am interested in using vdb-rs to create a WASM loader for NanoVDB and learning Rust and VDB in more depth along the way. 👍
When trying to build vdb-rs for wasm32, I see the following issue(s):
I believe this is due to some Rust attributes in bitvec which conditionally compile u64 code based on the target:
https://github.com/ferrilab/bitvec/blob/main/src/store.rs#L194
I found an identical issue laid out here but wondering if there are other options for resolving this rather than tearing out bitvec, which seems aggressive. With the WASM Memory64 proposal still nascent, maybe there is something else we can do to target wasm32 in the meantime?
The text was updated successfully, but these errors were encountered: