Support no_std use cases by using alloc #223
Comments
CryZe
added
enhancement
|
It seems that std::io is causing massive problems, where all our parsing, saving, serializing and co. is just not within the bounds of core and alloc. It easily could be as there barely is a reason you can't do IO without an operating system, but it's currently std only due to OS specific error codes. There is a fork called core-io, but that's going to be a ton of PRs. However there is the possibility of simply not doing any parsing, saving and serializing on no_std until then. Other problems include HashMap, Hotkeys, timing and paths, but all of these can easily be replaced (BTreeMap, mocked Hotkeys, timing handler, and a wrapper around String / &str). Images are probably also going to be problematic, but other than for rendering, image shrinking and parsing, we don't actually need to interpret them. |
|
Speaking in terms of a no_std implementation, I see no real reason to have file IO directly. At most I could see implementing support for Parsing and Serializing but leave it to the developer implementing the no_std library to handle any IO needs. This would require a custom built BufReader, BufRead, Seek (possibly others) implementations which might be outside the scope of this crate though. Having livesplit-core omit this functionality until that can be safely, and correctly, implemented seems like a viable path to go down for now. |
|
Well yeah it wouldn't be File IO, it would just be the IO traits, such as Read, Write, Seek, BufRead that we can't use as they are in std only. And all our dependencies use them too, so that's a pain to fix in the ecosystem without no clear solution other than possibly using the fork, but that's super hacky too. |
|
All required crates are released now, so we can merge basic support in. |
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
This implements initial support for no_std. Modules such as parsing, saving and rendering are disabled and timing has to be manually provided by registering a global handler. The rendering module is on its way to no_std support as well, but not all Pull Requests to the necessary dependencies are done yet. See LiveSplit#223 for more information.
|
So a ton changed in our renderer recently and we have fairly different dependencies now. rusttype is gone, lyon is gone and instead we have ttf-parser, tiny-skia and rustybuzz as dependencies now. ttf-parser is already no_std compatible, rustybuzz turned out to be trivial, so I just opened a PR. I'll have to look into tiny-skia as well, but I believe we can probably close this soon. |
|
This is blocked on proper optional feature propagation support in cargo, which is reasonably close to stabilizing. |
We long term want to support compilation of livesplit-core with just core + alloc. You'd provide your own time source as some global handler but other than that everything should mostly just work as we already see with wasm32-unknown-unknown. However most crates that we depend on probably don't support this yet, so that's probably going to be a lot of Pull Requests.
Update
All the crates we need are sufficiently patched on forked branches. We just need to do a bunch of PRs now. Here's the super fancy results, with LiveSplit One being rendered within the world of Wind Waker:
https://twitter.com/CryZe107/status/1158444993549414401
Status
Basic Support
Required
Polyfilled (not required, but would be good to get rid of the polyfill)
Optional
Rendering
lyon - Needs a PR: https://github.com/CryZe/lyon/tree/no-stddepends on euclidsid - Released as 0.6.1, PR is merged Implement Support for no_std nical/sid#2rusttype - Released as 0.8.0, PR is merged https://gitlab.redox-os.org/redox-os/rusttype/merge_requests/145stb_truetype - Released as 0.3.0, PR is merged https://gitlab.redox-os.org/redox-os/stb_truetype-rs/merge_requests/31smallvec - Released as 0.6.11, PR is merged alloc is now stable servo/rust-smallvec#159Software Rendering
euc - Released as 0.5.0, PR is merged Implement properno_stdsupport zesterer/euc#12vek - Released as 0.10.0, PR is merged Implement Support for no_std yoanlcq/vek#41depends on num-traitsThe text was updated successfully, but these errors were encountered: