-
Notifications
You must be signed in to change notification settings - Fork 210
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
Replace euclid with glam (proof-of-concept) #713
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the PR!
I haven't had a chance to look at everything yet, but I already left some remarks. Also some files are indented with Tab instead of Spaces (which is The Right Way ™️ but unfortunately not what godot-rust uses 😬). You might want to use cargo fmt
.
Regarding glam vs. other vector libraries: since they become an implementation detail, I'm fine with starting with glam without very deep API comparison. If necessary, we can always change the back-end later without breaking the API.
gdnative-core/src/core_types/mod.rs
Outdated
@@ -22,6 +25,9 @@ pub mod vector2; | |||
pub mod vector2_array; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more a comment towards @toasteater and the dev team, not specific to this PR:
Do we export both the inner module and core_types
? In my opinion, it could make sense to keep these mod
declarations private, and just the pub mod
re-export public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see also #713 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some additional comments about the API.
gdnative-core/src/core_types/mod.rs
Outdated
pub mod quat; | ||
pub mod rect2; | ||
pub mod rid; | ||
pub mod string; | ||
pub mod string_array; | ||
pub mod transform2d; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think they need to be public modules since they only contain single types that are re-exported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the changes, looks really good meanwhile! 🙂
One thing we should still discuss: before we had a dedicated Angle
type, now the functions just expose f32
. Would it make sense to keep that for type safety (at a cost of verbosity) or not?
If we decide to have our own Angle
, let's move it to a separate PR, so we can also discuss the API and so on.
pub mod variant; | ||
pub mod variant_array; | ||
pub mod vector2; | ||
pub mod vector2_array; | ||
pub mod vector3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mentioned the bindings depend on this one to be public?
Could you tell us the error you got, then we can make a note to fix it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The exact error is:
error[E0433]: failed to resolve: use of undeclared crate or module `vector3`
--> /home/david/Documents/godot/rust/target/debug/build/gdnative-bindings-bf0499e791931b11/out/generated.rs:460:3858
|
460 | ...= ""] # [inline] pub fn axis (& self) -> vector3 :: Axis { unsafe { let method_bind : * mut sys :: godot_method_bind = SpriteBase3DMet...
| ^^^^^^^ use of undeclared crate or module `vector3`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently the tests depend on them being technically public too: https://github.com/godot-rust/godot-rust/runs/2172242242
Maybe we want to keep them public for now and look for a solution later?
} | ||
} | ||
|
||
macro_rules! derive_op_impl { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@toasteater would it make sense to extract these macros to their own private file vector_ops.rs
and parametrize them over the vector type Vector2
/Vector3
?
Could avoid some code duplication and would keep the vector files cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense, but I think it's ok to merge this as is for now and do on that later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK for me 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is looking nice now! Please let us know when it's ready for a final review.
bors try
tryBuild failed: |
I'll try to fix the tests this evening and then it should be ready. |
@toasteater Let's discuss that in a separate issue then, to keep the scope of this PR limited? |
The tests will still fail due to mentioned ICE and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remember to run cargo fmt
, cargo clippy
, and the test suite before pushing.
Regarding approx
strictness, you can pass custom epsilons to the macros: relative_eq!(a, b, epsilon = 0.0001)
. We may or may not want that to be a parameter on is_equal_approx
, but I suppose probably yes?
/// Returns the axis of the vector's largest value. See `Axis` enum. | ||
/// If all components are equal, this method returns `Axis::X`. | ||
#[inline] | ||
#[allow(clippy::collapsible-if)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
collapsible_if
. Also this is a tab: run cargo fmt
before pushing. May I ask why did you ignore instead of use the lint suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ignore it because I believe the current version is more readable than the collapsed version.
if self.z > self.y {
if self.z > self.x {
Axis::Z
} else {
Axis::X
}
} else {
if self.y > self.x {
Axis::Y
} else {
Axis::X
}
}
vs
if self.z > self.y {
if self.z > self.x {
Axis::Z
} else {
Axis::X
}
} else if self.y > self.x {
Axis::Y
} else {
Axis::X
}
/// Returns the axis of the vector's smallest value. See `Axis` enum. | ||
/// If all components are equal, this method returns `Axis::Z`. | ||
#[inline] | ||
#[allow(clippy::collapsible-if)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as before.
I did not see any ICEs. Which version of rustc are you using? |
I was using I also reran the tests and they fail again due to very slightly differing output. Should I update the tests or keep it as it is? (the tests do pass when running
|
@Demindiro Keep them as-is. UI tests should always use stable as a reference, never nightly. |
While there are certainly things that are still debatable, like the placement of the internal trait, I feel that this PR has gone through enough, and further detailed things can be taken care of in additional follow-up PRs instead. @Demindiro When you think that this PR is ready, please remove any bors try |
tryBuild failed: |
bors try |
tryBuild failed: |
Also, apparently It also seems the stable output of the tests matches that of my nightly output. However, if I run the tests as stable it passes. I've also never touched those tests. |
According to the build log you can apparently update the UI tests with
No, it's allowed for nightly clippy to fail.
That's from rustc 1.46 which was a lot older than that I think? We haven't decided on a MSRV policy yet, but if you can work around it, please do for the moment being. |
bors try |
tryBuild failed: |
I think the expected outputs are preferrable here, but I'm not sure why the output for those errors changed. Shouldn't the error spans be provided by the derive macros? I don't think this PR touched those. Perhaps a rustc regression? EDIT: It turns out that the current expected outputs are from a nightly compiler. Presumably the difference is caused by the availability of |
@Demindiro It appears that you're having difficulty with the test suite. Since you have enabled the option to allow maintainers to push to your PR branch, would you mind if I fixed things and squashed the commits directly on your branch? |
Please do, this is getting ridiculous. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a big improvement over what we had. Thanks for the PR! I'm sorry that you've hit a few speedbumps with your first PR. I hope you'll take our enforcement of CI and bikeshedding of seemingly trivial points as evidence that we really care about the code here :)
Dealt with tests and squashed.
bors r+
713: Replace euclid with glam (proof-of-concept) r=toasteater a=Demindiro I had some time to take a look at #594. I decided to go with `glam` since it compiles the fastest. I went with the "front-end" approach as I believe that is the most flexible approach. I did rename a few things (like `zero()` to `ZERO`, `quaternion()` to `new()`, ...) but that is easy to revert if required. It doesn't seem like many changes are required. Wrapping all the methods in `glam` is easy to do with extensive use of `glam()` and `into()`. The crate does seem to miss implementations for a few types and methods like `Rect2` and `rotated`, so we'll have to implement those from scratch. the `impl Mul/Div/Add/...`s for `Vector2` and `Vector3` are pretty much identical, maybe there is some way to reduce duplication? Closes #594 Closes #670 (`Vector3` is fully implemented) Co-authored-by: David Hoppenbrouwers <[email protected]> Co-authored-by: toasteater <[email protected]>
Build failed: |
Update tests with the added `glam` dependency. Run tests that depend on Span::join only on nightly.
Well this is embarrasing bors retry |
Build succeeded: |
Cool to see this merged! 🍾 Thanks a lot to @Demindiro for your contribution and the patience, and @toasteater for the finishing touches! 🙂 |
I had some time to take a look at #594. I decided to go with
glam
since it compiles the fastest.I went with the "front-end" approach as I believe that is the most flexible approach.
I did rename a few things (like
zero()
toZERO
,quaternion()
tonew()
, ...) but that is easy to revert if required.It doesn't seem like many changes are required. Wrapping all the methods in
glam
is easy to do with extensive use ofglam()
andinto()
. The crate does seem to miss implementations for a few types and methods likeRect2
androtated
, so we'll have to implement those from scratch.the
impl Mul/Div/Add/...
s forVector2
andVector3
are pretty much identical, maybe there is some way to reduce duplication?Closes #594
Closes #670 (
Vector3
is fully implemented)