On Tuesday 2013-01-15 13:20 -0800, Gregory Szorc wrote:
> This seems to make sense. My only concern is if there is a scenario
> where you absolutely need to push without incurring a build (think
> merge commit where you don't have control over the previous
> commits). I'm not sure why we'd do that,
On Mon, Dec 26, 2011 at 12:54 PM, Brian Smith wrote:
> Henri Sivonen wrote:
>> I suspect some of our localizations have inappropriate defaults for
>> the fallback character encoding. On the conceptual level, telemetry
>> could be used to discover
>> a) how often pages end up relying on the fallbac
Dear All,
I ported a rather large xulrunner 1.9.2 based application to xulrunner 17.0.1.
So far, most of all functionality still works.
I use both JS and C++ xpcoms, initiated via JS and defined within
chrome.manifest. I can use those xpcoms, no issues at all.
However, on shutdown, the thing
Am Mittwoch, 16. Januar 2013 15:53:13 UTC+1 schrieb pmill...@gmail.com:
>
> However, on shutdown, the thing breaks badly. I can see from debugging, that
> non of the destructors within the C++ xpcoms get called. I get a free()
> corruption somewhere "near" one xpcom and "near" xpcomglue - if I c
Do we have any alternative to when you need pow() or other such
elementary functions? Normally I am Mr. We Should Use The Standard
Library, but in particular tends to have weird shit in it that
causes conflicts with xpcom headers, surprising behavior when everything
isn't a 'double', etc. I
For starters, the standard C++ library is already much better. You
get an overloaded/templatized pow(x,y) that does the right thing, instead
of pow()-only-for-double / powf()-only-for-float.
http://en.cppreference.com/w/cpp/numeric/math/pow
Benoit
2013/1/16 Zack Weinberg
> Do we have any alte
On 2013-01-16 2:38 PM, Benoit Jacob wrote:
For starters, the standard C++ library is already much better.
I was under the impression that the headers could not be
used in Mozilla code. Is that no longer the case?
I also expect that should contain at least as much weird shit as
the corre
Mike Hommey wrote:
On Tue, Jan 15, 2013 at 03:19:42PM +, Neil wrote:
Out of interest, where is that set?
For mozjemalloc (current default):
http://hg.mozilla.org/mozilla-central/file/b695e94363b5/memory/mozjemalloc/jemalloc.c#l547
Indeed, I don't know why I didn't spot it there.
-
2013/1/16 Zack Weinberg
> On 2013-01-16 2:38 PM, Benoit Jacob wrote:
>
>> For starters, the standard C++ library is already much better.
>>
>
> I was under the impression that the headers could not be used
> in Mozilla code. Is that no longer the case?
>
Really? I've been using them in all my
Please share your Snappy status on the etherpad by EOD Thursday.
https://etherpad.mozilla.org/snappy
Thanks,
Lawrence
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
hi,
a while ago I removed the need for NS_IMPL_CYCLE_COLLECTION_CLASS() and
its friends NS_IMPL_CYCLE_COLLECTION_NATIVE_CLASS
NS_IMPL_CYCLE_COLLECTION_LEGACY_NATIVE_CLASS
andNS_IMPL_CYCLE_COLLECTION_SCRIPT_HOLDER_NATIVE_CLASS in bug 819215.
I'm now removing the macros alltogether in bug 822289.
e
Thanks for taking care of this!
2013/1/16 Trevor Saunders
> hi,
>
> a while ago I removed the need for NS_IMPL_CYCLE_COLLECTION_CLASS() and
> its friends NS_IMPL_CYCLE_COLLECTION_NATIVE_CLASS
> NS_IMPL_CYCLE_COLLECTION_LEGACY_NATIVE_CLASS
> andNS_IMPL_CYCLE_COLLECTION_SCRIPT_HOLDER_NATIVE_CLASS
12 matches
Mail list logo
