Re: Increase in mozilla-inbound bustage due to people not using Try

Justin Lebar wrote: In addition, please bear in mind that landing bustage on trunk trees actually makes the Try wait times worse (since the trunk backouts/retriggers take test job priority over Try) - leading to others not bothering to use Try either, and so the situation cascades. I thought t

Re: Switching to stdint types on mozilla-central

Ehsan Akhgari wrote: Hello everybody, We have had a long history of using NSPR types such as PRInt32 everywhere on mozilla-central. This is no longer necessary as we have decent support for stdint types in mozilla/StandardInteger.h. I have a series of patches up for review on bug 579517 which

Re: Paint Timing Changes and Tp5

I'm going to rework the patches so that this change can be pref'd off. The rest of DLBI landing should improve the situation considerably (it improved Talos DHTML ~30%, and should reduce a lot of painting during tp5), as will OMTC. If I can't make up the performance difference in time for the ne

Fwd: Paint Timing Changes and Tp5

CC'ing dev-platform since I accidentally removed it. - Forwarded Message - From: "Matt Woodrow" To: "Benjamin Smedberg" Sent: Friday, August 10, 2012 11:27:20 AM Subject: Re: Paint Timing Changes and Tp5 >When OMTC arrives, which thread will be running the widget event loop >and recei

Re: Dragging an image inside contentEditable

This is probably a regression from https://bugzilla.mozilla.org/show_bug.cgi?id=499008. Could you please file a bug on bugzilla about this and CC me on it? (You can find me on bugzilla under :ehsan). Thanks! Ehsan On 12-08-08 8:18 PM, miva...@gmail.com wrote: Follow-up: testing using brows

Re: Paint Timing Changes and Tp5

On 8/9/12 11:37 AM, Benjamin Smedberg wrote: This seems important. If the computer is running close to 100% CPU which is why paints are being throttled, then we're just introducing extra work for no benefit. We know that a significant portion of our user base has relatively slow computers, and we

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On 12-08-03 5:46 PM, Blake Kaplan wrote: Benoit Jacob wrote: Isn't that exactly what mfbt/StandardInteger.h does? Yes, but the question is now: are we going to switch to using them over PR* types? Soon. See bug 579517. Ehsan ___ dev-platform ma

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On 12-08-03 1:32 PM, Justin Lebar wrote: tbsaunde pointed me to https://bugzilla.mozilla.org/show_bug.cgi?id=780203, where he's proposing we add stdint types to xpidl. I'd be happy to deprecate PRUintX in favor of stdint types. :) My patches in bug 579517 already do this. Ehsan

Re: Switching to stdint types on mozilla-central

On Thu, Aug 09, 2012 at 12:26:33PM -0400, Justin Lebar wrote: > > This will however > > bitrot most of your patches, so I have put together a script here > > which helps you > > unbitrot them. This script handles mq patches, and needs to be r

Re: Switching to stdint types on mozilla-central

On 12-08-09 12:26 PM, Justin Lebar wrote: This will however bitrot most of your patches, so I have put together a script here which helps you unbitrot them. This script handles mq patches, and needs to be run in the top mozilla-central dire

Re: Switching to stdint types on mozilla-central

> This will however > bitrot most of your patches, so I have put together a script here > which helps you > unbitrot them. This script handles mq patches, and needs to be run in the > top mozilla-central directory, and it creates a backup of

Re: Switching to stdint types on mozilla-central

...and I forgot to include the list! PRInt8 -> int8_t PRUint8 -> uint8_t PRInt16 -> int16_t PRUint16 -> uint16_t PRInt32 -> int32_t PRUint32 -> uint32_t PRInt64 -> int64_t PRUint64 -> uint64_t PRIntn -> int32_t PRUintn -> uint32_t PRSize -> size_t PROffset32 -> int32_t PROffset64 -> int64_t PR

Switching to stdint types on mozilla-central

Hello everybody, We have had a long history of using NSPR types such as PRInt32 everywhere on mozilla-central. This is no longer necessary as we have decent support for stdint types in mozilla/StandardInteger.h. I have a series of patches up for review on bug 579517 which switch us away from

Re: New MFBT features: enum underlying type and enum classes

On Thu, Aug 9, 2012 at 5:43 PM, David Rajchenbach-Teller wrote: > I mean that, in a number of places in our codebase, we use untyped > enumerations (which is only fair, given that we had no compiler support > for typed enumeration). If we decide to, we could probably write some > static analysis t

Re: Paint Timing Changes and Tp5

On 8/8/2012 9:16 PM, Matt Woodrow wrote: Are there details on what this actually means? e.g. don't we *have* to paint when when we receive a WM_PAINT event, and usually we shouldn't at other times? To clarify, these patches split painting up into two steps: 1) Compute invalid regions, build d

