On 11/13/2012 3:53 PM, Alex Keybl wrote:
If the Snappy initiative (or any other group of Mozillians) has short-term
plans to evangelize the perf wins of PGO to Linux distros, I agree that we
should leave PGO builds and testing enabled on Linux and further investigate
the mysterious crash in bu
On 2012-11-13 5:03 PM, Justin Dolske wrote:
On 11/13/12 4:34 PM, Ehsan Akhgari wrote:
But the point here is that unless we know for sure that we're dealing
with a compiler bug, disabling Linux PGO builds may just wallpaper over
the problem.
That's quite possible, and I'm sure there are other
On 11/13/12 4:34 PM, Ehsan Akhgari wrote:
But the point here is that unless we know for sure that we're dealing
with a compiler bug, disabling Linux PGO builds may just wallpaper over
the problem.
That's quite possible, and I'm sure there are other currently-used ways
to exercise the code tha
On 2012-11-13 3:30 PM, Justin Dolske wrote:
On 11/13/12 10:27 AM, Ehsan Akhgari wrote:
Agreed. Actually, reading the bug closely, there's nothing which says
someone has tried to debug this (it's not even clear if it's
reproducible locally), and it seems like the only evidence that we have
abou
If the Snappy initiative (or any other group of Mozillians) has short-term
plans to evangelize the perf wins of PGO to Linux distros, I agree that we
should leave PGO builds and testing enabled on Linux and further investigate
the mysterious crash in bug 799295. Otherwise, our builds/testing sho
On 11/13/12 10:27 AM, Ehsan Akhgari wrote:
Agreed. Actually, reading the bug closely, there's nothing which says
someone has tried to debug this (it's not even clear if it's
reproducible locally), and it seems like the only evidence that we have
about this being PGO related is that it happens o
On 13.11.2012 12:24, jim.math...@gmail.com wrote:
On Tuesday, November 13, 2012 4:49:14 AM UTC-6, Jonas Sicking wrote:
Note that putting "touch" in the UA is somewhat different than
traditional UA sniffing. It's actually capability testing which is
what we are encouraging people to do. Using HTT
The Snappy meeting is held bi-weekly to discuss issues with Firefox
responsiveness and the various responsiveness initiatives that are underway.
This week is a Snappy meeting ON week.
Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy
Dial-in: co
Henri Sivonen writes:
> On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup wrote:
>> The WebRTC API (and MediaStream API via the Media Capture Task Force and
>> getUserMedia()) is very much still in flux.
>
> I’m not familiar with these specs, so I don’t know why they are still in flux.
Mostly beca
On 11/13/12 10:27, Archaeopteryx wrote:
Hi,
what is the recommend way to import JavaScript code modules in files
part of Gecko?
1) Don't add the import line
Components.utils.import("resource://app/my_module.jsm"); into the file
if the module has already been loaded by a different JavaScript fil
This week's MemShrink meeting will be brought to you by infallible allocation
from Gecko Layout arenas:
https://bugzilla.mozilla.org/show_bug.cgi?id=809533
Note:
* New meeting time (2:00pm PST)
* New meeting room (today only)
The wiki page for this meeting is at:
https://wiki.mozilla.org/P
On 11/13/2012 01:34 AM, Robert O'Callahan wrote:
> Why is "using mozilla::RangedPtr" required; is "RangedPtr" ambiguous?
It's not -- just the increasing concern about using-collisions if we open the
whole mozilla namespace, which we'd rather not do because of the possibility
(actuality, for Rang
Hi,
what is the recommend way to import JavaScript code modules in files
part of Gecko?
1) Don't add the import line
Components.utils.import("resource://app/my_module.jsm"); into the file
if the module has already been loaded by a different JavaScript file
load earlier.
Advantage: Fastest
On 2012-11-13 9:56 AM, Jonathan Kew wrote:
On 12/11/12 15:47, Alex Keybl wrote:
Bug 799295 [1], the driver for this thread, is still an open issue for
FF18 (shipping in 6 weeks). The JS team's recommendation remains to
disable PGO on Linux. According to Taras, the major benefits of PGO on
Linux
On 2012-11-12 6:01 AM, Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari wrote:
Sort of. Well, from time to time we add a new DOM API which breaks a
website because they expect that name to be available as an expando property
or something.
Prefixing doesn't fix this problem
On 12/11/12 15:47, Alex Keybl wrote:
Bug 799295 [1], the driver for this thread, is still an open issue for FF18 (shipping in
6 weeks). The JS team's recommendation remains to disable PGO on Linux. According to
Taras, the major benefits of PGO on Linux are for a "starry-eyed-future". Given
al
On Tuesday, November 13, 2012 2:49:14 AM UTC-8, Jonas Sicking wrote:
> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd want to send a different piece of
> main content.
Just to be clear, this is NOT generally true in what I've seen. Websit
btw,
To some extend it will be possible to create a XUL port in HTML via some CSS
trickery. I also hope that XBL/XBL2 picks up to simplify this process even
further. However, we are talking about some serious commitment here because it
is a lot of work.
On Monday, November 12, 2012 7:22:13 PM
On 13.11.2012 00:47, Alex Keybl wrote:
>almost nobody uses Mozilla Firefox builds(and no Firefox disributors do pgo)
We should really get the latter fixed. Disabling PGO for our builds
seems like a step in the wrong direction; the numbers collected in this
thread suggest that it's a major los
On 11/12/2012 9:53 PM, Jeff Walden wrote:
> At the time the web server was introduced I don't believe we had
> Python as a build requirement, so we couldn't have used some
> Python-based server (the option most likely to be somehow portable
> across browsers/engines). That probably could be address
On 12.11.2012 19:05, Matt Brubeck wrote:
* Sites that follow our existing guidelines to send tablet-optimized
content to Firefox for Android tablets will not need any changes, and
will immediately begin serving tablet-optimized content to Firefox for
Metro.
Is there a significant amount of such
Henri Sivonen wrote:
On Tue, Nov 13, 2012 at 12:14 PM, Neil wrote:
Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 7:38 PM, Neil wrote:
Is there any way we can make it so that the prefixed version doesn't work
unless you attempt (and presumably fail) to detect the unprefixed version
On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup wrote:
> The WebRTC API (and MediaStream API via the Media Capture Task Force and
> getUserMedia()) is very much still in flux.
I’m not familiar with these specs, so I don’t know why they are still in flux.
> Chrome is shipping enabled-by-default so
jim.math...@gmail.com wrote:
Key notes -
* The 8.0 SDK requires Windows 7 (or Windows Server 2008 R2)
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platf
On Tuesday, November 13, 2012 4:49:14 AM UTC-6, Jonas Sicking wrote:
> Note that API detection is only possible client-side. (And using
> javascript, though this is less of an issue).
>
> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd wan
On Mon, Nov 12, 2012 at 7:51 AM, Gervase Markham wrote:
> D) Use neither, like Chrome. UA sniffing is evil. Developers should use the
> presence of a touch API to detect touch capability, and use flexible layout
> to adapt to whatever screen size the user has. This is Google's approach.
Note that
On Tue, Nov 13, 2012 at 12:14 PM, Neil wrote:
> Henri Sivonen wrote:
>
>> On Fri, Nov 9, 2012 at 7:38 PM, Neil wrote:
>>> Is there any way we can make it so that the prefixed version doesn't work
>>> unless you attempt (and presumably fail) to detect the unprefixed version?
>>
>> What purpose wou
Robert O'Callahan wrote:
On Mon, Nov 12, 2012 at 8:37 PM, Jeff Walden wrote:
We ended up removing the nested |using| above and making all SpiderMonkey
headers qualify everything with mozilla::. We use few enough things from
mozilla:: so far that we switched to |using mozilla::RangedPtr| an
Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 7:38 PM, Neil wrote:
Is there any way we can make it so that the prefixed version doesn't work
unless you attempt (and presumably fail) to detect the unprefixed version?
What purpose would the prefix serve in such a scenario?
You'd pref
On Mon, Nov 12, 2012 at 8:37 PM, Jeff Walden wrote:
> We ended up removing the nested |using| above and making all SpiderMonkey
> headers qualify everything with mozilla::. We use few enough things from
> mozilla:: so far that we switched to |using mozilla::RangedPtr| and so on
> in .cpp files a
On Mon, Nov 12, 2012 at 8:05 PM, Matt Brubeck wrote:
> PROPOSAL:
>
> * We should add "Tablet" to the User-Agent header when the the Metro Firefox
> UI is used *and* the hardware supports touch input.
>
> * For non-touch hardware, we should make no changes to the User-Agent
> header.
>
> * For the
Henri Sivonen writes:
> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari
> wrote:
>> But that's not really important, I'm mostly concerned about
>> the stuff that we will ship in the future. The specific thing that I'm
>> worried about is Web Audio which is a huge spec and we may not be able to
32 matches
Mail list logo
