Skip to content
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

Merged
merged 26 commits into from
Jun 28, 2024
Merged

chores #833

merged 26 commits into from
Jun 28, 2024

Conversation

pca006132
Copy link
Collaborator

@pca006132 pca006132 commented Jun 8, 2024

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.

@pca006132 pca006132 changed the title fix comparison between integers with different signedness and implicit narrowing chores Jun 8, 2024
@pca006132
Copy link
Collaborator Author

probably messed up the python binding somewhere, will fix tmr.

Copy link
Owner

@elalish elalish left a 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?

src/manifold/include/manifold.h Outdated Show resolved Hide resolved
src/utilities/include/vec_view.h Outdated Show resolved Hide resolved
@pca006132
Copy link
Collaborator Author

and for the record, yes it is fine to hold this for a week and wait for the next release.

Copy link

codecov bot commented Jun 20, 2024

Codecov Report

Attention: Patch coverage is 91.66667% with 13 lines in your changes missing coverage. Please review.

Project coverage is 89.95%. Comparing base (d437097) to head (84ba93c).
Report is 55 commits behind head on master.

Files Patch % Lines
bindings/c/conv.cpp 0.00% 3 Missing ⚠️
bindings/c/manifoldc.cpp 50.00% 2 Missing ⚠️
src/collider/include/collider.h 0.00% 2 Missing ⚠️
src/manifold/src/impl.h 60.00% 2 Missing ⚠️
src/manifold/src/properties.cpp 84.61% 2 Missing ⚠️
bindings/c/include/conv.h 0.00% 1 Missing ⚠️
src/manifold/src/subdivision.cpp 75.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@pca006132
Copy link
Collaborator Author

Converting everything to size_t turns out to be quite complicated, mainly due to SparseIndices and Collider. Probably need some more time to do it, and evaluate the performance differences. This can be merged even though the changes are incomplete.

@pca006132
Copy link
Collaborator Author

@elalish note that the old ASSERT is now DEBUG_ASSERT, and ASSERT is for things that should still be checked when MANIFOLD_DEBUG is disabled.

Copy link
Owner

@elalish elalish left a 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++) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems backwards?

Copy link
Collaborator Author

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.

flake.nix Show resolved Hide resolved
src/cross_section/src/cross_section.cpp Show resolved Hide resolved
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()),
Copy link
Owner

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.

Copy link
Collaborator Author

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?

@@ -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) {
Copy link
Owner

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.

Copy link
Collaborator Author

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/polygon/src/polygon.cpp Show resolved Hide resolved
@@ -18,6 +18,11 @@
#include <mutex>
#include <unordered_map>

#if defined(_MSC_VER)
#include <BaseTsd.h>
typedef SSIZE_T ssize_t;
Copy link
Owner

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...

Copy link
Collaborator Author

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.

#include <exception>
#endif
Copy link
Owner

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?

Copy link
Collaborator Author

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

#include <stdexcept>
#endif
Copy link
Owner

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]
Copy link
Owner

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?

Copy link
Contributor

@fire fire Jun 20, 2024

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.

Copy link
Owner

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?

Copy link
Contributor

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.

Copy link
Owner

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.

@elalish elalish mentioned this pull request Jun 25, 2024
@pca006132
Copy link
Collaborator Author

sorry, was having a headache today. Will update this tmr

@pca006132
Copy link
Collaborator Author

I also updated nanobind version.

@pca006132
Copy link
Collaborator Author

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.

Copy link
Owner

@elalish elalish left a 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!

@elalish elalish merged commit b817d07 into elalish:master Jun 28, 2024
21 checks passed
@elalish elalish mentioned this pull request Jul 13, 2024
@elalish elalish mentioned this pull request Nov 5, 2024
@pca006132 pca006132 deleted the shut-up branch November 16, 2024 16:32
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

Successfully merging this pull request may close these issues.

Warning comparison of integer expressions of different signedness
3 participants