Re: [JS-internals] new js jit sub-module and owner

2013-07-30 Thread Gary Kwong
\o/ Agreed! \o/ -Gary On 7/29/13 5:24 PM, Luke Wagner wrote: JS engine hackers, for the last five years, we've had an exciting sequence of jit compilers added, redesigned and removed. With the recent completion of the IonMonkey and Baseline projects, I think we're finally in a position

[JS-internals] SpiderMonkey standalone builds for Windows on TBPL - should they return?

2014-02-12 Thread Gary Kwong
Some may believe it is time for SpiderMonkey standalone builds for Windows to return, as personally I am admittedly increasingly frustrated at the increasing numbers of Windows-specific build failures. (More may come as :glandium points out, as long as Windows standalone builds are not on

Re: [JS-internals] SpiderMonkey standalone builds for Windows on TBPL - should they return?

2014-02-13 Thread Gary Kwong
On 2/13/14, 12:18 PM, Steve Fink wrote: Sounds like the sticking point is finding someone who will agree to keep them alive. There's no point in turning them on if they're going to be broken for weeks/months at a stretch. This can be mitigated as per Valgrind by having per-commit builds as

[JS-internals] Having the compilation process produce a binary as well as a symbols file

2014-03-05 Thread Gary Kwong
How useful would it be for the compilation process to produce a binary as well as a symbols file for everyone? My usecase would be to be able to archive just the binary and symbols in a cache folder so I don't need to compile it again when testing testcases. Currently if I just keep the

Re: [JS-internals] Tracking SpiderMonkey project priorities?

2014-04-11 Thread Gary Kwong
On 4/11/14, 2:37 AM, Nicolas B. Pierron wrote: Thanks for doing this priority list, at least this make things clear. :) I would suggest to amend it as follow: 6a. *reproducible* topcrash bugs 6b. fuzzblockers […] 9f. *non-reproducible* topcrash bugs - top-crash are not always