Randell Jesup writes:
> 1) running on TBPL (AWS) the internal timings reported show the specific
>test going from 30 seconds to 450 seconds with the patch.
> 2) on my local system, the test self-reports ~10 seconds, with or
>without the patch.
> Note: the timer in question is nsITimer::TY
Aryeh Gregor writes:
> On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari wrote:
>> What you're saying above is true *if* someone investigates the
>> intermittent test failure and determines that the bug is not
>> important. But in my experience, that's not what happens at
>> all. I think many peopl
Gregory Szorc writes:
> 2) Run marked intermittent tests multiple times. If it works all
> 25 times, fail the test run for inconsistent metadata.
We need to consider intermittently failing tests as failed, and we
need to only test things that always pass.
We can't rely on statistics to tell us a
On Fri, 11 Apr 2014 13:29:01 -0700, Gregory Szorc wrote:
> https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code
> I would be thrilled if we started adopting some of the
> recommendations such as more descriptive commit messages and many,
> smaller commits over fewer, com
I also added a link at
https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch#Creating_a_patch
Benoit Girard writes:
> I didn't know this existed. I filed bug 995763 to get this link added to
> the 'review requested' email to hopefully increase visibility.
>
>
> On Sat, A
Joshua Cranmer 🐧. writes:
> On 4/13/2014 4:42 PM, Robert O'Callahan wrote:
>> Honestly, I think we're already pretty close to most of those
>> recommendations, most of the time.
Some experienced Mozillians are breaking up their large changes
well, but some are not. And many less experienced cont
Thank you for putting this together. It is important.
jmaher writes:
> This policy will define an escalation path for when a single test case is
> identified to be leaking or failing and is causing enough disruption on the
> trees.
> Exceptions:
> 1) If this test has landed (or been modified) i
Birunthan Mohanathas writes:
> For top-level function definitions, the recommended style is:
>
> template
> static inline T
> Foo()
> {
> // ...
> }
The main reasons for having the function name at the start of a
new line, I assume, was to help some tools (including diff
Thanks for the overview of a real problem, Andrew.
(I recall having to add an exception for a "Mozilla Root CA" to
access email at one time.)
Andrew Sutherland writes:
> I propose that we use a certificate-observatory-style mechanism to
> corroborate any invalid certificates by attempting the con
Philip Chee writes:
> On 02/07/2014 18:13, David Rajchenbach-Teller wrote:
> We had libnotify support but this was removed from the tree on the
> grounds that it didn't suit our needs.
I don't think those were the grounds. AIUI it was just that
people didn't want to put effort into a lower prior
Aryeh Gregor writes:
> The compiler is required to use the move constructor (if one exists)
> instead of the copy constructor when constructing the return value of
> a function, and also when initializing an object from the return value
> of a function, or assigning the return value of a function.
Jonas Sicking writes:
> But any type of regression is cause for backout.
While I agree regressions are bad, this isn't the usual process.
If it were, then I wouldn't bother filing bugs, but merely back
out the offending change.
There is some kind test for whether the regression costs more than
Nicholas Nethercote writes:
> UNSURE
> --
> ./layout/mathml/updateOperatorDictionary.pl
> - appears to be in fairly recent use
This was used to generate an in-tree file from an external spec.
It is reasonably likely that there will be future changes to the
spec, in which case the script will
L. David Baron writes:
>> On 20/11/14 17:56, Boris Zbarsky wrote:
>> > Ah, we can't. We can whitelist the number of assertions in a mochitest
>> > (or a number range if the number is not quite stable), but not the text
>> > of the assertion.
>
> On Thursday 2014-11-20 18:05 +0100, David Rajchenba
On Fri, 28 Nov 2014 00:46:07 -0800, L. David Baron wrote:
> On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
>> The downside from doing so, though, is that non-unified build *will*
>> be broken, and code "purity" (right includes in the right sources,
>> mostly) won't be ensured. Do you think th
On Fri, 19 Dec 2014 18:58:53 -0500, Ehsan Akhgari wrote:
> On 2014-12-19 4:40 PM, Nils Ohlmeier wrote:
>>> On Dec 19, 2014, at 6:56 AM, Ehsan Akhgari wrote:
>>> Logging sufficiently is almost always enough to not have to
>>> use these timers, as those tests have demonstrated in
>>> practice.
> On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari
> wrote:
>> Are there good use cases for having functions accept an
>> nsRefPtr&? If not, we can outlaw them.
Aryeh Gregor writes:
> Do we have a better convention for an in/out parameter that's a
> pointer to a refcounted class? editor uses thi
Bobby Holley writes:
> On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren wrote:
>
> So let's change the project-wide coding rules instead to allow 99
>> columns as the hard limit, but keep 80 columns as the recommended
>> (soft) limit.
>>
>
> I think we should avoid opening up a can of worms on the
On Wed, 8 Apr 2015 20:40:12 -0700, Nicholas Alexander wrote:
> On Wed, Apr 8, 2015 at 4:06 PM, Mike Hommey wrote:
>
>> If
>> running nightly screws up profiles for older versions, that's a serious
>> problem imho.
>>
>
> Really? Presumably not every forward DB migration can be reverted without
>
Ehsan Akhgari writes:
> On 2015-04-27 9:54 PM, Trevor Saunders wrote:
>> On Mon, Apr 27, 2015 at 09:07:51PM -0400, Ehsan Akhgari wrote:
>>> On Mon, Apr 27, 2015 at 5:45 PM, Trevor Saunders
>>> wrote:
>>>
I believe we have some cases in the tree where a virtual function
doesn't override
Ehsan Akhgari writes:
> I think there's a typo of some sort in the question, but if you
> meant "every overriding function must be marked with override",
> then yes, that is the change I'm proposing, but the good news is
> that you can now run clang-tidy on the entire tree and get it to
> rewrite
Ehsan Akhgari writes:
>> This seems similar to the compiler warning situation.
>> Usually at least, I don't think we should automatically modify the
>> code in line with how the compiler reads the code just to silence
>> the warning. Instead the warning is there to indicate that a
>> programmer n
Ehsan Akhgari writes:
> On 2015-05-07 5:53 PM, Karl Tomlinson wrote:
>> Ehsan Akhgari writes:
>>
>>>> This seems similar to the compiler warning situation.
>>>> Usually at least, I don't think we should automatically modify the
>>>> c
Ehsan Akhgari writes:
> On Monday, May 11, 2015, Xidorn Quan wrote:
>
>> On Tue, May 12, 2015 at 7:29 AM, Ehsan Akhgari > > wrote:
>>
>>> On 2015-04-30 7:57 AM, Xidorn Quan wrote:
I guess we probably should forbid using any expression with side effect
for
member initializers.
> On 2015-05-23 5:02 AM, Jesper Kristensen wrote:
>> It would be nice of you could also support paste.
Ehsan Akhgari writes:
> Handling paste is a difficult topic, and I definitely don't have a
> good answer yet.
>
> Prompting for paste has two issues:
> 2. The synchronous nature of the execComm
Thanks, Joel. I've benefited from being able to use
perf.html#/comparechooser and will look forward to the performance
discussion.
jma...@mozilla.com writes:
> 2) compare-talos is in perfherder
> (https://treeherder.mozilla.org/perf.html#/comparechooser), other instances of
> compare-talos have
Martin Thomson writes:
> I guess that most of these are as a result of actual problems,
> even if they are minor.
The ones that are actual problems would be the ones that are
harder to resolve.
In my experience, however, when I've seen many of one kind of
warning, investigation has revealed that
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
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 rand
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
I would like to vote for voting.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Vladan D. writes:
> Should fixing shutdown hangs be higher priority?
_exit() after profile-before-change notification would be the
many-holes-with-one-plug bug to prioritize.
https://wiki.mozilla.org/XPCOM_Shutdown
https://bugzilla.mozilla.org/show_bug.cgi?id=662444
_
Jeff Gilbert writes:
> we should have a good reason or
> two for making our choice. No such reason is detailed in the style guide.
I find the 'a' prefix useful to tell me that this variable has the
value that was provided to the function.
(I'm assuming that the prefix is used with this convention
Jeff Gilbert writes:
> It can be a burden on the hundreds of devs who have to read and understand
> the code in order to write more code.
Some people find the prefix helps readability, because it makes
extra information immediately available in the code being
examined, while you are indicating th
Jeff Gilbert writes:
> I work with a number of these, but after a page or two, why is it at all
> relevant which vars were args? For information flow? Should we mark locals
> that purely derive from args as `aFoo` as well? Long functions (which have
> poor readability anyway) generally have so muc
Jeff Gilbert writes:
> On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson wrote:
>
>> Some people find the prefix helps readability, because it makes
>> extra information immediately available in the code being
>> examined, while you are indicating that this is a significant
Bobby Holley writes:
> On Wed, Jul 8, 2015 at 3:52 AM, Gabor Krizsanits
> wrote:
>
>> The priority is to automatically rewrite our source with a unified style.
>>> foo -> aFoo is reasonably safe, whereas aFoo->foo is not, at least with
>>> the
>>> current tools. So we either need to combine the r
Bobby Holley writes:
> On Wed, Jul 8, 2015 at 4:45 PM, Karl Tomlinson wrote:
>
>> I think we could relax the 'a' prefix requirement to be a
>> convention used when identifying the variable as a parameter is
>> useful. My opinion is that this is useful for mos
Tom Tromey writes:
> It was mentioned elsewhere in this thread that some code assigns to
> arguments.
The style guide should clarify that parameters named aFoo should
not be assigned to. Otherwise that defeats the purpose.
Non-const references are the exception. If these are really
needed, the
> AFAIK there is no webkitSrcObject, and Chrome/Opera use:
>
> video.src = URL.createObjectURL(stream);
>
> which works, but as I understand it leaves blobs around to be
> garbage collected.
In Gecko, object URLs from MediaStreams are currently not
auto-revoked, so the MediaStream will not be
Sometimes it would be nice to check in crashtests that use, or
attempt to use large memory allocations, but I'm concerned that
checking in these crashtests could disrupt subsequent tests
because there is then not enough memory to test what they want to
test.
Is anything done between crashtests to
Thanks everyone. That gives me some ideas on how to clean up
after the page. I figure that then any OOM issues will at least
be in the vicinity of the test doing the large allocation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://
James Burke writes:
> On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar
> wrote:
>> Can't you just make everything display:none until you're ready to show it?
>
> Just using display: none seems like it will run into the same problem
> that prompted bug 863499, where the browser did some render/pai
Martin Thomson writes:
> On Wed, Sep 5, 2018 at 4:42 PM Mark Banner wrote:
>> A couple of things that may help with the scrolling & finding, that
>> people may or may not have found yet...
>
> The keyboard shortcuts are more accessible (type ? to see the list
> [1]), though in my experience they
Ehsan Akhgari writes:
> On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote:
>
>> [...]
>>
>> So for converting from C-style to C++-style, that would be:
>>
>> /* static */ void Foo::Bar() {
>> ...
>> }
>>
>> // static
>> void Foo::Bar() {
>> ...
>> }
>>
>> [...]
>>
>> My one concern would be the p
Ehsan Akhgari writes:
> On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert wrote:
>
>> I would much rather revert to:
>> /*static*/ void
>> Foo::Bar()
>>
>> The Foo::Bar is the most relevant part of that whole expression, which
>> makes it nice to keep up against the start of the line.
>>
>
> The clang
Ehsan Akhgari writes:
> What tool do you use which has difficulty showing function names in diffs
> right now? It seems to work fine for me both in git and hgweb...
It's cases like these that are truncated earlier due to putting
the return type before the function name:
% hg export 9f7b93f5c4f8
Near the top of
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
there is
> New code should try to conform to these standards, so it is as
> easy to maintain as existing code. [...]
>
> This article is particularly for those new to the Mozilla
> codebase [...]" Before
https://google.github.io/styleguide/cppguide.html#Reference_Arguments
has a simple rule to determine when reference parameters are
permitted:
"Within function parameter lists all references must be const."
This is consistent with Mozilla's previous coding style:
"Use pointers, instead of references
Google style requires pointers for parameters that may be mutated
by the callee, which provides that the potential mutation is
visible at the call site. Pointers to `const` types are
permitted, but recommended when "input is somehow treated
differently" [1], such as when a null value may be passed
As of this week I intend to turn on AudioWorklet by default for
all platforms. It has been developed behind the
"dom.audioworklet.enabled" and "dom.worklet.enabled" preferences.
Status in other browsers is:
Chrome, Opera: shipping.
Edge, Webkit: not shipping, intentions unknown.
Product: Adam St
Thank you for highlighting those, Jonathan.
"Show Older Inlines" "Disabled" sounds like something to avoid
like the plague. I wonder whether global configuration to remove
that setting is available ...
I find the "Collapse" operation on inline comments useful to track
remaining relevant comments
Karl Tomlinson writes:
> "Show Older Inlines" "Disabled" sounds like something to avoid
> like the plague. I wonder whether global configuration to remove
> that setting is available ...
My comment was rash.
The setting can actually be very useful (at least tempor
On Fri, 24 Aug 2012 12:20:58 -0700, Justin Lebar wrote:
>> inline int32_t GetFoo() {
>>int32_t result = 0;
>>nsresult rv = GetFoo(&result);
>>MOZ_ASSERT(NS_SUCCEEDED(rv));
>>return result;
>> }
>
> so that we never return uninitialized memory in release builds. 0 may
> or may no
> On 8/22/12 6:10 AM, Robert Kaiser wrote:
>> [...]
>> esp. given that basic file I/O is often costly (from watching my CPU
>> usage, a lot of the build time is spent in I/O wait when using spinning
>> disks - SSDs improve that hugely).
On Wed, 22 Aug 2012 12:29:24 -0700, Gregory Szorc wrote:
>
delen...@gmail.com writes:
> When trying to build, after ./configure, I get
>
> gcc -shared -Wl,-z,defs -Wl,-soname -Wl,libnssutil3.so
> -Wl,--version-script,/home/fab/test/linuxmint-Cinnamon-bd02368/gjs-1.33.14/xulrunner-15.0.1/security/nss/lib/util/nssutil.def
> [...]
> /usr/bin/ld:/home/fab
Ben Hearsum writes:
> On 09/29/12 12:58 AM, Kannan Vijayan wrote:
>> 1. A patch that is expected to succeed, but you want to run it through
>> try to verify.
>
>> For "optimistic" pushes, we expect that the patch goes from green =>
>> green. For "pessimistic" pushes we expect a listing of all ora
On Fri, 28 Sep 2012 11:44:56 -0700, Gary Kwong wrote:
>> http://blog.johnford.org/new-mac-builders-ssds-j-settings/
>
> Quoted from that blog:
>
> "I did find that it is better to set the -j setting too high than
> it is to set it too low."
>
> -Gary
Better in terms of build time, which is the ri
Ehsan Akhgari writes:
> Over in bug 796087, I'm proposing for us to remove the -t all try server
> flag. The rationale is that the set of Talos tests vary greatly and most
> of the people who test performance are only interested in a subset of Talos
> tests.
Frequently enough people change code
jmaher writes:
> In our continuing effort on the Auotmation and Tools team to make Talos tests
> useful and make sure we know and care about what we are measuring, we have
> realized that the tdhtml tests are not providing us any value.
Are you able to expand on the reasons why these don't provid
On 2012-10-16 9:42 AM, Henri Sivonen wrote:
> (Aside: In a way, it's rather sad how much engineering effort is put
> into compressing TrueType hints, when the reason for sending TrueType
> hints over the wire is that Microsoft's font rasterizer's are so
> backwards that they still need hints even t
Nathan Froyd writes:
> - Trace Malloc tests (all of them); it's not clear how useful these
> tests are, given the pageload we run them with and the availability
> of tools like about:memory.
I'd like to receive notifications if these results change.
If the results are changing for the small p
LANGLOIS Olivier writes:
> xulrunner: 16.0.1
Is this a regression?
i.e. Do you know whether it worked differently in previous versions?
> and the plugin-container thread stack is:
>
> #1 0xb7f9a915 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2 0xb5aa4b5f in PR_WaitCondVar
Henrik Skupin writes:
> differences like 'mochitest' vs. 'mochitests'. The right usage would be
> 'mochitest' and it would apply to the other frameworks too.
It would be useful to have different names to distinguish between
tests and implementation for the tests. I don't know whether that
is an
Neil writes:
> Ah, so that explains the fallback flash I experience on a site I
> frequent that makes heavy use of a downloaded symbol font. It is
> irksome because the fallback content is ASCII text ;-)
Just in case others read and want to copy this behaviour, sites
should not be encoding symbo
On Wed, 17 Oct 2012 11:31:15 -0700, Jonas Sicking wrote:
> It sounds to me that it's not generally true that autohinters can replace
> hinting. At least not yet.
>
> What would be interesting is if we could enable an autohinter in Firefox
> and use that in cases when we are sent a font which doesn
BTW, everyone, please don't use NS_ENSURE_* unless you really want
all developers to be told if the test fails.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Robert O'Callahan writes:
> How about this idea: after processing a WM_MOUSEMOVE event, go into an
> "anti-flood" state where WM_MOUSEMOVE is ignored. After we service the
> Gecko event queue, exit the anti-flood state.
The general approach sounds good.
I expect "ignored" will have to be "ignore
Robert O'Callahan writes:
> On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson wrote:
>
>> Robert O'Callahan writes:
>>
>> > How about this idea: after processing a WM_MOUSEMOVE event, go into an
>> > "anti-flood" state where WM_MOUSEMOVE
101 - 169 of 169 matches
Mail list logo
