On Tuesday, December 18, 2012 6:08:53 PM UTC-8, Norbert Lindenberg wrote:
> On Dec 17, 2012, at 16:15 , Dave Mandelin wrote:
> > On Tuesday, December 11, 2012 3:08:28 PM UTC-8, Jeff Walden wrote:
> So, follow the conventions of function naming used in the ECMAScript specs?
That&
On Tuesday, December 11, 2012 3:08:28 PM UTC-8, Jeff Walden wrote:
> On 12/10/2012 10:02 PM, Norbert Lindenberg wrote:
>
> > a) Should we follow established JavaScript conventions and allow only
> > constructor and namespace names to start with a capital letter (i.e., Array
> > and Intl)? Or sho
On Wednesday, November 21, 2012 11:42:13 AM UTC-8, Bobby Holley wrote:
> On Wed, Nov 21, 2012 at 11:21 AM, Dave Mandelin wrote:
> > On Wednesday, November 21, 2012 11:14:18 AM UTC-8, Bobby Holley wrote:
> > > I've pondered having the JSAPI methods automatically enter
On Wednesday, November 21, 2012 11:29:44 AM UTC-8, smaug wrote:
> On 11/21/2012 09:13 PM, Bobby Holley wrote:
>
> > I know a lot of DOM folks hate the compartment API and a lot of JS folks
> > are sad that the DOM folks hate it, so I'd like to offer an alternative
> > perspective here.
>
> > I th
On Wednesday, November 21, 2012 11:14:18 AM UTC-8, Bobby Holley wrote:
> I've pondered having the JSAPI methods automatically enter compartments,
> but that's kind of sketchy.
What's sketchy about it? I've thought about that before too, and it seemed like
it would probably be OK, although APIs
I was reviewing one of the River Trail patches today and I noticed that it had
to add JS_THREADSAFE everywhere. This seems wrong to me. IIRC, JS_THREADSAFE
originally was a build configuration parameter used to decide between:
- I want a multithreaded engine, at the cost of some locking
ove
On Thursday, October 18, 2012 9:54:33 AM UTC-7, Brendan Eich wrote:
> Terrence Cole wrote:
>
> > On 10/17/2012 10:01 PM, Nicholas Nethercote wrote:
>
> >> Terrence and I have had problems with that one before. IIRC the test
> >> has some bogosity about it, but I don't remember the details --
>
On Friday, September 14, 2012 4:05:53 AM UTC-7, Till Schneidereit wrote:
> My question to the list is, then, what you all think I should work on
> with the highest priority. Obviously, there are still a lot of areas
> of the project that I don't know too well, so I'll have to see what
> even makes
On Tuesday, September 11, 2012 12:32:34 PM UTC-7, Jason Orendorff wrote:
> On Sep 11, 2012, at 9:13 AM, David Bruant wrote:
>
>
>
> > To a large extent, "Firefox x for developers" and compatibility tables
> > already document which version of Firefox implements which JS feature.
>
>
>
> Soun
Thanks for posting this, Tom. There are a lot of good ideas in there. Too many
to do at once, so I think we'll start with 1 or 2, and then think about doing
others over time. So expect to see something soon.
In your last post, you mentioned meetings and meeting notes as being the things
you wan
On Friday, July 13, 2012 1:41:00 PM UTC-7, Dave Mandelin wrote:
> Bill sent this out, but it seems not to have reached the newsgroup, so
> pasting it here. (By the way, to avoid such things, I just post through
> groups.google.com.)
>
> So Bill said:
>
> I didn't res
ofiling. For
now, I think our goal should be to convert as much stuff to handles
and rooters as possible inside the JS engine. It's great that we have
enough rooters to pass the dynamic rooting analysis, but I don't think
we've passed the threshold for handle density where people fee
authors.
- Ongoing maintenance costs. If the API is harder to use, it will
be more work to keep up. If we need to keep static or dynamic
analyses around, that's more ongoing cost.
> Brian
Dave
> - Original Message -
> > From: "Dave Mandelin"
I still have some concerns about our approach for adapting to moving GC. From
the meeting notes, I see that there are some open concerns about maintaining
proper handle usage outside the JS engine (and I'm not sure how easy it's going
to be inside the engine for that matter) and more worrying ev
On Wednesday, June 27, 2012 4:06:03 PM UTC-7, Vyacheslav Egorov wrote:
> It just seems that engine implementors agree that it's impractical to
> optimize it :-)
For my part, I also think it's on its way out of the language due to being a
bad feature :-), so why put in the effort?
There is a topcrash that appears to be caused mostly by add-ons that use
compartments incorrectly [1]. It crashes in a fairly arbitrary place,
GetNameFromBytecode. I think we can fix that crash, but of course the add-ons
in question will still be unsafe.
What should we do about add-ons using co
16 matches
Mail list logo
