On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote:
>
> What's needed here is a dependency management system that
> simply builds what's needed regardless of what's changed,
Otherwise known as "a proper build system". glandium and co. have been
working towards that for a long time. It's a big,
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote:
>>
>> Eventually |mach build| should just do the right
>> thing, no matter what files you've touched...
>
> The problem is that definitions of "right thing" differ depending on the
> goal, right?
I'm using the standard build system sense of "r
On Fri, Oct 23, 2015 at 6:57 PM, Mike Hommey wrote:
>
> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
> changes tend to break comm-central. While it can be argued that it
> shouldn't be platform engineers' burden to care about those, the fact
> is that even if they
On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking wrote:
>
> Given that people are already feeling pressure to fix up thunderbird
> code when they land patches, I can only see that pressure increasing
> when you don't even need to pull a separate tree.
That's more or less correct, though I'd rewrit
On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking wrote:
>
> The question is, do we fix that friction by making collaboration
> easier, or do we fix it by reducing collaboration.
Yes. Merging c-c into m-c would achieve the first alternative. (And it
has support from plenty of people in this thread,
And please note that following along isn't onerous. We typically get
~3 bugs to triage per week.
Nick
On Wed, Nov 4, 2015 at 8:07 AM, Eric Rahm wrote:
> Hi folks-
>
> The MemShrink project [1] has been around for several years. You may have
> seen the [MemShrink] tag added to bugs and then later
Hi,
One major remaining Moz2Dification step is the conversion of thebes
types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
equivalents. But this is largely blocked by the fact that the thebes
types use double-precision FP values while the Moz2D types use
single-precision FP val
On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan wrote:
>>
>> One major remaining Moz2Dification step is the conversion of thebes
>> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
>> equivalents.
>
> I think for now we should focus on replacing usage of gfxContext with
>
On Tue, Nov 24, 2015 at 7:05 PM, Robert O'Callahan wrote:
>>
>> It still seems like, where possible, we should switch from passing
>> around an nsRenderingContext or a gfxContext to passing around a
>> DrawTarget. (Presumably starting from leaf functions and moving
>> up.)
>
> Yes.
I spent some
On Tue, Dec 8, 2015 at 4:34 PM, Nicholas Nethercote
wrote:
>
> One interesting thing I found is that a *lot* of the functions that
> take an nsRenderingContext or gfxContext do so because they end up
> passing it into text run code -- gfxTextRun uses a gfxContext, via
> gf
On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote
wrote:
>>
>> One interesting thing I found is that a *lot* of the functions that
>> take an nsRenderingContext or gfxContext do so because they end up
>> passing it into text run code -- gfxTextRun uses a gfxContext,
On Sun, Dec 13, 2015 at 9:17 AM, Cameron Kaiser wrote:
>
> This would essentially mandate, then, that Gecko can only be built on
> platforms with a Rust toolchain. That may be desirable, but it would
> probably bust some of the obscure Tier-3 platforms and it would definitely
> bust TenFourFox (we
On Sun, Dec 13, 2015 at 11:28 AM, Bobby Holley wrote:
>>
>> I've been wondering about this. There's a big difference between (a)
>> permitting Rust components (while still allowing fallback C++
>> equivalents) and (b) mandating Rust components.
>
> I don't know why we would allow there to be a lon
Sheriffs make developers' lives easier. Thank you, sheriffs.
Nick
On Thu, Dec 31, 2015 at 1:19 AM, Carsten Book wrote:
> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers, IT
> Teams and Rele
On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote
wrote:
>>
>> One interesting thing I found is that a *lot* of the functions that
>> take an nsRenderingContext or gfxContext do so because they end up
>> passing it into text run code -- gfxTextRun uses a gfxContext,
Greetings,
Over the past few weeks I have spent some time doing gfxContext-to-DrawTarget
conversions. (Also nsRendering-to-DrawTarget conversions, which are basically
the same because nsRenderingContext is a wafer-thin wrapper around gfxContext.)
The number of occurrences of gfxContext and nsRend
On Tue, Jan 12, 2016 at 4:30 PM, Jeff Gilbert wrote:
> For a similar situation, we used an etherpad to allow painless
> acquisition of pending todos.
Good idea. I created
https://public.etherpad-mozilla.org/p/EasyDrawTarget for this purpose.
Nick
___
d
> Are C++ units tests that don't use GTest still run as part of the build job?
Chris told me that non-GTest C++ unit tests run in the "Cpp" job, and
that one-off test programs in make check targets will continue to run
as part of the build job.
Nick
___
On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote:
>
> I've gotten into the habit of just landing things if I r+ them and I think
> they are ready to land. This has startled a few people because it is a major
> role reversal of how we've done things for years. (Typically we require the
> patch
On Fri, Jan 22, 2016 at 1:35 PM, Gregory Szorc wrote:
>
> I encourage my fellow reviewers to join me and "just autoland it" when
> granting review on MozReview.
This thread is getting long and complicated. The simplest thing is to
say "actually, don't autoland someone else's patch without their
c
On Tue, Feb 2, 2016 at 10:55 AM, Xidorn Quan wrote:
>>
>> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit
>> Windows. If I’m reading the data correctly, more than half. A small
>> percentage of those don’t have SSE2.
>
> It's not surprising to me. We didn't have Firefo
On Fri, Jul 24, 2015 at 11:26 AM, Nicholas Nethercote
wrote:
>
> Given that, I went ahead and filed bugs to get rid of the ~200
> nsBaseHashtable::EnumerateRead() calls and ~140
> nsBaseHashtable::Enumerate() calls. They are all marked as blocking
> https://bugzilla.mozilla.org/
Approval requests for release/beta/aurora in Bugzilla still have
"[String/UUID change made/needed]" as one of the points in the checklist,
too. Though maybe we need to wait for this change to reach those branches
before removing that.
Nick
On Sat, Jan 30, 2016 at 8:52 AM, Ehsan Akhgari
wrote:
>
On Wed, Mar 9, 2016 at 7:56 AM, David Burns wrote:
>
> we started working on
> replacing the Autoconf configure script. We are planning to replace the old
> shell and m4 code with sandboxed python, which will allow us to have
> improved performance (especially on Windows), parallel configure chec
On Wed, Mar 9, 2016 at 6:40 AM, Boris Zbarsky wrote:
>
> That said, some of your results are a bit suspect.
Indeed, microbenchmarks like these are surprisingly difficult to write
well, and they often end up measuring something other than what the author
intends.
Microbenchmarks that are extracte
Greetings,
erahm recently wrote a nice blog post with measurements showing the
overhead of
enabling multiple content processes:
http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/
The overhead is high -- 8 content processes *doubles* our physical memory
usage -- which limi
On Fri, Mar 18, 2016 at 2:29 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
>
> I seem to remember that our ChromeWorkers (SessionWorker,
> PageThumbsWorker, OS.File Worker) were pretty memory-hungry, but I don't
> see any workers there. Does this mean that they have negligible overhead
On Tue, Mar 15, 2016 at 2:34 PM, Nicholas Nethercote
wrote:
>
>
-
> Conclusion
>
-
>
> The overhead per content process is sign
On Wed, Mar 23, 2016 at 3:03 AM, Mason Chang wrote:
> Hi David,
>
> The main benefit is architectural with a huge simplification of our
> graphics code, with a nice side benefit of performance. As it stands today,
> we have multiple different rendering paths for each platform (Linux, OS X,
> Wind
On Tue, Apr 12, 2016 at 2:45 PM, Masayuki Nakano
wrote:
>
>
> So, my question is, why do we still have Qt widget in mozilla-central?
What the reason of keeping it in mozilla-central?
The same question can be asked of widget/uikit/, which I believe is for the
old, never-released port to iOS.
I wa
On Mon, Mar 21, 2016 at 3:50 PM, Nicholas Nethercote
wrote:
>
> - Heap overhead is significant. Reducing the page-cache size could save a
> couple of MiBs. Improvements beyond that are hard. Turning on jemalloc4
> *might* help a bit, but I wouldn't bank on it, an
Great stuff all around! Thank you for the update.
Nick
On Fri, Apr 15, 2016 at 4:07 AM, Jonathan Griffin wrote:
> Engineering Productivity is off to a great start in 2016; here’s what we’ve
> been up to in Q1.
> Build System
>
> Build system improvements are a major priority for Engineering Prod
For me, having the CVS history in the mozilla-central repo would be
much more helpful than having all the different repositories in one.
Nick
On Sat, Apr 16, 2016 at 11:41 AM, smaug wrote:
> On 04/15/2016 11:29 PM, Gregory Szorc wrote:
>>
>> On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend
>> wro
On Sun, Apr 17, 2016 at 3:11 AM, L. David Baron wrote:
>
> We should instead use data to target advice on use of try to the
> correct people, and also use that data to allow people to see where
> they fit in in terms of ratios of Try resource usage to pushes, and
> breaking the tree to pushes.
We
On Mon, Apr 18, 2016 at 10:34 AM, Kartikaya Gupta wrote:
>
> My view is that if we have a lot of bugs and regressions, time spent
> investigating and fixing those naturally acts as a backflow to new feature
> work, which prevents the introduction of even more bugs and regressions. So
> really time
Hi,
There is a longstanding NSS crash -- which occurs at a rate of a ~200
per week -- that appears to be caused by buggy detection of AVX
instruction set support.
If you know about AVX detection and want to help, please take a look
at https://bugzilla.mozilla.org/show_bug.cgi?id=1263495.
Thank y
Hi,
C++ constructors can't be made fallible without using exceptions. As a result,
for many classes we have a constructor and a fallible Init() method which must
be called immediately after construction.
Except... there is one way to make constructors fallible: use an |nsresult&
aRv| outparam to
On Thu, Apr 21, 2016 at 11:50 AM, Jim Blandy wrote:
> The pattern seems reasonable enough.
>
> DXR says we have 2579 "init" or "Init" functions, and 9801 callers of such
> functions. I used:
>
> function:init ext:cpp ext:h
> callers:init ext:cpp ext:h
There are also some called "Initialize" :)
I
On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione wrote:
>
> If we do this, can we please use |nsresult*| rather than |nsresult&|?
I prefer a reference because of the guarantee of non-nullness. But I
could live with a pointer if people think it's better.
Nick
___
On Thu, Apr 21, 2016 at 2:13 AM, Bobby Holley wrote:
> I believe Ehsan was close to having Clang static analysis running on
> Windows.
Nathan Froyd has also been involved, and should be included in any
discussion there.
Nick
___
dev-platform mailing li
On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote:
> The general problem that
> it doesn't alleviate is that failure to check the return value leaves you
> with a reference/pointer to an object in an ill-defined half-constructed
> state. At least for heap allocations, I'd much rather have the p
On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote:
>>
>> Maybe you're referring to factory methods, like this:
>>
>> static T* T::New();
>>
>> which would return null on failure. Such methods can be useful, but
>> there's two problems. First, they're not applicable to stack-allocated
>> objects
On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva wrote:
> Fallible construction (even with a way to report failure) is annoying if
> only because the object's destructor has to account for the possible
> invalid states. I much prefer having a static creation method that will
> only instantiate the o
o. So I am perfectly
> happy with handling them differently, and I can't think of a stack
> allocated object in the code I work with that would need something as
> involved as a static creation method or an nsresult& out param, to be
> honest.
>
> Cheers,
>
> Nical
>
On Thu, Apr 21, 2016 at 8:41 PM, Martin Thomson wrote:
>
>> - I suspect that in some heap-allocated objects it will be hard to do
>> the fallible parts without having an object of the relevant type. I
>> don't have specific examples, just a hunch.
>
> I'm not aware of any way that necessary state
On Fri, Apr 29, 2016 at 10:25 AM, Nicholas Nethercote
wrote:
>
> I just landed on inbound the patches in bug 1267550, which renamed
> MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE.
>
> A shorter name was in order because it's an attribute that is already
> used widely, and s
Hi,
I just landed on inbound the patches in bug 1267550, which renamed
MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE.
A shorter name was in order because it's an attribute that is already
used widely, and should be used even more, because it catches real
problems. In fact, any function that is fallible
On Sat, Apr 30, 2016 at 6:46 AM, Chris Peterson wrote:
>
> In theory, nsresult seems like an important type to check.
>
> That said, I once tried building Gecko with `#define NS_IMETHOD
> MOZ_WARN_UNUSED_RESULT NS_IMETHOD_(nsresult)`. There were over 10,000
> warnings for XPCOM method callers not
It's natural that engineers in different parts of the organisation and
community will have different priorities.
Let's all take a deep breath and keep the discussion calm, please.
Nick
On Sat, Apr 30, 2016 at 1:30 AM, wrote:
> On Friday, April 29, 2016 at 2:44:25 AM UTC-5, Henri Sivonen wrote:
The good news is that jseward has been doing regular TSan runs with
xpcshell tests and fixing reported races since last year. Bug 929478
is the tracking bug. The number of reported races is much lower than
it used to be, and Telemetry code is the single biggest remaining
offender, which is why jsew
Greetings,
I've written a document called "All about crashes" which I've put on
the Project Uptime wiki:
https://wiki.mozilla.org/Platform/Uptime#All_about_crashes
It's about all the different ways we can discover, diagnose, and
address crashes. It's intended to be a comprehensive, because I wan
Hi,
Do we have documentation on how to read crash reports? The only thing
I have found is this page:
https://support.mozilla.org/en-US/kb/helping-crashes
which is not bad, but is lacking some details. I suspect there is
quite a bit of crash report interpretation wisdom that is in various
people'
On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel wrote:
>
> Wasn't sure how you wanted feedback. Here's some in email form.
Email is great, thank you.
> "Crashes are caused by defects"
>
> Reading this I think it implies defects in Firefox. This is not always the
> case. Crashes are also the re
On Thu, May 26, 2016 at 1:59 AM, Eric Rescorla wrote:
>>
>>> Under "Ways to prevent" you suggest
>>> "Ways to prevent (by making them impossible)" and rewriting in JS or Rust,
>>> using smart pointers, etc.
>>>
>>> This may prevent crashes in the narrow sense that it prevents SEGVs, etc.
>>> but i
On Wed, May 25, 2016 at 3:47 PM, Eric Rahm wrote:
> Thanks for putting this together!
>
> It would be nice to see some consolidated details on how to investigate
> crashes, ie loading minidumps in Visual Studio, interpreting results,
> figuring out when VS is lying to you and what disassembly to l
, so I filed bug 1275799.
On Wed, May 25, 2016 at 4:06 PM, Nicholas Nethercote
wrote:
> Hi,
>
> Do we have documentation on how to read crash reports? The only thing
> I have found is this page:
>
> https://support.mozilla.org/en-US/kb/helping-crashes
>
> which is not
On Thu, May 26, 2016 at 1:06 PM, Lawrence Mandel wrote:
>
>
> The aim is to make it much easier to handle intermittent test failures.
> Crashes may be possible as well.
>
> The project is not yet well defined. Jonathan Griffin is working on this
> with his team with the intention of getting starte
Hi,
Here is a crash-stats search that shows all the crash reports in the
past 7 days that have a "MozCrashReason" field -- which means they
were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
aggregated) by that field:
https://crash-stats.mozilla.com/search/?product=Firefox&_facets
On Tue, May 31, 2016 at 5:06 PM, Chris Peterson wrote:
>>
>> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
>> given. These are mostly OOMs, though there are a few others in there.
>> These ones should be annotated so they show up separately.
>
> MOZ_CRASH()'s explanation st
On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg wrote:
> You shouldn't need to annotate the file/line separately, because that is
> (or at least should be!) the top of the stack.
Yes. Don't get hung up on the lack of annotations. It isn't much of a
problem; you can click through easily enough.
On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew wrote:
>
> I took a quick look at a random one of these OOMs[1], and what strikes me
> about it is that according to the crash report:
>
> Total Virtual Memory2147352576
>
> Available Virtual Memory122331136
>
> Syste
On Wed, Jun 1, 2016 at 9:39 AM, Nicholas Nethercote
wrote:
>
> Yes. Don't get hung up on the lack of annotations. It isn't much of a
> problem; you can click through easily enough. I have filed bug 1277104
> to fix the handful of instances that are showing up in practice,
On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert wrote:
>
> Perhaps this isn't meant for me then? I looked at the query from the
> first post, but it's just noise to me. If it included the file that it
> crashed from, it would suddenly be very useful, since it'd then be
> trivial to see if there's so
Here's an update. This one is bug 1235183:
> 7 MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
This one is covered by bug 616421 (the signature includes a
combination of MOZ_CRASHes and other kinds of crashes):
> 8 MOZ_CRASH(Bogus tree op)459 0.04 %
Below are all th
t, and I
hope others will too.
Nick
On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert wrote:
> It would be useful to have a dashboard that collates this information better.
>
> PS: Sarcasm is unhelpful.
>
> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
> wrote:
>> On Wed, J
Hey baby,
Both kids are doing IXL right now! So I renamed Keira's account --
which Zack had been using -- as Zack, and then paid $29 to get an
extra account and added Keira.
N
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mo
Sorry, this email was not meant to go to this list. (Gmail changed the
auto-completion order I was accustomed to on the "address" field.)
Please ignore.
If anyone has the ability to remove this email from the list archives,
please do so!
Thanks.
Nick
On Fri, Jun 3, 2016 at 8:25 AM
BTW, you can tell if a crash report was triggered by this new feature
by looking for the presence of the "submitted from infobar" field.
On Sat, Jun 4, 2016 at 2:37 AM, Ehsan Akhgari wrote:
> FYI
>
> -- Forwarded message --
> From: Lawrence Mandel
> Date: Thu, Jun 2, 2016 at 6:10
Hi,
mozilla::NotNull is a recent addition to MFBT. It is used to mark
pointers (both raw and smart) that are never null, e.g.:
- NotNull
- NotNull>
- NotNull>
It's most useful when used in function parameters and class members,
more so than local variables. Its use can clarify APIs, and also hel
On Wed, May 25, 2016 at 4:06 PM, Nicholas Nethercote
wrote:
>
> Do we have documentation on how to read crash reports?
I've finished a first pass at documentation on understanding
individual crash reports. The bulk of the effort was in writing this
new page: https://developer.mozill
Hi,
FYI: when viewing a crash report on crash-stats, the order of the
fields in the "Details" (default) tab has changed slightly. Fields are
now grouped more logically (e.g. all OS fields are together, all
hardware fields are together). See the code [1] for details of the
grouping.
The verbose "
Hi,
Crash reports have a field called "WinSock LSP". In a crash report on
crash-stats.mozilla.org, this field is shown in both the "Details" tab
(which is the most important tab) and the "Metadata" tab (where all raw
crash report fields are always shown).
I suspect it is rare for this field to be
On Sun, Aug 21, 2016 at 2:30 AM, Philip Chee wrote:
>
>> We'll offer a standalone file that can be executed to install the
>> development environment.
>
> Isn't MozillaBuild "a standalone file that can be executed to install
> the development environment."
MozillaBuild unzips into lots of files a
Greetings,
I just added [1] a new property to XPIDL called [must_use].
When used with an IDL method, it will add MOZ_MUST_USE to the generated C++
declarations and macros relating to that method. Here is an example:
/* [must_use] void init (in nsIFile file); */
MOZ_MUST_USE NS_IMETHOD Init(n
On Tue, Aug 23, 2016 at 9:39 AM, R Kent James wrote:
> On 8/21/2016 9:14 PM, Nicholas Nethercote wrote:
>> I strongly encourage people to do likewise on
>> any IDL files with which they are familiar. Adding appropriate checks isn't
>> always easy
>
> Exactly
On Mon, Aug 22, 2016 at 2:14 PM, Nicholas Nethercote
wrote:
>
> If you file a bug to add [must_use] or MOZ_MUST_USE somewhere, please make the
> bug block the tracking bug
Some recent work on this front:
- Jan Varga used [must_use] in nsIQuota{ManagerService,Requests}.i
On Tue, Aug 23, 2016 at 11:40 PM, Benjamin Smedberg
wrote:
> cast-to-void is commonly suggested as an alternative to an explicit unused
> marking, and it is something that I wanted to use originally.
> Unfortunately, we have not been able to make that work: this is primarily
> because compilers of
On Tue, Aug 23, 2016 at 3:22 PM, R Kent James wrote:
>
> A common programming pattern that I would use, when I don't really care
> about why something failed, is:
>
> nsCOMPtr inputStream;
>
> pipe.GetInputStream(getter_AddRefs(inputStream));
>
> if (!inputStream) {
> ... take action
> }
>
> If
On Wed, Aug 24, 2016 at 9:38 PM, Gijs Kruitbosch
wrote:
>
> Can this problem be solved with more of these types of
> annotations/"compiler-aids", that is, could we teach the compiler to accept
> either nsresult or out checks at least for simple xpidl property fetches?
> Feels like that would avoid
On Fri, Aug 26, 2016 at 3:31 AM, ISHIKAWA,chiaki wrote:
>
> There ought to be a long-term plan for C-C and M-C to introduce such missing
> checks gradually.
That's exactly what I'm trying to do with MOZ_MUST_USE/[must_use]. Bug
1268766 is the tracking bug. There's a lot of work to be done.
Much
On Thu, Aug 25, 2016 at 10:33 PM, Gijs Kruitbosch
wrote:
>
> Sorry, I'm not being very clear, I'm afraid. I'm not asking to ditch
> nsresult.
>
> I'm wondering if we can make a "smarter" annotation than [must_use] that
> requires *either* a nullcheck on the outparam or an nsresult check (rather
>
Greetings,
NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1299727 for details,
including the justification.
See https://bugzilla.mozilla.org/show_bug.cgi?id=137 for a bug
that this change exposed, thus adding weight to the justificati
On Wed, Sep 14, 2016 at 3:22 AM, Gregory Szorc wrote:
> Just landed on the autoland repo and making its way to central shortly is a
> transition of the Windows toolchain from Visual Studio 2015 Update 2 /
> Windows SDK 10.0.10586.0 to Visual Studio 2015 Update 3 w/ KB3165756
> (version 14.0.25425.
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction
is also full of useful info.
> I need to know how can I contribute for a Firefox in new feature or API.I
> need to working on something else instead of bugs.
It depends exactly what you mean by "new feature". Have you
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
t
A comparison point: I opened
https://bugzilla.mozilla.org/show_bug.cgi?id=1264155 a while back
about removing widget/uikit/ -- which is used by the old iOS port of
Firefox -- and others disagreed so I let it slide. So there's
precedent for little-used/unused widget code hanging around. (Whether
or
Greetings,
crash-stats.mozilla.org has had some recent improvements that are
worth highlighting.
- There is new documentation on how to search through crash reports:
https://developer.mozilla.org/en-US/docs/A_guide_to_searching_crash_reports.
You might think you already know how to do this, but c
On Tue, Oct 11, 2016 at 5:17 AM, Peter Bengtsson wrote:
>
> If indeed, the memory report is safe to always show I'll change the template
> to always show the memory_report link (if applicable).
>
> Nicholas?
Based on nothing more than gut feeling, I'd prefer to keep it as PII.
Just feels like the
Greetings,
The presentation of start-up crashes on crash-stats has improved
recently. If you look at the top crashes for Nightly
(https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=52.0a1&days=7)
you will see three different icons that are next to some crash
signatures: a rocket,
[Forwarding this to a wider audience because this is a big deal. Please try
out these correlations! They can be critical in diagnosing the cause of a
crash.]
-- Forwarded message --
From: Adrian Gaudebert
Date: Fri, Nov 4, 2016 at 1:11 PM
Subject: New Correlations on crash-stats
On Thu, Nov 10, 2016 at 10:00 AM, Mike Hommey wrote:
>
> CppUnitTests are fine to keep.
Having said that, IMO it is desirable to convert CppUnitTests to gtests
where possible. Every CppUnitTest has to provide some basic check/pass/fail
infrastructure, and many of them provide their own. Convert
Hi,
Currently there are two platform regression triage meetings per week during
which bugs marked with the "regression" keyword are triaged. See
https://wiki.mozilla.org/Platform/ for details.
Last week Jim Mathies and I discussed the possibility of expanding the
triage to include bugs marked wit
On Thu, Dec 15, 2016 at 2:17 PM, Ryan VanderMeulen wrote:
>
> I like the idea in principle, but in practice, two meetings a week is
already not enough to get through regression bugs. Are we going to add more
meetings to accommodate this? And I'll note that already, attendance of the
regular regres
It was once a mess, but is not any more. MFBT has for some time used
standard Mozilla style, with the following minor exception described in
mfbt/STYLE:
- Some of the files use a lower-case letter at the start of function names.
This is because MFBT used to use a different style, and was later
c
Hooray!
What is the name of the job on Treeherder? I see a "Windows 2012 x64 opt
Executed by TaskCluster build-win64-clang/opt tc(Bcl)" job (and some minor
variations) but I suspect that's not the new static analysis one?
Nick
p.s. Nathan is omitting himself from the list of contributors -- he a
On Sat, Dec 24, 2016 at 2:10 AM, Ehsan Akhgari
wrote:
>
> > However, new files should follow standard Mozilla style and use
> > an upper-case letter at the start of function names.
>
> Isn't mozilla::Result new code?
Yes, and I requested the use of upper-case first letters in
https://bugzilla.moz
On Tue, Mar 5, 2013 at 11:47 AM, Dave Mandelin wrote:
>
> It appears that there a few areas that are only covered by Talos for now,
> though. I think in that category we have warm startup time via Ts, and basic
> layout performance via Tp. I'm not sure about memory, because we do seem to
> dete
On Thu, Apr 4, 2013 at 4:50 PM, Jeff Walden wrote:
> On 04/04/2013 01:55 PM, Daniel Holbert wrote:
>> MSVC C4244 is by far our spammiest MSVC warning -- it's already disabled
>> in /js/src due to its low value::trouble ratio.
>
> Actually I think this is a mistake, one that we should fix at some p
On Thu, Apr 4, 2013 at 9:27 PM, Karl Tomlinson wrote:
> Nicholas Nethercote writes:
>
>> Warnings about possibly dubious but common practices aren't much use.
>> I gave up on turning on -Wshadow for this reason,
>
> If you could now use |index| as a variable name, w
On Mon, Apr 8, 2013 at 4:46 PM, Benjamin Smedberg wrote:
>
> 1) early in the memory info, there appears to be a common pattern of a
> committed block and then 15 free blocks.
AIUI, on Windows the smallest block you can ask for with VirtualAlloc
is 4 KiB. However, no more than one VirtualAlloc bl
101 - 200 of 492 matches
Mail list logo
