1105044
On Friday, November 28, 2014 9:07:09 PM UTC+8, Benjamin Smedberg wrote:
> On 11/27/2014 10:38 PM, allencb...@gmail.com wrote:
> > I've reported this in bugzilla. Any one has any workaround?
>
> I commented in the bug
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1105044). This is proba
You all know Telemetry, our Firefox data collection system that provides us
with real-world data about performance, hardware, usage and customizations.
Spark is an open-source in-memory data analytics cluster computing framework
originally developed in the AMPLab at UC Berkeley. In contrast to H
Hi,
Just a heads up that default storage has landed on m-c, bug 1083927.
I'm posting to this list because there are some changes in the way how
quota manager clients store data (mostly IndexedDB).
Old structure:
storage
persistent
temporary
New structure:
storage
permanent
On Tuesday, July 15, 2014 7:34:35 AM UTC-7, Josh Aas wrote:
> This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
> Formats Study and the Mozilla Research blog post entitled "Mozilla Advances
> JPEG Encoding with mozjpeg 2.0".
It would help if you would use much more dis
On 2014-11-28 11:18 AM, Nicolas B. Pierron wrote:
On 11/28/2014 03:36 PM, Ehsan Akhgari wrote:
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downsi
On 2014-11-28 11:02 AM, Jonathan Kew wrote:
On 28/11/14 14:36, Ehsan Akhgari wrote:
The question is: what do we gain from doing that, technical purity
aside? Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing
On 11/28/2014 03:36 PM, Ehsan Akhgari wrote:
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, 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
On 28/11/14 14:36, Ehsan Akhgari wrote:
The question is: what do we gain from doing that, technical purity
aside? Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing .cpp files, so keeping support for non-unifie
On 2014/11/28 18:26, Mike Hommey wrote:
On Fri, Nov 28, 2014 at 11:57:56AM +0900, ISHIKAWA,chiaki wrote:
On 2014/11/28 10:12, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, 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 in
On 11/27/2014 10:38 PM, allencb...@gmail.com wrote:
I've reported this in bugzilla. Any one has any workaround?
I commented in the bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=1105044). This is probably
due to the MacOS v2 signing work which restructured the bundles. Since
XULRunner is
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, 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 ensu
On 28/11/14 08:46, 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 this is important enough to
Hi Gregory
>
> Please read http://www.conifersystems.com/whitepapers/gnu-make/. That is
> one of my go to articles for explaining why make sucks.
I would not point people to this article as it is flawed. I won't go
through the points it mentions. Some are relevant, others aren't, and
some probab
On Fri, Nov 28, 2014 at 06:29:49PM +0900, Mike Hommey wrote:
> On Fri, Nov 28, 2014 at 12:46:07AM -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" (righ
On Fri, Nov 28, 2014 at 12:46:07AM -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
On Fri, Nov 28, 2014 at 11:57:56AM +0900, ISHIKAWA,chiaki wrote:
> On 2014/11/28 10:12, Mike Hommey wrote:
> >Hi,
> >
> >A year ago, when unified compilation was introduced to speed up builds,
> >a couple issues were raised and we conservatively restricted them out
> >of aurora/beta/release/esr.
>
Gregory Szorc wrote:
Please read http://www.conifersystems.com/whitepapers/gnu-make/.
"after a command fails, |make| does not delete the partially built
output file"
.DELETE_ON_ERROR was added to address this.
--
Warning: May contain traces of nuts.
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 this is important enough to keep
> non-unified builds around?
An
19 matches
Mail list logo
