On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
Could we compress major parts of omni.ja en block? We could for
example stick all JS we load at startup into a zip with zero
compression and then compress that into an outer zip. I think we
already support nested containers like
On Fri, Feb 21, 2014 at 11:38 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
We now live in a memory-constrained world. By we, I mean anyone
working on Mozilla platform code.
I realize that .so size matters much less than per-process
heap-allocated stuff, but still:
On the i18n front,
Ehsan Akhgari wrote:
On 2014-02-26, 4:52 AM, Neil wrote:
The one that I spotted is that MSVC is unable to optimise static
variables, e.g. when you write static const length =
ArrayLength(array); If you write this as a local then the compiler is
able to optimise it away in release builds.
Andreas Gal wrote:
Could we compress major parts of omni.ja en block? We could for example stick
all JS we load at startup into a zip with zero compression and then compress
that into an outer zip. I think we already support nested containers like that.
Assuming your math is correct even
On 2014-02-27, 7:40 AM, Neil wrote:
On 2014-02-24, 1:25 PM, Chris Peterson wrote:
To avoid developers and reviewers from having to remember special
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.
They're not quivalent.
Would you mind xpanding on that?
Sure.
On 2/26/2014 4:36 PM, Bobby Holley wrote:
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman whardma...@gmail.comwrote:
It seems like it would be trivial to add a button in the Preferences UI to
let people precache all dynamically-loaded data.
I don't think that would be trivial. In particular,
On Thu, Feb 27, 2014 at 6:27 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
On 2/26/2014 4:36 PM, Bobby Holley wrote:
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman whardma...@gmail.com
wrote:
It seems like it would be trivial to add a button in the Preferences UI to
let people
On 2/27/2014, 12:30 AM, Axel Hecht wrote:
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/23/2014 11:54 PM, Daniel Holbert wrote:
On 02/22/2014 12:26 PM, Hubert Figuière wrote:
FWIW, I (and others) have been working on that, as a side project,
for a while now, and I think we're actually in pretty good shape
right now.
We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
Does that mean a patch to squelch the uninitialized variable
warnings in layout will now be accepted? Those are the only
warnings in layout on my (Linux, debug) builds.
Daniel Holbert writes:
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
Does that mean a patch to squelch the uninitialized variable
warnings in layout will now be accepted? Those are the only
warnings in layout on my (Linux, debug) builds.
layout/base/FrameLayerBuilder.cpp:3462:56
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/27/2014 03:11 PM, Karl Tomlinson wrote:
Daniel Holbert writes:
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
Does that mean a patch to squelch the uninitialized variable
warnings in layout will now be accepted? Those are the only
On Thursday 2014-02-27 15:44 -0500, Zack Weinberg wrote:
This is exactly the same thing dbaron said the last time I brought
this up (quite some time ago - 2010, maybe?) I didn't buy it then and
I don't buy it now. I think it is far more likely that a
maybe-used-uninitialized true positive
On 2/27/2014 10:00 AM, Nathan Froyd wrote:
- If there is a TEST-FAIL or a TEST-UNEXPECTED-PASS, then the failure itself is
logged, along with some number of messages (currently capped at 100) since the
start of the test or the last failure. The intent here was to provide most of
the benefits
I think it would be nice if there were a way of suppressing
the warning on a case-by-case basis, like with an
__attribute__((uninitialized)) or something. We could add
that annotation to places where we know not initializing
is safe, and treat the remaining cases as errors.
Cheers,
Botond
-
On Thu, Feb 27, 2014 at 12:44 PM, Zack Weinberg za...@panix.com wrote:
Treating these as warnings, not errors, is probably the best thing
here. If you see the warning and you've recently changed that
code, then check it. If you haven't, you see the may be and
ignore it.
This is exactly
- Original Message -
On 2/27/2014 10:00 AM, Nathan Froyd wrote:
- If there is a TEST-FAIL or a TEST-UNEXPECTED-PASS, then the failure
itself is logged, along with some number of messages (currently capped at
100) since the start of the test or the last failure. The intent here was
On Thu, Feb 27, 2014 at 07:33:39PM +0900, Mike Hommey wrote:
On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
Could we compress major parts of omni.ja en block? We could for
example stick all JS we load at startup into a zip with zero
compression and then compress that into
On 2/27/14, 2:02 PM, Nicholas Nethercote wrote:
So I'm pleased to hear that -W{sometimes,maybe}-initialized have lower
false positive rates. Investigating them sounds like the most
promising avenue for progress.
Just to be clear: gcc's -Wmaybe-uninitialized is still very spammy.
gcc's
19 matches
Mail list logo
