On Fri, Aug 10, 2012 at 2:04 PM, Jason Smith jsm...@mozilla.com wrote:
* Flagging of a risky patch needing to be sure it works - This is
where doing a deep dive generally by formulating a test plan and
executing it is useful.
This suggestion reminds me of the fact that members of the JS
On Tue, Sep 4, 2012 at 9:39 PM, Mike Hommey m...@glandium.org wrote:
On the other hand, the ccache miss rate is pretty high, at least it is
for me, so in the end, ccache might not be a win at all.
That's what I've found, for my compiling patterns.
Nick
On Thu, Sep 13, 2012 at 4:27 PM, Jonas Sicking jo...@sicking.cc wrote:
* Some content providers strike deals with hardware manufacturers
which allow devices made by the manufacturer to access content for
free. One way that this is implemented is by looking for tokens in UA
strings and serve
On Mon, Sep 24, 2012 at 5:22 PM, Tim timvk...@gmail.com wrote:
So there's a new benchmark out, seemingly from google.
It is designed to test performance in web app bottlenecks, especially DOM,
canvas API methods, SVG.
Paul Irish from Google's Chrome team is in charge of it. He blogged on it
On Wed, Sep 26, 2012 at 9:37 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Has anyone reached out directly to the guys running the benchmark to
try and get a feel for what their motivations are here? They may
actually be willing to do the work necessary to make this a good
benchmark.
Justin
On Tue, Sep 25, 2012 at 6:23 PM, Daniel Buchner dbuch...@mozilla.com wrote:
I know the principal Google PM, Alex K, who heads up RoboHornet - he has
been extremely helpful with our Web Components initiative. I believe he had
good intentions with RoboHornet, and his personal posts (and those of
On Thu, Oct 4, 2012 at 10:18 AM, Justin Lebar justin.le...@gmail.com wrote:
1) Build errors are hard to identify with make. Parallel execution can make
them even harder to track down. Poor output from invoked processes is also a
problem.
I have a script [1] which works well enough for my
Hi,
In https://wiki.mozilla.org/Tree_Rules/Inbound, one of the steps under
Please do the following after pushing to inbound is:
Add the inbound changeset URL to the bug. If there are multiple
patches on the bug and you are not pushing all of them, please
indicate which one(s) you pushed (eg: use
On Mon, Oct 8, 2012 at 12:57 PM, L. David Baron dba...@dbaron.org wrote:
At the very least, you need documentation on where to get or find
mach and what directory to run it in.
(I don't seem to have it right now, and I'm not sure if the mach
you're talking about is what I'd get if I 'sudo
On Tue, Sep 25, 2012 at 7:17 PM, Daniel Buchner dbuch...@mozilla.com wrote:
I will talk with Alex about all of the concerns you've raised (hopefully
this week)
Hopefully we can get everything straightened out and produce another great
benchmark option that we can all consume/contribute to!
Hi,
I'm seeing allocations like this in DMDV:
Reported(js): 2,765 block(s) in record 6 of 3468
231,104 bytes (225,824 requested / 5,280 slop)
1.42% of the heap (11.48% cumulative reported)
Allocated
at 0x402C2AF: malloc (vg_replace_malloc.c:270)
by 0x7A9F520: js_malloc (Utility.h:153)
On Thu, Nov 1, 2012 at 6:33 PM, therealbrendane...@gmail.com wrote:
The tyranny of hierarchy never ends. Either we have subsidiarity for js and
other modules, or not. If Gecko is one big module -- ok, I get it. But you
need a principle for giving js its own tests while hoisting all others.
On Sat, Nov 3, 2012 at 6:59 AM, Jason Duell jduell.mcb...@gmail.com wrote:
I see an increasing number of patches using anonymous namespaces instead of
'static'. This is debugger unfriendly
It also obfuscates the visibility of the identifier, because the
|namespace {| is often far from the
On Wed, Nov 21, 2012 at 8:19 AM, Benjamin Smedberg
benja...@smedbergs.us wrote:
Thank you to everyone who participated in this thread. Given the existing
information, I have decided to proceed with disabling windows 64-bit nightly
and hourly builds.
It's clear now that this decision has
On Tue, Nov 27, 2012 at 2:35 PM, Gregory Szorc g...@mozilla.com wrote:
If you have |-s|, if you build with |./mach build|, it uses silent mode by
default, so again, you don't need MOZ_MAKE_FLAGS.
What about --no-print-directory? I specify that too...
Nick
Hi,
This is a moderately common idiom:
NS_ENSURE_TRUE(foo, );
It also occurs with NS_ENSURE_FALSE and NS_ENSURE_SUCCESS. It's used
in functions that return |void|.
Unfortunately, it causes warnings with recent versions of clang, and
they can turn into errors if you have
Hi
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
says that mozilla code files should have the following Emacs and Vim
mode lines:
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil;
c-basic-offset: 2 -*- */
/* vim: set ts=2 et sw=2 tw=80: */
AIUI, |tab-width| in
On Thu, Jan 3, 2013 at 5:13 PM, Justin Lebar justin.le...@gmail.com wrote:
Are there any common installations of vi/vim that actually honor
modelines anymore? The ones on the Linux distros that I used
stopped doing so as a security measure.
Mine (vanilla Ubuntu 12.10) does. I had to |set
On Fri, Jan 4, 2013 at 12:23 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
But putting sts in would be
reasonable for those that don't have |smarttab| set.
So it sounds like the recommended mode lines should look like this:
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil;
c
On Fri, Jan 4, 2013 at 4:21 PM, Benjamin Smedberg benja...@smedbergs.us wrote:
So it sounds like the recommended mode lines should look like this:
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil;
c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
Please make this
Of the three options I present, the one that I think has the
strongest support and least opposition among the developers
investigating the problems is option 2:
# (2) Disable the testpilot extension on aurora using the patch in
# comment 48, and reopen mozilla-aurora. comment 43 says
On Tue, Jan 22, 2013 at 2:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/20/13 2:37 PM, Gregory Szorc wrote:
* Have all or most of chrome-privileged JS share the same compartment
(like on B2G). It's my understanding the CPG decision was largely driven
by content/security requirements and
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Given the above, I'd like to propose the following long-term solutions:
1. Disable PGO/LTCG now.
2. Try to delay disabling PGO/LTCG as much as possible.
3. Try to delay disabling PGO/LTCG until the next time that
On Sat, Feb 2, 2013 at 6:26 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Vladan performed the analysis on telemetry measures reported out of a Tp5
run and the results seem to indicate that the performance of several things
such as GC and CC, image decoding, page loading, session restore,
On Tue, Jan 22, 2013 at 6:13 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=759585 proposes
introducing zones. Compartments in the same zone could share
arenas, which would fix (1) (for compartments in the same zone). This
would also fix
On Tue, Feb 12, 2013 at 3:29 PM, Jet Villegas j...@mozilla.com wrote:
BTW, 20 seems to be a very high number to cache per tab. The biggest problem
I'd like to solve is that I often accidentally swipe back, and that's almost
always just 1 page back.
That was my first thought, too.
Nick
On Wed, Feb 20, 2013 at 7:04 PM, Kyle Huey m...@kylehuey.com wrote:
I have no idea what phases are.
A sort of useful, sort of annoying Mercurial feature. Run |hg help
phase| in a sufficiently recent version for details.
Nick
ps: when you update to a version that supports phases, the first
On Thu, Apr 4, 2013 at 4:50 PM, Jeff Walden jwalden+...@mit.edu 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
On Thu, Apr 4, 2013 at 9:27 PM, Karl Tomlinson mozn...@karlt.net 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, would it be worth
On Mon, Apr 8, 2013 at 4:46 PM, Benjamin Smedberg benja...@smedbergs.us 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
Some comments on this whole thread:
- I'm very sympathetic to Justin's concerns. 120 MiB is not much
memory. While it's (somewhat) ok to kill apps that are using too much
memory, that doesn't work with the main B2G process, and I've been
CC'd on enough the B2G main process is using too much
On Mon, Apr 22, 2013 at 1:32 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
- Looking at the merged.json data: the system principal compartment
merging is happening on the main process, but doesn't appear to be
happening on all the other processes: Homescreen, Usage,
(Preallocated
On Mon, Apr 22, 2013 at 6:35 PM, Justin Dolske dol...@mozilla.com wrote:
That said, I think it's critically important that we're working to make JS a
acceptable -- nay, _excellent_ -- language/runtime for application
development for the long run. We can't tell a credible story about why
On Mon, Apr 22, 2013 at 12:54 PM, Kartikaya Gupta kgu...@mozilla.com wrote:
TL;DR:
* Inbound is closed 25% of the time
* Turning off coalescing could increase resource usage by up to 60% (but
probably less than this).
* We spend 24% of our machine resources on changes that are later backed
On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen rya...@gmail.com wrote:
-In the event of a long tree closure, the last green changeset from m-i will
be merged to inbound2 and inbound2 will be opened for checkins.
If I have a patch ready to land when inbound closes, what would be the
On Thu, Jul 11, 2013 at 5:06 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Jul 10, 2013 at 6:09 AM, smaug sm...@welho.com wrote:
One thing, which has often brought up, would be to have other automatic
coding style checker than just Ms2ger.
See
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would
require a lot more polling on my review queue.
You poll your review queue? Like, by visiting your Bugzilla
dashboard, or something like that? That's
On Fri, Jul 12, 2013 at 9:49 AM, Gervase Markham g...@mozilla.org wrote:
We keep hitting cases where we would like Firefoxes in the field to have
some data updated using a process which is much lighter in expended
effort than shipping a security release.
Would such an update increment the
On Wed, Jul 31, 2013 at 3:22 PM, Joshua Cranmer pidgeo...@gmail.com wrote:
We also have needs like
sizeOfIncludingThis/sizeOfExcludingThis that can't be as easily satisfied
with STL code.
This is, unsurprisingly, a requirement that's close to my heart. We
actually have a few instances of
On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp ga...@gavinsharp.com wrote:
Seems likely, I recall markh mentioning something similar - adblock probably
doesn't work in the content process.
That seems... less than ideal. I don't think creeping down the e10s
path when all the e10s issues haven't
On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp ga...@gavinsharp.com wrote:
Do you have specific issues you're worried about, or are you just speaking
about issues in general?
This AdBlock issue worries me specifically. And the fact that there's
breakage with our #1 add-on makes me worry in
Building mozilla-central has gotten noticeably slower.
Yep. A bit over two years ago I started doing frequent browser builds
for the first time; previously I'd mostly just worked with the JS
shell. I was horrified by the ~25 minutes it took for a clobber
build. I got a new Linux64 box and
On Sat, Aug 3, 2013 at 5:47 PM, Mike Hommey m...@glandium.org wrote:
One piece of the puzzle, at least in Mozilla code, is the tendency to
#include Foo.h when class Bar contains a field of type Foo*, instead of
leaving the include to Bar.cpp and forward declare in Bar.h. This
certainly
On Sat, Aug 3, 2013 at 5:47 PM, Mike Hommey m...@glandium.org wrote:
If I could speed up any part of the builds, it would be linking.
Waiting a long time to test a one file change sucks.
If you're on linux, you can try --enable-debug-symbols=-gsplit-dwarf.
That worked nicely. Before I get
On Sun, Aug 4, 2013 at 10:12 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
I tried --enable-debug-symbols=-gsplit-dwarf in a debug build like this:
CC='clang' CXX='clang++' ../configure --enable-debug
--enable-debug-symbols=-gsplit-dwarf --enable-optimize='-O0'
--enable-valgrind
I fixed these in https://bugzilla.mozilla.org/show_bug.cgi?id=881579.
Unlike the #include minimization, these don't require domain-specific
expertise and are easy to fix.
Did you measure a noticeable performance improvement? I can't imagine
that it would take too much time to include a file
On Sun, Aug 4, 2013 at 11:05 PM, Justin Lebar justin.le...@gmail.com wrote:
Nick, when you made changes to the JS engine's #includes, did you
observe a change in build times?
I don't have good measurements, largely because I've been doing it in
small chunks over time. I'll try to do
On Sun, Aug 4, 2013 at 11:48 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
Nick, when you made changes to the JS engine's #includes, did you
observe a change in build times?
I don't have good measurements, largely because I've been doing it in
small chunks over time. I'll try to do
On Tue, Aug 13, 2013 at 3:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Reducing our #include dependency will help speed up the compilation for
C/C++ files, and will also help us build fewer files after each change. We
have a tracker bug (785103) for improvements to the #include
Hi,
When you load about:memory, all the memory reporters run. Each
measurement made includes a description, which shows up in
about:memory as a tool-tip if you hover over the measurement.
These descriptions are string literals in C++ code, and they can be
long (e.g. several sentences). They
On Thu, Aug 15, 2013 at 4:22 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
- Somehow indicate that I want the string on the JS side to be an
JSExternalString.
I just had a discussion on #developers with khuey, bent, and jcranmer.
AIUI, if I change the |description| parameter
Hi,
Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has
indicated that jsapi.h is probably responsible for more recompilation
than any other file in the Mozilla tree -- it gets included in *lots*
of files, and it gets modified very often, partly because it's so
large.
namespace JS {
class Value; // #include js/Value.h (not jsapi.h) if you need the
*definition*
}
Oh, and avoid |jsval| -- it's on the way out, and is just a typedef
for JS::Value, which should be used instead.
Nick
___
dev-platform mailing
On Tue, Aug 20, 2013 at 11:19 AM, Jeff Walden jwalden+...@mit.edu wrote:
On 08/20/2013 09:01 AM, Boris Zbarsky wrote:
DOMJSClass.h only needs various forward-declarations, mostly. The
exceptions are:
2) It needs the definition of JSClass, for a member of the DOMJSClass
struct and the
On Tue, Aug 20, 2013 at 9:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
BindingUtils.h we could try breaking up in various ways, but it should be
very rare for _headers_ to include that file; for the most part such
inclusions are a bug from my point of view. For non-headers that include it
On Wed, Aug 21, 2013 at 4:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/21/13 2:23 AM, Nicholas Nethercote wrote:
And jswrapper.h includes jsapi.h.
I will try to remedy that... it looks doable.
Nick
___
dev-platform mailing list
dev-platform
Hi,
I just read this:
http://voices.canonical.com/jussi.pakkanen/2013/08/23/comparing-build-speeds-of-different-code-bases/
The author compiled 10 different C++ projects and found that the
number of lines compiled per second varied from 46 to 288.
The final paragraph:
What we can deduce from
On Fri, Aug 30, 2013 at 8:03 PM, Henri Sivonen hsivo...@hsivonen.fi wrote:
I think we should encourage Web authors to use UTF-8 *and* to *declare* it.
I'm no expert on this stuff, but Henri's point sure sound sensible to me.
Nick
___
dev-platform
Hi,
In a recent thread (Stop #including jsapi.h everywhere!), I wrote
the following.
Next time you're thinking of adding a |#include jsapi.h| statement,
please think about whether a forward declaration would suffice -- i.e.
if you are only using public JS types (i.e. not functions), and only
On Sun, Sep 8, 2013 at 2:38 AM, Benoit Jacob jacob.benoi...@gmail.com wrote:
I just was starting to look at BindingUtils.h as it is one of the most
important hub headers that we have (see
https://bugzilla.mozilla.org/show_bug.cgi?id=912735). But it seems that you
guys are already well ahead
On Sun, Sep 8, 2013 at 11:02 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I believe nsCxPusher.h only needs jsapi.h because it needs to know
sizeof(JSAutoRequest) and sizeof(JSAutoCompartment) for the members of
AutoCxPusher... Not sure what we can do with that.
One possibility is to move them
Hi,
I want to land https://bugzilla.mozilla.org/show_bug.cgi?id=910517,
which is just a clean-up of memory reporters (and is blocking a bunch
of follow-up work.) But I'm blocked by some baffling time-outs
occurring only on 32-bit opt Linux builds. (32-bit debug Linux builds
are fine.)
About
On Sun, Sep 8, 2013 at 4:29 PM, Nicholas Cameron
nick.r.came...@gmail.com wrote:
I don't think these kind of time improvements make it worth duplicating std
library code into mfbt, we may as well just pull in the headers and forget
about it. A caveat would be if it makes a significant
On Sun, Sep 8, 2013 at 5:29 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
I want to land https://bugzilla.mozilla.org/show_bug.cgi?id=910517,
which is just a clean-up of memory reporters (and is blocking a bunch
of follow-up work.) But I'm blocked by some baffling time-outs
occurring
Hi,
How is Talos on Android deployed? It appears to be done differently
to Talos on desktop (Windows, Mac, Linux).
I need to update the Android deployment so it has the patch from
https://bugzilla.mozilla.org/show_bug.cgi?id=912863 in order to land
the patch in
On Mon, Sep 9, 2013 at 5:52 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
How is Talos on Android deployed?
For those who are curious, there's a zip file that must be uploaded to
a particular machine, and then testing/talos/talos.json must be
modified to point to it. See
https
Does anyone know of prior art that we could apply to this problem, or
suggestions for how to implement this kind of logging safely, correctly, and
efficiently? It's possible that the system will need to be different across
platforms, using a logging service on B2G, some kind of native logging
On Wed, Sep 18, 2013 at 12:55 PM, Luke Wagner l...@mozilla.com wrote:
So, can we agree to use the typedefs all over Gecko?
And note that js/public/TypeDecls.h (included with |#include
js/TypeDecls.h) has the most common of these typedefs in one
convenient location.
Nick
On Fri, Sep 20, 2013 at 3:58 PM, Mike Hommey m...@glandium.org wrote:
Add the following to your .mozconfig:
export MOZ_PSEUDO_DERECURSE=1
That's it.
I just tried this on my fast new Linux machine.
- A |--enable-tests --enable-debug build| with -j8 improved from
15m48s to 13m30s, a
On Fri, Sep 20, 2013 at 11:24 PM, Mike Hommey m...@glandium.org wrote:
Try an incremental build, too :)
Some fresh results, with a |--enable-test --enable-debug
--enable-optimize='-O0'| build. (And I forgot to mention that I'm
using clang).
- Clobber build: 12m54s -- 11m16s (1.14x faster)
-
On Sat, Sep 21, 2013 at 10:16 AM, Gregory Szorc g...@mozilla.com wrote:
On 9/20/2013 4:47 PM, Nicholas Nethercote wrote:
I'm also surprised your no-change rebuild was 29s before this patch. I'm
still hovering around ~60s on my i7-2600K under Linux and on my 2011 MBP
pre-patch. This patch
On Wed, Oct 9, 2013 at 1:49 AM, Neil n...@parkwaycc.co.uk wrote:
Nor can I seem to get regexp search to work; I never get any results.
If you're using the regexp field in the advanced search, you're
probably failing to put '/' (or some other delimiter) at the start and
end. I too was having
On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
In the spirit of learning from this, what's next on the chopping block?
JSD. Firebug's the main consumer, AFAIK.
* Most OOM recovery in the JS engine
In the past that has been left alone due to the preference of
On Wed, Oct 9, 2013 at 9:12 PM, Mike Hommey m...@glandium.org wrote:
At the summit a few of us were talking about ways to promote Rust.
One idea was to rewrite a smallish, well-separated component of
Firefox in Rust, to (a) gain the benefits (parallelism, safety) of
Rust, and (b) promote Rust
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org wrote:
I'm sure fellow developers building on Windows felt sad that they were
left out on the recent build improvements. Rejoice at last, as we are
now bringing those to you.
In case you're interested how this happened... AIUI,
On Thu, Oct 17, 2013 at 5:58 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
I landed bug 895047 last night which makes the following changes:
1. It makes the char16_t type globally available across the tree.
2. It defines PRUnichar and jschar to be char16_t.
Nice! Replacing crusty old
On Mon, Oct 21, 2013 at 12:00 PM, Stephen Pohl sp...@mozilla.com wrote:
We are now (finally) getting ready to turn on history swipe animations
(bug 860493). There have been two major changes since sending out the
email below earlier in the year:
1. We will only store snapshots for the 5 most
On Wed, Oct 30, 2013 at 11:04 AM, Ed Morley emor...@mozilla.com wrote:
Hi all!
Trunk trees are currently closed [1] - the requirements for reopening are:
https://bugzilla.mozilla.org/show_bug.cgi?id=932781#c11
I have (slightly optimistically) started writing a post-mortem of this
closure,
On Thu, Oct 31, 2013 at 6:52 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
Remaining things I'm aware of:
One more: lots of patches will need to be backported to Aurora and
Beta. I've set the appropriate tracking flags on the bugs that I
think need it, but please double-check ones you
I have (slightly optimistically) started writing a post-mortem of this
closure, analyzing what went wrong and why, and how we might avoid it
in the future:
https://etherpad.mozilla.org/mEB0H50ZjX
FWIW, I added the following TL;DR to the document, which reflects my
understanding of the
On Tue, Nov 5, 2013 at 7:10 AM, James Graham ja...@hoppipolla.co.uk wrote:
So, as far as I can tell that the heart of the problem is that the
end-to-end time for the build+test infrastructure is unworkably slow. I
understand that waiting half a dozen hours — a significant fraction of a
work
On Fri, Nov 1, 2013 at 12:52 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
- Finish fixing the devtools leaks:
https://bugzilla.mozilla.org/show_bug.cgi?id=932880.
Fixed on mozilla-central and backported to aurora, beta, and
b2g26_v1_2. Nothing more to do.
- Finish fixing the social
On Sun, Nov 17, 2013 at 2:17 AM, smaug sm...@welho.com wrote:
the recent OOM cases have been really annoying. They have slowed down
development, even for those who
haven't been dealing with the actual issue(s).
Could we handle this kind of cases differently. Perhaps clone the bad state
of
Hi,
As you probably know, we just had a second (in a matter of weeks)
prolonged tree closure due to tests OOMing.
The post-mortem for the last tree closure
(https://etherpad.mozilla.org/mEB0H50ZjX) was quite satisfactory...
basically we fixed some leaks, tweaked some silly tests, and know how
to
On Tue, Nov 19, 2013 at 3:51 AM, Benjamin Smedberg
benja...@smedbergs.us wrote:
I'd like to announce and welcome Nathan Froyd as a peer of the XPCOM module.
Nathan is a careful and thoughtful reviewer, and I'm happy that he has
agreed to help spread review load and serve as the resident expert
Hi,
It feels to me like there have been quite a few graphics-related memory leaks
recently.
Here are a couple that have been fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=937878 (layer retention)
https://bugzilla.mozilla.org/show_bug.cgi?id=938612 (canvas leak)
Here is one that's still
On Tue, Nov 19, 2013 at 6:36 AM, Benoit Jacob jacob.benoi...@gmail.com wrote:
Because of the way it ended being used in many places, SurfaceDescriptor was
involved in maybe half of the b2g 1.2 blocking (koi+) graphics crashes that
we went over over the past few months.
During the Paris work
On Tue, Nov 19, 2013 at 3:17 PM, Tim Abraldes tabral...@mozilla.com wrote:
Somebody stop me if this already exists...
I'm envisioning a central location, probably a wiki page at
https://wiki.mozilla.org/BrokenBuilds or similar, where people can find the
answers to these questions:
1.
On September 12, a debug clobber build on my new Linux desktop took
12.7 minutes. Just then it took 7.5 minutes. Woo!
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thu, Nov 21, 2013 at 7:38 AM, Gregory Szorc g...@mozilla.com wrote:
You people are sick. I go to bed, wake up and my builds have gotten faster
And I've gone from 7.5 minutes to 6.75 minutes in the past day or two.
Nick
___
dev-platform mailing
Last I heard, the official recommendation from IT was for Mozilla
folks (esp. devs) to not upgrade to 10.9 yet, because some things
might not work. Is that no longer the case?
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Mon, Nov 25, 2013 at 1:46 PM, Aki Sasaki a...@mozilla.com wrote:
Github has closed access to https://github.com/mozilla/mozilla-central :
This repository has been disabled.
Access to this repository has been disabled by GitHub staff.
Contact support to restore access to this
On Tue, Nov 26, 2013 at 4:02 AM, Benjamin Smedberg
benja...@smedbergs.us wrote:
In crashkill we have been tracking crashes that occur in low-memory
situations for a while. However, we are seeing a troubling uptick of issues
in Firefox 23 and then 25. I believe that some people may not be able
Hi,
I'm working on getting Valgrind (Linux64-only) runs visible on TBPL.
https://bugzilla.mozilla.org/show_bug.cgi?id=valgrind-green is the tracking
bug. This aim of this email is to (a) get answers to some questions I have,
and (b) serve as a heads-up for people I will have to co-ordinate with.
On Tue, Dec 3, 2013 at 9:15 PM, Lawrence Mandel lman...@mozilla.com wrote:
I would assert that if a bug hasn't been fixed in 10 years it probably isn't
important enough to spend time on now.
I strongly disagree with this statement, and any follow-on implication
that blanket-closing bugs based
On Tue, Dec 3, 2013 at 5:02 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
I'm working on getting Valgrind (Linux64-only) runs visible on TBPL.
In order to understand what needs to be done, I looked at the Requirements
for
being shown in the default TBPL view, from From
https
[I'm highlighting this exchange, because it's been buried somewhat;
apologies for the misleading information]
On Tue, Dec 10, 2013 at 4:29 PM, Joshua Cranmer pidgeo...@gmail.com wrote:
Based on
On Tue, Dec 10, 2013 at 4:12 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
Unfortunately, on December 5th, just before the changes were enabled,
something
else happened that caused the Valgrind jobs to start timing out all the time.
This is being tracked in https
On Thu, Dec 12, 2013 at 9:48 AM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
Unfortunately, on December 5th, just before the changes were enabled,
something
else happened that caused the Valgrind jobs to start timing out all the time.
This is being tracked in https
On Fri, Dec 13, 2013 at 2:53 AM, Benjamin Smedberg
benja...@smedbergs.us wrote:
Also, we now have the ability to use DMD builds on Windows
DMD works on Windows debug builds, but doesn't currently work on opt
builds. But https://bugzilla.mozilla.org/show_bug.cgi?id=947117
(compile-time) and
1 - 100 of 435 matches
Mail list logo
