by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    conando2000
    @conando2000
    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
    Alessandro Pignotti
    @alexp-sssup
    Using during DOM/JS objects from Wasm is currently forbidden by the standard, but Cheerp can also generated plain JS code by tagging functions or types with the [[cheerp::genericjs]] attribute
    conando2000
    @conando2000
    Ok great thanks, that was exactly my understanding and plan :)
    Alessandro Pignotti
    @alexp-sssup
    As far as I know XHR is strongly deprecated in the main thread, and for good reasons
    conando2000
    @conando2000
    Exactly.. and then Cheerp handles everything else "under the hood", right? My understanding would be that internally messages are then passed between the WASM and JS parts, right?
    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
    Alessandro Pignotti
    @alexp-sssup
    There is no need for messages, the JS can call wasm and the other way around
    This post is from 2012
    And indeed using responseType with synx XHR has not been allowed "forever"
    conando2000
    @conando2000
    Ooops sorry, I guess I went down the rabbithole for too long last night :(
    Alessandro Pignotti
    @alexp-sssup
    This post is about sync xhr in the main thread, it has no impact on your plan
    conando2000
    @conando2000
    Ok, great :) Then I'll try to implement a basic prototype now... just wanted to make sure the basic idea at least could work... I definitely would prefer that approach to building some old school "callback hell"
    Alessandro Pignotti
    @alexp-sssup
    I think that for this use case you may also consider Cheerp "pure JS" mode
    Unless you have some heavy duty computation do do in wasm
    conando2000
    @conando2000
    Without using webworkers that would be the only option (callbacks)... I hope WASM will see some improvement in that regard at some point (that doesn't need something like "asyncify")
    Alessandro Pignotti
    @alexp-sssup
    If you want to try that, simply use -target cheerp instead of -target cheerp-wasm (which is the default) on the command line
    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