Fantastic - was reluctant to use EM_ASM before because of the eval overhead.
Just wondering: is there a way to mark EM_ASM inline Javascript to be asm.js compliant, such that it is merged into the asm.js module? Or could emcc even validate that automatically? Soeren On Saturday, April 4, 2015 at 4:55:32 AM UTC+10, Alon Zakai wrote: > > Progress on > > https://github.com/kripken/emscripten/issues/2596 > > has landed on incoming, specifically we now emit EM_ASM contents as normal > JS functions inside the .js file that emscripten emits. They are outside of > the asm.js module, but they are JS code now, compared to before when they > were read as strings from the C heap and evalled. > > The benefit is that we can avoid evalling in order to use EM_ASM. (That > also means you can use the WebIDL binder without using eval, as it uses > EM_ASM.) Avoiding eval is both faster and avoids some issues with JS static > analyzers that look for eval and flag it as a security concern. > > This does however change EM_ASM if you are using closure compiler. The > difference is that before, closure couldn't see the code, so > > EM_ASM( do({ prop: value }) ); > > would be run exactly as it looks. However, now the do({ prop: value }) > code is visible to closure, and it might emit > > do({ a: value }) > > i.e. it might minify the property name. Normally this is fine and > beneficial - letting closure see everything means it can minify across the > entire program, which now includes EM_ASM blocks, but you might need to be > aware of it in some cases. > > If you are not using closure compiler, you don't need to worry about this; > if you are, you are probably already familiar with this topic, this is just > a heads up that EM_ASM blocks are now relevant to it. > > - Alon > > -- 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.
