Well, that's a temporary bug, but true... - Alon
On Wed, Mar 5, 2014 at 2:01 PM, Chad Austin <[email protected]> wrote: > For temporary debugging purposes, it's probably better if it _does_ break > validation, because asm.js code doesn't show in the call stack, making > tracing the failure hard. :) > > Sent from my iPhone > > On Mar 5, 2014, at 1:31 PM, Alon Zakai <[email protected]> wrote: > > I implemented emscripten_debugger() with one function call, so it is > closer. Emitting it directly in the code will take some checking to make > sure it does not break asm validation, I'll try to do that later. > > - Alon > > > > On Wed, Mar 5, 2014 at 11:49 AM, Chad Austin <[email protected]> wrote: > >> On Wed, Mar 5, 2014 at 11:22 AM, Alon Zakai <[email protected]> wrote: >> >>> asm() has some odd behavior of how escaping and so forth works - it's >>> designed for typical inline assembly, not JS. EM_ASM is in practice easier >>> to use for that reason. >>> >> >> Ah, interesting. >> >> Also, expanding the code inline can break asm.js validation - it's >>> arbitrary JS - so we expand it outline. >>> >> >>> I guess there might be a use case for actually expanding inline though, >>> for things like `debugger;`. But, perhaps we should just add an intrinsic >>> emscripten_debugger() that you would call. Is there anything aside from >>> `debugger;` like this? >>> >> >> debugger; is the only use case I've had for asm() so far! I like the >> idea of emscripten_debugger(); >> >> >>> >>> - Alon >>> >>> >>> >>> On Tue, Mar 4, 2014 at 11:55 PM, Chad Austin <[email protected]> wrote: >>> >>>> I'm playing with fastcomp to see what it would take to get a few embind >>>> demos running in asm.js. >>>> >>>> It was pretty convenient to put asm("debugger"); in Emscripten output, >>>> but now asm() doesn't work. You have to use EM_ASM, which breaks into the >>>> debugger a couple entries down in the stack, which is just a bit less >>>> convenient. >>>> >>>> Is there a particular reason why? >>>> >>>> -- >>>> Chad Austin >>>> Technical Director, IMVU >>>> http://engineering.imvu.com <http://www.imvu.com/members/Chad/> >>>> http://chadaustin.me >>>> >>>> >>>> -- >>>> 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/groups/opt_out. >>>> >>> >>> -- >>> 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/groups/opt_out. >>> >> >> >> >> -- >> Chad Austin >> Technical Director, IMVU >> http://engineering.imvu.com <http://www.imvu.com/members/Chad/> >> http://chadaustin.me >> >> >> -- >> 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/groups/opt_out. >> > > -- > 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/groups/opt_out. > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
