On Thu, Jun 4, 2015 at 1:48 PM, Luke Wagner lwag...@mozilla.com 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.
On Fri, Jun 5, 2015 at 1:22 AM, kgu...@mozilla.com 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
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
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
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
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
On Thursday, June 4, 2015 at 11:14:59 AM UTC-7, Martin Thomson wrote:
On Jun 4, 2015 10:27 AM, Daniel Holbert dholb...@mozilla.com wrote:
Also: in layout, there are various warnings related to coordinate
wraparound/overflow, where we're basically throwing up our hands and
warning that
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,
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 cpeter...@mozilla.com
wrote:
On 6/4/15 11:32 AM, kgu...@mozilla.com wrote:
I just landed bug 1164218 on inbound,
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,
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 bobbyhol...@gmail.com wrote:
On Thu,
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 load and so the
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
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*
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 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 back:
On Jun 4, 2015, at 11:17 AM, Daniel Holbert dholb...@mozilla.com 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
On 3 June 2015 at 19:42, Benjamin Francis bfran...@mozilla.com 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].
On Jun 4, 2015 10:27 AM, Daniel Holbert dholb...@mozilla.com 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.
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
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
On Thu, Jun 4, 2015 at 1:18 PM, smaug sm...@welho.com 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
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking jo...@sicking.cc 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
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
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 for
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 e...@mozilla.com wrote:
DXR 2.0 is about to land! This is a major revision touching every part of the
system, swapping out SQLite for
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()
{
nsCOMPtrnsIRunnable r = NS_NewRunnableFunction[this] () - void
{
mBar.poke();
});
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?
___
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
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 log
On 04/06/2015 12:34 , Benjamin Francis wrote:
On 4 June 2015 at 03:27, Michael[tm] Smith m...@w3.org 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
On 4 June 2015 at 03:27, Michael[tm] Smith m...@w3.org 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
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
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 5:38 AM, Robert O'Callahan rob...@ocallahan.org 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
On Thu, Jun 4, 2015 at 2:24 PM, Seth Fowler s...@mozilla.com 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
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking jo...@sicking.cc 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
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
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 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 06/04/2015 09:52 PM, Jonas Sicking wrote:
On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan rob...@ocallahan.org 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
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 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 also
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
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
45 matches
Mail list logo
