Sorry, I meant to say that "the *keypress* event isn't captured, only the keyup and keydown events are captured".
Suppose I use EM_ASM to execute native Javascript inside my mouse_callback when my program is sleeping during emscripten_sleep_with_yield. What happens when the sleep ends and the program resumes from emscripten_sleep_with_yield? Will Emscripten allow my native Javascript to run to completion before resuming from emscripten_sleep_with_yield? Thanks for your help. On Saturday, August 29, 2015 at 1:56:19 AM UTC+8, Alon Zakai wrote: > > 1. It's fine that memcpy and strlen are not interpreted. They just need to > be on the list of methods it is ok to call while async (which now both > are). malloc might be a problem, since it can call sbrk which is an ffi. If > that turns out to be a problem we'll need to figure something out. > > 2. "But for some reason, the keydown event isn't captured, only the keyup > and keydown events are captured. " - did you mean another event than > keydown in the first part of that sentence? > > Maybe we need to not call preventDefault on a previous event for the one > that is missing - can you look at the stream of incoming events and try > that? > > On Fri, Aug 28, 2015 at 4:14 AM, awt <[email protected] <javascript:>> > wrote: > >> Thanks for the quick fix Alon :) I just have 2 more questions: >> >> 1) I noticed that functions like _memcpy, _malloc, _strlen are also not >> emterpreted. Will you be fixing this as well? >> 2) Another issue is that the code currently does not post the keypress >> event over to the worker. After looking at the code, >> >> ['keydown', 'keyup', 'keypress', 'blur', >> 'visibilitychange'].forEach(function(event) { >> document.addEventListener(event, function(event) { >> worker.postMessage({ target: 'document', event: cloneObject(event) }); >> event.preventDefault(); >> }); >> }); >> >> I realized that we are capturing keypress events for the document. But >> for some reason, the keydown event isn't captured, only the keyup and >> keydown events are captured. This is an issue for me because I need to >> capture the exact char returned from the key and not just the keycode >> itself. As of now, there's no way in which I can differentiate between >> upper and lowercase characters. >> >> Is there a way in which we can post the charcode over to the worker? I >> debugged this issue by simply printing out the event type in the code >> above. Thanks for your help. >> >> On Friday, August 28, 2015 at 2:21:42 AM UTC+8, Alon Zakai wrote: >>> >>> That was a bug - we have a list of functions we avoid interpreting for >>> performance reasons, but weren't aware of that in another part of the >>> compiler. This would have been caught but we didn't have an iostream test >>> during async. Fixed on incoming and added a test. >>> >>> On Thu, Aug 27, 2015 at 4:08 AM, awt <[email protected]> wrote: >>> >>>> Thanks for your reply Alon, I managed to get the mouse callback to >>>> trigger by doing some debugging. This is my code as of now: >>>> >>>> helloworld.cpp: >>>> >>>> #include <stdio.h> >>>> #include <iostream> >>>> #include <emscripten.h> >>>> #include <html5.h> >>>> using namespace std; >>>> >>>> extern "C" { >>>> EM_BOOL mouse_callback(int eventType, const EmscriptenMouseEvent *e, >>>> void* userData) >>>> { >>>> cout << "mouse_callback+" << endl; >>>> return 0; >>>> } >>>> } >>>> >>>> void handleMouseEvent() >>>> { >>>> emscripten_sleep_with_yield(100); >>>> } >>>> >>>> int main() { >>>> cout << "HelloWorld" << endl; >>>> >>>> //emscripten_set_mousemove_callback("#canvas",0,1, mouse_callback); >>>> emscripten_set_mousedown_callback("#canvas", 0, 1, mouse_callback); >>>> >>>> emscripten_set_main_loop(handleMouseEvent, 0, 0); >>>> return 0; >>>> } >>>> >>>> My build commands: >>>> emcc helloworld.cpp --proxy-to-worker -s EMTERPRETIFY=1 -s >>>> EMTERPRETIFY_ASYNC=1 -s NO_EXIT_RUNTIME=1 -s >>>> EXPORTED_FUNCTIONS="['_mouse_callback', '_main']" -o helloworld.html >>>> >>>> Unfortunately, when I click on the canvas, I see the following abort in >>>> the console: >>>> >>>> Uncaught abort(-12) at Error >>>> at jsStackTrace (http://localhost:8000/helloworld.js:1166:13) >>>> at stackTrace (http://localhost:8000/helloworld.js:1183:22) >>>> at abort (http://localhost:8000/helloworld.js:24467:44) >>>> at _strlen (http://localhost:8000/helloworld.js:20487:26) >>>> at emterpret (http://localhost:8000/helloworld.js:11969:11) >>>> at emterpret (http://localhost:8000/helloworld.js:11520:4) >>>> at emterpret (http://localhost:8000/helloworld.js:11520:4) >>>> at Array._mouse_callback ( >>>> http://localhost:8000/helloworld.js:16841:2) >>>> at dynCall_iiii (http://localhost:8000/helloworld.js:20532:41) >>>> at Object.Runtime.dynCall ( >>>> http://localhost:8000/helloworld.js:280:39) >>>> This error happened during an emterpreter-async save or load of the >>>> stack. Was there non-emterpreted code on the stack during save (which is >>>> unallowed)? You may want to adjust EMTERPRETIFY_BLACKLIST, >>>> EMTERPRETIFY_WHITELIST. >>>> This is what the stack looked like when we tried to save it: 1,Error >>>> at Object.EmterpreterAsync.handle ( >>>> http://localhost:8000/helloworld.js:8152:40) >>>> at _emscripten_sleep_with_yield ( >>>> http://localhost:8000/helloworld.js:8177:24) >>>> at emterpret (http://localhost:8000/helloworld.js:12550:6) >>>> at Array.__Z16handleMouseEventv ( >>>> http://localhost:8000/helloworld.js:20629:2) >>>> at dynCall_v (http://localhost:8000/helloworld.js:20670:31) >>>> at Object.Runtime.dynCall ( >>>> http://localhost:8000/helloworld.js:284:39) >>>> at http://localhost:8000/helloworld.js:6409:21 >>>> at Object.Browser.mainLoop.runIter ( >>>> http://localhost:8000/helloworld.js:6471:13) >>>> at Browser_mainLoop_runner ( >>>> http://localhost:8000/helloworld.js:6405:26) >>>> at http://localhost:8000/helloworld.js:23845:7 >>>> abort @ helloworld.js:24473_strlen @ helloworld.js:20487emterpret @ >>>> helloworld.js:11969emterpret @ helloworld.js:11520emterpret @ >>>> helloworld.js:11520_mouse_callback @ helloworld.js:16841dynCall_iiii @ >>>> helloworld.js:20532Runtime.dynCall @ helloworld.js:280handlerFunc @ >>>> helloworld.js:7301jsEventHandler @ helloworld.js:7204(anonymous function) >>>> @ >>>> helloworld.js:23955fireEvent @ helloworld.js:23954onmessage @ >>>> helloworld.js:24230 >>>> >>>> I took a look at the _strlen code and saw the following: >>>> >>>> function _strlen(ptr) { >>>> ptr = ptr | 0; >>>> var curr = 0; >>>> curr = ptr; >>>> asyncState ? abort(-12) | 0 : 0; >>>> while (HEAP8[curr >> 0] | 0) { >>>> curr = curr + 1 | 0; >>>> } >>>> return curr - ptr | 0; >>>> } >>>> >>>> I find it strange that _strlen will abort when the program is in an >>>> async state. From what I understand, all the functions would already have >>>> been emterpreted when I use -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1. Is >>>> my understanding correct or do I have to manually add _strlen to the >>>> whitelist as well? I am using emsdk 1.34.1. >>>> >>>> On Thursday, August 27, 2015 at 11:11:27 AM UTC+8, Alon Zakai wrote: >>>>> >>>>> Not sure where the problem is (I didn't implement that API myself, not >>>>> very familiar with the code) but you might take a look at >>>>> tests/test_html5_mouse.c for example, which tests that API, and is known >>>>> to >>>>> work. >>>>> >>>>> On Wed, Aug 26, 2015 at 5:41 PM, awt <[email protected]> wrote: >>>>> >>>>>> Thanks for your reply Alon, are there other APIs that I can use to >>>>>> capture mouse and keyboard events in Emscripten >>>>>> besides emscripten_set_click_callback? Or do you think the issue lies >>>>>> with >>>>>> my mouse_callback itself? >>>>>> >>>>>> On Thursday, August 27, 2015 at 6:01:35 AM UTC+8, Alon Zakai wrote: >>>>>>> >>>>>>> The mouse_callback doesn't seem to work without --proxy-to-worker >>>>>>> either, so proxying isn't the issue either. I'm not sure offhand what >>>>>>> is >>>>>>> wrong there, but it should be easier to debug without proxying. >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 2:59 PM, Alon Zakai <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Yes, the JS running in the HTML needs a Module object, so that we >>>>>>>> can find the canvas element to render to, text area to show stdout to, >>>>>>>> and >>>>>>>> so forth. If you emit an html file instead of js, that will be emitted >>>>>>>> for >>>>>>>> you. Otherwise, you need to create it in the HTML. >>>>>>>> >>>>>>>> It's definitely an error that we fail in this way, though. I fixed >>>>>>>> this on incoming, we'll show a warning now, and provide some basic >>>>>>>> Module >>>>>>>> functionality if one is not defined (writing to console.log for >>>>>>>> stdout, >>>>>>>> etc.) >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 25, 2015 at 11:59 PM, awt <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I was trying to generate a javascript output for a simple hello >>>>>>>>> world program and insert it into my own html file. These are my build >>>>>>>>> commands: >>>>>>>>> >>>>>>>>> emcc helloworld.cpp --proxy-to-worker -o helloworld.js >>>>>>>>> >>>>>>>>> This is my helloworld.html file: >>>>>>>>> >>>>>>>>> <html> >>>>>>>>> <header></header> >>>>>>>>> <body> >>>>>>>>> <script src="helloworld.js"></script> >>>>>>>>> </body> >>>>>>>>> </html> >>>>>>>>> >>>>>>>>> This is my cpp file: >>>>>>>>> >>>>>>>>> #include <stdio.h> >>>>>>>>> #include <iostream> >>>>>>>>> >>>>>>>>> using namespace std; >>>>>>>>> int main() { >>>>>>>>> cout << "HelloWorld" << endl; >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> I get the following error: >>>>>>>>> Uncaught ReferenceError: Module is not defined >>>>>>>>> >>>>>>>>> at the following line of code in helloworld.js: >>>>>>>>> >>>>>>>>> ['mousedown', 'mouseup', 'mousemove', 'DOMMouseScroll', >>>>>>>>> 'mousewheel', 'mouseout'].forEach(function(event) { >>>>>>>>> Module.canvas.addEventListener(event, function(event) { >>>>>>>>> worker.postMessage({ target: 'canvas', event: >>>>>>>>> cloneObject(event) }); >>>>>>>>> event.preventDefault(); >>>>>>>>> }, true); >>>>>>>>> >>>>>>>>> Do I need to manually declare the Module object in >>>>>>>>> helloworld.html? Or should I just include helloworld.worker.js in >>>>>>>>> helloworld.html directly? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "emscripten-discuss" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "emscripten-discuss" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
