Re: [webkit-dev] PSA: rebaseline tooling

If someone feels like doing extra hacking to improve this, I'm happy to walk you through the code. It'd be awesome if you could expand out that section to show which revision has been run on each bot. https://bugs.webkit.org/show_bug.cgi?id=91163 On Thu, Jul 12, 2012 at 4:18 PM, Peter Kasting wr

Re: [webkit-dev] PSA: rebaseline tooling

On Thu, Jul 12, 2012 at 4:16 PM, Dirk Pranke wrote: > At the top of the garden-o-matic page there is a line like "Latest > revision processed by every bot: 122499 (trunk is at 122524)". I think > that does what you want? Ah, I hadn't noticed that. That sounds promising! PK ___

Re: [webkit-dev] PSA: rebaseline tooling

At the top of the garden-o-matic page there is a line like "Latest revision processed by every bot: 122499 (trunk is at 122524)". I think that does what you want? On Thu, Jul 12, 2012 at 3:56 PM, Peter Kasting wrote: > On Thu, Jul 12, 2012 at 3:17 PM, Ojan Vafai wrote: >> >> https://trac.webkit.

Re: [webkit-dev] PSA: rebaseline tooling

On Thu, Jul 12, 2012 at 3:17 PM, Ojan Vafai wrote: > https://trac.webkit.org/wiki/Rebaseline > > I've recently consolidated the various rebaseline commands and made the > tool work for non-Chromium ports. > > I especially like "webkit-patch rebaseline > path/to/test/i/just/broke.html", which lets

[webkit-dev] PSA: rebaseline tooling

https://trac.webkit.org/wiki/Rebaseline I've recently consolidated the various rebaseline commands and made the tool work for non-Chromium ports. I especially like "webkit-patch rebaseline path/to/test/i/just/broke.html", which lets you easily rebaseline the test for all ports once the bots have

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 12, 2012, at 1:47 PM, Stephen Chenney wrote: > > > On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke wrote: > On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: > > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney > > wrote: > >> > >> As several people have shown, it is quite easy to

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Thu, Jul 12, 2012 at 2:03 PM, Ryosuke Niwa wrote: > On Thu, Jul 12, 2012 at 1:47 PM, Stephen Chenney wrote: > >> On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke wrote: >> >>> On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: >>> > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney < >>> schen

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Thu, Jul 12, 2012 at 1:47 PM, Stephen Chenney wrote: > On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke wrote: > >> On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: >> > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney < >> schen...@chromium.org> >> > wrote: >> >> >> >> As several people ha

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke wrote: > On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: > > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney > > > wrote: > >> > >> As several people have shown, it is quite easy to come up with a formula > >> that shows the cost of maintaini

Re: [webkit-dev] Web APIs and class name collisions

I for one, very much appreciate your cleanup/organizational efforts! On Thu, Jul 12, 2012 at 12:37 PM, Alexis Menard wrote: > So far in the css/ directory we tried to renamed slowly classes so that : > > CSS* prefixed classes are the implementation of CSSOM > "whatevername" is for internal classe

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney > wrote: >> >> As several people have shown, it is quite easy to come up with a formula >> that shows the cost of maintaining comments is much lower than the cost of >> living without. > > >

Re: [webkit-dev] Web APIs and class name collisions

So far in the css/ directory we tried to renamed slowly classes so that : CSS* prefixed classes are the implementation of CSSOM "whatevername" is for internal classes. For example we renamed CSSStyleApplyProperty class to StyleBuilder because it's internal. Hope that helps. On Thu, Jul 12, 2012

