On Fri, Apr 08, 2016 at 04:43:29PM -0700, Nick Fitzgerald wrote:
> Is there a reason why we aren't using LTO?
Last time it was tried, LTO regressed performance compared to the PGO
builds we produce (and yes, both LTO and LTO+PGO were tried).
We recently upgraded GCC to 4.8, so we can give it anot
On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> On 04/08/2016 10:38 AM, Jip de Beer wrote:
>> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
> [...]
>> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran
>> lldb from Terminal as well as Xcode).
>
Is there a reason why we aren't using LTO?
On Fri, Apr 8, 2016 at 4:35 PM, Ted Mielczarek wrote:
> No. GCC *has* an LTO optimizer, but we're not using it. We're just doing
> a PGO build. MSVC requires enabling LTO to use their PGO, so the
> resulting build has both.
>
> -Ted
>
> On Fri, Apr 8, 2
No. GCC *has* an LTO optimizer, but we're not using it. We're just doing
a PGO build. MSVC requires enabling LTO to use their PGO, so the
resulting build has both.
-Ted
On Fri, Apr 8, 2016, at 05:08 PM, Jeff Gilbert wrote:
> I thought Linux did LTO but not PGO?
>
> On Tue, Apr 5, 2016 at 3:53 PM
In the interest of expanding this beyond just the -i=mi stuff, I've created
a metabug for making mach and emacs play nicer together:
https://bugzilla.mozilla.org/show_bug.cgi?id=1263253
If you've got any wants for things emacs could do but doesn't that would
make life developing gecko/ff/sm/etc e
It's noisy in code you *do* understand, which is the bulk of the code
we should be dealing with the majority of the time.
I do not parse this initially as a type because that generally doesn't
make sense given context.
Generally the names involved are also unlikely to be types, based on name alone
On Fri, Apr 8, 2016 at 2:03 PM, Jeff Gilbert wrote:
> Strong preference against eFoo, here. :)
Would you mind saying why?
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2016-04-08 23:03, Jeff Gilbert wrote:
Strong preference against eFoo, here. :)
Strong preference *for* eFoo, here. :)
If I see Bar::Foo anywhere in code I'm not familiar with, my brain
is likely to first parse that as a type before realizing that, hmm
that doesn't make sense in an expressio
On 04/08/2016 10:38 AM, Jip de Beer wrote:
> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
[...]
> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb
> from Terminal as well as Xcode).
> I was able to attach lldb to the browser, but not
On Wed, Apr 6, 2016 at 6:47 PM, Emma Humphries wrote:
>
> I'd like to finish up feedback on by the end of the working day Thursday
> the 6th (PST.)
>
> Then we'll get to work on a solid specification for the work so we can
> start implementation sometime in Q2.
>
Okay, closing off discussion f
I thought Linux did LTO but not PGO?
On Tue, Apr 5, 2016 at 3:53 PM, Mike Hommey wrote:
> On Tue, Apr 05, 2016 at 09:02:09PM +0100, David Burns wrote:
>> Below is a highlight of all work the build peers have done in the last 2
>> weeks as part of their work to modernise the build infrastructure.
I've just landed patches on fx-team which switch the in-tree
configuration and our automatic linting checks to use ESLint 2. If
you're running linting checks locally you will need to update. As
usual "mach eslint --setup" will install the things you need.
___
Strong preference against eFoo, here. :)
Just use enum classes.
On Fri, Apr 8, 2016 at 10:35 AM, smaug wrote:
> On 04/08/2016 07:38 PM, Nick Fitzgerald wrote:
>>
>> On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
>> birunt...@mohanathas.com> wrote:
>>
>>> On 8 April 2016 at 18:10, Kartika
Even better!
On Fri, Apr 8, 2016 at 2:49 PM, Steve Fink wrote:
> On 04/08/2016 09:13 AM, Andreas Farre wrote:
>
>> Looking for someone emacs savvy to help me with running mach --debug as a
>> command for M-x gdb. Currently there is an issue with mach logging a bit
>> to
>> much which screws up t
On 04/08/2016 09:13 AM, Andreas Farre wrote:
Looking for someone emacs savvy to help me with running mach --debug as a
command for M-x gdb. Currently there is an issue with mach logging a bit to
much which screws up the GDB/MI communication with emacs. Has anyone
already some solution for this? O
I've been experimenting with a patch in mach that adds a quiet flag that
sets the verbosity level to WARNING. After that I can start with M-x gdb,
and then substituting the gdb command with:
$HOME/src/gecko/mach --log-file /dev/null run -q --debug
--debugparams="-i=mi -fullname"
and it works.
On
Hmm.. Well, whether platform adopts this universally or not seems like a
question for
Doug and Johnny. Though, I'm sure they'll take your input seriously.
Doug, do you have any thoughts on how long an evaluation period you think is
appropriate here?
-Ekr
On Fri, Apr 8, 2016 at 3:25 PM, Emma Hu
And yes, that's what I mean by Platform.
Thanks.
On Fri, Apr 8, 2016 at 11:24 AM, Andrew McCreight
wrote:
> Emma can correct me if I'm wrong, but I think she is using "Firefox" in
> the non-jargony sense of the entire thing we're shipping in Firefox,
> including Gecko. We've been using this sys
Emma can correct me if I'm wrong, but I think she is using "Firefox" in the
non-jargony sense of the entire thing we're shipping in Firefox, including
Gecko. We've been using this system for a month or so in DOM. I think it
has been going well. Anybody who is interested can ask Andrew Overholt or I
I don't know of a good way to make mach stop chatting in the middle of
GDB's serious conversation with Emacs. It sure would be nice to fix this.
Note that Emacs sets the "EMACS" environment variable to "t" in the GDB
subprocess. Perhaps mach could use this as a way to automatically behave
correctl
On Friday, 8 April 2016 20:06:19 UTC+2, Jeff Muizelaar wrote:
> Check out
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Layout_Debugger.
> I expect it gets the information that you're looking for.
>
> -Jeff
>
> On Fri, Apr 8, 2016 at 1:38 PM, Jip de Beer wrote:
> > Hi all,
> >
>
Check out
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Layout_Debugger.
I expect it gets the information that you're looking for.
-Jeff
On Fri, Apr 8, 2016 at 1:38 PM, Jip de Beer wrote:
> Hi all,
>
> I would like to inspect the Frame Tree (or Render Tree:
> http://www.html5rocks
https://bugzilla.mozilla.org/show_bug.cgi?id=1254313
I've had this filed for a while now, just need to do something about it. :/
On Fri, Apr 8, 2016 at 9:13 AM, Andreas Farre wrote:
> Looking for someone emacs savvy to help me with running mach --debug as a
> command for M-x gdb. Currently ther
Emma,
Thanks for doing this.
I'm not sure whether something like this would work for platform engineering,
but we'll keep an eye how things develop with Firefox and might consider it
once we have some experience there. I encourage you to report back here when
Firefox starts using this system
On 04/08/2016 07:38 PM, Nick Fitzgerald wrote:
On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:
On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
Others?
enum class OptionD {
SentenceCaseValues,
ThisWontBeConfusedWithOtherThings
// ... because
Hi all,
I would like to inspect the Frame Tree (or Render Tree:
http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Render_tree_construction)
in real time while browsing with Firefox.
I first tried to access this tree with JavaScript or a browser addon. It seems
that this informa
On Fri, Apr 8, 2016 at 10:54 AM, Benjamin Smedberg
wrote:
> On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron wrote:
>> Why it's important
>> What makes this problem important or urgent to fix?
>>
>
> Yes! If this isn't clear, who owns this? Either the module owner/peer, or a
> product m
On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:
> On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
> > Others?
>
> enum class OptionD {
> SentenceCaseValues,
> ThisWontBeConfusedWithOtherThings
> // ... because you need to use OptionD::ThisWontBeConfu
On 04/08/2016 06:10 PM, Kartikaya Gupta wrote:
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, a
On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
> Others?
enum class OptionD {
SentenceCaseValues,
ThisWontBeConfusedWithOtherThings
// ... because you need to use OptionD::ThisWontBeConfusedWithOtherThings
};
___
dev-platform mailing list
dev-pl
Looking for someone emacs savvy to help me with running mach --debug as a
command for M-x gdb. Currently there is an issue with mach logging a bit to
much which screws up the GDB/MI communication with emacs. Has anyone
already some solution for this? Otherwise I got it working by adding a
quiet fla
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, and update the style guide
accordingly.
enum Opti
On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron wrote:
>
>
> I don't think the idea that a bug belongs in the triage queue if it
> is untriaged and without a needinfo? is the right process. I think,
> instead, that there should be less emphasis on needinfo? to a
> specific person, and more emphas
33 matches
Mail list logo
