: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.
Hey all. I'd like to compile this project to Javascript: https://github.com/potassco/clingo It uses a big Makefile with lots of settings (I'm not a C++ expert so a lot of it is over my head). I tried setting the compiler to Cheerp's version of Clang++. However, when I run
cmake, it still outputs a binary file instead of Javascript files. How do I make it output Javascript?
Hi @d4hines!
We provide a CMake toolchain file, so generally it is just a matter of calling cmake like this: cmake -DCMAKE_TOOLCHAIN_FILE=/opt/cheerp/share/cmake/Modules/CheerpToolchain.cmake <regular arguments>
I see that in the Makefile you are manually setting CC and CXX variables. You should probably unset them.
Hello everybody. I am trying to use Cheerp to compile a C++ code for the browser. I managed to compile it but when I try to test it in the browser I get:
CompileError: wasm validation error: at offset 216400: type mismatch: expression has type i64 but expected i32 Do you have any ideas of what I should change? Thanks
@carlopi I was using firefox, in chromium I get more details, also where in the code is the problem, which is more helpful
Uncaught (in promise) CompileError: WebAssembly.instantiate(): Compiling function #522:"_ZN8nlohmann6detail10serializerINS_10basic_json..." failed: call[2] expected type i32, found i64.const of type i64 @+322391 Cheerp 1597723567-1~bionic clang version 7.0.0 (based on LLVM 7.0.0svn). I understand that int64_t is used but only int32_t is supported. Shouldn't this appear when compiling as an error?
Hi ! I am trying to compile this project. https://github.com/unbound-tech/blockchain-crypto-mpc It has makefile, but no cmakelist file. Can I set the makefile manually?
Hi @gdmiron !
64-bit integers are supported (except in a few cases, where you should get compiler errors).
It seems that you are using an outdated nightly version of the compiler. We are currently revamping 64-bit integers support and there may be some bugs in the version you are using. You can try again with a more recent nightly build, or wait for the upcoming 2.6 release in a month or so.
64-bit integers are supported (except in a few cases, where you should get compiler errors).
It seems that you are using an outdated nightly version of the compiler. We are currently revamping 64-bit integers support and there may be some bugs in the version you are using. You can try again with a more recent nightly build, or wait for the upcoming 2.6 release in a month or so.
Hi @atomrigs !
You can setup a makefile manually, by telling it to use cheerp as the C/C++ compiler.
By a quick look to the makefile in question though, I see a couple of issues:
You can setup a makefile manually, by telling it to use cheerp as the C/C++ compiler.
By a quick look to the makefile in question though, I see a couple of issues:
- it builds a shared library. This is not supported by cheerp, so you need to modify it to produce a static library
- it depends on openssl. This is a pretty big library, and there is no existing port currently. You would need to do it yourself, but it may be quite a big task
@yuri91 I could compile openssl itself using emscripten, https://gist.github.com/ip6li/b01022c49ad10deb9aa21dda45dddc78 but still I could not figure out how to recombine this compiled openssl with others though.
@yuri91 Thanks for the reply. I have updated to the latest nightly build, but now I get errors during compiling (was working before):
/opt/cheerp/bin/../include/c++/v1/fstream:579:17: error: use of undeclared identifier 'fdopen'; did you mean 'fopen'?
__file_ = fdopen(__fd, __mdstr);
^
/opt/cheerp/bin/../include/c++/v1/cstdio:145:9: note: 'fopen' declared here
using ::fopen;
^
/opt/cheerp/bin/../include/c++/v1/fstream:579:24: error: cannot initialize a parameter of type 'const char *' with an lvalue of type 'int'
__file_ = fdopen(__fd, __mdstr);
@gdmiron I tried a simple testcase that includes fstream, and it works for me on the current master.
Could you produce a testcase and file an issue on github? https://github.com/leaningtech/cheerp-meta/issues/new
Could you produce a testcase and file an issue on github? https://github.com/leaningtech/cheerp-meta/issues/new
@atomrigs you need to modify the makefile used to compile openssl to work with cheerp, and then when linking the final application pass the resulting .a to the final linking command
Hello, I am trying to use the cheerp file system, as soon as I add in my test file:
cheerp::FilePreloader files(preloadCallback, "CemHyds-dat.lst", "CemHyds-dbr.lst",
"CemHyds-dch.dat", "CemHyds-imp.dat", "CemHyds-dbr-0-0000.dat", "logfile.txt");I get this error in the browser:
Uncaught (in promise) Error: this should be unreachable
__dummy http://127.0.0.1:8080/gemsw.js:57
promise http://127.0.0.1:8080/gemsw.js:78
promise callback* http://127.0.0.1:8080/gemsw.js:69
@gdmiron Please create a minimal test case and create a github issue here: https://github.com/leaningtech/cheerp-meta/issues