Re: libstdc++ debug mode enabled in debug builds

[Chris Peterson]

Similarly, quite a few third-party libraries do not use the standard 
DEBUG and assert() macros. When integrating new third-party code, be 
sure to check whether you must define any extra macros to enable 
assertions in debug builds.


For example, to enable assertions in the ffvp9 decoder, we had to 
#define ASSERT_LEVEL 2:


https://hg.mozilla.org/mozilla-central/rev/e475e587c448#l1.34


On 5/11/16 4:19 PM, Nathan Froyd wrote:

libstdc++ has a "debug" mode:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

which adds checks for iterator safety and algorithm preconditions.
Bug 1270832, recently landed on inbound, turns this mode on for debug
builds via our wrapped C++ headers.  Please file a bug if you find
that debug mode is not getting turned on when you think it should.

Safer hacking,
-Nathan


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

libstdc++ debug mode enabled in debug builds

[Nathan Froyd]

libstdc++ has a "debug" mode:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

which adds checks for iterator safety and algorithm preconditions.
Bug 1270832, recently landed on inbound, turns this mode on for debug
builds via our wrapped C++ headers.  Please file a bug if you find
that debug mode is not getting turned on when you think it should.

Safer hacking,
-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Telemetry::Accumulate threadsafe?

[Kyle Huey]

Ok.
https://treeherder.mozilla.org/logviewer.html#?job_id=27652194=mozilla-inbound#L9753
seems to indicate that it is not currently threadsafe, but 1258183 adds a
lot of locks so hopefully that will help.

- Kyle

On Wed, May 11, 2016 at 11:46 AM, Georg Fritzsche 
wrote:

> Bug 1141565 made it thread-safe, bug 1258183 is dealing with some
> remaining TSan issues.
>
> Georg
>
> On Wed, May 11, 2016 at 7:23 PM, Kyle Huey  wrote:
>
>> And if not, why is this not documented?
>>
>> - Kyle
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Telemetry::Accumulate threadsafe?

[Georg Fritzsche]

Bug 1141565 made it thread-safe, bug 1258183 is dealing with some remaining
TSan issues.

Georg

On Wed, May 11, 2016 at 7:23 PM, Kyle Huey  wrote:

> And if not, why is this not documented?
>
> - Kyle
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is Telemetry::Accumulate threadsafe?

[Kyle Huey]

And if not, why is this not documented?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Boris Zbarsky]

On 5/11/16 12:46 PM, Mike Taylor wrote:

Is there any handy way of identifying these, other than
cross-referencing with the relevant specs?


Generally they are in a separate partial interface in the webidl file. 
And typically that partial interface is documented as non-standard or 
Gecko-only or something.  At least that's how it works when people are 
being careful and annotating all the IDL snippets with the spec links 
for where they come from.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/11/16 3:56 AM, Cameron McCormack wrote:

Recording use counter information as we parse CSS is not too expensive,
although if we were doing it for all ~300 properties I’d be wanting to
check that we don’t slow sheet parsing speed down appreciably.  It’s
probably fine, but see the work that is done when recording one here:

  https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#13129

We use a std::bitset<> on the document to store the “use counted or not”
for each use counter so the memory overhead is low.  Someone with more
familiarity about the actual Telemetry payload can say whether it would
be alarming to have ~300 new entries, if you plan to eventually include
all properties.


bsmedberg got pinged in the bug to give feedback on that.


But starting with recording all of our non-standard property usage
sounds fine.


I've changed the bug title to start with non-standard props and we can 
take it from there.



Note that UseCounters.conf only supports longhand
properties currently, since we record them in here, where we’ve already
expanded shorthands out to their component longhands:

  
https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSDataBlock.cpp#712

We could handle shorthands by recording them earlier, up in nsCSSParser
somewhere.


Good to know, thanks.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/10/16 6:53 PM, Jonas Sicking wrote:

