Re: We live in a memory-constrained world

Henri Sivonen wrote: Any chance static atoms could reside as plain old static C data structures in the data segment of libxul.so instead of being heap-allocated? At least under MSVC, they have vtables, so they need to be constructed, so they're not static. Note that their string storage is

Re: Use of MOZ_ARRAY_LENGTH for static constants?

Ehsan Akhgari wrote: does fixing this enable you dogfood debug builds? I'm not expecting it to be a magic bullet. Where do you suggest I start? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org http

Re: Including Adobe CMaps

On 26/02/14 20:21, Jonathan Kew wrote: >> Lets turn this question around. If we had an on-demand way to load >> stuff like this, what else would we want to load on demand? > > A few examples: > > Spell-checking dictionaries > Hyphenation tables > Fonts for additional scripts If this came with an

Re: New necko cache?

Honza Bambas wrote: The old API talks only to the old cache. It's now used for appcache (Offline Application Cache) only. The old API doesn't emulate the new API well enough; it actually ignores failures to call onCacheEntryCheck, and reads uninitialised memory in that case. -- Warning: M

Re: Including Adobe CMaps

On 28/2/14 11:44, Gervase Markham wrote: On 26/02/14 20:21, Jonathan Kew wrote: Lets turn this question around. If we had an on-demand way to load stuff like this, what else would we want to load on demand? A few examples: Spell-checking dictionaries Hyphenation tables Fonts for additional sc

Re: We live in a memory-constrained world

On Fri, Feb 28, 2014 at 1:04 PM, Neil wrote: > At least under MSVC, they have vtables, so they need to be constructed, so > they're not static. So structs that inherit at least one virtual method can't be plain old C data? That surprises me. And we still don't want to give the dynamic linker init

Re: We live in a memory-constrained world

http://en.wikipedia.org/wiki/Plain_Old_Data_Structures confirms that POD can't have a vptr :-) Benoit 2014-02-28 7:39 GMT-05:00 Henri Sivonen : > On Fri, Feb 28, 2014 at 1:04 PM, Neil wrote: > > At least under MSVC, they have vtables, so they need to be constructed, > so > > they're not stat

Re: Including Adobe CMaps

On 28/02/14 12:37, Jonathan Kew wrote: > Presumably we always want the complete PSL available. So it really > should be part of the base product, not a [try-to-]load-on-demand resource. I was proposing it be part of the base product, but updated on demand. > Isn't it sufficient to update that wit

Re: We live in a memory-constrained world

- Original Message - > http://en.wikipedia.org/wiki/Plain_Old_Data_Structures > > > confirms that POD can't have a vptr :-) Just because it's not POD in the language doesn't mean that it necessarily requires a static initializer in all implementations: class Interface { public: const

Re: Fixing build warnings [was: Re: Always brace your ifs]

On 2/27/2014 2:02 PM, Nicholas Nethercote wrote: > On Thu, Feb 27, 2014 at 12:44 PM, Zack Weinberg 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

Re: Including Adobe CMaps

Boris Zbarsky schrieb: On 2/26/14 3:58 PM, Wesley Hardman wrote: Personally, I would prefer to have it already available. We have several deployment targets with different tradeoffs. Broadly speaking: Phones: expensive data, limited storage. Want to not use up the storage, so download lazil

Re: Fixing build warnings [was: Re: Always brace your ifs]

On 2/28/14 10:49 AM, Gregory Szorc wrote: Speaking of compiler warnings, do people commonly run into "compiler warning mismatch" with warnings-as-errors due to running separate versions of Clang/GCC/MSVC locally than what runs in automation? I did, to the point where I locally don't --enable-wa

Re: We live in a memory-constrained world

On Fri, Feb 28, 2014 at 05:59:13AM -0800, Nathan Froyd wrote: > - Original Message - > > http://en.wikipedia.org/wiki/Plain_Old_Data_Structures > > > > > > confirms that POD can't have a vptr :-) > > > class Interface { > public: > constexpr Interface() {} > virtual int f() = 0; > }

Maybe-uninitialized warning helper template

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is a half-baked idea that occurred to me in the shower this morning, but I think it's worth at least looking at. The trouble with squelching maybe-uninitialized warnings via initialization, when manual inspection indicates there's no problem, i

Re: Fixing build warnings [was: Re: Always brace your ifs]

On 2/28/2014 10:49 AM, Gregory Szorc wrote: > Speaking of compiler warnings, do people commonly run into "compiler > warning mismatch" with warnings-as-errors due to running separate > versions of Clang/GCC/MSVC locally than what runs in automation? i.e. > do you find yourself building things fine

Why are images that are uploaded in Pinterest and Instagram modified in terms of size and pixel colors?

When images are uploaded in Pinterest and Instagram, the size of the images get modified and so do the colors (within a ranges of +/- 10 pixels). Are images modified to align the images as a grid as seen in Pinterest and Instagram? If yes, how do they do it done? Also is there a way when the ima

Re: We live in a memory-constrained world

Neil wrote: Henri Sivonen wrote: Any chance static atoms could reside as plain old static C data structures in the data segment of libxul.so instead of being heap-allocated? At least under MSVC, they have vtables, so they need to be constructed, so they're not static. Note that their strin

Re: We live in a memory-constrained world

On 2/28/14 12:26 PM, Neil wrote: Perhaps we could probably use string buffers directly as atoms. Atoms have various info string buffers don't (like the hashcode). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozil

Re: Why are images that are uploaded in Pinterest and Instagram modified in terms of size and pixel colors?

On 2014-02-28, 11:53 AM, Usman Ehtesham wrote: When images are uploaded in Pinterest and Instagram, the size of the images get modified and so do the colors (within a ranges of +/- 10 pixels). Are images modified to align the images as a grid as seen in Pinterest and Instagram? If yes, how do

Re: Why are images that are uploaded in Pinterest and Instagram modified in terms of size and pixel colors?

On 2014-02-28 8:53 AM, Usman Ehtesham wrote: > When images are uploaded in Pinterest and Instagram, the size of the images > get modified and so do the colors (within a ranges of +/- 10 pixels). Are > images modified to align the images as a grid as seen in Pinterest and > Instagram? If yes, how

Re: We live in a memory-constrained world

On Friday 2014-02-28 11:04 +, Neil wrote: > Henri Sivonen wrote: > >Any chance static atoms could reside as plain old static C data structures > >in the data segment of libxul.so instead of being heap-allocated? > > > At least under MSVC, they have vtables, so they need to be > constructed, so

Changing how build automation interacts with the tree

(This is likely off-topic for many dev-platform readers. I was advised to post here because RelEng monitors dev-platform and I don't like cross-posting.) The technical interaction between build automation and mozilla-central has organically grown into something that's very difficult to maintai

Re: Fixing build warnings [was: Re: Always brace your ifs]

On 2014-02-28, 11:06 AM, Boris Zbarsky wrote: On 2/28/14 10:49 AM, Gregory Szorc wrote: Speaking of compiler warnings, do people commonly run into "compiler warning mismatch" with warnings-as-errors due to running separate versions of Clang/GCC/MSVC locally than what runs in automation? I did,

Re: Maybe-uninitialized warning helper template

On Sat, Mar 1, 2014 at 3:26 AM, Zack Weinberg wrote: > > Then, when you get a false-positive maybe-uninitialized warning, you > could just replace T var; with mfbt::ConditionalUse var; In a > release build, there would be no overhead; in a debug or valgrind > build you would get a prompt assertio

Re: Changing how build automation interacts with the tree

On 2/28/14 3:48 PM, Gregory Szorc wrote: * A lot of us want to kill client.mk. Having automation not directly calling it will allow us to finally do this. This will make bisects a bit exciting, because the right command to run to "do a toplevel build" will depend on the exact revision you have

Re: Maybe-uninitialized warning helper template

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 04:24 PM, Nicholas Nethercote wrote: > On Sat, Mar 1, 2014 at 3:26 AM, Zack Weinberg > wrote: >> >> Then, when you get a false-positive maybe-uninitialized warning, >> you could just replace T var; with mfbt::ConditionalUse var; >> In

Re: Changing how build automation interacts with the tree

On 2/28/14, 1:28 PM, Boris Zbarsky wrote: On 2/28/14 3:48 PM, Gregory Szorc wrote: * A lot of us want to kill client.mk. Having automation not directly calling it will allow us to finally do this. This will make bisects a bit exciting, because the right command to run to "do a toplevel build"

Re: Maybe-uninitialized warning helper template

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-02-28 1:52 PM, Zack Weinberg wrote: > Yeah, I guess you would. We could maybe just live with that - at > least, what *I* personally care about is not having to wade through > a flood of preexisting "maybe used uninitialized" warnings to find

Re: Maybe-uninitialized warning helper template

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 05:19 PM, Ralph Giles wrote: > On 2014-02-28 1:52 PM, Zack Weinberg wrote: > >> Yeah, I guess you would. We could maybe just live with that - >> at least, what *I* personally care about is not having to wade >> through a flood of pree

Re: Maybe-uninitialized warning helper template

> > Is there a way to make the template generate 'T var = var;' in the > > release case when there's no initializer? That's be a useful hack > > to silence -Wunused-variable, -Wsometimes-uninitialized, etc. on > > gcc and clang. > > I'm not aware of any way to do that, but I am certainly not the >

Re: Maybe-uninitialized warning helper template

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 06:04 PM, Botond Ballo wrote: >>> Is there a way to make the template generate 'T var = var;' in >>> the release case when there's no initializer? That's be a >>> useful hack to silence -Wunused-variable, >>> -Wsometimes-uninitialized,

Re: Use of MOZ_ARRAY_LENGTH for static constants?

On 2014-02-28, 6:05 AM, Neil wrote: Ehsan Akhgari wrote: does fixing this enable you dogfood debug builds? I apologize, I think that came out snarky, it wasn't mean to be. :-) I'm not expecting it to be a magic bullet. Where do you suggest I start? By profiling a debug build and see wher

Consensus sought - when to reset try repository?

tl;dr: what is the balance point between pushes to try taking too long and loosing repository history of recent try pushes? Summary: As most developers have experienced, pushing to try can sometimes take a long time. Once it takes "too long" (as measured by screams of pain in #releng)

Re: Consensus sought - when to reset try repository?

On Friday 2014-02-28 17:24 -0800, Hal Wine wrote: > So, the question is - what say developers -- what's the balance point > between: > - too often, making collaborating on try pushes hard > - too infrequent, introducing increasing push times Why not change the try repo reset procedure so that in

Re: Consensus sought - when to reset try repository?

On 02/28/2014 05:32 PM, L. David Baron wrote: > Why not change the try repo reset procedure so that instead of just > cloning mozilla-central, you also pull from the old try repo into > the new one all of the heads of try pushes made within the last one > or two weeks. (Presumably there's a list o

Re: Consensus sought - when to reset try repository?

On 02/28/2014 05:40 PM, Daniel Holbert wrote: On 02/28/2014 05:32 PM, L. David Baron wrote: Why not change the try repo reset procedure so that instead of just cloning mozilla-central, you also pull from the old try repo into the new one all of the heads of try pushes made within the last one or

Re: Consensus sought - when to reset try repository?

On 2/28/2014 8:44 PM, John Schoenick wrote: Or taking this a step further, having a rolling cronjob |hg strip| revisions not on m-c older than a certain date would remove the need to perform resets entirely, and give a predictable date after which your try push would disappear. You could even add

Re: Consensus sought - when to reset try repository?

On Friday 2014-02-28 17:44 -0800, John Schoenick wrote: > Or taking this a step further, having a rolling cronjob |hg strip| > revisions not on m-c older than a certain date would remove the need > to perform resets entirely, and give a predictable date after which > your try push would disappear.

Re: Consensus sought - when to reset try repository?

On 2014-02-28 17:32 , L. David Baron wrote: > On Friday 2014-02-28 17:24 -0800, Hal Wine wrote: >> So, the question is - what say developers -- what's the balance point >> between: >> - too often, making collaborating on try pushes hard >> - too infrequent, introducing increasing push times > >