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
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
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
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
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
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
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
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:
> 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
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
Mark Côté writes:
> On August 20, we will remove public access to MozReview and archive
> patches. Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket. The “stub attachments” in
> Bugzilla that currently redirect to MozReview will be update
Xidorn Quan writes:
>> Would the color for the auto property be derived in such as way as
>> to hide the thumb or to make it constrast?
>
> No, currently we don't derive them from each other. We simply use some
> fallback color in that case.
How is the fallback color chosen?
> It is not impossib
Thanks very much for answering some of my questions for me.
Xidorn Quan writes:
> On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote:
>> Is there a plan to avoid the contrast problems we have mixing
>> document colors with system colors in other widgets?
>>
>> e.g
Is there a plan to avoid the contrast problems we have mixing
document colors with system colors in other widgets?
e.g. If one scrollbar color is specified by the document, then what ensures
that other parts of the scrollbar are visually distinct?
Does the computed value of the other scrollbar co
Is there a guideline that should be used to evaluate what can
acceptably run in the same process for different sites?
I assume the primary goal is to prevent one site from reading
information that should only be available to another site?
There would also be defense-in-depth value from having eac
On Fri, 13 Apr 2018 10:22:06 -0400, Boris Zbarsky wrote:
> On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote:
>> Would people agree to use:
>>
>> , mIsRootDefined { false }
>>
>> Instead of:
>>
>> , mIsRootDefined{ false }
>
> So my take is that we should not use braced initializer syntax in
> co
On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote:
> IMO, it's not reasonable to keep CI builds around forever, so the question
> is then how long to keep them? 1 year doesn't quite cover a full ESR cycle,
> would 18 months be sufficient for most cases?
>
> Alternatively, we could investigate
Steven Englehardt writes:
> While it may have been
> theoretically possible for all trackers to gather statistics on video
> playback for each configuration, the only scripts that could practically
> carry out those attacks without degrading user experience would have been
> video providers. This
On Fri, 4 May 2018 14:32:20 -0400, Boris Zbarsky wrote:
> On 5/4/18 3:34 AM, Karl Tomlinson wrote:
>> Not sure I understand your question, but the observable behavior
>> described by this section, or specifically "Before an AudioNode is
>> deleted, it will discon
to
fix it.
> If there is no difference in observable behavior, what would a
> normative requirement mean?
Good question. I will find that useful at some point.
> Karl Tomlinson wrote:
>> If the whole normative AudioNode lifetime section were dropped
>> then this would clearl
Boris Zbarsky writes:
> On 5/2/18 5:21 AM, Karl Tomlinson wrote:
>> [[AudioNode Lifetime]] https://github.com/WebAudio/web-audio-api/issues/1471
>
> I've read through that thread, but I'm still a little unclear on
> where thing stand. With the latest proposa
=Summary/benefits:
"The AudioWorklet object allows developers to supply scripts
(such as JavaScript or WebAssembly code) to process audio on the
rendering thread, supporting custom AudioNodes." [[Concepts]]
Allowing scripts to process audio on the rendering thread is
important for low latency g
> On Thu, Nov 30, 2017 at 11:09:07AM +1300, Karl Tomlinson wrote:
>> The native bytes may not be valid UTF-8, and so if the
>> character encoding is UTF-8, then there may not be a valid
>> `path` that can be encoded to produce the same `nativePath`.
Kris Maglione
I've always found this confusing, and so I'll write down the
understanding I've reached, in the hope that either it will help
others, or others can help me by correcting if these are
misunderstandings.
On Unix systems:
`nativePath`
contains the bytes corresponding to the native filename u
Zibi Braniecki writes:
> On Tuesday, November 7, 2017 at 2:54:45 AM UTC-8, pa...@paul.cx wrote:
>> I'm using this setup daily (with clang trunk from some weeks ago, not
>> 5.0, but it's the same really), here is my mozconfig:
>>
>> ```
>> export CC="icecc clang"
>> export CXX="icecc clang++"
>> m
I don't know how well GConf is supported by more recent GNOME
versions. I assume GSettings support was added to
nsUnixSystemProxySettings because GConf was to be no longer
supported, but the crash reporter uses separate code.
https://bugzilla.mozilla.org/show_bug.cgi?id=1388897
http://searchfox.
I assume this was integrated with OrangeFactor?
That is the only way I know to determine whether an intermittent
failure has occurred, because failures are not necessarily
reported to bugzilla.
Is there a mechanism for tracking a failure that we intend to
addresss, even when it does not fail ever
Andrew McCreight writes:
> On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote > wrote:
>
>> There's also a pre-processor constant that we define in Valgrind/ASAN/etc.
>> builds that you can check in order to free more stuff than you otherwise
>> would. But I can't for the life of me remember wha
On Sat, 20 May 2017 14:59:11 -0400, Eric Rescorla wrote:
> On Sat, May 20, 2017 at 1:16 PM, Kris Maglione
> wrote:
>
>> On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote:
>>
>>> Hmm, these are all -Wsign-compare issues bar one, which is fixed
>>> upstream. We have an open bug tracki
Nathan Froyd writes:
> I think a broader definition of "POD struct" would be required here:
> RefPtr and similar are technically not POD, but I *think* you'd
> want to require RefPtr* arguments when you expect the smart pointer
> to be assigned into? Not sure.
Yes, please, for similar reasons as
had it been posted to firefox-dev, would very clearly be
> on-topic and not rejected.
>
> Justin
>
> On Wed, Mar 22, 2017 at 7:35 PM, Karl Tomlinson wrote:
>
>> Benjamin Smedberg writes:
>>
>> > This is not the list for this question. Please respect this q
Benjamin Smedberg writes:
> This is not the list for this question. Please respect this question to the
> firefox-dev list.
https://wiki.mozilla.org/Firefox/firefox-dev says "Anyone can post. By
default, posts will be reviewed by a moderator before being sent to the list."
bit in fact some unclea
> It'd make me feel slightly less sad that we're disabling tests
> that do their job 90% of the time...
The way I interpret a test failing 10% of the time is that either
it has already done its job to indicate a problem in the product,
or the test is not doing its job.
Either way, if it is not go
zbranie...@mozilla.com writes:
> * I still have only 8GB of ram which is probably the ultimate
> limiting factor
You are right here. RAM is required not only for link time, but
also when compiling several large unified files at a time (though
perhaps this is not so significant with only 4 core
I would like to see failure rates expressed as a ratio of failures
to test runs, but I recognise that this data may not be readily
available and getting it may not be that important if we have a
rough idea. These are a means for setting priorities, and so a
rank works well.
If we have 100 tests,
Kartikaya Gupta writes:
> On Wed, Mar 8, 2017 at 4:01 PM, wrote:
>> In the past I have not always been made aware when my tests were disabled,
>> which has lead to me feeling jaded.
>
> We have a process (in theory) that ensures the relevant people get
> notified of tests. The process involves t
Gijs Kruitbosch writes:
>> What if it causes a regression and a blocking bug needs to be filed?
> Then you file a bug and needinfo the person who landed the commit
> (which one would generally do anyway, besides just marking it
> blocking the regressor).
I find the association of multiple regress
Gregory Szorc writes:
> On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson wrote:
>> When history is rewritten, is there a way to view the original
>> history through the web interface, so that autoland tinderbox
>> builds can be used to find regression ranges?
>
> No.
Gregory Szorc writes:
> When the autoland repository was introduced, it was advised to not pull
> from this repository because we plan to do rewrites like this frequently in
> the future. So if this rewriting impacted your local repo and you aren't a
> sheriff, you should consider changing your wo
Aryeh Gregor writes:
> On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren wrote:
>> The basic problem is prompting the user at all for non-HTTPS since
>> that leads them to think they can make an informed decision whereas
>> that's very much unclear. So prompting more would just make the
>> probl
On Fri, 19 Aug 2016 17:05:30 -0400, Eric Shepherd wrote:
> I'm trying to update the table of scan codes and the keys they go with here:
>
> https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code#Code_values_on_Linux_(X11)_(When_scancode_is_available)
>
> But the values in that table f
William Lachance writes:
> As part of a larger effort to improve the experience around
> debugging intermittents, I've been looking at reducing the time it
> takes for common "try" workloads for developers (so that
> e.g. retriggering a job to reproduce a failure can happen faster).
> Also, accou
> Could the lack of failure emails be specific to taskcluster jobs?
https://bugzilla.mozilla.org/show_bug.cgi?id=1275774
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Could the lack of failure emails be specific to taskcluster jobs?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a8c6ab15dd8f
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Lawrence Mandel writes:
> Do we need this criteria?
>
> RAM - Does it hurt to move an instance that has <4GB?
Yes. OOM will be more common with 64-bit builds on systems with
less RAM because 64-bit builds use more memory.
___
dev-platform mailing list
Cross-posting to mozilla.dev.tech.mathml so that this is seen by
people who are interested.
Please follow-up to mozilla.dev.platform.
Henri Sivonen writes:
> We ship data tables for converting from Unicode to HTML entities.
> These tables obviously take space. (They are not optimized for space
>
Thanks for the replies, Dan and Roy.
A first order filter node with AudioParam inputs seems a likely
future addition AFAIK.
Even with that though, having a way to apply a custom biquad
without needing to decompose into multiple textbook filters is
useful I think. And I agree that implementing th
Xidorn Quan writes:
> I think this specific case should actually use UniquePtr& rather
> than && in parameter for conditional move, so that callsite can only pass
> in an lvalue, and we don't need a Move there.
Jim Blandy writes:
> TakeMediaIfKnown is accepting a
> UniquePtr as an inout paramete
Daniel Minor writes:
> Summary: This provides an alternative to using BiquadFilterNode when
> odd-order filters are required or automation is not needed. It is part of
> the Web Audio spec and is already implemented in Blink.
Thanks for looking at this, Daniel.
I fear that high order filters are
libxul.so is dlopen()ed from the firefox process.
That firefox process would already have a libc.so.6, I assume, and
so I would not expect libxul.so to load another libc.so.6.
That seems to be confirmed here by running
strace -e trace=file firefox/firefox
See whether something different is hap
Thanks for the info, Mark.
In the mean time, at least, it would make interdiffs easiest to
read if patch authors can submit updates to patches against the
same revision as the original patches.
If that causes too much inconvenience (and it will sometimes),
then separate pushes for the rebase and
Eric Rescorla writes:
> I don't believe I am asking for this, just auto-squash on submit. I
> certainly understand if it's your position that you have higher priorities,
> that's fine, but it's not fine to remove the ability to do squashed reviews
> before something like that lands.
Perhaps the d
Felipe G. writes:
> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other tabs and/or windows opened manual
Honza Bambas writes:
> On 1/25/2016 20:23, Steve Fink wrote:
>> For navigation, there's a list of changed files at the top
>> (below the fixed summary pane) that jumps to per-file anchors.
>
> Not good enough for review process.
>
>> Are you saying you want tabs or something for this (like
>> spl
>> On 25/01/16 05:44 PM, Eric Rescorla wrote:
>> >On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey wrote:
>> >
>> >>It's also painful to use MozReview's comment system. The comments in the
>> >>reviews pane don't show much diff context, and while I just realized
>> >>it's possible to make it show more
Mike Hommey writes:
> On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:
>> Heh. Your list of UI complaints is very similar to mine. Some comments:
>>
>>
>> On 01/25/2016 04:26 AM, Honza Bambas wrote:
> Also, iirc, when you reply diff comments in MozReview, the resulting
> comments sent
On Fri, 22 Jan 2016 14:24:38 -0500, Ehsan Akhgari wrote:
> What about the case where the information doesn't exist in the
> repository because the author, for example, cherry-picked a
> specific commit on a throw-away branch because the rest of the
> dependencies are still being worked on? Or, as
Boris Zbarsky writes:
> On 1/23/16 9:48 PM, Mike Hommey wrote:
>> Note that if /other/ changes from other bugs have happened to the same
>> files between the last reviewed iteration and the rebase before landing,
>> the interdiff will show them without any kind of visual cues.
>
> Ah, that's unfor
Xidorn Quan writes:
> On Thu, Jan 7, 2016 at 6:47 AM, Karl Tomlinson wrote:
>> Xidorn Quan writes:
>>
>>> You can keep a raw pointer yourself, and release it manually after you
>>> find the dispatch fails, like what is done in
>>> NS_DispatchToCurrentThr
Xidorn Quan writes:
> On Wed, Jan 6, 2016 at 3:53 AM, Kyle Huey wrote:
>> On Mon, Jan 4, 2016 at 4:10 PM, Randell Jesup wrote:
>>>
>>> Yup. In cases where we anticipate a possible Dispatch failure (which is
>>> supposed to become impossible, but isn't currently) you can use the
>>> (still-exist
Kyle Huey writes:
> (This is a continuation of the discussion in bug 1218297)
>
> In bug 1155059 we made nsIEventTarget::Dispatch take an
> already_AddRefed instead of a raw pointer. This was done to allow the
> dispatcher to transfer its reference to the runnable to the thread the
> runnable wil
Kartikaya Gupta writes:
> Personally I much prefer the new approach to reporting intermittents.
> It's much easier for me to see at a glance (i.e when the bugs are
> updated with the weekly count) which ones are actually occurring more
> frequently and which bug would be best to spend time on. Wit
David Rajchenbach-Teller writes:
> To improve the Performance Stats API, I'm looking for a way to find out
> if we are currently animating something on the main thread.
>
> My definition of animating is pretty large, i.e. "will the user probably
> notice if some computation on the main thread last
On Fri, 16 Oct 2015 10:31:43 -0700, Gregory Szorc wrote:
> But as awesome as
> these targets are, they can still build more than is desired (especially in
> the edit .h file case). This slows down iteration cycles and slows down
> developers.
>
> For this reason, I think dumbmake needs to remain o
On Mon, 27 Jul 2015 21:35:20 +1200, Karl Tomlinson wrote:
> 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
Jonas Sicking writes:
> On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan wrote:
>> Probably we should generally avoid using constructor directly for
>> those cases. Instead, use helper functions like MakeUnique() or
>> MakeAndAddRef(), which is much safer.
>
> We used to have NS_NewFoo() objects all o
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
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://
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
> 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
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
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
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
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
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:
> 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:
> 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
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
_
I would like to vote for voting.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 rand
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
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
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
> 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
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.
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:
>> 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-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
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
>
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 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
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 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
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
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
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
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.
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
1 - 100 of 169 matches
Mail list logo
