-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no_std doesn't seem to be transitive #57
Comments
Good catch. Currently PR welcome if you want to attempt it. Otherwise it's going to be at least until this weekend before I get a chance to take a look. |
https://gist.github.com/robomancer-or/a427335eeb5690e96cb10b2d4c40feed#file-uom-patch What do you think? (I haven't actually tested that it will solve my problem, but it does compile without std and all the tests pass) |
Pulling in both Leave the version as 0.16. I've been meaning to release the current code as 0.17 for a while now and can include these changes. Could you also investigate re-exporting the |
So, I've been working on it and I can safely say that I'm not yet good enough at Rust to help you with this. After an hour or so of poking I'm no closer to understanding how your code works. I tried adding "std" as a dependency for all of the big* and rational* features, and then changing lib.rs to include
But it didn't work, I thought I'd be able to fix it by adding |
Awesome, it's nice to see progress (even if this one isn't done yet), thanks for the new version! |
Did a bit more work on this today. My new fear is that because |
I guess my question is why do non-rational types depend on num-rational? For applications that can accept some degree of rounding errors couldn't floats work to implement the conversion methods? (sorry if I'm missing the point, I still don't totally understand how uom works) |
Conversion factors for integral types are stored as a ratio of that type. The main reason is that conversion between integral and floating point gets messy. Some integral values can't be represented as a floating point value and of course many floating point values can't be represented as an integral value. Conversion between types also makes it a lot harder to get simple performant code. I'd like to get ratio conversion factors working before investigating using floating point (PRs always welcome). Although I haven't reviewed the |
What do you think about https://gist.github.com/robomancer-or/bbbed5cfd458a57ed03bb64e5c934063 ? Should I submit it as a PR to num-rational? Edit: Got impatient ;-) rust-num/num-rational#23 |
Awesome! I briefly looked over the changes earlier today and |
... and it's merged! num-rational now supports no_std (in master, hasn't been released to crates.io yet)! |
Only include `std`, `rational`, and `bigint` support as necessary based on `uom` feature selection. Resolves #57.
@robomancer-or I just pushed what should be a final version. When you have some time could you try testing the |
No such luck, I added
and got
it may be relevant that the line
is only in the output when I have the uom dependency. Why anything involving crates.io would be involved I'm not sure... |
I haven't been able to reproduce yet. Try |
So the trick is I'm cross compiling, so I'm using xargo instead of cargo. I just recreated it via:
Then in Xargo.toml:
and in Cargo.toml:
and then I run
|
Well, partial success. The new failure is in the Is there some way to choose a different target architecture for build scripts? |
Ugh. Forgot about .cargo/config . Okay, uom just built successfully in the deleteme project, but it's still not building in the project I care about (same num-traits error). I've deleted |
I can't think of anywhere else that it would be cached. Could you post the log of |
|
Update! One of my transitive build-dependencies is Edit: you can recreate the behavior by adding the follwoing to Cargo.toml in the deleteme example
which will build fine when uom is not included. |
The curse of many small dependencies. The "good" news is that the latest |
So it seems the next yak lay yonder... well... wish me luck! |
I can confirm your linked branch works on a Unfortunately it seems floating point operations are being pulled in even when just using I'm not sure if there's any way to avoid this, other than potentially being able to force I may have an attempt at manually writing out the few implementations I actually need at the moment, hopefully that will give me some idea of how this could be worked around, if you have some suggestions of known work arounds/areas to look at I'd be grateful for them. |
Just added #60 regarding conversion factors having a run-time cost to access for certain underlying storage types. There is really two parts to the issue: remove the dependency on the conversion factor being represented as If you're interested in discussing how the |
Good news everyone! After updating nightly (according to https://users.rust-lang.org/t/psa-you-no-longer-need-xargo-to-do-arm-cortex-m-development/16703 ) the |
As soon as |
Only include `std`, `rational`, and `bigint` support as necessary based on `uom` feature selection. Resolves #57.
|
Awesome, thanks!
…On Thu, Jun 21, 2018 at 1:13 PM, Mike Boutin ***@***.***> wrote:
v0.19.0 just released to crates.io <https://crates.io/crates/uom>!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#57 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AX2m8aNeTa2_8WQXD9fYd14KrgERGZDnks5t-9RIgaJpZM4SY66N>
.
|
This might just be me being new to rust, but I'm having a really tough time cross compiling uom for ARM. Starting from a lib crate that builds fine, if I add
to Cargo.toml and then run
xargo build
it tells meof special note there is the part that says
--cfg feature="std"
. It seems that specifyingno_std
foruom
isn't enforcing that constraint on upstream dependencies.The text was updated successfully, but these errors were encountered: