Thanks @geoffder, more hands are always appreciated! Is it just me or is everyone inventing a language these days? I hadn't even heard of OCaml, but it looks interesting.

It's not so new (1996, a descendant of a line of ML family languages before that), but it certainly isn't all that well known 😅. It's probably going to take me a bit, but I think I'll get started on the OCaml bindings using my fork so I can discover any pain points with the C API and iterate.

OCaml is a functional programming language, so it is probably less well-known to people not working on programming languages, but it is definitely not something new :). I think the C binding looks pretty clean, which should be good. Using this API directly (without compiler inserting delete or GC calling the destructor) might be a bit painful though, we can probably add something like a memory arena (https://github.com/elalish/manifold/blob/master/bindings/wasm/examples/worker.js#L67) that helps the user manage memory references in a less painful way.

Thanks. It is true that it would be painful to use directly, but the intended purpose of the API is to make it straightforward to bind into from other languages (allocating the memory in the host language and registering a finalization for the GC). I'm not as familiar with them, but I did spend time looking at the olm bindings in Rust as I was writing mine in OCaml and it seemed very straightforward for them as well (more automated than mine in fact). That there is nothing fancy happening with the memory in the C API is actually a benefit here.

Fortunately I don't think there are so many interested in using a library like this through C directly.

True, I guess we can merge the current C API later when you tried it with OCaml.

Hmm, I may not have thought this through completely, but decompose is exactly what it says: it doesn't create or destroy anything, it just sorts out the pieces. All of the decomposed manifolds together should have exactly the same faces/verts (memory) as the single input manifold, since it's just a partition. Would that help? The expensive part is running the graph search, and that solves both the number of components and the mapping, so I don't think there's a way to separate the computations.

To make sure that I'm following:

  std::vector<int> components;
  const int numLabel = ConnectedComponents(components, graph);

This is the expensive part right? If I'm correct, that's where I was suggesting to break the method apart. With the knowledge of how big of a buffer to allocate (how many manifolds to be returned), then using the C binding can avoid doing the ConnectedComponents operation twice (returning the components vector from the first function such that it can be fed back in for the cheap part). For the C++ API of course it shouldn't be broken into the cumbersome two steps, so Decompose would bundle these together.

Yes, that's right. Okay, that seems reasonable. This reminds me how glad I am I never had to write C.

Yea, I definitely don't prefer it either 😅

I have cooked up this hack for LevelSet:

#ifdef AVOID_LAMBDA_CUDA
  const auto auto_policy = autoPolicy(maxMorton);
  const auto policy = auto_policy == ParUnseq ? Par : auto_policy;
#else
  const auto policy = autoPolicy(maxMorton);
#endif

with this in the top-level CMakeLists.txt:

if(CBIND)
    # for avoiding handing lambda to for_each_n with a GPU policy in sdf LevelSet
    add_compile_definitions(AVOID_LAMBDA_CUDA)
endif()

I haven't tested them, but from my experience on the C side, I suspect this should probably be turned on for the other bindings as well.

I think maybe we should just use template specialization: specialize the function parameter as std::function, and avoid using the GPU in that specialization.

Ah good point, a specialized template wrapper around the call to for_each_n that avoids ParUnseq you think?

Yes

This works:

template <typename Func>
void for_each_n_wrapper(ExecutionPolicy policy, int morton,
                        ComputeVerts<Func> cv) {
  for_each_n(policy, countAt(0), morton, cv);
}
template <>
void for_each_n_wrapper<std::function<float(glm::vec3)>>(
    ExecutionPolicy policy, int morton,
    ComputeVerts<std::function<float(glm::vec3)>> cv) {
  const auto pol = policy == ParUnseq ? Par : policy;
  for_each_n(pol, countAt(0), morton, cv);
}

and in LevelSet:

  while (1) {
    VecDH<int> index(1, 0);
    // avoid handing dynamic function pointers to CUDA
    for_each_n_wrapper<Func>(
        policy, maxMorton + 1,
        ComputeVerts<Func>({vertPos.ptrD(), index.ptrD(), gridVerts.D(), sdf,
                            bounds.min, gridSize + 1, spacing, level}));

I guess another specialization is needed to match the type of the closure given by the WASM bindings (a cast function pointer, rather than std::function). Unless those happen to be treated the same.

Reading into it, I wonder if —whole-archive would help to just pack in everything to libmanifoldc.a and avoid having to move all the archives and link with -fPIC as well as remedy this skipped collider situation. Will try and see later. Obviously my lack of non-abstracted away linking experience is biting me now.

After trying it, and reading more, it is infact not the answer to wanting everything packed in to libmanifoldc.a. I'd have to use a post build tool like ar it seems.

On the organization of the simple sub-libraries like collider, is there a particular reason why they need to be build as separate shared/static libraries? It seems like making them with the OBJECT (as opposed to STATIC/SHARED) tag, it would make it possible to include them in other libraries directly, rather than packing them into distinct libraries.

Honestly, I have less experience with build systems than you do. I guarantee I didn't give this question any thought when I set up this project. If you think it can be improved, I'm all ears.

This is weird, no idea why it will cause such a problem. I can look into it a bit later.

At the moment I'm using OBJECT on the little sublibraries, but it seems to require -fPIC when CUDA is on (it complains and recommends using the flag), since I guess OBJECT works by a sort of relocation that CUDA doesn't like. Seems like there might be less fuss if collider, polygon, utilities, and graphlite were moved under the yoke of the manifold library. I'm not sure how much of an impact -fPIC has on manifold in particular though.