Skip to content

Serde serialization breakage #320

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

Closed
jswrenn opened this issue Feb 15, 2018 · 6 comments
Closed

Serde serialization breakage #320

jswrenn opened this issue Feb 15, 2018 · 6 comments

Comments

@jswrenn
Copy link
Contributor

jswrenn commented Feb 15, 2018

This library upgraded to serde 1.0 in #245. However, the @rust-num crates have yet to upgrade to serde 1.0 (this upgrade is tracked by rust-num/num#357). This breaks serde serialization for all nalgebra types that make direct use of @rust-num's container structures, namely Complex, which is used by nalgebra's UnitComplex, which is used by Isometry2.

(I imagine this may also affect some of nalgebra's dependent crates, like ncollide and nphysics, too.)

Unfortunately, I don't think there's much that can be done in nalgebra about this other than wait for rust-num/num#357. Since this is a breaking change for @rust-num crates, it will require a major version number bump for num, and for a full fix we will need to coordinate an upgrade of nalgebra's dependencies that depend on num, namely alga.

@ThomasdenH
Copy link

What is the status here? The PR in num has landed and the new version released.

@sebcrozet
Copy link
Member

sebcrozet commented Apr 6, 2019

This is fixed as we already depend on num 0.2.
I'll add some tests before closing this.

@ThomasdenH
Copy link

I see. I was hoping this would fix this PR: ThomasdenH/casimir-fdfd#8.

@sebcrozet
Copy link
Member

@ThomasdenH It seems your pipeline is failing because of rand, which is unrelated to serialization.

@ThomasdenH
Copy link

ThomasdenH commented Apr 8, 2019

The PR just changes the nalgebra version. Should I open an issue in this repository or ask somewhere else?

Edit: Removing Cargo.lock before the build solved the problem.

@sebcrozet
Copy link
Member

Edit: Removing Cargo.lock before the build solved the problem.

Now that you mention it, you probably had mismatching versions of rand on your Cargo.lock. So removing Cargo.lock or calling cargo update was the right thing to do!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants