Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alessandro Pignotti
    @alexp-sssup
    No, I don't think that the problem is connected to vec3 *Vert. I think the code is accessing a vector out-of-bounds
    I recommend to assert that all the access to vectors are in to valid elements
    Serega
    @kgames54
    Right now there are no errors, but as soon as I make a call to the void InvApplyMatrix function (float MyVert, float m), it gives an error
    void InvApplyMatrix(float *MyVert, float* m)
    {
    MyVert[0] = MyVert[0] - m[0];
    //console.log("InvApplyMatrix:",MyVert[0]," ",MyVert[1]," ",MyVert[2]);    
    }
    "MyVert" and "m" non-empty
    I'm already afraid of working with vec3 and other math libraries.
    Therefore, I use float arrays.
    Sergey Popov
    @Split174
    Hi, I am trying to compile cheerp from the sources on manjaro. At the installation stage of "Build Cheerp LLVM / clang based compiler", the following error appears:
    "/home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp: In lambda function:
    /home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:6251:24: error: lambda parameter “CGF” previously declared as a capture
    6251 | CodeGenFunction & CGF, PrePostActionTy &) {
    | ~~~~ ^ ~~
    /home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp: In lambda function:
    /home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:6297:62: Error: lambda parameter "CGF" previously declared as a capture
    6297 | auto && EndThenGen = [& CGF, Device, & Info] (CodeGenFunction & CGF,
    | ~
    ~~~ ^ ~~
    /home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp: In lambda functions:
    /home/serj/cheerp/cheerp-llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:6376:56: Error: lambda parameter “CGF” previously declared as a capture
    6376 | auto && ThenGen = [& D, & CGF, Device] (CodeGenFunction & CGF, PrePostActionTy &) {
    | ~~~~~~ ^ ~~
    "
    Alessandro Pignotti
    @alexp-sssup
    @Split174 Please use al older version of clang or any gcc
    Serega
    @kgames54
    But it still seems to me that the compiler is missing something. Made a public variable "TimeFrame" in one function, we add "DeltaTime" to another, print to the console and get zero.
    void MovieClip3D::CalcProcessAnim(TAnim *anim, float Time)
    {
    if(!calcModel)return;
    timeFrame += Time;
    if(timeFrame >= 1.0f)
    {
    iFrame++;
    timeFrame = 0.0f;
    nextFrame = true;
    anim->addFramePos();
     }
    if(anim->getFramePos() > anim->getCountFrame()-3)anim->setFramePos(0);
    if(iFrame > anim->getCountFrame()-3)iFrame = anim->getCountFade();
        if(iFrame > anim->getCountFrame()-3)nFrame = anim->getCountFade();
        else{nFrame = iFrame + 1;}
    }
    
    void MovieClip3D::ViewFrameBone(TAnim *anim)
    {
    console.log("ViewFrameBone:",timeFrame); //show in console ViewFrameBone:0
    }
    timeFrame this is public float
    Alessandro Pignotti
    @alexp-sssup
    @kgames54 Is the variable static? If so make sure that it is correctly initialized. Using private/public members is of course fully supported by the compiler. As usual for us to investigate the problem we need a small reproducible example.
    Serega
    @kgames54
    Do you plan support GLM Math in Cheerp?
    https://glm.g-truc.net/0.9.9/index.html
    `
    #include <glm/vec3.hpp> // glm::vec3
    #include <glm/vec4.hpp> // glm::vec4
    #include <glm/mat4x4.hpp> // glm::mat4
    #include <glm/gtc/matrix_transform.hpp> // glm::translate, glm::rotate, glm::scale, glm::perspective
    glm::mat4 camera(float Translate, glm::vec2 const & Rotate)
    {
    glm::mat4 Projection = glm::perspective(glm::radians(45.0f), 4.0f / 3.0f, 0.1f, 100.f);
    glm::mat4 View = glm::translate(glm::mat4(1.0f), glm::vec3(0.0f, 0.0f, -Translate));
    View = glm::rotate(View, Rotate.y, glm::vec3(-1.0f, 0.0f, 0.0f));
    View = glm::rotate(View, Rotate.x, glm::vec3(0.0f, 1.0f, 0.0f));
    glm::mat4 Model = glm::scale(glm::mat4(1.0f), glm::vec3(0.5f));
    return Projection * View * Model;
    }
    Alessandro Pignotti
    @alexp-sssup
    I am not sure what you mean, no special support should be needed. If you find a specific bug (with a reproducible test case) let us know and we will take a look.
    danormsby
    @danormsby
    Hi! I compiled my jars and all looks almost perfect.
    I keep getting this though...
    loader.js:2168 Uncaught (in promise)
    (anonymous) @ loader.js:2168
    Promise.catch (async)
    cheerpjRunMain @ loader.js:2168
    (anonymous) @ (index):14
    Any tips on how to debug this? I can see in the console my code is doing stuff. No graphics though just the "Graphics System is Initialising" message and the Promise.catch error in the console.
    Alessandro Pignotti
    @alexp-sssup
    @danormsby This is the channel for Cheerp, our C++ product. Please ask the question on the appropiate channel for CheerpJ (our Java product): https://gitter.im/leaningtech/cheerpj
    Alessandro Pignotti
    @alexp-sssup
    @danormsby My impression is that an exception is being raised from Java, so adding a catch-all handler like try{....}catch(Exception e){System.out.println(e)} in your main method would be a good first step. It is also possible that there is an error in the jar paths given to cheerpjRunMain, so also check the network tab to make sure your jars are loaded as expected.
    ShabeehFatima
    @ShabeehFatima
    Hello. I am new to cheerp and was following the tutorial available at GitHub: https://github.com/leaningtech/cheerp-meta/wiki/Getting-started#install
    the output was fine for js, but when I compiled the test code to html the page didnot contain the html code rather something like this showed up
    "use strict";/Compiled using Cheerp (R) by Leaning Technologies Ltd/var k=Math.imul;var l=Math.fround;var oSlot=0;var nullArray=[null];var nullObj={d:nullArray,o:0};function j(){var a=null;a=g();console.log(a);}function h(){var a=null,d=null;a=String();d=String.fromCharCode(72);a=a.concat(d);d=String.fromCharCode(101);a=a.concat(d);d=String.fromCharCode(108);a=a.concat(d);d=String.fromCharCode(108);a=a.concat(d);d=String.fromCharCode(111);a=a.concat(d);d=String.fromCharCode(32);a=a.concat(d);d=String.fromCharCode(87);a=a.concat(d);d=String.fromCharCode(111);a=a.concat(d);d=String.fromCharCode(114);a=a.concat(d);d=String.fromCharCode(108);a=a.concat(d);d=String.fromCharCode(100);a=a.concat(d);return a;}function g(){var a=null;a=h();a=String(a);return a;}j();
    can someone tell me what went wrong
    Serega
    @kgames54
    @ShabeehFatima do you connect js to your page? The html page should look like this.
    <html>
    <head>
            <script src="wp_main.js"></script>
    </head>
    <body>
    <canvas id="glcanvas" width="800" height="600">
    <canvas id="webgl-text"></canvas>
    </canvas>
    </body>
    </html>
    Alessandro Pignotti
    @alexp-sssup
    @ShabeehFatima, as @kgames54 mentions, you need to include the script into your own HTML page. Cheerp generates JS + Wasm code, but the HTML should be written by you (can be very simple like @kgames54 has shown). This is well described in the Tutorial, so please carefully follow all the steps in it.
    ShabeehFatima
    @ShabeehFatima
    @kgames54 and @alexp-sssup Thankyou so much for the help. I really appreciate it and sorry for the amature mistake I made in following the tutorial
    mhoeben
    @mhoeben
    Goodmorning, I again picked up a project that uses Cheerp C++, compiled to Wasm. One of the problems I constantly run into is that the browser APIs, such as for example XMLHttpRequest seem to be only accessible from Javascript compiled classes. A lot of glue is required between Wasm compiled code and Javascript compiled code to abstract away this limitation. For example, calling Javascript code from Wasm (and vice versa) is only possible when the functions are plain functions or static member functions. Also it seems impossible to pass pointers between the two domains, so (for example) the Javascript code cannot store a Wasm class or callback pointer in its cheerp::Callback capture list to later pass on to one of the glue functions. I currently use a kind of integer handle mechanism that does lookups in both domains to obtain the "contexts", but this is cumbersome. My compiler is approximately half a year old, so maybe this has improved or maybe I am missing something. I looked at the documentation but that seems to confirm that everything needs to happen through plain functions and POD arguments between the domains. Any pointers on how to do a Wasm only application with only limited glue to access the browser API's?
    mhoeben
    @mhoeben
    A correction; I just found out that it is possible to store pointers of Wasm objects in Javascript objects and that one can callback, however, it must not be to a virtual function. That already helps a lot. Would be nice if the reverse would also work and that the Javascript functions do not need to be plain or static methods.
    mhoeben
    @mhoeben
    Just as a clarification, if I store a pointer to a Javascript class in a Wasm compiled class I get the following dump;
    0  clang-3.7       0x0000000000f3fd42 llvm::sys::PrintStackTrace(_IO_FILE*) + 50
    1  clang-3.7       0x0000000000f3dde1
    2  libpthread.so.0 0x00007fcc31c56890
    3  clang-3.7       0x0000000001a8127f clang::Sema::CheckCompletedCXXClass(clang::CXXRecordDecl*) + 2927
    4  clang-3.7       0x0000000001a82062 clang::Sema::ActOnFinishCXXMemberSpecification(clang::Scope*, clang::SourceLocation, clang::Decl*, clang::SourceLocation, clang::SourceLocation, clang::AttributeList*) + 466
    5  clang-3.7       0x000000000182d74f clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) + 1487
    6  clang-3.7       0x000000000182f0c0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) + 3120
    7  clang-3.7       0x00000000018153d1 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 2913
    8  clang-3.7       0x00000000017fd6e4 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 100
    9  clang-3.7       0x00000000017fde61
    10 clang-3.7       0x00000000017fde8f clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 31
    11 clang-3.7       0x00000000018036bf clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 287
    12 clang-3.7       0x0000000001827805 clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) + 357
    13 clang-3.7       0x00000000018282dc clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 2556
    14 clang-3.7       0x000000000181a31d clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 669
    15 clang-3.7       0x00000000018036e1 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 321
    16 clang-3.7       0x00000000018040a8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 536
    17 clang-3.7       0x00000000017f8833 clang::ParseAST(clang::Sema&, bool, bool) + 499
    18 clang-3.7       0x00000000010c5066 clang::FrontendAction::Execute() + 118
    19 clang-3.7       0x000000000109dc99 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 313
    20 clang-3.7       0x0000000001139b73 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1987
    21 clang-3.7       0x00000000007a4148 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1064
    22 clang-3.7       0x000000000078de02 main + 962
    23 libc.so.6       0x00007fcc30f35b97 __libc_start_main + 231
    24 clang-3.7       0x00000000007a2969 _start + 41
    Continue;
    Stack dump:
    0.    Program arguments: /opt/cheerp/bin/clang-3.7 -cc1 -triple cheerp--webbrowser -emit-llvm-bc -disable-free -disable-llvm-verifier -main-file-name http.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -g -dwarf-column-info -coverage-file /home/mhoeben/Development/manto-client2/build/CMakeFiles/manto-client.dir/src/cheerp/http.cpp.obj -resource-dir /opt/cheerp/bin/../lib/clang/3.7.0 -D _GLIBCXX_DEBUG -I /home/mhoeben/Development/manto-client2/src -I /home/mhoeben/Development/manto-base/include -internal-isystem /opt/cheerp/bin/../include/c++/v1 -internal-isystem /opt/cheerp/bin/../lib/clang/3.7.0/include -internal-externc-isystem /opt/cheerp/bin/../include -internal-externc-isystem /opt/cheerp/bin/../include/client -Wunused -Wuninitialized -Winit-self -Wstrict-aliasing -Wsequence-point -Wreturn-type -Wmissing-braces -Wno-unknown-attributes -std=gnu++14 -cheerp-mode=wasm -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /home/mhoeben/Development/manto-client2/build -ferror-limit 19 -fmessage-length 272 -mstackrealign -fno-rtti -fno-threadsafe-statics -fobjc-runtime=gcc -fdiagnostics-show-option -o CMakeFiles/manto-client.dir/src/cheerp/http.cpp.obj -x c++ /home/mhoeben/Development/manto-client2/src/cheerp/http.cpp 
    1.    /home/mhoeben/Development/manto-client2/src/cheerp/http.cpp:104:2: current parser token ';'
    2.    /home/mhoeben/Development/manto-client2/src/cheerp/http.cpp:12:1: parsing namespace 'impl'
    3.    /home/mhoeben/Development/manto-client2/src/cheerp/http.cpp:73:1: parsing struct/union/class body 'HTTPRequest'
    clang-3.7: error: unable to execute command: Segmentation fault (core dumped)
    clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation)
    Cheerp 2.0-xenial-1~xenial clang version 3.7.0  (based on LLVM 3.7.0svn)
    Target: cheerp--webbrowser
    Thread model: posix
    clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
    clang-3.7: note: diagnostic msg: 
    ********************
    
    PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
    Preprocessed source(s) and associated run script(s) are located at:
    clang-3.7: note: diagnostic msg: /tmp/http-9fbbde.cpp
    clang-3.7: note: diagnostic msg: /tmp/http-9fbbde.sh
    clang-3.7: note: diagnostic msg: 
    
    ********************
    CMakeFiles/manto-client.dir/build.make:134: recipe for target 'CMakeFiles/manto-client.dir/src/cheerp/http.cpp.obj' failed
    make[2]: *** [CMakeFiles/manto-client.dir/src/cheerp/http.cpp.obj] Error 254
    CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/manto-client.dir/all' failed
    make[1]: *** [CMakeFiles/manto-client.dir/all] Error 2
    Makefile:83: recipe for target 'all' failed
    make: *** [all] Error 2
    Yuri Iozzelli
    @yuri91

    Hi @mhoeben!

    There are indeed limitations in what can be passed between wasm and genericjs functions and types.
    The specific rules are going to be relaxed more and more with improvements in the compiler and in the actual wasm spec (for example when the anyref proposal will be accepted, many limitations will be lifted. We are currently working on this).

    The general principles are these:

    • pointers to basic types are safe to pass from wasm to genericjs, but not the other way around
    • calling function pointers (and by extensions virtual functions calls) between different modes is not supported at the moment, but we plan to relax this at least when calling wasm from genericjs.
    • in general, using wasm types from genericjs is fine (except for indirect calls), including stack-allocating structs/classes, so it is usually best to define structs in wasm mode (unless you need to share them with native js code)
    • if you need to do many DOM/JS operations, it is best to incapsulate them in a genericjs function

    If you have some code or more specific description of what you are trying to do that you feel could be done more easily, feel free to share it, we may be able to help.

    As for the dump, that is definitely a bug. It may be fixed in more recent versions, but if you can provide a small testcase I will be able to confirm if this is the case or not (and fix it for real).

    Yuri Iozzelli
    @yuri91

    For the record: these limitations could in theory be removed by implementing something like your integer handle mechanism, and by copying data between the wasm heap and js arrays to allow passing pointers to basic types, directly in the compiler.

    We don't do it intentionally because we want the compiler to provide zero-cost interoperability, without hidden copies, tables or reference counting.

    mhoeben
    @mhoeben
    @yuri91 thank you for the clarification. These were the limitations I indeed ran into. I spent the morning refactoring my code and it is a bit simpler now, but still uses the handle mechanism to refer to js objects - which is fine for now. I will post a minimal example that demonstrates the problem later today.
    mhoeben
    @mhoeben
    Ok, got to it immediately. Simplest I can come up with is;
    struct [[cheerp::genericjs]] Foo
    {
    };
    
    struct Bar
    {
        Foo *foo;
    };

    FYI compile flags are;

    /opt/cheerp/bin/clang++ -target cheerp -cheerp-mode=wasm -g -D_GLIBCXX_DEBUG -cheerp-mode=wasm -Wunused -Wuninitialized -Winit-self -Wstrict-aliasing -Wsequence-point -Wreturn-type -Wmissing-braces -Wno-unknown-attributes -fstrict-aliasing -std=gnu++14 -o CMakeFiles/manto-client.dir/src/test.cpp.obj -c /home/mhoeben/Development/manto-client2/src/test.cpp

    Yuri Iozzelli
    @yuri91

    I can confirm that in current master the bug is solved. Now a proper frontend error is emitted:

    /tmp/a.cpp:7:10: error: Cheerp: Attribute 'genericjs' of field 'foo' is incompatible with attribute 'asmjs' of class
          'Bar'
        Foo *foo;
             ^
    1 error generated.

    If you are on Debian/Ubuntu you can get nightly builds from our PPA.
    Otherwise you can compile it yourself, or wait for the next stable release (which should land in a few weeks).

    mhoeben
    @mhoeben
    I'll wait for a few weeks. I'm quite happy otherwise with my current installation. Good to see active development on this project/product by the way. I'm currently still in an exploration phase of my project, but if this turns out to be a viable route, I'm sure I'll be in contact about a Developer license for my client.
    Yuri Iozzelli
    @yuri91
    Nice to hear that! Feel free to ask here again if you have other issues
    mhoeben
    @mhoeben
    Just out of curiosity; where does the name cheerp come from?
    Yuri Iozzelli
    @yuri91
    the "C" is to remind C/C++, the name sound nice (I think), and very importantly, no other product has this name :)
    mhoeben
    @mhoeben
    :-)
    mhoeben
    @mhoeben
    Hi @yuri91, I ran in another compiler crash. If this is also fixed in the nightly build I'll upgrade... :-)
    struct [[cheerp::genericjs]] Foo
    {
        static void foo(char *ptr);
    };
    
    void Foo::foo(char *ptr)
        {}
    
    struct Bar
    {
        void bar()
        {
            char *ptr = nullptr;
            Foo::foo(ptr);      // Works
    
            Foo::foo(nullptr);  // Crashes
        }
    };
    Yuri Iozzelli
    @yuri91
    This seems to be a new bug. Thanks for catching it.
    The code that checks for the allowed parameter passing has still some rough edges. This seems an easy one to fix. If you want to be updated on the fix you can report it on github
    Yuri Iozzelli
    @yuri91
    @mhoeben the bug is fixed in the current nightly
    mhoeben
    @mhoeben
    Thanks for letting me know.
    Serega
    @kgames54
    Hello! I am writing on the site cheerp.ru C ++ articles using the compiler cheerp. I plan to launch the editor cheerp.ru / editor / in alpha version. At the moment, the editor is available to moderators and testers.
    Thank by Sergey!
    Serega
    @kgames54
    If you want to become a moderator or tester, register on the site and unsubscribe to my email address kgames (@) yandex (.) ru
    or unsubscribe in chat