Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    conando2000
    @conando2000
    I know, I was/am considering it... but it's for a trading application and now WASM and "real" compilation will offer me the possiblity to do some heavier computation... so I'll try it
    :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 ;)
    Alessandro Pignotti
    @alexp-sssup
    We have our own share of problems with the Extension review process, but I don't expect wasm to be a problem. They are very nervous about extension permissions though, so I would suggest to be conservative with those
    conando2000
    @conando2000
    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
    hopefuel
    @hopefuel
    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:
    1. The value I give is the minimum usable heap size or maximum heap size?
    2. 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?
    Yuri Iozzelli
    @yuri91

    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).

    hopefuel
    @hopefuel
    @yuri91 Thank you for explanation, that makes sense!
    Carlo Piovesan
    @carlopi
    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.
    conando2000
    @conando2000
    @carlopi Is there any way to try new features/improvements like that on Windows by any chance? (the launchpad binaries for win don't seem to get updated that often)
    Carlo Piovesan
    @carlopi
    @conando2000: checking with the person in charge of the deployments how the timeline looks like
    Alessandro Pignotti
    @alexp-sssup
    @conando2000 For Windows we only publish build for full releases. This is mostly a CI limitation that we plan to eventually lift. Have you considered using WSL though? I don't have direct experience but a pure command line tool like Cheerp may easily work.
    Alessandro Pignotti
    @alexp-sssup
    @conando2000 You might also be able to use Docker for Windows or another virtualization solution to run a Ubuntu command line and use the Linux version of Cheerp from there
    conando2000
    @conando2000
    good idea! thx.. going to try that... not super important anyways, was just curious to try out the new jsexport stuff ;)
    Nader Ghanem
    @naderghanem
    hi, I have an existing project in c++ and I want to compile it with cheerp, is there any documentation on how I do it ?
    Carlo Piovesan
    @carlopi
    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>
    Carlo Piovesan
    @carlopi
    And for a more comprehensive starting point, consider also: https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-Tutorial
    Nader Ghanem
    @naderghanem
    thank you @carlopi
    Chris Kiefer
    @chriskiefer
    Hi, is there a way to ask cheerp to correctly transpile overloaded class methods to javascript?
    Alessandro Pignotti
    @alexp-sssup
    @chriskiefer Cheerp does correctly supported overloaded methods both when compiling to JS and to WebAssembly. Are you referring the the [[cheerp::jsexport]] functionality maybe?
    Carlo Piovesan
    @carlopi
    @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".
    Carlo Piovesan
    @carlopi
    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.
    Chris Kiefer
    @chriskiefer
    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.
    Alan Jefferson
    @alanjfs
    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.
    Alan Jefferson
    @alanjfs
    Ok, having read those along with the blog post and release notes, my takeaway is that the primary advantage of Cheerp is commercial support, along with a slightly improved performance increase and slightly reduced output size.
    Alessandro Pignotti
    @alexp-sssup
    @alanjfs Actually Cheerp also feature very advanced JS/Wasm interoperability features. You can generate both JS and Wasm code from a single codebase, use the DOM directly from C++ in a seamless manner and export full C++ classes to JS.
    conando2000
    @conando2000
    Does emscripten even feature any JS generation? (besides the required bootstrap and basic interop stuff) I mean JS as a target like Cheerp does...
    Alessandro Pignotti
    @alexp-sssup
    @conando2000 Emscripten historically could generated asm.js, a precursor to Wasm. But no, pure JS, object based code generation is only supported by Cheerp
    Daniel Hines
    @d4hines
    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?
    Yuri Iozzelli
    @yuri91

    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.

    Yuri Iozzelli
    @yuri91

    Actually, there are two toolchain files: CheerpToolchain.cmake is for compiling to js, and CheerpWasmToolchain.cmake is for compiling to wasm

    You probably want the second one, and you can explicitly compile code to JavaScript when needed with the [[cheerp::genericjs]] attribute

    George Dan Miron
    @gdmiron
    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
    Carlo Piovesan
    @carlopi
    Hi @gdmiron, this is very strange indeed, could you by any chance double check with a second browser? And what version of cheerp-llvm & cheerp-clang are you using? Ideally if you could share with us a way to reproduce the error, we could then triage and solve the problem.
    George Dan Miron
    @gdmiron
    @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?
    atomrigs
    @atomrigs
    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?
    Yuri Iozzelli
    @yuri91
    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.
    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:
    • 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
    atomrigs
    @atomrigs
    @yuri91 Thanks for your nice feedback.
    atomrigs
    @atomrigs
    @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.
    George Dan Miron
    @gdmiron
    @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);
    Yuri Iozzelli
    @yuri91
    @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
    @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
    George Dan Miron
    @gdmiron
    @yuri91 I tried to build the problematic file that uses fsteam /opt/cheerp/bin/clang++ -target cheerp test.cpp -o test.js -O3 and all works. The same file produces the errors above when is compiled with the whole project using CMake.
    George Dan Miron
    @gdmiron

    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
    Alessandro Pignotti
    @alexp-sssup
    @gdmiron Please create a minimal test case and create a github issue here: https://github.com/leaningtech/cheerp-meta/issues