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-Sili
Hello all,
I'm one of the maintainers of the Jalangi dynamic analysis framework for
JavaScript:
https://github.com/SRA-SiliconValley/jalangi
Jalangi works via source-to-source transformation, and we already have an
implementation of many of the clients you listed (e.g., record/replay, taint
a
On Tue, Nov 19, 2013 at 11:02:52AM +0900, Mike Hommey wrote:
> Hi,
>
> I am going to land a long series of patches that changes how Gecko code
> linkage is defined.
>
> Currently, when you add new code (like, a new module) to Gecko, you:
> - Add a new directory
> - Edit the parent moz.build to ad
Record/replay would be incredibly useful for game developers trying to
do automated testing or go back and analyze a rare failure case that
happens occasionally. I already do a bunch of this on my end by
recording API calls and results and such, having it at a lower JS
level would be incredibly use
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 may
Hi everyone,
Brian Hackett, Bobby Holley, and I have been working on some changes to the way
that add-ons run (bug 990729). These changes make possible a lot of awesome new
features for monitoring add-on performance and memory usage (which I'll talk
about below). However, there's the possibilit
On 6/25/14, 1:06 PM, 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 undesira
On 06/25/2014 01:04 PM, Fitzgerald, Nick wrote:
Yes! We'd absolutely love to show code coverage in the debugger's
source editor! We've played with implementations based on
Debugger.prototype.onEnterFrame and hidden breakpoints, but it is
pretty slow and feels like a huge hack. Would this work
On 25 Jun 2014, at 20:04, Fitzgerald, Nick wrote:
>
> Record/replay is such a holy grail (eclipsed only by "time traveling" /
> reverse and replay interactive (as opposed to a static recording) debugging
> with live, on-stack code editing) that I hesitate to even get my hopes up…
Oh, the joy I
On 6/25/2014 10:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
I've begged this several times, and, as I mentioned
This is terrific!
The docs make mention of POST under bz_rest_options. Do you now (or will you at
some point) support bug creation via API? Would you do full CRUD at some point?
I'm excited to tinker with this. I'd guess REST support will eventually lead to
more creative interfaces on top of
Tainting could also be of use in a particular problem area for Content
Security Policy (CSP): allowing modifications to CSP-protected pages
caused by add-ons or bookmarklets. At the moment, such modifications
(e.g. an add-on injecting tags into a page) are indistinguishable from
malicious content i
How does a gamepad differ from say a keyboard?
What is the purpose of the actor?
I just figured I'd ask these basic questions to help clarify some of the
details that might otherwise be missing.
I'm guessing that dealing with analog joysticks wouldn't be event based, but
would be more of a po
On 6/25/14 5:15 PM, Jason Orendorff wrote:
> We're considering building a JavaScript API for dynamic analysis of JS
> code.
> Here's the sort of thing you could do with it:
I usually don't do this, but since the others have mentioned all the
good reasons and I am likewise totally excited about cod
On 6/25/14, 8:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
As someone who develops JS for Firefox features, code
Yes!!
On 6/25/14, 8:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
Yes! We'd absolutely love to show code coverag
Those are just the API root paths, for reference. For example, to view
a bug, they would be
https://bugzilla.mozilla.org/bzapi/bug/35
https://bugzilla.mozilla.org/rest/bug/35
Mark
On 2014-06-22, 4:42 AM, Josh Matthews wrote:
> [5] https://bugzilla.mozilla.org/bzapi
> [6] https://bugzilla.mozil
On 6/25/2014 11:15 AM, Jason Orendorff wrote:
> We're considering building a JavaScript API for dynamic analysis of JS
> code.
> Here's the sort of thing you could do with it:
>
> - Gather code coverage information (useful for testing/release mgmt?)
>
There have been several JS code coverage impl
Thanks for bringing this to dev-platform.
Dynamic analysis is something the security teams are particularly
interested in. Especially tainting user input is something we could make
use of across the project: Existing security efforts for Firefox OS,
Firefox Desktop, Firefox Mobile and our websites
We're considering building a JavaScript API for dynamic analysis of JS code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
- Trace all object mutation and method calls (useful for devtools?)
- Record/replay of JS execu
On 25/06/2014 15:16:04, Chris Mills wrote:
It looks like a good place to put this information would be as a subsection of
https://developer.mozilla.org/en/docs/Mochitest#Writing_tests
Can you add in a brief section covering this point, along with a brief code
snippet illustrating a good and a b
On 8 May 2014, at 22:02, Irving Reid wrote:
> I've recently fought my way through a bunch of intermittent test
> failures in the Add-on Manager mochitest-browser suite, and there's a
> common anti-pattern where tests receive a Window callback, usually
> "unload", and proceed to do significant wo
22 matches
Mail list logo