On Mon 10 Feb 2014 00:56, Nicholas Nethercote writes:
> For a long time I've had Cachegrind set up to run SunSpider in the
> shell. It's really useful being able to see instruction counts at the
> level of source code lines when optimizing.
>
> I just tried it today for the first time in a while,
On Wed 09 Oct 2013 17:28, Sean Stangl writes:
> Is there anything that can be done on the Solaris side to restrict
> the available memory to only the lower 47 bits of the address space?
https://bugzilla.mozilla.org/show_bug.cgi?id=577056
Andy
___
dev-
On Tue 17 Sep 2013 16:52, Andy Wingo writes:
> It is difficult to preserve compatibility in the builder interface,
> while adding new variations on old syntax. Furthermore there is this
> positional argument protocol, where the builder callback has to know
> which arg maps to whic
Hi,
The Reflect.parse API returns a tree of objects. That's cool. However
Reflect.parse also allows for a user-specified callback to be run
instead on the individual nodes. This is the "builder" interface:
https://developer.mozilla.org/en-US/docs/SpiderMonkey/Parser_API#Builder_objects
So
Hi,
On Fri 06 Sep 2013 21:49, Luke Wagner writes:
> I was thinking about this and it seems like we could flag the
> ParseNode somehow so that Reflect.parse could resugar.
It could work, but it seems quite tricky to get right. I can imagine
lots of debugging related regressions. I don't know h
On Fri 06 Sep 2013 18:32, Luke Wagner writes:
> This brings up a related question: what is the proposed future of the
> builtin Reflect.parse now that we have pure-JS alternatives like
> Esprima?
On the "remove" side, Reflect.parse makes it impossible to do
"desugaring" at the ParseNode level.
6 matches
Mail list logo
