Fix build, tests, and clean up int types

[alecjacobson]

• The build was failing. Appears to be fixed by using C++14.
• A few tests were also failing. I've fixed most of them by using correct/modern numpy types.
• Fixes Does dense_longlong mean the same thing on linux and windows? #59 by replacing non-standard int, long and long long in C++ code with int32 and int64 and (omitted) and on the python/codegen side connects intc/int32 and int/int64 appropriately
• fixed broken github ci workflow
• modified cmake build to work on local windows machine

Since 128 integers are not supported in a standard way in C++ or numpy, it doesn't make sense to me to try to support them. (I didn't purge the complex256 related code, but along these lines it should also go).

When writing bindings, code will need to change according to:

Before	After
npe_arg(x, dense_int, dense_long, dense_longlong)	npe_arg(X, dense_int32, dense_int64)

I don't understand the remaining failing test. I'm not sure what the correct behavior is supposed to be and I can't make sense of the macros defining the npe_default_arg

An upshot of this, is that a bunch of the #ifdef WIN stuff can be dropped. By insisting on explicitly declaring the int sizes, we get the benefits of using std::.

While it would have been easier to just keep a transform_type_char for windows to filter 'Q','q' into 'L','l', the change I made uses isinstance checks to truly verify that the type is the correct it. Ideally the chars could be eliminated entirely for compile-time type checks but I leave that for another day.

I tried to fix the failing test (already failing before this PR) npe_default_arg for sparse types. It seems npe_default_arg is not working at all for sparse types (also not working with npe_matches / not clear how to pass a default arg [as Eigen::SparseMatrix?] ). Ideally, npe_default_arg with sparse types should just not compile rather than silently building and getting a suprise at runtime.

[alecjacobson]

(Sorry this snowballed into a larger change and I didn't break it up. If this has any chance of getting merged and you'd prefer it in smaller PRs just let me know.)

[fwilliams]

Hey Alec, thanks a lot for this change! I agree with your points about types and this is a much cleaner API. I'm a bit busy this week but I'll review this and try to get it merged asap.

I need to update point-cloud-utiles and an internal library at NVIDIA to match your changes. This should give some extra test coverage.

Also, I have an open PR to integrate the very small change (added a public method to a bumpy class) from my fork, so we should soon be able to depend on mainline pybind.

[alecjacobson]

Sounds good. FWIW libigl-python-bindings main is currently ✅ building and ✅ passing tests with this branch.

[fwilliams]

There's one broken test that checks if you can pass in a None. This actually isn't supported behavior because it turns out to be quite hard to handle this case and there's an easier way to do it.

If you could comment out that line and make sure the tests pass, I'm ready to merge.

[fwilliams]

maybe separate out a dim=1 case

[fwilliams]

NumpyEigen squeezes 1 dimensions by default when returning values, but there's an argument to npe::move (maybe it's hidden -- I don't recall atm) that changes this behavior.

[fwilliams]

These characters are unique identifiers for the internal numpy types (https://numpy.org/doc/stable/reference/generated/numpy.dtype.char.html#numpy.dtype.char).

If I remember correctly, we need a way of translating from the pybind array type into an identifier, and also being able to return something in the case where the array is something weird (like Object) which will throw an error.

I suppose you're right though, this could all be inlined into the generated code.

[fwilliams]

Found a small bug that fixes the failing test. Merging your PR and will send a fix.