Re: Embind 3.1.60 broke my binding.

2024-05-21 Thread キャロウ マーク
When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code

Re: Embind 3.1.60 broke my binding.

2024-05-21 Thread キャロウ マーク
> On May 22, 2024, at 14:15, キャロウ マーク wrote: > > The good news is that a new version of the wrapper that I have been working > on for a couple of weeks compiles successfully with 3.1.60. Not good after all. It turns out the first build I did with 3.1.60, that prompted me to write the above,

Re: Embind 3.1.60 broke my binding.

2024-05-21 Thread キャロウ マーク
> On May 22, 2024, at 3:09, 'Brendan Dahl' via emscripten-discuss > wrote: > > This was a part of a change to add more explicit object ownership > > for bindings. In this case you'd likely want

Re: WASM memory access from JS

2024-05-21 Thread 'Felipe Gasper' via emscripten-discuss
> On May 21, 2024, at 6:52 PM, 'Sam Clegg' via emscripten-discuss > wrote: > > On Tue, May 21, 2024 at 11:18 AM 'Felipe Gasper' via emscripten-discuss > wrote: > > > > On May 21, 2024, at 1:52 PM, 'Sam Clegg' via emscripten-discuss > > wrote: > > > > To access the wasmMemory from the o

Dropping support for Ubuntu/Bionic by upgrading to nodejs v18

2024-05-21 Thread 'Sam Clegg' via emscripten-discuss
Hi all, In emsdk we currently support running on distributions as old as Ubuntu/Bionic 18.04. However, we are attempting to upgrade the version of node we ship/use from v16 to v18, Node dropped support for Ubuntu/Bionic with v18, so we are now proposing to do that same. See: https://github.com

Re: WASM memory access from JS

2024-05-21 Thread 'Sam Clegg' via emscripten-discuss
On Tue, May 21, 2024 at 11:18 AM 'Felipe Gasper' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > > > > On May 21, 2024, at 1:52 PM, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > > > > To access the wasmMemory from the outside you should

Re: embind questions

2024-05-21 Thread 'Brendan Dahl' via emscripten-discuss
For the first question, you could use a getter/setter e.g. .property("format", +[](const foo& a) { return a.format; }, +[](foo& a, Format value) { a.format = value; }) For the second, char arrays are not currently bindable. Depending on what you're trying to do you can

Re: WASM memory access from JS

2024-05-21 Thread 'Felipe Gasper' via emscripten-discuss
> On May 21, 2024, at 1:52 PM, 'Sam Clegg' via emscripten-discuss > wrote: > > To access the wasmMemory from the outside you should be able to do > `-sEXPORTED_RUNTIME_METHODS=wasmMemory` and then access it via > `Module.wasmMemory`. > > You can also use the `.buffer` property of any of th

Re: Embind 3.1.60 broke my binding.

2024-05-21 Thread 'Brendan Dahl' via emscripten-discuss
This was a part of a change to add more explicit object ownership for bindings. In this case you'd likely want to use a return_value_policy:: take_ownership. There's more information in the docs

Re: WASM memory access from JS

2024-05-21 Thread 'Sam Clegg' via emscripten-discuss
To access the wasmMemory from the outside you should be able to do `-sEXPORTED_RUNTIME_METHODS=wasmMemory` and then access it via `Module.wasmMemory`. You can also use the `.buffer` property of any of the HEAPXX exports if you export any of those? BTW, I'm curious about the "The safest approach i

Embind 3.1.60 broke my binding.

2024-05-21 Thread キャロウ マーク
Hi, I have a binding for a c pseudo object-oriented API. The binding has a very simple c++ class with a single unique_ptr that points at the underlying c object. namespace ktx { class texture { private: texture(ktxTexture* ptr) : m_ptr{ ptr, &destroy } {