Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    JF Bastien
    @jfbastien
    @sderossi / @alexp-sssup Hi ! Congrats on the wasm launch :) I was wondering if you were interested in joining the CG? https://www.w3.org/community/webassembly/ We've mostly only had Emscripten representation for tooling, and it would be great to have types of producers.
    Alessandro Pignotti
    @alexp-sssup
    @jfbastien Thanks a lot for your interest, we really appreciate it. One of our engineers (Sander van Veen) has already joined a few meetings but I think he has not been authorised yet to join the WebAssembly community group. I'll join myself as well. Looking forward to collaborate!
    Stefano De Rossi
    @sderossi

    @kkimdev it does, see https://github.com/leaningtech/cheerp-meta/wiki/FAQs-(Frequently-asked-questions)#should-i-release-my-code-as-gpl-if-i-use-cheerp.

    However, if GPLv2 restrictions are not acceptable, we offer alternative (non-copyleft) licenses https://leaningtech.com/cheerp/

    JF Bastien
    @jfbastien
    @alexp-sssup great! Looking forward to working with all of you :smile:
    Zack Penn
    @hikilaka
    hey guys
    i have a question--i have a function that does a simple client::console.log call, i'm setting the cheerp::wasm attribute and whenever it gets executed, it prints 0 every time
    is there a reason why?
    Alessandro Pignotti
    @alexp-sssup
    Hello @hikilaka. The WebAssembly standard does not allow any DOM call. Not even a simple console.log. Cheerp can split the same C++ codebase into plain (optimized) JS and WebAssembly to workaround this limitation.
    All the DOM code (i.e. stuff in the client:: namespace) needs to be inside a function tagged with the [[cheerp::genericjs]] attribute
    In the specific case of console.log we provide a convenience wrapper already, it is called cheerp::console_log and it can be used from wasm code
    In the final Cheerp 2.0 release there will be proper frontend errors when trying to call DOM and JS methods from wasm code, unfortunately these are not available in RC1
    @hikilaka One more thing, if you are compiling with the -cheerp-mode=wasm command line option you don't need to also add [[cheerp::wasm]] to your code, as that will be the default.
    Zack Penn
    @hikilaka
    ahhh, right. thanks @alexp-sssup. Are you one of the developers of cheerp?
    it appears so. where can i submit a bug report? i'm actually having trouble with the -cheerp-mode=wasm option. it's crashing the compiler.
    well actually, idk, that may have to do with the wasm limitation you listed. i'll get back on that lol
    Alessandro Pignotti
    @alexp-sssup
    @hikilaka You can report bugs here: https://github.com/leaningtech/cheerp-meta/issues. Take a look at this for an extensive example on how to mix DOM APIs and wasm code: https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-Tutorial:-Mixed-mode-C---to-WebAssembly-and-JavaScript
    OSM go
    @OSM__go_twitter
    After XMLHttpRequest: How can I pass the return of get_responseText() to a WASM function to work with it (as char*)
    Alessandro Pignotti
    @alexp-sssup
    @OSM__go_twitter WASM code can only access memory from the wasm heap. To pass memory to him you should actually allocate the memory on the wasm side, pass the pointer to it genericjs code (this is allowed) and then notify the wasm side to use the data. It is not possible to pass the pointer back to wasm as it is not possible to know that it's from wasm anymore.
    To access the data from the string, you can use ->charCodeAt
    I would recomment using set_responseType("arraybuffer") and get_response()
    in that way you can access bytes directly, and avoiding the conversion to string
    client::ArrayBuffer* buf=(client::ArrayBuffer*)xhr->get_response();
    int byteLength = buf->get_byteLength();
    client::Int8Array* i8buf=new client::Int8Array(buf);
    char* charBuf=__builtin_cheerp_make_regular<char>(i8buf, 0);
    This code can be used to read an ArrayBuffer as a normal char* in genericjs mode.
    OSM go
    @OSM__go_twitter
    That works! Now I can stay with Cheerp, thanks
    OSM go
    @OSM__go_twitter
    Any idea? If I use functions of math.h, I get RangeError: WebAssembly.Instance is disallowed on the main thread, if the buffer size is larger than 4KB. Use WebAssembly.instantiate.
    OSM go
    @OSM__go_twitter
    Would it help to place the large memory use in a thread by using WebWorkers?
    OSM go
    @OSM__go_twitter
    Oh, thanks! As Cheerp uses that Compile, we need an build-option, don't we. My >4k only happens if I use math.h in the JS part. I will avoid it.
    Just a remark: I need much more but 4k anyway and will use malloc, called after the XMLHttpRequest callback, because then I know the size.
    OSM go
    @OSM__go_twitter
    4k quite often! Like if using malloc: WebWorkers
    Alessandro Pignotti
    @alexp-sssup
    @OSM__go_twitter that will be fixed in RC2
    OSM go
    @OSM__go_twitter
    Good. I just try to use WebWorkers with WASM. No success yet.
    OSM go
    @OSM__go_twitter
    The Line
    bytes = new Promise( (resolve, reject) => {resolve(read(path,'binary'));
    does not like my path "jquery.wasm" : Invalid asm.js: Illegal export name
    Ângelo Andrade Cirino
    @aacirino
    I've downloaded the macOS version of cheerp and am not able to use it due to header files not being found. I tried the following to compile the example from the tutorial page:
    /Applications/cheerp/bin/clang -O3 -target cheerp -I/Applications/cheerp/include hello.cpp -o hello
    but there are too many errors due to undefined symbols and header files not found. Can you supply a simple compile invocation or compiler flags for a usable macOS experience?
    Alessandro Pignotti
    @alexp-sssup
    Please try without the -I option, it is not needed
    headers will be found automatically
    what errors do you get exactly
    ?
    Ângelo Andrade Cirino
    @aacirino
    The headers are not found automatically and there are lots of errors:
    /usr/include/sys/cdefs.h:707:2: error: Unsupported architecture
    /usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
    for instance
    These errors are reported when not using the -I flag
    Alessandro Pignotti
    @alexp-sssup
    Can you try again with the clang++ program?
    /Applications/cheerp/bin/clang++ -O3 -target cheerp hello.cpp -o hello
    Ângelo Andrade Cirino
    @aacirino
    The same outcome
    Alessandro Pignotti
    @alexp-sssup
    Please put in a pastebin the output of the following command: /Applications/cheerp/bin/clang++ -E -x c++ - -v -target cheerp < /dev/null
    And also the output of /Applications/cheerp/bin/clang++ -v
    Ângelo Andrade Cirino
    @aacirino
    The second is shorter:
    Cheerp 2.0rc1 clang version 3.7.0 (https://github.com/leaningtech/cheerp-clang.git 0becf4771548324fce4e66a22a3eb30526253384) (https://github.com/leaningtech/cheerp-llvm.git cbf31a0e0f58fbaa347b065932ffb3f67efd883b) (based on LLVM 3.7.0svn) Target: x86_64-apple-darwin15.6.0 Thread model: posix
    Alessandro Pignotti
    @alexp-sssup
    Can show the code of hello.cpp?
    Ângelo Andrade Cirino
    @aacirino

    It was a copy and paste from the example in the tutorial page:
    `#include <cheerp/clientlib.h>

    // webMain is the entry point for web applications written in Cheerp.
    void webMain()
    {
    // client is a C++ namespace that contains all browser APIs
    client::console.log("Hello World Wide Web!");
    }`

    Alessandro Pignotti
    @alexp-sssup
    Please also post the full output of the compiler. Since the header paths seems correct I cannot see how system headers are pull in.