The moz-isms aren't as easy to spot in the DOM since there's much less
of a history of prefixing DOM-API names, but they certainly exist.


Is there any handy way of identifying these, other than 
cross-referencing with the relevant specs?


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: unprefix :dir pseudo-class

[L. David Baron]

On Wednesday 2016-05-11 18:31 +1000, Cameron McCormack wrote:
> Mike de Boer:
> > We use :-moz-locale-dir extensively in frontend code. Who will own
> > converting that to the unprefixed version? Or, if :-moz-locale-dir
> > is still supported after the transition period, can we discuss
> > deprecating it in favour of unprefixed alternatives?
> 
> :-moz-locale-dir is kind of XUL-specific, so I don’t think there’s an
> obvious standards track alternative.  (It basically means “is this
> element in a XUL document for which
> https://dxr.mozilla.org/mozilla-central/source/dom/xul/XULDocument.cpp#4488
> returns a value that matches the pseudo-classes’ argument”, which
> involves looking at localedir="" on the root element or a pref.)

To be clear, this change doesn't affect :-moz-locale-dir at all.
What's changing is that :-moz-dir (no "locale") is now preferably
known as :dir, and :-moz-dir will go away in a bit.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[natanael . copa]

On Tuesday, March 22, 2016 at 11:06:18 PM UTC, Petr Cerny wrote:
> i.stakenvic...@gmail.com wrote:
> > Technically speaking, as i've been told at least, rust can still be
> > built from scratch if ocaml is available on the platform, starting
> > with rust-0.6, to 0.7, 0.8, 0.9, 1.0 and then finally 1.7 or newer.
> > If a distro really does ban cross-compiling to jump directly to
> > rust-1.7 or newer then their developers can stoll go this route to
> > package it.  Theoretically it only needs to be done once, right?
> 
> Question is, whether we'll be fine with some 7 iterations like you 
> suggest or we'd need the ~300 steps Henri mentioned.

I´d like to build rust for alpine linux, which uses musl libc. There is big 
interest among alpine users to get rust working for alpine.

I´d say that 7 iteration is too much, because it is 7 x number of 
architectures. In alpine case it is currently 3 arch, x86, x86_64 and arm. It 
will likely be more.

It would be *very* helpful to be able to bootstrap rust directly from 
C/python/perl/whatever.

-nc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: can't load script in overlayed XUL

[Jorge Villalobos]

On 5/11/16 9:40 AM, oonuma ryouyu wrote:
> I just learning XUL.
> 
> I create simple addon,but it can't load script.
> 
> I tryed this problem for whole two days.
> 
> https://github.com/lv/overlay_xul
> 
> please help me. 
> 

Please use one of the resources listed here for add-on questions:
https://developer.mozilla.org/en-US/Add-ons#Contact_us

Jorge
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

can't load script in overlayed XUL

[oonuma ryouyu]

I just learning XUL.

I create simple addon,but it can't load script.

I tryed this problem for whole two days.

https://github.com/lv/overlay_xul

please help me. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Jeff Muizelaar]

Or mozglue/build/SSE.cpp

-Jeff

On Wed, May 11, 2016 at 9:35 AM, Ehsan Akhgari 
wrote:

> On 2016-05-10 10:01 PM, Robert Strong wrote:
> > On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel 
> > wrote:
> >
> >> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg <
> benja...@smedbergs.us>
> >> wrote:
> >>
> >>> I agree that we should drop support for non-SSE2. It mattered 7 years
> ago
> >>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it
> really
> >>> doesn't matter now.
> >>>
> >>> We do need to avoid updating these users to a build that will crash,
> and
> >> do
> >>> the same "unsupported" messaging we're doing for old versions of MacOS.
> >>> Gregory, will you own that? You will probably need to add CPU feature
> >>> detection to the update URL/params for 47, or use some kind of system
> >> addon
> >>> to shunt these users off the main update path.
> >>>
> >>
> >> Benjamin - We're likely going to want to do this again in the future.
> Not
> >> that Greg isn't capable but is there someone more familiar with the
> update
> >> system who can step in to get this done?
> >>
> > The majority of this involves getting whether the CPU supports SSE. The
> app
> > update part involves inserting the value into the url.
>
> In theory you should be able to lift that code from
> <
> https://dxr.mozilla.org/mozilla-central/source/js/src/jit/x86-shared/Assembler-x86-shared.cpp#219
> >.
>  Unfortunately I don't think this is exported from the JS engine, but
> should be possible to copy the CPU feature detection parts out of it.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Ehsan Akhgari]

