I agree with Rob that S2S would give the most flexibility. Something similar to java.lang.instrumentation API would be immensely useful (http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html). I am a maintainer and developer of Jalangi (https://github.com/SRA-SiliconValley/jalangi) and I believe a java.lang.instrumentation like API would help us to make Jalangi easily accessible to developers.
On Wednesday, June 25, 2014 3:40:26 PM UTC-7, Robert O'Callahan wrote: > On Thu, Jun 26, 2014 at 8:06 AM, Jason Orendorff > > wrote: > > > > > An alternative involves letting you modify JS code just before it's > > > compiled (source-to-source transformation). This is more general (you could > > > modify the instrumented code arbitrarily, and react synchronously as it > > > executes) but maybe that's undesirable. It's not clear that transformed > > > source would interact nicely with other tools, like the debugger. And a > > > usable API for this is a tall order. > > > > > > > Why is a usable S2S API difficult to produce? > > > > A while ago I spent a few years doing dynamic analysis of Java code. > > Although the VMs had a lot of tracing and logging hooks, bytecode > > instrumentation was always more flexible and, done carefully, almost always > > more performant. I had to write some libraries to make it easy but tool > > builders enjoy writing and reusing those :-). > > > > For JS of course we wouldn't want to expose our internal bytecode, hence > > S2S. > > > > Rob > > -- > > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > > waanndt wyeonut thoo mken.o w _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
