manifold.wasm works only with JavaScript

[briansturgill]

The value_object and class embind directives work only for JavaScript.
See embind docs for details.
I know of no way to get this to work with other languages.
It also seems to require unknown exports by the client language, so using those directives effectively makes that
binding JavaScript only.
NOTE: the use of those directives makes it work very easily in JS, I'm arguing for a second binding, not getting rid of the current one.

I'm looking into making my own binding for what I need.

Along the same lines I notice you are rolling your own Python binding.
I really think you would be better off making a "C" binding and then using a tool like SWIG to generate bindings.
This would allow you to get to many other languages automatically.
This is one of the major drawbacks with using C++ for this kind of project. C++ doesn't play well with other languages.
Having a dual C interface is probably the easiest to maintain solution.
Oh, SWIG supposedly has support for C++, but you use very advanced C++ and I know a large number of projects use the C binding approach instead. Certainly the "C" bind approach is easier to use in SWIG.

[elalish]

Agreed, I believe the only purpose of WASM is to create JS bindings. What other languages are you interested in binding to? These JS and Python bindings are due to community contributions, for which I am hugely thankful as that part I'm not familiar with. If you'd like to contribute more here that would be fantastic!

[briansturgill]

@elalish

... I believe the only purpose of WASM is to create JS bindings. ...

Definitely not. For example there's a server "OS" under development that is using WASM as it's plugin architecture.
I'm using C#, I make CSharpCAD/Pycscad which started as a port from JSCAD.

You can use WASM files in many languages... list from the Byte Code Alliance README:
Rust - the wasmtime crate
C - the wasm.h, wasi.h, and wasmtime.h headers, CMake or wasmtime Conan package
C++ - the wasmtime-cpp repository or use wasmtime-cpp Conan package
Python - the wasmtime PyPI package
.NET - the Wasmtime NuGet package
Go - the wasmtime-go repository

[pca006132]

I guess you can create a C API and use it for all other languages? Although I'm not sure if we would want to maintain such an API, there are already the official C++ API, Python and JS API that we need to maintain.

[pca006132]

The problem with binding generator is that the general binding is not very ergonomic for others to use, so if we use it to generate the js and python binding, we still need significant effort to make an ergonomic interface.

[briansturgill]

... we still need significant effort to make an ergonomic interface.
I guess what I was thinking was that the "ergonomic interface" would be the "C" one. Which could then be exported to other languages via SWIG and could also be used in an alternate WASM binding.
I'm not trying to get you to support all languages, just make it simple for others to do so.
The "C" api is probably the easiest way to get there.

[elalish]

I would love to see what that looks like; do you want to start a PR @briansturgill? Perhaps there's room for a generic low-level API with more ergonomic, language-specific niceties on top. Being not much of a C-developer, what in our case would be the big difference between our C++ API and C? Is it mostly avoiding the use of std::vector in our interface?

I don't want to commit to this route yet; @pca006132's points regarding maintainability are valid, but I would also like to be convinced.

[pca006132]

My main concern is regarding the use of smart pointers. Our current C++ API is functional, so users have to be responsible for dropping a lot of intermediate states if they want to discard them. I guess maybe we can provide a C API that is not functional by default, and users have to clone the objects explicitly? (just do the operation and drop the old result internally) Not sure if that would be more ergonomic.

[briansturgill]

I would love to see what that looks like; do you want to start a PR @briansturgill? Perhaps there's room for a generic low-level API with more ergonomic, language-specific niceties on top. Being not much of a C-developer, what in our case would be the big difference between our C++ API and C? Is it mostly avoiding the use of std::vector in our interface?

I don't want to commit to this route yet; @pca006132's points regarding maintainability are valid, but I would also like to be convinced.

The alternate WASM binding would be similar to what it would look like... I can show that to you when it's done (though I don't think you want that to be a pull request).
As to the "big differences" between the C and C++ APIs:
Objects are returned as blobs.
The blob is pass into a function in order to call a method on the object.
Name mangling is turned off. (i.e. extern "C" { })
Obviously no C++ standard library data structures are used.
There should be faciilites in SWIG to handle the smart pointer issues.
Data sizes of arguments are fixed (i.e. avoid the 'int' size issue from C). Typicially all numbers double, int32, int64.

