On Wed, Nov 06, 2013 at 06:39:19PM -0800, Robert O'Callahan wrote:
> On Wed, Nov 6, 2013 at 6:21 PM, Mike Hommey wrote:
>
> > Our build system is currently building a lot of (fake) intermediate
> > static libraries, mainly for historical reasons. I am planning to fade
> > this away, but I also kn
On 11/05/2013 07:35 AM, James Graham wrote:
On 05/11/13 15:20, Till Schneidereit wrote:
Do we have any way to identify tests that break particularly often for
specific areas? If so, we could create a mach command that runs just
these
tests and finishes quickly. Something like `mach canary-tes
Sounds good to me!
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann
On Wed, Nov 6, 2013 at 6:21 PM, Mike Hommey wrote:
> Our build system is currently building a lot of (fake) intermediate
> static libraries, mainly for historical reasons. I am planning to fade
> this away, but I also know that some subsystems rely on the possibility
> to have those libraries def
Hi,
Our build system is currently building a lot of (fake) intermediate
static libraries, mainly for historical reasons. I am planning to fade
this away, but I also know that some subsystems rely on the possibility
to have those libraries defined for out-of-tree builds or whatever. I
think it's th
Currently on Linux our only 'supported' graphics backend is the
main-thread software backend (basic layers). It is possible to use the
main-thread OpenGL backend using the 'layers.acceleration.force-enabled'
pref, and to use OpenGL with off-main-thread compositing using that pref
and 'layers.of
For anyone interested, I'll be posting about 5 videos per week.
After today, only the videos that are live will be clickable.
The videos will be a bit rough around the edges, but the important part for me
is not perfection, just to get the content out there. If I want to refine
later I'll do th
On 11/06/2013 03:58 AM, Aryeh Gregor wrote:
> Has anyone considered allowing try pushes to run only specified
> directories of tests, and to allow incremental builds rather than
> clobbers on try? This would make try a heck of lot faster and
> resource-efficient, for those who are willing to accep
David Rajchenbach-Teller wrote:
> Context: I am currently working on patches designed to improve
> performance of some subsystems in Firefox Desktop by decreasing disk
> I/O, but I hope that they will also have an effect (hopefully
> beneficial) on power/battery usage. I'd like to confirm/infirm th
Thanks - I moved to 3.4 (latest recommended by us) and it solved it as well.
--
- Milan
On 2013-11-01, at 11:53 , Andrew McCreight wrote:
> I was having a similar problem compiling that file with regular debug builds
> on OSX. I solved it by upgrading to clang 3.3.
>
> Andrew
>
> - Origi
On 11/6/2013 10:57 AM, James Graham wrote:
It could be a win if the results are misleading infrequently enough
compared to the time savings that the expectation time for getting a
patch to stick on m-c decreases. That depends on the P(result is
different between try and clobber) and the time savi
On 06/11/13 15:49, Ryan VanderMeulen wrote:
On 11/6/2013 6:58 AM, Aryeh Gregor wrote:
Has anyone considered allowing try pushes to run only specified
directories of tests, and to allow incremental builds rather than
clobbers on try? This would make try a heck of lot faster and
resource-efficien
On 11/6/2013 6:58 AM, Aryeh Gregor wrote:
Has anyone considered allowing try pushes to run only specified
directories of tests, and to allow incremental builds rather than
clobbers on try? This would make try a heck of lot faster and
resource-efficient, for those who are willing to accept less c
You might be interested in bug 769431 where Intel modified power gadget to
export symbols that the profiler can use to sample the power state and
correlate it with execution.
On Tue, Nov 5, 2013 at 11:02 AM, jmaher wrote:
> I am working on using intel power gadget to measure the power usage.
>
Has anyone considered allowing try pushes to run only specified
directories of tests, and to allow incremental builds rather than
clobbers on try? This would make try a heck of lot faster and
resource-efficient, for those who are willing to accept less certain
results.
On Wed, Nov 6, 2013 at 12:5
On Tue, Nov 5, 2013 at 5:09 PM, Ed Morley wrote:
> Many cases of
> failures would have been caught be just a simple single-platform build+run
> of a single directory's worth of tests.
Requiring a single-platform build seems reasonable. However, it's much
harder to figure out what tests need to be
I think Gecko needs some work and attention around character
encodings. This is a collection of items that I need think we should
get it done and items that I think we should investigate.
# Why?
In general, it's better for the Web that browsers behave consistently.
In the character encoding depar
17 matches
Mail list logo