On 2016-05-10 9:43 PM, Lawrence Mandel wrote:
> On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari  > wrote:
> 
> On 2016-05-10 4:45 PM, Gregory Szorc wrote:
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  > wrote:
> >
> >> There is a compiler bug in VS2015 that results in SSE instructions 
> being
> >> emitted when they shouldn't be. Since Firefox still needs to remain
> >> compatible with ancient hardware that doesn't support SSE, this is 
> causing
> >> crashes on Firefox built with VS2015 (see bug 1265615).
> >>
> >> The good news is glandium found a pretty minimal reproduce case and
> >> reported the bug to Microsoft.
> >>
> >> The bad news is the issue still reproduces in the latest pre-release
> >> version of the Visual C++ toolchain.
> >>
> >> The worse news is we'll have to revert to building Firefox 48 (current
> >> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> >> track. Aurora will likely land soon. Central might take a few days, as 
> I
> >> believe VS2013 is a bit broken on central at the moment.
> >>
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
> 
> Firstly, great to hear this!
> 
> But since the topic of when to drop support for legacy platforms seems
> to be coming up a few times per week these days, it would be helpful to
> document somewhere how the decision to drop support for processors not
> supporting SSE was reached.  Do we have data covering what number of
> users will be affected by this change?  Do we have guidelines on what's
> the threshold for supporting other similar legacy configs?
> 
> It would be helpful to see some information about this shared here.
> 
> I don't know how this specific decision was reached but I did speak with
> Chris Cooper and Peter Dolanjski about developing criteria/guidelines
> for support today. I don't expect us to have something this month but we
> will flesh this out as part of the ongoing conversation about platform
> support.

Thank you, that would be super helpful!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Ehsan Akhgari]

On 2016-05-10 10:01 PM, Robert Strong wrote:
> On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel 
> wrote:
> 
>> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg 
>> wrote:
>>
>>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>>> doesn't matter now.
>>>
>>> We do need to avoid updating these users to a build that will crash, and
>> do
>>> the same "unsupported" messaging we're doing for old versions of MacOS.
>>> Gregory, will you own that? You will probably need to add CPU feature
>>> detection to the update URL/params for 47, or use some kind of system
>> addon
>>> to shunt these users off the main update path.
>>>
>>
>> Benjamin - We're likely going to want to do this again in the future. Not
>> that Greg isn't capable but is there someone more familiar with the update
>> system who can step in to get this done?
>>
> The majority of this involves getting whether the CPU supports SSE. The app
> update part involves inserting the value into the url.

In theory you should be able to lift that code from
.
 Unfortunately I don't think this is exported from the JS engine, but
should be possible to copy the CPU feature detection parts out of it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: unprefix :dir pseudo-class

[Neil Deakin]

On 2016-05-11 4:31 AM, Cameron McCormack wrote:

Mike de Boer:

We use :-moz-locale-dir extensively in frontend code. Who will own
converting that to the unprefixed version? Or, if :-moz-locale-dir
is still supported after the transition period, can we discuss
deprecating it in favour of unprefixed alternatives?