Most importantly, the C API should be easy to use... you've used OpenSCAD, see it's cheat sheet.
Also, here's mine: CSharpCAD docs
End users generally only use the static functions defined in CSCAD. Advanced ones might use SegmentedExtruder.
(SegmentedExtruder is a class... I can get away with that as I'm limited to dotnet.)
Dotnet has such good reflection capabilities that a Python bridge doesn't have to be specifically written.
I do have a Python wrapper module that makes naming more Pythonic.
It also provides the data marshaling that would be done in the "C" API (i.e. conversion between generic and internal data types).

Here's the Python wrapper.

JSCAD's ergonomic API is a bit painful, so I don't think I'll hold that one up as an example.

[elalish]

What's the story with blobs? C supports objects with methods. The rest seems reasonable, though I don't know how much code it'll take. I like to think our C++ API is pretty easy to use, and it's based strongly on OpenSCAD's already.

[briansturgill]

What's the story with blobs? C supports objects with methods. The rest seems reasonable, though I don't know how much code it'll take. I like to think our C++ API is pretty easy to use, and it's based strongly on OpenSCAD's already.

I'm not sure what you mean by C supports objects with methods. C doesn't have classes. Gcc allowed some C++ features to be used from C, but even then it I don't think that was allowed.

It won't take that much code. Basically you decide on what parts of the API you want to expose and make a C wrapper that talks to your fancy C++.
The reason you use C (actually you'll probably use C++ with extern "C" {}) is that it is easily called from any language.

Your API really isn't that easy to use... consider the case of creating a Manifold from points.
You have to first create a Mesh object with a constructor with 4 arguments (2 of which have unintelligible documentation - fortunately they have defaults.).
For a C++ API it is fairly clean, but isn't anywhere close to OpenSCAD in ease of use.
C++ is not an easy language, I think you'll have few users using that API directly.
It also has a slow edit/compile/run cycle.

I never did manage to get a proper export of manifolds to glb to work (in Python). Had to insert code into your run_all.py to get output. (When I called what seemed like the exact same code in a "save" function, I kept getting complaints about skipping an empty mesh.)
Anyway, where's stl support? Why isn't there a simple way to save? Really, the list goes on and on.

I think the use of C++ operator overloads will cause most users confusion.I know why ^ is intersect, but really, you expect most OpenSCAD users to understand that?

[briansturgill]

What's the story with blobs? C supports objects with methods. The rest seems reasonable, though I don't know how much code it'll take. I like to think our C++ API is pretty easy to use, and it's based strongly on OpenSCAD's already.

Oh, perhaps it was my use of the word "blob" that is the problem. I just mean you'll return a void *. It will be untyped from a C perspective.

[pca006132]

You can just declare it by

struct ManifoldObj;

No need to use void* in this case... Everything is type safe.

[briansturgill]

You can just declare it by
...
struct ManifoldObj;
...
No need to use void* in this case... Everything is type safe.

It might well work, but it's not proper "C" and is not guarenteed to work. The people calling the C API will not be parsing your Manifold headers. They may not be parsing any headers at all. (For an example, consider ctypes from Python .)
Essentially they'll just dynamically load the library and lookup the exported C name and call it. They will have no type info.
Have you never called a C dll from a non-C language?

[pca006132]

How is this not proper C? This is very typical for C libraries to forward declare a struct and hide the implementation from the users. User code will not know the size of the object and can only work with the pointer of the object, just like void* but is much safer. For FFI, a pointer is just a pointer, nothing is changed. I know the intent of the C API is for FFI, but it doesn't mean that we need to throw away the types.

And yes, I did work with C FFI before.

[briansturgill]

And yes, I did work with C FFI before.

And just how did you pass a C struct definition to something like Python ctypes, or C#, which access a C dll like this:
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);
(IntPtr is C#'s version of void*, uint is C#'s uint and int and means an (unsigned) 32-bit int not what C means by uint/int).
You can use a struct for both, BUT they must not be using anything that is not a C definable type.
Manifold makes massive use of C++ only features..

You use void * because the C spec says that is what void * is for, a pointer which is untyped.
Before ANSI C, by convention, (char *) was often used for this.
Obviously in Manifold the "C" API will cast the void * to the proper type inside your program. (Often likely, Manifold *)
You define your API with void * to explicitly point out that the return is a blob to the outsider caller and that they should not
be modifying it. When they need to call a method on that blob, they'll call a function (inside Manifold) similar to:

extern "C" {
    void *translate(void *_m, ...) { Manifold *m = (Manifold *)_m; return m->Translate(...);  }
}

The point here is that Manifold object is a BLOB, not something the host language should be messing with, except to pass it back.
That's what void * is for.

[pca006132]

Can you please have a look at this:

User code will not know the size of the object and can only work with the pointer of the object, just like void* but is much safer.

From C# and Python point of view, there is no different. But if someone wants to use a language with native C FFI support, such as Rust or Zig, having a type safe interface will be better.

[briansturgill]

Can you please have a look at this:

User code will not know the size of the object and can only work with the pointer of the object, just like void* but is much safer.

From C# and Python point of view, there is no different. But if someone wants to use a language with native C FFI support, such as Rust or Zig, having a type safe interface will be better.

I'm confused about what you want me to look at.
Rust and Zig cannot possibly have "type safe" access to C-FFI as C-FFI contains no type information.
They (like C#) are allowing you to specify a signature, when assuming_the_given_signature_is_valid will then be typesafe within the language.
From any of these languages, if the C signature in the DLL changes, you will get a crash or at least undefined behavior.

[elalish]

Thank you, I've learned a lot from this discussion, particularly how little I know about C. @briansturgill it sounds like you have ideas for how to improve things, but it's a bit hard to tell what magnitude of changes you're talking about. Let's do further discussion in the context of a PR, as contributions are always welcome.

[pca006132]

Sorry I don't want to waste more time on this pointless debate. Type information exists outside the specific DLL. You are fine to send a PR for your C API, and then I will review it.