Repository navigation
stdweb usage #123
Description
Related to #17
I have the following deps for my WASM project (it uses easy_reader to read random lines from a text file).
stdweb = "0.4.20"
getopts = "0.2"
rand = {version = "0.7", features = ['stdweb']}
easy_reader = "0.5.0"
yew = { path = "../.." }
I think the line which required the stdweb feature was reader.random_line() but I am not sure if that will work with rand 0.8 and it says that I should change the getrandom crate instead but how can I verify that it works and will it work today already if I tried to remove the rand 0.7 dependency and use getrandom instead?
What I am compiling to WASM is the following:
let mut c = Cursor::new(Vec::new());
let str42 = include_str!("spook.lines").as_bytes();
// // Write into the "file" and seek to the beginning
c.write_all(str42).unwrap();
c.seek(SeekFrom::Start(0)).unwrap();
let mut reader = EasyReader::new(c).unwrap();
let _res = reader.build_index();
let tmpspooks = reader.random_line().unwrap().unwrap()...
I read that the way I do it might be removed from rand 0.8 if I understand correctly.
"stdweb implies getrandom/stdweb to enable getrandom support on wasm32-unknown-unknown (will be removed in rand 0.8; activate via getrandom crate instead)
wasm-bindgen implies getrandom/wasm-bindgen to enable getrandom support on wasm32-unknown-unknown (will be removed in rand 0.8; activate via getrandom crate instead)"
Activity
josephlr commentedon Jan 6, 2020
This is (probably) going to be addressed in #109
Depending on timing (and dev availability)
getrandom 0.2will come out beforerand 0.8. In that case, if you're usinggetrandomorrandon wasm/stdweb, you will have to set a Custom RNG. The setup should seem familiar if you've ever used a Custom Allocator.In practice, you would have the following
Cargo.tomldependencies:You would also need to have the following code in your crate/binary (to prevent linking issues):
We will document all of this as part of
getrandom 0.2and the transition doc orrand 0.8.dhardy commentedon Jan 7, 2020
Probably, but I think it doesn't matter? Rand 0.8 will then depend on
getrandom0.2 and must document this, while 0.7 will continue to depend on 0.1.If
getrandom0.1 gets a shim over 0.2 then the feature flags can opt-in tostdweb_getrandometc. (only an issue if bothstdwebandwasm-bindgenfeatures are used); if not, then both will exist side-by-side.Summary: no loss of functionality, just a different interface.
(I think there's no reason we can't close this?)