OTL
commented
1 year ago If k is compiled with this change, I feel it's almost OK.
I tried it, but I can't do that easily.
Could you try to fix k?
https://github.com/openrr/k
The number of errors is not so many.
❯ cargo build
Compiling k v0.29.1 (/Users/ogura/rust/k)
error[E0277]: the trait bound `link::Geometry<T>: From<GeometrySerde>` is not satisfied
--> src/urdf.rs:115:13
|
115 | urdf_visual.geometry.into(),
| ^^^^^^^^^^^^^^^^^^^^ ---- required by a bound introduced by this call
| |
| the trait `From<GeometrySerde>` is not implemented for `link::Geometry<T>`
|
= help: the trait `From<urdf_rs::Geometry>` is implemented for `link::Geometry<T>`
= note: required for `GeometrySerde` to implement `Into<link::Geometry<T>>`
error[E0277]: the trait bound `link::Geometry<T>: From<GeometrySerde>` is not satisfied
--> src/urdf.rs:129:13
|
129 | urdf_collision.geometry.into(),
| ^^^^^^^^^^^^^^^^^^^^^^^ ---- required by a bound introduced by this call
| |
| the trait `From<GeometrySerde>` is not implemented for `link::Geometry<T>`
|
= help: the trait `From<urdf_rs::Geometry>` is implemented for `link::Geometry<T>`
= note: required for `GeometrySerde` to implement `Into<link::Geometry<T>>`
error[E0769]: tuple variant `urdf_rs::Geometry::Box` written as struct variant
--> src/urdf.rs:140:13
|
140 | urdf_rs::Geometry::Box { size } => Geometry::Box {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
140 | urdf_rs::Geometry::Box(size) => Geometry::Box {
| ~~~~~~
error[E0769]: tuple variant `urdf_rs::Geometry::Cylinder` written as struct variant
--> src/urdf.rs:145:13
|
145 | urdf_rs::Geometry::Cylinder { radius, length } => Geometry::Cylinder {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
145 | urdf_rs::Geometry::Cylinder(_) => Geometry::Cylinder {
| ~~~
error[E0769]: tuple variant `urdf_rs::Geometry::Capsule` written as struct variant
--> src/urdf.rs:149:13
|
149 | urdf_rs::Geometry::Capsule { radius, length } => Geometry::Capsule {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
149 | urdf_rs::Geometry::Capsule(_) => Geometry::Capsule {
| ~~~
error[E0769]: tuple variant `urdf_rs::Geometry::Sphere` written as struct variant
--> src/urdf.rs:153:13
|
153 | urdf_rs::Geometry::Sphere { radius } => Geometry::Sphere {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
153 | urdf_rs::Geometry::Sphere(radius) => Geometry::Sphere {
| ~~~~~~~~
error[E0769]: tuple variant `urdf_rs::Geometry::Mesh` written as struct variant
--> src/urdf.rs:156:13
|
156 | urdf_rs::Geometry::Mesh { filename, scale } => {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
156 | urdf_rs::Geometry::Mesh(_) => {
| ~~~
error[E0308]: mismatched types
--> src/urdf.rs:246:41
|
246 | axis: axis_from(joint.axis.xyz),
| --------- ^^^^^^^^^^^^^^ expected array `[f64; 3]`, found struct `Vec3`
| |
| arguments to this function are incorrect
|
note: function defined here
--> src/urdf.rs:199:4
|
199 | fn axis_from<T>(array3: [f64; 3]) -> na::Unit<na::Vector3<T>>
| ^^^^^^^^^ ----------------
help: consider dereferencing the type
|
246 | axis: axis_from(*joint.axis.xyz),
| +
error[E0308]: mismatched types
--> src/urdf.rs:250:37
|
250 | axis: axis_from(joint.axis.xyz),
| --------- ^^^^^^^^^^^^^^ expected array `[f64; 3]`, found struct `Vec3`
| |
| arguments to this function are incorrect
|
note: function defined here
--> src/urdf.rs:199:4
|
199 | fn axis_from<T>(array3: [f64; 3]) -> na::Unit<na::Vector3<T>>
| ^^^^^^^^^ ----------------
help: consider dereferencing the type
|
250 | axis: axis_from(*joint.axis.xyz),
| +
Some errors have detailed explanations: E0277, E0308, E0769.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `k` due to 9 previous errorsIt will show the new usage of urdf-rs.
luca-della-vedova
taiki-e
:warning: This PR is a pretty large change to the library itself and I believe it might need careful review / changes to make sure it is OK from both a functionality and style point of view. :warning:
TLDR: Switch implementation from
serde-xml-rstoyaserdeand derive serialization traits to allow users to also save their structs into a urdf file, as opposed to what it was before that was only allowing deserialization.Why yaserde?
I'm working on a "urdf editor" project, so while deserializing urdf is great I would need to be able to also serialize it back to save my changes. When trying to derive
SerializeI noticed that it's currently impossible to tellserdewhether a field should be saved in a child element or in an attribute, for example if we had a struct:It could be serialized in any of the following ways, depending on whether
childshould be serialized as a child element or as an attribute:Or
Serde does not allow tagging fields to change the serialization behavior so the serializer can't be told exactly what to do. It defaults to using child elements (first behavior) but that is not enough for urdf that makes extensive use of attributes. The discussion started here, with the
serdemaintainer mentioning that xml should use a different crate, which sparked the creation of yaserde that is specific for xml.yaserdeallows specifying for each field whether it is an attribute or a child by adding a feature[yaserde(attribute)], child is implied. The rest of the APIs, such as flattening, renaming, are mostly similar to theserdecrate.The good
serdedependency has been migrated toyaserde.The bad
yaserdeseems to have a few issues when generating serialization code for enums with struct fields, as documented in this issue. This forced me to rewrite serialization and deserialization for geometries manually. Unit tests pass but the surface for bugs is a lot higher. The code should be able to be removed once the upstream issue is fixed.Migration Guide
Vec3andVec4types have been added for consistency, together withDerefandDerefMutimplementations, types that were raw arrays are now vectors. If your code expects an array either add a tuple index or dereference operator, as such: