No std support #110

mb64 · 2018-07-09T18:04:11Z

Adds support for using palette without the standard library, as discussed in issue #108.

Fixes #108.

One tiny question: because this would be in a future release (not 0.4.0), what version should be in the README example Cargo.toml for #![no_std]? I put 0.4, but was unsure about if it should be something different.

… hack

…and `m`

Ogeon · 2018-07-09T19:56:07Z

Excellent! I will look closer at it tomorrow (I think), but until then, leave the version as 0.4. I have a script for incrementing it automatically throughout the project when I'm preparing a release, so I will make it find that one as well.

Ogeon · 2018-07-09T20:18:35Z

Oh, and those test results are way off! I didn't think the soft floats would differ that much...

…ith "std" disabled

mb64 · 2018-07-09T23:37:29Z

I ran some tests, and mish::powf(x, 1./3.) returns NaN for x < 0.0852. However, the cbrt_f32 function seems OK. I'll push an update in a few minutes that changes it to use .cbrt().

Ogeon · 2018-07-10T20:03:32Z

Didn't know qbrt existed, but that sounds like a better choice in any case. Looks like you have made some really good progress with making the tests pass, and the code looks good as well! I'm just wondering if the float functions follow any specification, seeing that they are not just plain wrappers.

Ogeon · 2018-07-10T20:07:19Z

Maybe I should have checked your last commit... Then I would have known where most some of it came from. 😛

Ogeon · 2018-07-31T16:10:02Z

Hi! I'm just checking in to see how it's going. If you are just taking a break or on vacation, or similar, I'll leave you to enjoy that. Otherwise let me know if you are getting stuck somewhere or if anything else came in the way.

Also, I wanted to check if you have followed the recent development over at https://github.com/japaric/libm. It has gotten a ton of help during the last few weeks, so it's almost feature complete. Would be nice to only have to depend on that one library.

mb64 · 2018-07-31T18:11:15Z

Sorry I haven't been working on this for a couple weeks -- I was of town for a while, and then just didn't get back to it. There are a few things left in this:

To be able to say that it depends on std, Cargo wants a feature name for serde that's not the same name as the library. Some options could be serialize, serializable, serialize_deserialize, json_formatting, etc. (Personally, I vote for serializable.)
Now that there's an actual community effort for math on no_std, I think that libm will eventually include any x86/arm hard float implementations, making the potential need for user-provided extern "C" implementations an even more niche use-case. I think it would probably be better (less surprising to users) to just use libm all the time (when std is disabled).
Unrelated to no_std, recent nightly's have "fixed" a thing with proc macros that palette_derive was using, so now there's lots of warnings (or errors with -Dwarnings) about macro hygiene, etc.

Ogeon · 2018-07-31T18:28:31Z

Alright, no hurry. 🙂

So serde depends on std after all, or am I misunderstanding? In that case I would probably pick serializing as feature name.
Sounds good! Better to reduce the complexity now and add it back later if it turns out to be required.
Yep, see Replace the hidden module for derives with a hidden function #111. I would ideally want to fix it in a 0.4.1 release, but haven't gotten around to do it yet, as I have also been quite occupied elsewhere until about now.

Ogeon · 2018-08-01T12:58:37Z

palette/tests/convert/lab_lch.rs

