The weekly Engineering meeting will be broadcast on Air Mozilla starting this
coming week (Aug 6, 2013). The reasons for broadcasting this meeting on Air
Mozilla are to:
1. provide a recording of the meeting for those who unable to attend at the
scheduled time
2. make it easier for people to at
On Fri, Aug 2, 2013 at 9:12 PM, Kyle Huey wrote:
> On Fri, Aug 2, 2013 at 8:59 PM, L. David Baron wrote:
>
>> khuey was also recently working on something to reduce some pretty
>> bad #include fanout related to the new DOM bindings generation.
>> (I'm not sure if it's landed.)
>>
>
> That was bu
On Fri, Aug 2, 2013 at 8:59 PM, L. David Baron wrote:
> khuey was also recently working on something to reduce some pretty
> bad #include fanout related to the new DOM bindings generation.
> (I'm not sure if it's landed.)
>
That was bug 887553. I'll land it on Monday.
- Kyle
__
On Saturday 2013-08-03 13:36 +1000, Nicholas Nethercote wrote:
> > # Header dependency hell
>
> I've recently done a bunch of work on improving the header situation
> in SpiderMonkey. I can break it down to two main areas.
>
> == MINIMIZING #include STATEMENTS ==
>
> There's a clang tool called
> Building mozilla-central has gotten noticeably slower.
Yep. A bit over two years ago I started doing frequent browser builds
for the first time; previously I'd mostly just worked with the JS
shell. I was horrified by the ~25 minutes it took for a clobber
build. I got a new Linux64 box and bu
On 8/2/2013 10:09 PM, Brian Smith wrote:
2. It is reasonable to expect that std::whatever works as the C++
standard says it should. It isn't reasonable to expect
mozilla::Whatever to work exactly like std::whatever. And, often,
mozilla::Whatever isn't actually the same as std::whatever
Judgin
On 8/2/2013 4:21 PM, Brian Smith wrote:
For purposes of discussion, I think it's worth breaking down the C++ (and
C) standard library into the following components:
* Containers--vector, map, etc.
* Strings
* I/O
* Platform support (threading, networking, filesystems, locales)
* Other helpful uti
On Sat, Aug 3, 2013 at 12:47 AM, Ehsan Akhgari wrote:
> On 2013-08-02 5:21 PM, Brian Smith wrote:
>
>> 3. How should we handle bridge support for standardized features not yet
>>> universally-implemented?
>>>
>>>
>> Generally, I would much rather we implement std::whatever ourselves than
>> implem
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
> On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote:
>
> > This adds too much risk of security patches failing to backport from
> >
> >> mozilla-central to ESR 24. Remember that one of the design goals of ESR
> >> is to minimize the a
On Fri, Aug 02, 2013 at 02:44:57PM -0700, Justin Lebar wrote:
> > I agree that iostream-based logging would be safer. If we had it I
> > wouldn't have had to work on this one:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=855335
>
> I can't access that bug, but maybe you mean
> https://bug
On Fri, Aug 02, 2013 at 06:47:08PM -0400, Ehsan Akhgari wrote:
> On 2013-08-02 5:21 PM, Brian Smith wrote:
> >>3. How should we handle bridge support for standardized features not yet
> >>universally-implemented?
> >>
> >
> >Generally, I would much rather we implement std::whatever ourselves than
>
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari wrote:
> On 2013-08-02 4:49 PM, Brian Smith wrote:
>
>> That sounds reasonable to me. So, based on that then, let's get back to my
>> original question that motivated the discussion of the policy: If we add
>> std::move, std::forward, and std::unique_
On Sat, Aug 3, 2013 at 1:32 AM, Robert O'Callahan wrote:
> On Sat, Aug 3, 2013 at 9:13 AM, Gregory Szorc wrote:
>
> > Many of the complaints I've heard have been from overhearing hallway
> > conversations, noticing non-directed complaints on IRC, having 3rd
> parties
> > report anecdotes, etc. *P
On 8/2/13 8:14 PM, Brian Smith wrote:
The risk that any developer would need to
waste time on ESR just to support a product that isn't even Firefox on a
platform that virtually nobody uses, and the risk that comes with making
any changes to the security fix that you are trying to backport.
I fe
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote:
> This adds too much risk of security patches failing to backport from
>
>> mozilla-central to ESR 24. Remember that one of the design goals of ESR
>> is to minimize the amount of effort we put into it so that ESR doesn't
>> slow down real Fire
On 8/2/13 4:43 PM, Robert O'Callahan wrote:
Nathan has just made an excellent post on this topic:
https://blog.mozilla.org/nfroyd/2013/08/02/i-got-99-problems-and-compilation-time-is-one-of-them/
It would be interesting to measure the number of non-blank precompiled
lines in each build, over tim
On Fri, Aug 02, 2013 at 04:32:08PM -0700, Gregory Szorc wrote:
> On 8/2/13 3:38 PM, Ehsan Akhgari wrote:
> >Hmm. I'm not sure if the number of source files is directly correlated
> >to build times, but yeah there's clearly a trend here!
>
> I concede a lines of code count would be a better indica
On Sat, Aug 3, 2013 at 11:43 AM, Robert O'Callahan wrote:
> It would be interesting to measure the number of non-blank precompiled
> lines in each build, over time.
>
Gah, I meant preprocessed, not precompiled.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le
Nathan has just made an excellent post on this topic:
https://blog.mozilla.org/nfroyd/2013/08/02/i-got-99-problems-and-compilation-time-is-one-of-them/
It would be interesting to measure the number of non-blank precompiled
lines in each build, over time. This is probably going up faster than the
n
On 8/2/13 3:38 PM, Ehsan Akhgari wrote:
Hmm. I'm not sure if the number of source files is directly correlated
to build times, but yeah there's clearly a trend here!
I concede a lines of code count would be a better indicator. I'm lazy.
# Header dependency hell
I have been playing with an i
On Sat, Aug 3, 2013 at 9:13 AM, Gregory Szorc wrote:
> Many of the complaints I've heard have been from overhearing hallway
> conversations, noticing non-directed complaints on IRC, having 3rd parties
> report anecdotes, etc. *Please, please, please voice your complaints
> directly at me and the
It was brought to my attention that it's unclear what I'm looking for in
this conversation, so let me try to summarize. I am not convinced that
there is something wrong with the way that things currently work (polyfill
where the feature is not available everywhere, else use it if
appropriate). I'
Brian Smith wrote:
We have mozilla-build for Windows. From what you say, it sounds like we should
have mozilla-build for Linux too that would include a pre-built GCC or Clang or
whatever we choose as *the* toolchain for desktop Linux.
mozilla-build doesn't include a compiler or SDK. At one po
On Fri, Aug 2, 2013 at 3:38 PM, Ehsan Akhgari wrote:
> # Building faster
>>
>> One of our Q3 goals is to replace the "export tier" with something more
>> efficient. More on tiers at [1]. This should make builds faster,
>> especially on pymake. Just earlier this week we made WebIDL and XPIDL
>> cod
On 2013-08-02 4:39 PM, Brian Smith wrote:
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey mailto:m...@glandium.org>> wrote:
> Upgrading minimum compiler requirements doesn't imply backporting
those
> requirements to Aurora where ESR24 is right now. Are you opposed to
> updating o
On 2013-08-02 4:49 PM, Brian Smith wrote:
That sounds reasonable to me. So, based on that then, let's get back to my
original question that motivated the discussion of the policy: If we add
std::move, std::forward, and std::unique_ptr to STLPort for Android and
B2G, can we start using std::move,
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement mozilla::Whatever, all other things being equal.
Yes, but it's still
First of all, I'd like to thank you and the rest of the build peers for
your tireless efforts!
On 2013-08-02 5:13 PM, Gregory Szorc wrote:
(Cross posting. Please reply to dev.builds.)
Sorry, but cross-posting to both lists. I don't think most of the
people interested in this conversation ar
On 8/2/2013 1:52 PM, Jeff Gilbert wrote:
It's certainly worrying given the number of security- and privacy-related
addons people rely on working. Seeing ads in thumbnails is relatively harmless
(if disconcerting), but if someone is relying on an addon for important
security or privacy reasons,
Sorry I should've noticed that 855335 is a sec-bug. It's title is "Audit
SIPCC printf-style format strings" which means we went through every
logging call and repaired a few which had incorrect printf-style args.
-EH
On Fri, Aug 2, 2013 at 2:44 PM, Justin Lebar wrote:
> > I agree that iostr
> I agree that iostream-based logging would be safer. If we had it I
> wouldn't have had to work on this one:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ?
I feel like the goals there a
>It is very useful for building a logging interface that is safer and more
>convenient than NSPR's printf-style logging. Note that, again, Eric
>Rescorla already built an (partial) iostream-based wrapper around NSPR for
>WebRTC. I would say that, if there is no additional overhead, then we
>should
On Wed, Jul 31, 2013 at 7:41 PM, Joshua Cranmer 🐧 wrote:
> implementation, libc++, libstdc++, and stlport. Since most nice charts of
> C++11 compatibility focus on what the compiler needs to do, I've put
> together a high-level overview of the major additions to the standard
> library [3]:
> * std
(Cross posting. Please reply to dev.builds.)
I've noticed an increase in the number of complaints about the build
system recently. I'm not surprised. Building mozilla-central has gotten
noticeably slower. More on that below. But first, a request.
Many of the complaints I've heard have been fr
It's certainly worrying given the number of security- and privacy-related
addons people rely on working. Seeing ads in thumbnails is relatively harmless
(if disconcerting), but if someone is relying on an addon for important
security or privacy reasons, and we auto-updated them and bypassed thei
On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer 🐧 wrote:
> On 8/1/2013 5:46 PM, Brian Smith wrote:
>
>> FWIW, I talked about this issue with a group of ~10 Mozillians here in
>> Berlin and all of them (AFAICT) were in favor of requiring that the latest
>> versions of GCC be used, or even dropping G
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey wrote:
> > Upgrading minimum compiler requirements doesn't imply backporting those
> > requirements to Aurora where ESR24 is right now. Are you opposed to
> > updating our minimum supported gcc to 4.7 on trunk when Firefox OS is
> ready
> > to switch?
On 02/08/2013 16:57, t...@adblockplus.org wrote:
> The code in question was explicitly running in Firefox Mobile only.
> It used messageManager.loadFrameScript() API to inject code into the
> content process of new tabs - I doubt that it will work the same
> here, Adblock Plus would probably need
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
> On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey wrote:
>
> > On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
> > > Debian doesn't keep Iceweasel up to date in oldstable anyway.
> >
> > Actually, I'm providing backports for
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey wrote:
> On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
> > Debian doesn't keep Iceweasel up to date in oldstable anyway.
>
> Actually, I'm providing backports for oldstable. 24 is as far as I'm
> ready to go to support oldstable until it
We are working on ways to make add-ons like adblock work with e10s on
desktop without major changes to the add-on. That mechanism might work
for the thumbnail case. Gavin can reach out to trev and discuss whether
this is something we should try to make work. I do agree this isn't
super high p
On 02/08/2013 03:50, Nicholas Nethercote wrote:
On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp wrote:
Do you have specific issues you're worried about, or are you just speaking
about issues in general?
This AdBlock issue worries me specifically. And the fact that there's
breakage with our #1 a
On 02.08.2013 03:35, Gavin Sharp wrote:
> The experiment you're referring to was Adblock running in Firefox with
> remote tabs enabled, I think. I'm not up to date with how that
> experiment was progressing, but I think there are some fundamental
> differences between that scenario and the backgrou
43 matches
Mail list logo
