PR made … let me know what you need.
> On Apr 10, 2019, at 8:58 AM, Beuc wrote:
>
> Hi,
>
> Would you like to propose a pull request? :)
>
> https://github.com/emscripten-core/emscripten/blob/incoming/site/source/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.rst
>
Sure, but after the Event Horizon Telescope press conference, starting in a few
minutes!
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi,
Would you like to propose a pull request? :)
https://github.com/emscripten-core/emscripten/blob/incoming/site/source/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.rst
I might be really useful to add a sentence to the "Access Memory from
Javascript" section of
https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html,
referencing your illuminating memory growth note
In my use case it's not hard to catch the memory growth. There are only a
few entry points, and I can check the allocated views afterward. The
problem is managing the references to the views that have spread throughout
the application state.
I can write a Proxy to a view that can swap out the
If you don't capture references to views, then emscripten will update
Module.HEAP8 etc. when memory grows. So only using those should be fine.
Otherwise, perhaps there should be an option to listen for memory growth
events, so that you can be notified when you need to recreate the views,
but this
Copy overhead for large data is too high, so I'm hoping to keep the data in
the wasm heap and provide access from js via typed array views.
This seems to work well except when the heap grows, invalidating the views.
Are there any good ways of dealing with this? I'm hoping to avoid putting