@@ -7,8 +7,8 @@ fn lab_lch_green() {
    let expect_lab = lch.into_lab();
    let expect_lch = lab.into_lch();

-    assert_relative_eq!(lab, expect_lab, epsilon = 0.001);
-    assert_relative_eq!(lch, expect_lch, epsilon = 0.001);
+    assert_relative_eq!(lab, expect_lab, epsilon = 0.1);


Have you tried tightening these error margins again?

I have -- it works fine 😃 thanks to libm.
I'll push those changes in a moment.

Great! 😄

mb64 · 2018-08-01T16:12:55Z

I expect this CI run to fail, because of rust-lang/libm#4. I could only get it to work by running it with RUSTFLAGS=-Coverflow-checks=off. There are a few ways to deal with this:

Set RUSTFLAGS in the CI: this is unideal because it disables other overflow checks that you might want the CI to catch
Make lots of PR's to libm and wait for them to be released: this will take a while and potentially create merge conflicts with other changes, etc.
Both?

Ogeon · 2018-08-01T16:51:59Z

I appreciate that you are already on the case with PRs! Hopefully we can get away with just a few of those, because I would really like to wait for it to be fixed in libm. To me, the alternative feels like just hiding the problem (and other potential problems, as you mention). Waiting is not a problem for me, but the conflicts could be annoying if the branches diverges too much. Maybe the whole thing could be split into two phases. The first one prepares for no_std by removing the current usages of std. The second one waits for the current issues in libm to be fixed and implements the final changes. I'm happy with the general implementation, so building it in debug mode is pretty much all that's left from my point of view.

What's your view on it? You are putting in a lot of work to get this through (which I once again appreciate a lot) and I don't want it to turn into a burden for you, rather than something enjoyable.

mb64 · 2018-08-01T17:33:11Z

The only necessary PR's to libm are for atan2 and sqrt; the others work fine. Here's an idea:

Add a commit to this PR that disables "really" using no_std based on a not-in-Cargo.toml feature (something like "libm_works"). This will make it at least mergeable.
Make another PR to Palette that undoes the temporary feature; wait to merge it until libm is OK.

Ogeon · 2018-08-01T18:43:25Z

Sounds like a plan!

Ogeon · 2018-08-01T19:14:38Z

By the way, I have a PR up with a quick fix for the hygiene warning and will make a release within the next day or so. Then I'll also merge those changes into master. 🙂

Ogeon · 2018-08-06T10:00:58Z

The fix is in master now.

mb64 · 2018-08-27T21:29:23Z

I just pushed a merge from master -- it should pass CI now. The no_std float trait that uses libm is hidden behind a never-enabled feature flag.

I think it's OK to merge, waiting on reverting the float trait once the libm PR's are in and released.

mb64 · 2018-08-27T21:40:30Z

(As a side note -- the docs link in palette/README.md points to the 0.4.0 docs, not the 0.4.1 docs)

Ogeon · 2018-08-28T16:43:58Z

Thanks! I saw that one of the travis jobs timed out, so I restarted it, but I'll merge it when it's all green. If you have your revert ready, you can upload it and open a PR that can stay open until it's time. Otherwise I'll make an issue for it so it's not forgotten.

(As a side note -- the docs link in palette/README.md points to the 0.4.0 docs, not the 0.4.1 docs)

Oh, you're right. It's supposed to be symlinked to the root README.md, but I must have messed something up...

Ogeon · 2018-08-28T16:52:21Z

bors: r+

110: No std support r=Ogeon a=mb64 Adds support for using palette without the standard library, as discussed in issue #108. Fixes #108. One tiny question: because this would be in a future release (not 0.4.0), what version should be in the README example Cargo.toml for `#![no_std]`? I put 0.4, but was unsure about if it should be something different. Co-authored-by: Mark Barbone <mark.l.barbone@gmail.com>

bors · 2018-08-28T17:15:34Z

Build succeeded

continuous-integration/travis-ci/push

mb64 added 9 commits June 24, 2018 23:11

std feature added; tests don't work on no_std yet though

07e4534

Further work on adding #![no_std] support, including a floating point…

9f72854

… hack

WIP no_std support -- some small cleanup

64ab2de

Changed #![no_std] api to use floating point functions from mish …

fe2273a

…and `m`

[WIP no_std] Fixed some tests

df60673

[WIP no_std] Fixed warnings coming from deriving Pixel

59f3248

Implement "soft_float" feature and add README note about no_std

ee3c2b7

Add method docs for no_std float::Float trait

cacfe2d

Make tests compile without the std feature

0b18908

Fix "unused import" warnings in palette/examples/readme_examples.rs w…

b5b9605

…ith "std" disabled

mb64 added 2 commits July 9, 2018 19:47

Change Lab conversions to use .cbrt() instead of .powf(1/3)

f23b893

Workaround imprecise soft-float math

8fa96e3

Change to use libm instead of mish and m

c0f7b26

Ogeon reviewed Aug 1, 2018

View reviewed changes

Tighten error margins back to previous margins

70d9426

Temporary feature to disable libm

e9d060a

Merge branch 'master' into no_std-support

6c0342c

Re-disable import warnings in derived blocks

c729c30

bors bot merged commit c729c30 into Ogeon:master Aug 28, 2018

evq mentioned this pull request Mar 25, 2019

fix no_std #127

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No std support #110

No std support #110

mb64 commented Jul 9, 2018

Ogeon commented Jul 9, 2018

Ogeon commented Jul 9, 2018

mb64 commented Jul 9, 2018

Ogeon commented Jul 10, 2018

Ogeon commented Jul 10, 2018

Ogeon commented Jul 31, 2018

mb64 commented Jul 31, 2018 •

edited

Ogeon commented Jul 31, 2018

Ogeon Aug 1, 2018 •

edited

mb64 Aug 1, 2018

Ogeon Aug 1, 2018

mb64 commented Aug 1, 2018

Ogeon commented Aug 1, 2018

mb64 commented Aug 1, 2018

Ogeon commented Aug 1, 2018

Ogeon commented Aug 1, 2018

Ogeon commented Aug 6, 2018

mb64 commented Aug 27, 2018

mb64 commented Aug 27, 2018

Ogeon commented Aug 28, 2018

Ogeon commented Aug 28, 2018

bors bot commented Aug 28, 2018

No std support #110

No std support #110

Conversation

mb64 commented Jul 9, 2018

Ogeon commented Jul 9, 2018

Ogeon commented Jul 9, 2018

mb64 commented Jul 9, 2018

Ogeon commented Jul 10, 2018

Ogeon commented Jul 10, 2018

Ogeon commented Jul 31, 2018

mb64 commented Jul 31, 2018 • edited

Ogeon commented Jul 31, 2018

Ogeon Aug 1, 2018 • edited

Choose a reason for hiding this comment

mb64 Aug 1, 2018

Choose a reason for hiding this comment

Ogeon Aug 1, 2018

Choose a reason for hiding this comment

mb64 commented Aug 1, 2018

Ogeon commented Aug 1, 2018

mb64 commented Aug 1, 2018

Ogeon commented Aug 1, 2018

Ogeon commented Aug 1, 2018

Ogeon commented Aug 6, 2018

mb64 commented Aug 27, 2018

mb64 commented Aug 27, 2018

Ogeon commented Aug 28, 2018

Ogeon commented Aug 28, 2018

bors bot commented Aug 28, 2018

Build succeeded

mb64 commented Jul 31, 2018 •

edited

Ogeon Aug 1, 2018 •

edited