On Thu, Jun 4, 2015 at 1:48 PM, Luke Wagner wrote:
> In addition to judging noisiness by volume over a whole test run, can we
> also include any warning that happens on normal browser startup, new tab,
> and other vanilla browser operations? This has always annoyed me.
Indeed. Here's an attempt
On Fri, Jun 5, 2015 at 1:22 AM, wrote:
> On Wednesday, June 3, 2015 at 9:16:46 PM UTC-4, Xidorn Quan wrote:
> > I guess it is probably better to add different color on "true" and
> "false",
> > which should improve the readability. Or probably just remove all
> "false"?
> >
>
> Looks like Mike an
On 6/4/15 6:14 PM, Ehsan Akhgari wrote:
They are both equally slow, but fatal assertions happen only once, by
definition. ;-)
Except that for some of our tests we restart after a crash (e.g. for web
platform tests).
So in that test harness, fatal assertions that are hit are much slower
tha
Very interesting, thank you!
Would there be a way to add an environment variable or harness flag to run
all tests in chaos mode?
On Thu, Jun 4, 2015 at 5:31 PM, Chris Peterson
wrote:
> On 6/4/15 11:32 AM, kgu...@mozilla.com wrote:
>
>> I just landed bug 1164218 on inbound, which adds the abilit
On 2015-06-04 9:40 AM, David Rajchenbach-Teller wrote:
On 04/06/15 14:30, Ehsan Akhgari wrote:
There are very good reasons for warnings to not cause tests to fail. We
have a lot of tests that are testing failure conditions that are
expected to warn, because they are failure conditions.
Well,
On Thursday, June 4, 2015 at 11:14:59 AM UTC-7, Martin Thomson wrote:
> On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote:
> > Also: in layout, there are various warnings related to coordinate
> > wraparound/overflow, where we're basically throwing up our hands and
> > warning that broken layout is
On 06/05/2015 12:06 AM, Daniel Holbert wrote:
On 06/04/2015 01:18 PM, smaug wrote:
More likely we need to change a small number of noisy NS_ENSURE_* macro
users to use something else,
and keep most of the NS_ENSURE_* usage as it is.
I agree -- I posted about switching to something opt-in, like
On Thursday, June 4, 2015 at 1:48:30 PM UTC-7, Luke Wagner wrote:
> In addition to judging noisiness by volume over a whole test run, can we
> also include any warning that happens on normal browser startup, new tab,
> and other vanilla browser operations? This has always annoyed me.
Yes, this bo
Gregory Szorc writes:
> hg.mozilla.org now displays extra metadata on changeset pages. e.g.
> https://hg.mozilla.org/mozilla-central/rev/dc4023d54436. Read more at
> http://gregoryszorc.com/blog/2015/06/04/changeset-metadata-on-hg.mozilla.org/
Thank you, Gregory.
I'm sure that will be *very* use
William Lachance writes:
> Hi Karl,
>
> On 2015-06-04 12:30 AM, Karl Tomlinson wrote:
>> jma...@mozilla.com writes:
>>
>>> >We will deprecate those instances of compare-talos next quarter
>>> >completely.
>> The treeherder version seems to randomly choose which and how many
>> of the results to
On 6/4/15 11:32 AM, kgu...@mozilla.com wrote:
I just landed bug 1164218 on inbound, which adds the ability to run individual
mochitests and reftests in chaos mode. (For those unfamiliar with chaos mode,
it's a feature added by roc a while back that makes already-random things more
random; see
hg.mozilla.org now displays extra metadata on changeset pages. e.g.
https://hg.mozilla.org/mozilla-central/rev/dc4023d54436. Read more at
http://gregoryszorc.com/blog/2015/06/04/changeset-metadata-on-hg.mozilla.org/
If you notice anything wonky, including performance issues, please speak
up. I'm s
On 06/04/2015 01:18 PM, smaug wrote:
> More likely we need to change a small number of noisy NS_ENSURE_* macro
> users to use something else,
> and keep most of the NS_ENSURE_* usage as it is.
I agree -- I posted about switching to something opt-in, like MOZ_LOG,
for some of the spammier layout NS
In addition to judging noisiness by volume over a whole test run, can we
also include any warning that happens on normal browser startup, new tab,
and other vanilla browser operations? This has always annoyed me.
On Thu, Jun 4, 2015 at 3:33 PM, Bobby Holley wrote:
> On Thu, Jun 4, 2015 at 1:18
On Thu, Jun 4, 2015 at 1:18 PM, smaug wrote:
> More likely we need to change a small number of noisy NS_ENSURE_* macro
> users to use something else,
> and keep most of the NS_ENSURE_* usage as it is.
>
+1.
___
dev-platform mailing list
dev-platform@li
On 06/04/2015 09:52 PM, Jonas Sicking wrote:
On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan wrote:
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew
On 06/04/2015 01:07 PM, David Rajchenbach-Teller wrote:
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
Turning warnings into failures sounds odd (but bug 1080457 seems to be actually
On Thu, Jun 4, 2015 at 2:24 PM, Seth Fowler wrote:
> My impression was that the conclusion was “refcounted objects are not banned
> inside C++ lambdas” - i.e., no policy change from the status quo - "but we
> need to be aware of the pitfalls”. The pitfalls are discussed pretty
> thoroughly in t
Turns out my original problem was some other mistake I made. Using just
self works (thanks botond for the poke on IRC about that).
I remember reading the linked thread, although I had since forgotten about
it -- thanks for the reminder. My impression was that using raw pointers
for ref counted obj
On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan wrote:
> Usually I use NS_WARNING to mean "something weird and unexpected is
> happening, e.g. a bug in Web page code, but not necessarily a browser bug".
> Sometimes I get useful hints from NS_WARNING spew leading up to a serious
> failure.
Yup.
I just landed bug 1164218 on inbound, which adds the ability to run individual
mochitests and reftests in chaos mode. (For those unfamiliar with chaos mode,
it's a feature added by roc a while back that makes already-random things more
random; see [1] or bug 955888 for details).
The idea with m
> On Jun 4, 2015, at 11:17 AM, Daniel Holbert wrote:
>
> You may be interested in this thread from a few months back:
> "Proposal to ban the usage of refcounted objects inside C++ lambdas in
> Gecko"
> https://groups.google.com/d/msg/mozilla.dev.platform/Ec2y6BWKrbM/xpHLGwJ337wJ
>
> (Not sure i
On 06/04/2015 07:29 AM, Andrew Osmond wrote:
> Suppose I have some ref counted class Foo with the private member mBar.
> Normally with a lambda expression, [...]
> obviously the Foo object could get released before the dispatch
> completes
You may be interested in this thread from a few months bac
On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote:
> Also: in layout, there are various warnings related to coordinate
> wraparound/overflow, where we're basically throwing up our hands and
> warning that broken layout is likely to occur because the page is
> millions of pixels tall. These can be u
Hi Karl,
On 2015-06-04 12:30 AM, Karl Tomlinson wrote:
jma...@mozilla.com writes:
>2) compare-talos is in perfherder
>(https://treeherder.mozilla.org/perf.html#/comparechooser), other instances of
>compare-talos have a warning message at the top indicating you should use
>perfherder. We will
On 06/04/2015 05:30 AM, Ehsan Akhgari wrote:
> There are very good reasons for warnings to not cause tests to fail. We
> have a lot of tests that are testing failure conditions that are
> expected to warn, because they are failure conditions.
Also: in layout, there are various warnings related to
On 3 June 2015 at 19:42, Benjamin Francis wrote:
> This is what I'd really like to get more of, particularly usage data.
>
I've reached out to a few people at Yahoo, Google and a couple of
universities and have managed to turn up a few studies with useful data
[1][2][3][4].
My conclusions so fa
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking wrote:
> FWIW, I suspect it'll be hard to put a dent in the number of warnings
> that we emit unless we either change all instances of
> NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
> or unless we change NS_ENSURE_SUCCESS(rv,
Hi Gijs,
Sorry for late reply (for some reason we've never received a notification of
your post)!
Our much earlier study was about the lifecycle of Firefox patches: "The Secret
Life of Patches: A Firefox Case Study"
(https://cs.uwaterloo.ca/~obaysal/wcre2012-baysal.pdf)
We then worked on Mart
This has landed; PR_LOG(_TEST) is now verboten.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
> It looks like finding of overrides of virtual methods is missing from
> DXR 2.0. Is this intentional?
Hmm, no. The tests seem to pass
(https://github.com/mozilla/dxr/blob/es/dxr/plugins/clang/tests/test_overrides.py).
Where are you seeing it?
___
dev
It looks like finding of overrides of virtual methods is missing from
DXR 2.0. Is this intentional?
-Jeff
On Wed, Jun 3, 2015 at 3:10 PM, Erik Rose wrote:
> DXR 2.0 is about to land! This is a major revision touching every part of the
> system, swapping out SQLite for elasticsearch, and replaci
> I am wondering, how close are we to be able to index IDL/WebIDL files, and
> navigate through JS and C++ callers and implementations of those
> attributes/methods? That is currently the biggest reason why I have to use
> MXR from time to time, and it would be nice to see DXR growing support f
Suppose I have some ref counted class Foo with the private member mBar.
Normally with a lambda expression, you can easily access the private
members by passing the this pointer:
void Foo::pokeBar()
{
nsCOMPtr r = NS_NewRunnableFunction[this] () -> void
{
mBar.poke();
});
NS_DispatchToM
On 04/06/15 14:30, Ehsan Akhgari wrote:
> There are very good reasons for warnings to not cause tests to fail. We
> have a lot of tests that are testing failure conditions that are
> expected to warn, because they are failure conditions.
Well, that's why the patch linked above offers a whitelist
This is great to see Erik! Thanks everyone for their hard work!
I am wondering, how close are we to be able to index IDL/WebIDL files,
and navigate through JS and C++ callers and implementations of those
attributes/methods? That is currently the biggest reason why I have to
use MXR from time
On Wednesday, June 3, 2015 at 9:16:46 PM UTC-4, Xidorn Quan wrote:
> I guess it is probably better to add different color on "true" and "false",
> which should improve the readability. Or probably just remove all "false"?
>
Looks like Mike and Adam cleaned it to be much more readable, thanks! I a
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew leading up to a serious
failure, but for those usages could probably be switched to PR_LOG without
losing
On 2015-06-04 5:49 AM, Jonas Sicking wrote:
FWIW, I suspect it'll be hard to put a dent in the number of warnings
that we emit unless we either change all instances of
NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn.
On 2015-06-04 6:07 AM, David Rajchenbach-Teller wrote:
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
There are very good reasons for warnings to not cause tests to fail. We
have a
On 04/06/2015 12:34 , Benjamin Francis wrote:
On 4 June 2015 at 03:27, Michael[tm] Smith wrote
As came up in some off-list discussion with Anne, is the “Manifest for a
web application” spec at https://w3c.github.io/manifest/ not relevant
here?
(Nothing to reverse engineer, since it has an actua
Nicholas Nethercote writes:
> Do warnings (as opposed to NS_ASSERTION) do anything in tests? I don't
> think they do. If that's right, a warning is only useful if a human
> looks at it and acts on it, and that's clearly not happening for a lot
> of these.
Warnings in tests don't do anything but l
On 4 June 2015 at 03:27, Michael[tm] Smith wrote
> As came up in some off-list discussion with Anne, is the “Manifest for a
> web application” spec at https://w3c.github.io/manifest/ not relevant
> here?
> (Nothing to reverse engineer, since it has an actual spec—with defined
> processing require
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking wrote:
>
> It feels like right now we have three incompatible desires:
>
> * Test lots of failure cases.
> * Make errors warn in debug builds on all/most frames as the failure
> is propagated up the callstack.
> * Don't warn a lot when testing debug bu
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
Cheers,
David
On 04/06/15 03:14, Eric Rahm wrote:
> We emit a *lot* of runtime warnings when running debug tests. I inadvertently
> trig
FWIW, I suspect it'll be hard to put a dent in the number of warnings
that we emit unless we either change all instances of
NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn.
It feels like right now we have three incompa
Hi all,
The next Nightly should have certain process-level mitigations turned on for
the Windows content process sandbox.
These are Chromium sandbox features that ensure that things like DEP, ASLR and
SEHOP are turned on for the content process when available.
If you are running Nightly on Win
47 matches
Mail list logo
