> FWIW, it looks like Mozilla uses the former (gnu++0x) in the build system:
> http://mxr.mozilla.org/mozilla-central/source/build/autoconf/toolchain.m4?mark=152-153#145
Good enough, thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
ht
On 11/15/13, 12:26 PM, Terrence Cole wrote:
The problem this mess is solving, at least in the GC, is that gecko
needs to be able to inline barriers, UnmarkGray, and misc other stuff.
Whenever we accidentally out-of-line anything in these paths we see a
tremendous slowdown on dromaeo_dom and droma
On 11/15/2013 03:16 PM, ops...@gmail.com wrote:
> adding either
> export CXXFLAGS="-std=gnu++0x"
> or
> export CXXFLAGS="-std=gnu++11"
> both seem to work. From Mozilla's perspective -- is one preferable?
FWIW, it looks like Mozilla uses the former (gnu++0x) in the build system:
http://mxr.m
@Jeff
reading here,
http://gcc.gnu.org/projects/cxx0x.html
adding either
export CXXFLAGS="-std=gnu++0x"
or
export CXXFLAGS="-std=gnu++11"
both seem to work. From Mozilla's perspective -- is one preferable?
___
dev-platform mailing list
dev-p
You need to compile as C++11 to use sufficiently Mozilla headers. If you look
at the error you're getting, it's clear your compiler isn't treating
|static_assert| as referring to the built-in construct in C++11. Adding
-std=c++0x or -std=gnu++0x to your commandline should get you past this err
On 11/15/2013 03:01 PM, Jeff Walden wrote:
> You need to compile as C++11 to use sufficiently Mozilla headers.
...sufficiently-recent, that is.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-plat
hi,
I've installed,,
/usr/local/xulrunner-sdk/bin/xulrunner --version
Mozilla XULRunner 25.0.1 - 20131112160018
on
uname -a
Linux andromeda 3.7.10-1.16-desktop #1 SMP PREEMPT Fri May 31
20:21:23 UTC 2013 (97c14ba) x86_64 x86_64 x86_64 GNU/Linux
On 11/15/2013 06:51 AM, Jason Orendorff wrote:
> On 11/14/13 11:43 PM, Gregory Szorc wrote:
>> * Why does lots of js/'s source code gravitate towards the "bad"
>> extreme for most of the metrics (code size, compiler time,
>> preprocessor size)?
>
> We use templates very heavily and we inline like
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place today, Monday, November 18th at 2:30 PM
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/P
I'm trying to manually or programmatically set the geo.wifi.uri for
testing purposes. I've tried to do this several different ways to no
avail.I may be missing something.
In my version of FireFox 25.0 this value is being set via the googleapis
geolocation geolocate webservice.
https://w
On 11/14/13 11:43 PM, Gregory Szorc wrote:
> * Why does lots of js/'s source code gravitate towards the "bad"
> extreme for most of the metrics (code size, compiler time,
> preprocessor size)?
We use templates very heavily and we inline like mad.
Templates make C++ compilers go slowly. The GC sma
On 2013-11-15 4:58 AM, Neil wrote:
Ehsan Akhgari wrote:
we go down from 1m51s on my machine to 31s
And how does that compare to the case where you touch one .cpp file in
each subdirectory of layout?
It depends on which file, obviously, but here is an example with a
random file:
Before th
On 11/15/13 12:43 AM, Gregory Szorc wrote:
* The mean ratio of .o size to lines from preprocessor is 16.35
bytes/line. Why do 38/4916 (0.8%) files have a ratio over 100? Why are a
lot of these in js/ and gfx?
* What's in the 150 files that have 100k+ lines after preprocessing that
makes them so
Ehsan Akhgari wrote:
we go down from 1m51s on my machine to 31s
And how does that compare to the case where you touch one .cpp file in
each subdirectory of layout?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@
14 matches
Mail list logo
