Re: From nsIntSize to gfx::IntSize
The first part just landed on inbound (Bug 1132854). On Fri, Mar 27, 2015 at 10:28 PM, Robert O'Callahan rob...@ocallahan.org wrote: Sounds good. But, is gfx::IntSize going to get a ToAppUnits method like nsIntSize has? The method: nsIntSize::ToAppUnits(nscoord aAppUnitsPerPixel) const was replaced by a function: IntSizeToAppUnits(mozilla::gfx::IntSize aSize, nscoord aAppUnitsPerPixel) As a followup it's probably worth replacing all of nsIntSize with gfx::IntSize. So no more nsIntSize and gfxIntSize typedefs anywhere (I guess layout is the most impacted non-gfx module)? Sounds go to me, I felt like it wasn't my decision to make, but I do prefer having ony gfx::IntSize in the entire gecko code base. Cheers, Nical ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
TBPL now redirects to Treeherder
The TBPL - Treeherder redirects have now been deployed to production, to allow a day or so of bake time before we switch off TBPL for good. They handle tree/pusher/revision URL params, so the vast majority of legacy TBPL links will redirect to an equivalent Treeherder page [1]. Many thanks to everyone who has contributed to TBPL over the years, and a warm welcome to those who join us on the Treeherder project [2] in the future! The Treeherder UI can be set up locally in only a few minutes [3], if anyone would like to contribute/has an itch they wish to scratch :-) This will be the last multi-newsgroup TBPL/Treeherder related email - so for further updates please subscribe to dev.tree-management [4] (now talos-email free). Best wishes, Ed the rest of the Treeherder team. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1145713#c7 / https://hg.mozilla.org/webtools/tbpl/rev/73ad7a52c30e [2] https://wiki.mozilla.org/Auto-tools/Projects/Treeherder [3] https://treeherder-ui.readthedocs.org/en/latest/installation.html [4] https://lists.mozilla.org/listinfo/dev-tree-management On 9 March 2015 at 03:52, Ed Morley emor...@mozilla.com wrote: tl;dr: Barring any surprises, we would like to switch off TBPL [1] at the end of the month. == Treeherder (TBPL's replacement)[2] has been in production since the summer, and used as the primary tree-management tool by sheriffs since September. Since then, the majority of users of TBPL have switched over to Treeherder and the survey of remaining TBPL users has not revealed any major surprises (bug 1117183). More critically, TBPL is no longer capable of giving an accurate indication of tree health, or for determining whether a Try push was successful, since: * TBPL is not being used by the sheriffs, so failures on integration repositories are not classified. * The TBPL hidden/visible jobs list is not up to date, so it's hard to tell which failures are expected vs real breakage. * Support for new buildbot job/platform types are only being added to Treeherder, so there are already jobs not recognised by TBPL. * Most importantly: TBPL only supports displaying buildbot build/test results, but there are now other submitters of data such as Taskcluster - which are only supported on Treeherder. We're concious that there are some papercuts/feature regressions when comparing TBPL to Treeherder (for example UI performance/responsiveness), however these are actively being worked on and aside from the remaining deps of bug 1059400, are not expected to block TBPL end of life. If anyone has objections, now would be a good time to raise them - please send replies to dev.tree-management (subscribe for Treeherder news, that group is now free of talos-alerts) or comment in bug 1054977 :-) Wikis/other external links have been updated to link to Treeherder instead of TBPL some time ago, as have hghooks other tooling. We will also set up redirects initially, from tbpl.m.o to treeherder.m.o. Many thanks, Ed [1] http://tbpl.mozilla.org/ [2] http://treeherder.mozilla.org/ https://wiki.mozilla.org/Auto-tools/Projects/Treeherder ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: From nsIntSize to gfx::IntSize
On Fri, Mar 27, 2015 at 10:50 PM, Jet Villegas jville...@mozilla.com wrote: Probably safe for the integer types, but can we add strong assertions when converting from Thebes and Moz2D floats? Bugs like this one are tough to debug: https://bugzilla.mozilla.org/show_bug.cgi?id=1091709 Thanks! I haven't planned to do an all-at-once conversion of Moz2D floats, especially because we ran into bugs like the one you mentioned. For now I am doing the integer types because they are easy and constantly getting in my way, but I don't think that I'll look into the float ones in the short term. Cheers, Nical ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: From nsIntSize to gfx::IntSize
On Sun, Mar 29, 2015 at 5:01 PM, Mats Palmgren m...@mozilla.com wrote: On 03/27/2015 09:28 PM, Robert O'Callahan wrote: As a followup it's probably worth replacing all of nsIntSize with gfx::IntSize. I think we should stop using these unit-less types in layout and convert the few remaining uses to the unit-bearing types in layout/base/Units.h instead. I'm taking a stab on a couple of those Cool! In case you find them useful, we now also have strongly-typed region classes (bug 1043013). Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|
Bobby Holley writes: On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote: So let's change the project-wide coding rules instead to allow 99 columns as the hard limit, but keep 80 columns as the recommended (soft) limit. I think we should avoid opening up a can of worms on the merits of different styles, and instead focus on the most pragmatic ways to unify Gecko and JS style. Under that framework, Mats' proposal makes a lot of sense. ... in that it tolerates multiple different styles. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|
On 03/28/2015 02:32 AM, Nicolas B. Pierron wrote: On 03/27/2015 11:51 PM, Bobby Holley wrote: On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote: So let's change the project-wide coding rules instead to allow 99 columns as the hard limit, but keep 80 columns as the recommended (soft) limit. I think we should avoid opening up a can of worms on the merits of different styles, and instead focus on the most pragmatic ways to unify Gecko and JS style. Under that framework, Mats' proposal makes a lot of sense. I do not see the advantages of having huge patches to rewrite an entire project just for the benefit of having only one style guide. My reviewer's hat on, having just one style speeds up reviewing and makes the code easier to read. So much nicer to look at patches dealing with xpcom/ or docshell/ now that they have been converted to use the normal coding style. Having the one commit in the blame doesn't really matter. Often one needs to go to the first commit of the code anyway. -Olli What I see with such patches, is pain to rebase patches, pain to change habs of the developers, and security issues as contributors (including employees) do not look for the original authors. From my point of view, the only time where such patches sounds acceptable, is when you are trying to take over a dead project, and as far as I know SpiderMonkey is far from being a dead project. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