Re: [webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

Mark Rowe wrote: > It'd be complicated to do this more widely since the AvailabilityMacros.h > version of the macros are defined even when building for iOS. We'd need to > review all of the uses to ensure that they were handled correctly. Given > that I think it'd be better to just use this as a l

Re: [webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

On 2012-07-12, at 11:29, Mark Mentovai wrote: > We just discovered (via a rollout on bug 91103) that there’s a bug with > __MAC_OS_X_VERSION_MAX_ALLOWED in the version of the 10.5 SDK as present in > Xcode 3.2.6. This may be the last version of the 10.5 SDK ever released (I > haven’t checked

Re: [webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

We just discovered (via a rollout on bug 91103) that there’s a bug with __MAC_OS_X_VERSION_MAX_ALLOWED in the version of the 10.5 SDK as present in Xcode 3.2.6. This may be the last version of the 10.5 SDK ever released (I haven’t checked all of the early Xcode 4 releases). Chromium uses this SDK f

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney wrote: > As several people have shown, it is quite easy to come up with a formula > that shows the cost of maintaining comments is much lower than the cost of > living without. > I object to that conclusion. I've never seen any scientifically soun

Re: [webkit-dev] Web APIs and class name collisions

I'd prefer we keep "Region" for the low-level graphics primitive Region (just like Path), and use something prefixed for the higher-level layout concept. Simon On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: > On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa wrote: > I'd vote for CSSRegion or C

Re: [webkit-dev] Web APIs and class name collisions

I'd prefer we keep "Region" for the low-level graphics primitive Region (just like Path), and use something prefixed for the higher-level layout concept. Simon On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: > On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa wrote: > I'd vote for CSSRegion or C

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Wed, Jul 11, 2012 at 6:07 PM, Alec Flett wrote: > I absolutely do not buy that the "cost" of keeping comments up to date and > the "cost" of out-of-date comments outweighs the benefits - that has NEVER > been my experience and if anything the benefits of comments grow as the > number of people

Re: [webkit-dev] Web APIs and class name collisions

On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa wrote: > I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll > also suggest we rename the existing Region class now that the term "region" > has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? > IntRegion? It see

Re: [webkit-dev] Web APIs and class name collisions

I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll also suggest we rename the existing Region class now that the term "region" has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? - Ryosuke On Jul 12, 2012 10:13 AM, "Eric Seidel" wrote: > I would go with CS

Re: [webkit-dev] Web APIs and class name collisions

I would go with CSSRegion, and stick it in the css/ folder. Much of the CSS folder is our implementation of the CSS Object Model (CSSOM). At some point it might make sense to pull all the classes which implement the CSSOM out of css/ into a new cssom/ similar to dom/, but that's a later discussion

Re: [webkit-dev] Web APIs and class name collisions

>From my knowledge the "CSS" prefix is reserved for the CSS engine classes in >WebKit. Prefixing the Region class with "CSS" could prove confusing. Regards, Andrei. From: Alan Stearns mailto:stea...@adobe.com>> Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth mailto:aba...@webkit.org>>, Andr

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 12, 2012, at 6:50 AM, John Mellor wrote: > > > To take an arbitrary example, lets say that while iterating through a > ListHashSet something causes entries to be deleted. Intuitively it seems this > needn't invalidate the iterator, as long as the entry the iterator is > currently poi

Re: [webkit-dev] Web APIs and class name collisions

The spec itself consistently and deliberately calls them "CSS Regions," so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth mailto:aba...@webkit.org>> To: Andrei Bucur mailto:abu...@adobe.com>> Cc: "webkit-dev@lists.webkit.org" mailto:webkit

Re: [webkit-dev] Web APIs and class name collisions

One common thing we do is prefix "DOM" to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur wrote: > Hello Webkittens! > > While implementing the Region in

[webkit-dev] Web APIs and class name collisions

Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name "Region" is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: 1. Rename the

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Wed, Jul 11, 2012 at 4:53 PM, Ryosuke Niwa wrote: > > On Jul 11, 2012 8:43 AM, "John Mellor" wrote: > > > > On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa wrote: > >> > >> What's the point of adding this comment when the URL contains all the > information? All we need is the URL. If anythin