Possibility of supporting no_std?

[mb64]

I was wondering if it would be possible for this library to support a #![no_std] environment. Because it's mostly conversion logic, I think a lot of it could be useful in embedded situations when it's necessary to e.g. write colors to a framebuffer, or control an RGB LED, or something like that.

My specific use case is in a project I'm working on with bare-metal raspberry pi development, where you can get a 24-bit color depth framebuffer from the GPU. I would love to just use Pixel::from_raw_slice_mut as shown in the docs, but I was forced to roll my own struct Pixel(u8, u8, u8) instead.

If it's simple enough, I'd be willing to try to implement this myself with some help. (I don't know enough about colors or about the Pixel-deriving mechanism to do anything very complicated, though.)

Thanks!

[Ogeon]

Absolutely! And if it's an opt-in feature I suppose it can be released as a patch to 0.4. I think only a couple of things actually require std, and those should not be essential. The only thing I would imagine that could make it hard is if any dependencies doesn't work without it. If you want to give it a try, I would suggest that you branch from the 0.4.0 release label and see if it can be done in a backwards compatible way (disabling incompatible parts with a cargo feature is fine). Feel free to ask if anything is unclear, and it's fine to open a work in progress pull request. Den fre 22 juni 2018 17:57Mark Barbone <notifications@github.com> skrev:

…

I was wondering if it would be possible for this library to support a #![no_std] environment. Because it's mostly conversion logic, I think a lot of it could be useful in embedded situations when it's necessary to e.g. write colors to a framebuffer, or control an RGB LED, or something like that. My specific use case is in a project I'm working on with bare-metal raspberry pi development, where you can get a 24-bit color depth framebuffer from the GPU. I would love to just use Pixel::from_raw_slice_mut as shown in the docs <https://docs.rs/palette/0.4.0/palette/#1-decoding>, but I was forced to roll my own struct Pixel(u8, u8, u8) instead. If it's simple enough, I'd be willing to try to implement this myself with some help. (I don't know enough about colors or about the Pixel-deriving mechanism to do anything very complicated, though.) Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#108>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANvzfTM3jgLQSUSme9gdFp85mu5Vuizks5t_RPlgaJpZM4U0CsU> .

[Ogeon]

I have just pushed a 0.4 branch for non-breaking things.

[mb64]

I have a mostly-working prototype branch.
It compiles both with and without the standard library, based on whether the on-by-default std feature is enabled.

• In general, std could just be replaced by core without repercussions
• Gradients had to be disabled without std; its backbone is Vec, and making it work without std would require probably a complete rewrite and many breaking changes.
• There are many uses of floating point operations like powf, sin, etc. that aren't available with no_std, so I made a workaround wrapper module to num_traits::Float that has a custom-made trait under no_std that requires users to link in their own implementations

I didn't want to open a PR because it's horribly incomplete (e.g. the tests don't even work yet without std, and there's a weird thing with derived Pixel giving lots of warnings it didn't used to) and the design decisions around FP operations are really arbitrary.

I'd appreciate any comments!

[Ogeon]

Awesome! I will take a closer look later, but it's nice to see that you have made progress! Too bad it's not as straight forward as I thought.

Gradients had to be disabled without std; its backbone is Vec, and making it work without std would require probably a complete rewrite and many breaking changes.

That was expected. I'm fine with disabling them completely for now, in no_std mode.

There are many uses of floating point operations like powf, sin, etc. that aren't available with no_std, [...]

I didn't know that... Annoying, but I see why it's necessary. I did a bit of research and it looks like there are some attempts to writing pure Rust replacements for libm. None of the alternatives I found stood out as optimal, but mish looks like it has a lot of features (although unoptimized). I'm not sure what would be the best thing to do, but it doesn't feel great to require external functions to exist.

and there's a weird thing with derived Pixel giving lots of warnings it didn't used to

That sounds weird. It didn't look like you did a lot of changes there, but maybe the generated code need to be tweaked more. Hard to say without seeing the warnings.

[mb64]

Thanks for the pointer to mish! I changed it to now use functions from both mish and m.

What would be optimal would be to only have those crates as dependencies under no_std, but Cargo doesn't support that.

Is adding a dependency (even if it's not used) OK for a patch release, or is it a breaking change?

[Ogeon]

It's not breaking if it doesn't replace a public dependency (any dependency items that are exported from this library), but I realized that we have entered breaking territory anyway. The fact that default_features = false removes a feature that was always on before is quite breaking. I do still think having an std feature is nice, so let's not worry about that and aim for version 0.5.0 instead.

As for always including them, they seem small enough to not be a burden, but it's icky. I'm also not sure m really works for f64, since a lot (all?) of those functions are unimplemented!() in the repo. It's very tempting to just copy-paste functions from here and there and keep a private math module until something proper pops up (there's also the unreleased math.rs). May be just as good/bad if none of them are maintained, accurate or performant anyway.

Yet another alternative is to hook in the libm bindings on linux, but that's a bit niche and will add C dependencies.

[mb64]

Here's my idea for this, let me know what you think.

From a user's perspective:

• If they're using the standard library, they're all set! No math dependencies are pulled in, and no Cargo features need tweaking.
• If they're not, then they can set default-features = false. (The named-from-str requires std because of phf, anyway.) They also have to deal with floating point operations, however:
  • Either enable the soft-float feature, pulling in math libraries;
  • Or supply them themselves with extern "C" declarations. This is useful if their platform has hard-float capabilities and they want to write a (presumably faster) asm!() implementation or something.

Some more notes about this: It should be noted that the soft-float feature is a best-effort implementation, not guarunteeing exactness (there are disclaimers to this effect in most of the math libraries out there). I also think that supplying floating-point routines via extern "C" might benefit from being semver-exempt, in case new math is necessary in a point releease.

[Ogeon]

That sounds like a good plan to get it all going! It can always be improved if a better option appears. It would be nice if you could add a section in the readme that explains why it's not trivial and give an example or at least some pointers to how to get it working without soft-float. I guess that would also match your own use case, right?