Re: Increase in mozilla-inbound bustage due to people not using Try

On 8/9/2012 10:35 AM, Justin Lebar wrote: Is there a plan to mitigate the coalescing on m-i? It seems like that is a big part of the problem. One thing that might help would be a limit on the number of consecutive pushes that a test is able to coalesced before another run has to be schedule

Re: New MFBT features: enum underlying type and enum classes

On 12-08-09 10:43 AM, David Rajchenbach-Teller wrote: Also, with this new feature, should we consider some static analysis to try and root out untyped enumerations? I'm not sure what you mean. I mean that, in a number of places in our codebase, we use untyped enumerations (which is only fair

Re: Switching nsnull to nullptr

On 12-08-08 9:16 PM, Nicholas Nethercote wrote: On Mon, Jul 30, 2012 at 4:14 AM, Aryeh Gregor wrote: When are we doing PRUint32? ;-) I'll see if I can't tackle that after I'm done with nsnull and nsresult. Great! I think the change to using stdint types in SpiderMonkey was a wonderful ste

Re: Include dependencies in Gecko

On 08/08/2012 04:32 PM, Justin Lebar wrote: So I have this scripts that gives for each header the number of translation units that use it, here is part of the output (i skipped the headers included in less than 9 TUs) from a week ago (after dzbarsky's patch): http://pastebin.mozilla.org/1745141

Re: New MFBT features: enum underlying type and enum classes

On 8/9/12 2:41 PM, Aryeh Gregor wrote: > On Thu, Aug 9, 2012 at 3:38 PM, David Rajchenbach-Teller > wrote: >> Perhaps, at some point, we will want to adapt xpidl to take advantage of >> this. > > XPIDL doesn't allow enums at all, does it? Not yet, no. But this doesn't prevent us from defining se

Re: Increase in mozilla-inbound bustage due to people not using Try

> In addition, please bear in mind that landing bustage on trunk trees actually > makes the Try wait times worse (since the trunk backouts/retriggers take test > job priority over Try) - leading to others not bothering to use Try either, > and so > the situation cascades. I thought tryserver used

Increase in mozilla-inbound bustage due to people not using Try

Increasingly over the last few weeks, people have been landing untested changes on mozilla-inbound that has resulted in bustage - which with high levels of coalescing (that makes finding the culprit require multiple time-consuming re-triggers) has meant closing the tree for several hours. For

Re: New MFBT features: enum underlying type and enum classes

On Thu, Aug 9, 2012 at 3:38 PM, David Rajchenbach-Teller wrote: > Perhaps, at some point, we will want to adapt xpidl to take advantage of > this. XPIDL doesn't allow enums at all, does it? https://bugzilla.mozilla.org/show_bug.cgi?id=8781 > Also, with this new feature, should we consider some

Re: New MFBT features: enum underlying type and enum classes

On 8/9/12 11:29 AM, Aryeh Gregor wrote: > The other is to define "enum classes", a.k.a. strongly-typed or scoped > enumerations. This is done as follows: [...] That sounds great! Perhaps, at some point, we will want to adapt xpidl to take advantage of this. Also, with this new feature, should

Re: New MFBT features: enum underlying type and enum classes

On Thursday, August 9, 2012 3:05:56 PM UTC+3, Ted Mielczarek wrote: > Did you mean VC++ 2010 or 2012? There's no version called 2011. (VC > 2010 is VC 10.0, and VC 2012 is VC 11.0, confusingly.) I meant Visual Studio 11, based on this:

Re: New MFBT features: enum underlying type and enum classes

On Thu, Aug 9, 2012 at 5:29 AM, Aryeh Gregor wrote: > This instructs the compiler to allocate only one byte of storage for Foo, to > save space. Otherwise, the compiler is entitled to allocate anywhere from > one byte to the size of an int, and gcc in practice will allocate four bytes. > Comp

New MFBT features: enum underlying type and enum classes

Support just landed for two new C++11 features in MFBT: https://bugzilla.mozilla.org/show_bug.cgi?id=751554 They're described in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf In brief, this lets you do two new things. One is you can use MOZ_ENUM_TYPE() to speci

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On Thu, Aug 9, 2012 at 9:15 PM, Aryeh Gregor wrote: > "long" is of standard length in WebIDL, for better or for worse (it's 32 > bits). Since some of our IDLs come from WebIDLs in web specs, or at least > are based on them, I'm not sure we really want to standardize on stdint.h > types for all X

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On Wednesday, August 8, 2012 6:35:59 PM UTC+3, Benjamin Smedberg wrote: > If somebody wants to mass-change IDL to the standard types and then make > > deprecation warnings if you use "long", I'd take that patch. "long" is of standard length in WebIDL, for better or for worse (it's 32 bits). Si