Great, then I'll attempt this probably. I just have to research a bit more.. to me it also doesnt make sense for them to completely remove sync XHR... I understand it should be removed or avoided in certain scenarious but a worker thread to me seems like the perfect usecase for it
Here thats the last thing I read about it... https://developers.google.com/web/updates/2012/01/Getting-Rid-of-Synchronous-XHRs
Sadly it doesn't really make it perfectly clear if they plan to remove it for basically every usecase. But to me it sounds like it will now or very soon always fail as soon as you set the responseType AND try to use it synchronous
This post is from 2012
And indeed using responseType with synx XHR has not been allowed "forever"
Unless you have some heavy duty computation do do in wasm
:ok_hand: Thanks again! Really love Cheerp so far
Really excited/motivated now :D
Oh one more thing.. do you guys know of any users yet who used (binary) WASM in a Chrome extension? I was struggling quite a lot lately with the Google review process which has really gotten out of hand and very unpredictable.. and I fear that using WASM will get an extension even harder to pass through it (if at all)
If you haven't heard of anything yet no worries... I'll still attempt it ;)
If you haven't heard of anything yet no worries... I'll still attempt it ;)
Yup I know, already went through this whole process and I think I have thoroughly documented every single (optional) permission by now ;) still every time I submit an update it becomes a suspenseful waiting game :D .. they currently seem to be changing a lot of it almost daily
Hi all, I am using Cheerp to compile a C program to WebAssembly.
I found that without adding the option '-cheerp-linear-heap-size=1024', compiled program cannot run in Chrome and throws the error 'RuntimeError: memory access out of bounds'.
I know that this error is because the program requires memory exceeding the default limitation of 8 MB, but I still have several questions about this option:
I found that without adding the option '-cheerp-linear-heap-size=1024', compiled program cannot run in Chrome and throws the error 'RuntimeError: memory access out of bounds'.
I know that this error is because the program requires memory exceeding the default limitation of 8 MB, but I still have several questions about this option:
- The value I give is the minimum usable heap size or maximum heap size?
- Let's say if '-cheerp-linear-heap-size=64' is enough for my program, what is the influence of setting it to 1024? Will the generated WASM code becomes larger? Will the WebAssembly program takes more memory when running? Will it runs longer?
Hi @hopefuel!
That options set the maximum size of the wasm linear memory. The only difference in the binary produced is the corresponding value in the module declaration. Browsers will use this value when setting up the memory for the module. Tipically they will reserve some virtual memory equal to that amount, which should be free until actually used.
The memory allocator of cheerp will request to use more and more memory dinamically as needed, up until that limit.
So I would say that a larger than necessary value should not negatively affect your application, except maybe in 32 bits architectures (phones) when more than one wasm module is in the same tab process (since you could exaust the virtual memory).
Hi everyone, in the last weeks I had the chance to work on the [[cheerp::jsexport]] attribute, coming up with a (hopefully) stable set of rules + understanding what's needed to move it forward to non-trivially destructible classes and/or the possiblity of tagging Wasm classes with jsexport
I wrote down current limitations and some examples in a post here: https://medium.com/leaningtech/jsexport-cpp-in-the-browser-made-easy-710b2982046e
The PPA version is already updated, so it's already possible to start playing with it.
I wrote down current limitations and some examples in a post here: https://medium.com/leaningtech/jsexport-cpp-in-the-browser-made-easy-710b2982046e
The PPA version is already updated, so it's already possible to start playing with it.
The documentation about porting is here: https://github.com/leaningtech/cheerp-meta/wiki/Porting-Guidelines
It's slightly outdated, in the sense that some of the limitations have since been lifted, but there you will find a collection of recommendations that recommendations we found most useful. Also if the project build file is based on cmake, you might just start from:
cmake -DCMAKE_TOOLCHAIN_FILE=/opt/cheerp/share/cmake/Modules/CheerpWasmToolchain.cmake <regular arguments>
cmake -DCMAKE_TOOLCHAIN_FILE=/opt/cheerp/share/cmake/Modules/CheerpWasmToolchain.cmake <regular arguments>
And for a more comprehensive starting point, consider also: https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-Tutorial
@chriskiefer: in case you are talking about [[cheerp::jsexport]], currently there is a restriction that forbids inherited classes to be tagged with [[jsexport]]. I am working on ways to solve this problem, but until then your best bet is a using something like: https://gist.github.com/carlopi/73825f9915dfcd00847f37d93eded97c.
Basically any class, with no restrictions of sort (non-trivial deleter / inheritance / multiple constructors / etc) can be pointed to from a jsexported class. This pattern comes at a cost: you will have to declare/implement (even if just calling the relevant function from the pointer) the interface of the wrapper class, that will then be jsexported.
If you declare a "deleter" or equivalent functions that calls the destructor, you are also taking responsibility of calling the "deleter" on each created object, since the JavaScript GC have no way of knowing (at least until FinalizationRegistry) that it has to call the "deleter".
Basically any class, with no restrictions of sort (non-trivial deleter / inheritance / multiple constructors / etc) can be pointed to from a jsexported class. This pattern comes at a cost: you will have to declare/implement (even if just calling the relevant function from the pointer) the interface of the wrapper class, that will then be jsexported.
If you declare a "deleter" or equivalent functions that calls the destructor, you are also taking responsibility of calling the "deleter" on each created object, since the JavaScript GC have no way of knowing (at least until FinalizationRegistry) that it has to call the "deleter".
I may have mistook the problem, in any case sorry for the confusion generated, if you are referring to overloading + [[cheerp::jsexport]], as in 2 functions with the same name but with different signature, then there is no luck since there is no way of expressing that in a jsexport-ed class. (as Alessandro says, this limitation applies only to jsexport, not to regular C++ code compiled to JS or Wasm)
But then the recommended solution is just naming the methods differently (either in the original class on the jsexported-wrapper). A more complete solution (that involves argument numer checking + lots' of typeof) is currently out of scope for Cheerp, but can always be implemented on top of a [[cheerp::jsexport]]-ed class with some care on the JS side.
But then the recommended solution is just naming the methods differently (either in the original class on the jsexported-wrapper). A more complete solution (that involves argument numer checking + lots' of typeof) is currently out of scope for Cheerp, but can always be implemented on top of a [[cheerp::jsexport]]-ed class with some care on the JS side.
Hi, thanks (sorry for confusion, i should have provided a code example). Anyway, the latter case with [jsexport] is what i meant. I think the solution for now will be to export the most extensive version of the overloaded function, and then fill in the other overloads on the javascript side. Thanks for your help.
Hello! I've gotten up to speed with Emscripten lately, and just discovered Cheerp. I'm missing a comparison or mention of how it differs from Emscripten, other than the licence and cost. I bet you get this all the time! Is there something I could read up on to help make a decision about which of the two platforms to go for with our (C++) software? The one issue I've been having with Emscripten so far is compilation time, taking about 1 min to produce a 5 mb WASM of about ~100 source files. Threading is something I've only read about being an issue but haven't tried it out yet.
Discovered some good starting points above in this chat, here.