:-moz-locale-dir is kind of XUL-specific, so I don’t think there’s an
obvious standards track alternative.  (It basically means “is this
element in a XUL document for which
https://dxr.mozilla.org/mozilla-central/source/dom/xul/XULDocument.cpp#4488
returns a value that matches the pseudo-classes’ argument”, which
involves looking at localedir="" on the root element or a pref.)



For a xul document, it actually means match the directionality of the 
locale of the user agent for that document. It never matches in an html 
document, although there is a bug 588996 to support this.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Cameron McCormack]

Mike Taylor:
> Having recently discovered UseCounters.conf[1], I'd like to add use
> counters for all CSS properties, starting with prefixed props. And
> likewise for Moz-prefixed DOM props and methods.
> 
> Ultimately, I'd like us to have a Firefox equivalent to
> https://www.chromestatus.com/metrics/css/popularity to help us make
> decisions around removing support for non-standard-isms without
> breaking the web.
> 
> (https://platform-status.mozilla.org/ seems like a good home for
> this kind of data)
> 
> Before I start writing patches, is there any reason to not do this?

Recording use counter information as we parse CSS is not too expensive,
although if we were doing it for all ~300 properties I’d be wanting to
check that we don’t slow sheet parsing speed down appreciably.  It’s
probably fine, but see the work that is done when recording one here:

  https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#13129

We use a std::bitset<> on the document to store the “use counted or not”
for each use counter so the memory overhead is low.  Someone with more
familiarity about the actual Telemetry payload can say whether it would
be alarming to have ~300 new entries, if you plan to eventually include
all properties.

But starting with recording all of our non-standard property usage
sounds fine.  Note that UseCounters.conf only supports longhand
properties currently, since we record them in here, where we’ve already
expanded shorthands out to their component longhands:

  
https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSDataBlock.cpp#712

We could handle shorthands by recording them earlier, up in nsCSSParser
somewhere.

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: unprefix :dir pseudo-class

[Cameron McCormack]

Mike de Boer:
> We use :-moz-locale-dir extensively in frontend code. Who will own
> converting that to the unprefixed version? Or, if :-moz-locale-dir
> is still supported after the transition period, can we discuss
> deprecating it in favour of unprefixed alternatives?

:-moz-locale-dir is kind of XUL-specific, so I don’t think there’s an
obvious standards track alternative.  (It basically means “is this
element in a XUL document for which
https://dxr.mozilla.org/mozilla-central/source/dom/xul/XULDocument.cpp#4488
returns a value that matches the pseudo-classes’ argument”, which
involves looking at localedir="" on the root element or a pref.)

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: unprefix :dir pseudo-class

[Mike de Boer]

We use :-moz-locale-dir extensively in frontend code. Who will own converting 
that to the unprefixed version?
Or, if :-moz-locale-dir is still supported after the transition period, can we 
discuss deprecating it in favour of unprefixed alternatives?

Thanks,

Mike.

> On 11 May 2016, at 09:13, Astley Chen  wrote:
> 
> With the patches landed in bug 859301 
> , the :dir 
>  CSS4 pseudo-class is 
> now available in Firefox49 without the vender prefix.
> The prefixed :-moz-dir pseudo-class will be kept for a short transition 
> period(3 release cycles) and removed by bug 1270406 
> .
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=859301
> Spec: https://drafts.csswg.org/selectors-4/#the-dir-pseudo
> Target Release: Firefox 49
> 
> —--
> Best Regards,
> Astley Chen | Mozilla Taiwan 
> 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: unprefix :dir pseudo-class

[Astley Chen]

With the patches landed in bug 859301 
, the :dir 
 CSS4 pseudo-class is 
now available in Firefox49 without the vender prefix.
The prefixed :-moz-dir pseudo-class will be kept for a short transition 
period(3 release cycles) and removed by bug 1270406 
.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=859301
Spec: https://drafts.csswg.org/selectors-4/#the-dir-pseudo
Target Release: Firefox 49

—--
Best Regards,
Astley Chen | Mozilla Taiwan 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform