On 07/04/2014 23:13, Dave Hylands wrote:
> Personally, I think that the more ways we can test for threading issues the
> better.
> It seems to me that we should do some amount of testing on single core and
> multi-core.
>
> Then I suppose the question becomes how many cores? 2? 4? 8?
>
> Maybe
Why don’t we just switch to x86 emulator? x86 emulator runs way faster than the
ARM emulator.
Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
On Apr 8, 2014, at 8:49 AM, Ehsan Akhgari wrote:
> On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
>> When you say "debug", you mean the emulator is run
On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that the
emulator is just too slow?
Applying tim
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that the
emulator is just too slow?
Applying time dilation might make tests green but we'd be left
On 2014-04-07, 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still has some value in that it can catch regressions that
cause it to fail permanently, but we would not be able
>How easy is it to identify CPU-sensitive tests?
Easy for some (most but not all media tests). Almost all
getUserMedia/PeerConnection tests. ICE/STUN/TURN tests.
Not that easy for some. And some may be only indirectly sensitive -
timeouts in delay-the-rendering code, TCP/DNS/SPDY timers, etc,
On 4/7/2014 3:16 PM, Randell Jesup wrote:
> The B2G emulator design is causing all sorts of problems. We just fixed
That sounds very similar to some of the failures seen on the Android 2.3
emulator. Many media-related mochitests intermittently time out on the Android
2.3 emulator when run on aw
How easy is it to identify CPU-sensitive tests?
I think the most practical solution (at least in the near term) is to
find that set of tests, and run only that set on a faster VM, or on real
hardware (like our ix slaves).
Jonathan
On 4/7/2014 3:16 PM, Randell Jesup wrote:
The B2G emulator
The B2G emulator design is causing all sorts of problems. We just fixed
the #2 orange which was caused by the Audio channel StartPlaying()
taking up to 20 seconds to run (and we "fixed" it by effectively
removing some timeouts). However, we just wasted half a week trying to
land AEC & MediaStream
>(Follow-ups to dev.tree-management please)
>A proportion of the current mozilla-central non-critical commits are made
>by people inadvertently pushing to the wrong repository. To prevent these,
>once the tree rules are adjusted on the wiki the sheriffs envisage the next
>step will be switching moz
Hey Ted,
- Original Message -
> From: "Ted Mielczarek"
> To: "Mozilla Platform Development"
> Sent: Monday, April 7, 2014 11:11:22 AM
> Subject: Linux testing on single-core VMs nowadays
>
> I wanted to post about this because I don't think it's common knowledge
> (I only just came to t
Ed Morley wrote:
(Follow-ups to dev.tree-management please)
Hi all :-)
The vast majority of mozilla-central landings are now via curated merges
from integration/team repositories. This dramatically increases the
chance that the tip of mozilla-central is in a known-good state, meaning
that:
*
I wanted to post about this because I don't think it's common knowledge
(I only just came to the realization today) and it has potential impact
on the effectiveness of our unit tests.
Currently we run our Linux unit tests exclusively on Amazon EC2
m1.medium[1] instances which have only one CPU cor
On 2014-04-07, 11:12 AM, Ted Mielczarek wrote:
It's difficult to say whether bugs we find via tests are more or less
important than bugs we find via users. It's entirely possible that
lots of the bugs that cause intermittent test failures cause
intermittent weird behavior for our users, we simp
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek wrote:
> If a bug is causing a test to fail intermittently, then that test loses
> value. It still has some value in that it can catch regressions that
> cause it to fail permanently, but we would not be able to catch a
> regression that causes it to
On 4/7/2014 9:02 AM, Aryeh Gregor wrote:
> On Mon, Apr 7, 2014 at 3:20 PM, Andrew Halberstadt
> wrote:
>> I would guess the former is true in most cases. But at least there we have a
>> *chance* at tracking down and fixing the failure, even if it takes awhile
>> before it becomes annoying enough t
On 2014-04-07 6:00 AM, Karl Tomlinson wrote:
chiaki ISHIKAWA writes:
I think 7.2 10 is also relevant here.
--- quote ---
An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly. The
value is unchanged if it is in the range of enumeration values of
the
On Mon, Apr 7, 2014 at 3:20 PM, Andrew Halberstadt
wrote:
> I would guess the former is true in most cases. But at least there we have a
> *chance* at tracking down and fixing the failure, even if it takes awhile
> before it becomes annoying enough to prioritize. If we made it so
> intermittents n
Hi Terrence,
Thanks! I've filed Bug 992887 to track the expanded mach command.
Cheers,
Dan
- Original Message -
From: "Terrence Cole"
To: dev-platform@lists.mozilla.org
Sent: Saturday, April 5, 2014 4:30:53 PM
Subject: Re: Removing 'jit-tests' from make check
Dan,
Congratulations on
On 07/04/14 05:10 AM, James Graham wrote:
On 07/04/14 04:33, Andrew Halberstadt wrote:
On 06/04/14 08:59 AM, Aryeh Gregor wrote:
Is there any reason in principle that we couldn't have the test runner
automatically rerun tests with known intermittent failures a few
times, and let the test pass i
On Mon, Apr 7, 2014 at 6:33 AM, Andrew Halberstadt
wrote:
> Many of our test runners have that ability. But doing this implies that
> intermittents are always the fault of the test. We'd be missing whole
> classes of regressions (notably race conditions).
We already are, because we already will s
chiaki ISHIKAWA writes:
> I think 7.2 10 is also relevant here.
>
> --- quote ---
> An expression of arithmetic or enumeration type can be converted
> to an enumeration type explicitly. The
> value is unchanged if it is in the range of enumeration values of
> the enumeration type; otherwise the re
(2014/04/07 14:27), Karl Tomlinson wrote:
> It is allowed in N3242. I think the relevant sections are
5.2.9 Static cast
Thank you for the pointer.
I found a floating copy of n3242.pdf at the following url.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
I think 7.2 10 is
(Follow-ups to dev.tree-management please)
Hi all :-)
The vast majority of mozilla-central landings are now via curated merges
from integration/team repositories. This dramatically increases the
chance that the tip of mozilla-central is in a known-good state, meaning
that:
* Integration/pro
On 07/04/14 04:33, Andrew Halberstadt wrote:
On 06/04/14 08:59 AM, Aryeh Gregor wrote:
On Sat, Apr 5, 2014 at 12:00 AM, Ehsan Akhgari
wrote:
Note that is only accurate to a certain point. There are other
things which
we can do to guesswork our way out of the situation for Autoland, but of
cou
25 matches
Mail list logo
