-
Notifications
You must be signed in to change notification settings - Fork 105
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
chores #833
chores #833
Conversation
probably messed up the python binding somewhere, will fix tmr. |
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, this looks great. Given the breaking changes, what do you say we hold this for ~week while we release v2.5, then put this in for v3.0 with the switch to doubles and all?
and for the record, yes it is fine to hold this for a week and wait for the next release. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #833 +/- ##
==========================================
- Coverage 91.84% 89.95% -1.89%
==========================================
Files 37 64 +27
Lines 4976 9067 +4091
Branches 0 948 +948
==========================================
+ Hits 4570 8156 +3586
- Misses 406 911 +505 ☔ View full report in Codecov by Sentry. |
Converting everything to size_t turns out to be quite complicated, mainly due to |
@elalish note that the old |
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.
Looks great, thanks for all this! Just noticed a few small things.
@@ -68,7 +68,7 @@ struct nb::detail::type_caster<glm::vec<N, T, Q>> { | |||
int size = PyObject_Size(src.ptr()); // negative on failure | |||
if (size != N) return false; | |||
make_caster<T> t_cast; | |||
for (size_t i = 0; i < size; i++) { | |||
for (int i = 0; i < size; i++) { |
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.
seems backwards?
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.
Ah, should fix this. Thanks.
src/manifold/include/manifold.h
Outdated
if (vertProperties.size() / numProp >= std::numeric_limits<int>::max()) | ||
throw std::out_of_range("mesh too large"); | ||
ASSERT(vertProperties.size() / numProp < | ||
static_cast<size_t>(std::numeric_limits<unsigned int>::max()), |
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.
Why unsigned int
max? I was thinking it would be either int
max or something 64-bit, once Collider gets updated.
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 forgot why, need to check. Probably due to MeshGL
indices are/should be unsigned integers?
src/manifold/src/boolean3.cpp
Outdated
@@ -137,7 +139,7 @@ inline thrust::pair<int, glm::vec2> Shadow01( | |||
|
|||
// https://github.com/scandum/binary_search/blob/master/README.md | |||
// much faster than standard binary search on large arrays | |||
size_t monobound_quaternary_search(VecView<const int64_t> array, int64_t key) { | |||
ssize_t monobound_quaternary_search(VecView<const int64_t> array, int64_t key) { |
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.
what is ssize_t
? Okay, I found this and am slightly more confused.
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.
ssize_t
is signed version of size_t
. But thinking about it, we only need that -1 to signal failure, and I can do it with size_t
max as well.
src/utilities/include/utils.h
Outdated
@@ -18,6 +18,11 @@ | |||
#include <mutex> | |||
#include <unordered_map> | |||
|
|||
#if defined(_MSC_VER) | |||
#include <BaseTsd.h> | |||
typedef SSIZE_T ssize_t; |
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 makes me slightly worried about ssize_t
...
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.
yeah, thinking about it ssize_t
is not really needed.
src/utilities/include/vec.h
Outdated
#include <exception> | ||
#endif |
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.
Do we need to include this per file, or can it just be wherever we define ASSERT
?
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.
yeah probably just need it when we define ASSERT
src/utilities/include/vec_view.h
Outdated
#include <stdexcept> | ||
#endif |
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 above.
@@ -107,6 +107,9 @@ jobs: | |||
timeout-minutes: 30 | |||
runs-on: ubuntu-22.04 | |||
if: github.event.pull_request.draft == false | |||
strategy: | |||
matrix: | |||
exception: [ON, OFF] |
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.
Is there any reason to build WASM with exceptions off? Maybe better to test one of the nix builds since they're fast?
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.
If testing generally exceptions off is the test. then it could be linux.
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.
@fire I think your earlier comment mentioned you do build WASM with exceptions off - that requires special CMake instructions which I was considering removing since JS is generally exceptions-based. But if WASM sans exceptions is actually useful to someone, then @pca006132 has it set up properly now. Do you build for WASM without exceptions?
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 would expect to build Godot Engine WASM without exceptions since the Godot Engine editor and Godot Engine game templates build without exceptions in the default configuration on all platforms.
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! Okay, let's leave it as is in this PR then.
sorry, was having a headache today. Will update this tmr |
I also updated nanobind version. |
there are still a lot of uses of integer that should be fixed, but we should probably leave to another PR and unblock your iterator changes. |
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, this looks great!
Fix #802, #804 and #832 (comment)
@elalish When doing this change, I found that we are using 32-bit integers extensively. I feel like the proper way would be to use 64-bit integers. There may be some performance hit, but I doubt if it will be huge. And it just feels better if we can make things work with larger meshes, considering we don't have any reasons not to do so? Some public APIs will have to be changed, but they will be changed when we update to double precision floating point.
For #804, it should now build fine, but it is not the best way of handling exceptions. We need more careful checks everywhere, probably together with #744.