Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Ojan Vafai]

Filed https://bugs.webkit.org/show_bug.cgi?id=56988.

On Thu, Mar 24, 2011 at 2:53 PM, Maciej Stachowiak  wrote:

>
> It could just be a bug with WebKitTestRunner; it may be failing to focus
> the window.
>
>  - Maciej
>
> On Mar 22, 2011, at 10:45 PM, Ojan Vafai wrote:
>
> Actually, looks like this is a WebKit2-related bug. It just happens that
> this is the only non-pixel test that depends on the window having focus. For
> example, the following fails on my SnowLeopard machine due to lacking the
> focus ring:
> run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p
> --tolerance 0
>
>
> On Wed, Mar 23, 2011 at 4:13 PM, Stephanie Lewis  wrote:
>
>> The machine did have a software update dialog up.  However, i dismissed
>> the dialog and the test is still failing.
>>
>> -- Stephanie
>>
>> On Mar 22, 2011, at 9:29 PM, Ojan Vafai wrote:
>>
>> > fast/css/pseudo-any.html is failing on SnowLeopard Intel Release
>> (WebKit2 Tests), but it's not failing on SnowLeopard Intel Release (Tests).
>> The test depends on the window having focus and the failure it's getting is
>> the one you get if you load the page in a blurred window. So, I assume some
>> dialog or something is up on that bot causing focus issues. What I don't get
>> is that there are other tests that depend on the window having focus that
>> don't seem to be failing on this bot. Does someone with access to the bot
>> mind taking a look?
>> >
>> > Ojan
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Maciej Stachowiak]

It could just be a bug with WebKitTestRunner; it may be failing to focus the 
window.

 - Maciej

On Mar 22, 2011, at 10:45 PM, Ojan Vafai wrote:

> Actually, looks like this is a WebKit2-related bug. It just happens that this 
> is the only non-pixel test that depends on the window having focus. For 
> example, the following fails on my SnowLeopard machine due to lacking the 
> focus ring:
> run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p 
> --tolerance 0
> 
> 
> On Wed, Mar 23, 2011 at 4:13 PM, Stephanie Lewis  wrote:
> The machine did have a software update dialog up.  However, i dismissed the 
> dialog and the test is still failing.
> 
> -- Stephanie
> 
> On Mar 22, 2011, at 9:29 PM, Ojan Vafai wrote:
> 
> > fast/css/pseudo-any.html is failing on SnowLeopard Intel Release (WebKit2 
> > Tests), but it's not failing on SnowLeopard Intel Release (Tests). The test 
> > depends on the window having focus and the failure it's getting is the one 
> > you get if you load the page in a blurred window. So, I assume some dialog 
> > or something is up on that bot causing focus issues. What I don't get is 
> > that there are other tests that depend on the window having focus that 
> > don't seem to be failing on this bot. Does someone with access to the bot 
> > mind taking a look?
> >
> > Ojan
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Maciej Stachowiak]

On Mar 23, 2011, at 3:33 AM, Adam Barth wrote:

 While this is certainly technically feasible, it would add a huge amount 
 of overhead to the process of performing a submission.
>>> 
>>> How often do you submit WebKit to the Apple internal build system?  If
>>> that's sensitive information, I'm just looking for an order of
>>> magnitude (e.g., every revision, every hour, every day, every week).
>>> As a reference, the Chromium project creates one branch per day for
>>> daily builds.
>> 
>> I don't see how the frequency is relevant.
> 
> The relevancy arises from the observation that the overhead is
> proportional to the frequency.  If we only submit WebKit to Apple's
> internal build system once a week, then this approach won't cause too
> much branch proliferation.  If, on the other hand, we're submitting
> every revision, then we're talking about doubling or tripling the
> revision burn rate, which might not be desirable.
> 
>>> In any case, I'm glad we've found a technically feasible solution.
>> 
>> We've had at least one technically feasible solution from day zip: check in 
>> the generated project files.
> 
> From my perspective, approach (2) is more desirable than checking in
> generated project files because approach (2) encapsulates
> Apple-internal build process to Apple folks, more specifically to the
> Apple folks who interact with the Apple-internal build system.
> Checking in generated project files, on the other hand, imposes a
> maintenance burden on all WebKit contributors.

I believe Apple submissions generally happen with greater frequency than the 
rate at which new files are added to the project. Furthermore: When files are 
added to the project, the patch submitted must already run the tool to 
regenerate projects, and is already going to submit a patch, so the maintenance 
burden of the Xcode projects being checked in is low. But having to regenerate 
project files and then check them in on a branch adds extra steps, doing things 
that are not done in the normal course of development, and therefore may have 
bitrotted.

I don't think you are going to get Apple folks enthusiastic about switching to 
a build system that creates significantly more work for us, on the basis that 
it saves everyone else a small amount of work. For that matter, slowing down 
the pace of Apple engineers' development would be a bad thing for the project 
overall, not just for Apple.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Ojan Vafai]

Will do.

On Thu, Mar 24, 2011 at 2:44 AM, Adam Roben  wrote:

> On Mar 23, 2011, at 1:47 AM, Ojan Vafai wrote:
>
> > People who work on WebKit2: should I check in the failing result and/or
> does someone want to look into the focus issue?
>
> Checking in failing results and filing a bug would be great.
>
> -Adam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Ojan Vafai]

On Wed, Mar 23, 2011 at 11:38 PM, Avi Drissman  wrote:

> On Wed, Mar 23, 2011 at 1:45 AM, Ojan Vafai  wrote:
>
>> For example, the following fails on my SnowLeopard machine due to lacking
>> the focus ring:
>> run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p
>> --tolerance 0
>>
>
> This sounds very familiar to me. On Snow Leopard (not on Leopard) there
> exists a bug where the system fails to draw a focus ring when drawing a
> control into a context. See
> ThemeChromiumMac.mm's currentOSHasSetFocusRingStyleInBitmapBug() for more
> details.
>
> I solved it by doing an ugly interposing hack. It wasn't needed for WebKit
> because its controls draw directly into the window. Perhaps it's needed for
> WebKit2?
>
> Email me if you need more info.
>
> (For Apple peeps: rdar://7604051)
>

This isn't a painting bug. It's failing to return a value for
document.querySelector(a:focus). In fact, I wonder if this is really correct
behavior. Perhaps querySelector of :focus should return the document's
focused element even if the window is blurred (analogous to
document.activeElement)?

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Dirk Pranke]

On Wed, Mar 23, 2011 at 1:33 PM, David Levin  wrote:
>
>
> On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth  wrote:
>>
>> $ time git svn rebase
>> [... update my working copy from changes during lunch (four revisions)
>> ...]
>> real    1m10.316s
>> user    0m8.194s
>> sys     0m16.400s
>>
>> $ time ./Tools/Scripts/generate-project-files
>> real    0m4.339s
>> user    0m3.888s
>> sys     0m0.269s
>>
>> which is about 6.1% overhead on an almost trivial update.  We can also
>> reduce this overhead to zero in many cases by detecting that we don't
>> need to re-generate the project files if the inputs to the generation
>> process haven't changed.
>>
> It looks like you are using a slow mechanism for syncing. :)
> TLDR version: 8% overhead for updating 191 revisions. 49% overhead for
> trivial sync (3 revisions) -- in addition to the added complexity (when I
> sync or switch branches in git).
> Here's my results for updating 191 revisions (81605 through 81796).
>
> $ time git fetch && time git svn rebase
>
> fetch, svn rebase times
> real 0m21.071s, 0m36.195s
> user 0m2.271s, 0m3.205s
> sys 0m0.497s, 0m9.428s
> total 57 seconds for a nontrivial update.
> $ time ./Tools/Scripts/generate-project-files
> real 0m4.642s
> user 0m4.243s
> sys 0m0.322s
>
> An 8% overhead on a non-trivial sync.
>
> For a trivial update of 3 revisions:
> real 0m3.490s, 0m6.017s
> user 0m0.932s, 0m2.266s
> sys 0m0.184s, 0m2.824s
> For a total of 9.5 seconds.
>
> The generate project files step remained the same, so this adds a 49%
> overhead for a trivial sync.
> It also adds time (and complications) whenever I switch branches in git.
> dave
> PS For chromium, my experience is
> $ time gclient runhooks --force
> real 0m42.459s
> user 0m29.236s
> sys 0m2.543s
> I don't know enough about chromium build system and gyp to know why it is an
> order of magnitude slower, but this overhead is noticeable and annoying
> there. I love the idea of a one project file system, but I have concerns
> about project file generation on sync becoming the norm in WebKit. fwiw, I
> checked how many gyp files were in chromium and it appeared within 20%.
>

FWIW, with Chromium, the regular 'gclient sync' regenerates the
project files even if it didn't update anything, which is a step that
could probably be eliminated. Also, as far as I know, there's been
little effort to profile and optimize gyp, so I bet we could probably
speed things up a fair amount.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 2:13 PM, Peter Kasting  wrote:
> On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth  wrote:
>> Indeed.  I suspect (2) and (3) are worth doing regardless.
>
> AFAIK, gyp currently always regenerates everything and then compares the new
> versions to the old to see if it actually needs to touch the files on disk.
>  This seems safe but slow.

My plan is to use a make-like system to stat the input files and
compare the last-modified date with the output files.  That approach
seems to work well for other aspects of the build system.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Peter Kasting]

On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth  wrote:

> Indeed.  I suspect (2) and (3) are worth doing regardless.
>

AFAIK, gyp currently always regenerates everything and then compares the new
versions to the old to see if it actually needs to touch the files on disk.
 This seems safe but slow.

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 1:58 PM, Mark Rowe  wrote:
> On 2011-03-23, at 13:49, Adam Barth wrote:
>> On Wed, Mar 23, 2011 at 1:33 PM, David Levin  wrote:
>>> On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth  wrote:
 $ time git svn rebase
 [... update my working copy from changes during lunch (four revisions)
 ...]
 real    1m10.316s
 user    0m8.194s
 sys     0m16.400s

 $ time ./Tools/Scripts/generate-project-files
 real    0m4.339s
 user    0m3.888s
 sys     0m0.269s

 which is about 6.1% overhead on an almost trivial update.  We can also
 reduce this overhead to zero in many cases by detecting that we don't
 need to re-generate the project files if the inputs to the generation
 process haven't changed.
>>>
>>> It looks like you are using a slow mechanism for syncing. :)
>>> TLDR version: 8% overhead for updating 191 revisions. 49% overhead for
>>> trivial sync (3 revisions) -- in addition to the added complexity (when I
>>> sync or switch branches in git).
>>> Here's my results for updating 191 revisions (81605 through 81796).
>>>
>>> $ time git fetch && time git svn rebase
>>>
>>> fetch, svn rebase times
>>> real 0m21.071s, 0m36.195s
>>> user 0m2.271s, 0m3.205s
>>> sys 0m0.497s, 0m9.428s
>>> total 57 seconds for a nontrivial update.
>>> $ time ./Tools/Scripts/generate-project-files
>>> real 0m4.642s
>>> user 0m4.243s
>>> sys 0m0.322s
>>>
>>> An 8% overhead on a non-trivial sync.
>>>
>>> For a trivial update of 3 revisions:
>>> real 0m3.490s, 0m6.017s
>>> user 0m0.932s, 0m2.266s
>>> sys 0m0.184s, 0m2.824s
>>> For a total of 9.5 seconds.
>>>
>>> The generate project files step remained the same, so this adds a 49%
>>> overhead for a trivial sync.
>>> It also adds time (and complications) whenever I switch branches in git.
>>> dave
>>> PS For chromium, my experience is
>>> $ time gclient runhooks --force
>>> real 0m42.459s
>>> user 0m29.236s
>>> sys 0m2.543s
>>> I don't know enough about chromium build system and gyp to know why it is an
>>> order of magnitude slower, but this overhead is noticeable and annoying
>>> there. I love the idea of a one project file system, but I have concerns
>>> about project file generation on sync becoming the norm in WebKit. fwiw, I
>>> checked how many gyp files were in chromium and it appeared within 20%.
>>
>> There seem to be four approaches to improving this situation:
>>
>> 1) Check in the generated project files.  In this approach, only one
>> person pays the cost of generating the project files.
>>
>> 2) Make generate-project-files run faster.  I haven't looked at what's
>> taking 4 seconds, but it seems entirely possible that we can improve
>> the performance.
>>
>> 3) Avoid running generate-project-files when not necessary.  This
>> approach would improve the performance of the trivial sync, for
>> example.
>>
>> 4) Run generate-project-files at time other than sync.  For example,
>> we could run generate-project-files as part of build-webkit, which
>> already takes more more than 4 seconds, leading to a lower percentage
>> overhead.
>
> People build much more frequently than the update, so 4 would have to be done 
> in conjunction with 2 and/or 3.

Indeed.  I suspect (2) and (3) are worth doing regardless.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Mark Rowe]

On 2011-03-23, at 13:49, Adam Barth wrote:

> On Wed, Mar 23, 2011 at 1:33 PM, David Levin  wrote:
>> On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth  wrote:
>>> $ time git svn rebase
>>> [... update my working copy from changes during lunch (four revisions)
>>> ...]
>>> real1m10.316s
>>> user0m8.194s
>>> sys 0m16.400s
>>> 
>>> $ time ./Tools/Scripts/generate-project-files
>>> real0m4.339s
>>> user0m3.888s
>>> sys 0m0.269s
>>> 
>>> which is about 6.1% overhead on an almost trivial update.  We can also
>>> reduce this overhead to zero in many cases by detecting that we don't
>>> need to re-generate the project files if the inputs to the generation
>>> process haven't changed.
>> 
>> It looks like you are using a slow mechanism for syncing. :)
>> TLDR version: 8% overhead for updating 191 revisions. 49% overhead for
>> trivial sync (3 revisions) -- in addition to the added complexity (when I
>> sync or switch branches in git).
>> Here's my results for updating 191 revisions (81605 through 81796).
>> 
>> $ time git fetch && time git svn rebase
>> 
>> fetch, svn rebase times
>> real 0m21.071s, 0m36.195s
>> user 0m2.271s, 0m3.205s
>> sys 0m0.497s, 0m9.428s
>> total 57 seconds for a nontrivial update.
>> $ time ./Tools/Scripts/generate-project-files
>> real 0m4.642s
>> user 0m4.243s
>> sys 0m0.322s
>> 
>> An 8% overhead on a non-trivial sync.
>> 
>> For a trivial update of 3 revisions:
>> real 0m3.490s, 0m6.017s
>> user 0m0.932s, 0m2.266s
>> sys 0m0.184s, 0m2.824s
>> For a total of 9.5 seconds.
>> 
>> The generate project files step remained the same, so this adds a 49%
>> overhead for a trivial sync.
>> It also adds time (and complications) whenever I switch branches in git.
>> dave
>> PS For chromium, my experience is
>> $ time gclient runhooks --force
>> real 0m42.459s
>> user 0m29.236s
>> sys 0m2.543s
>> I don't know enough about chromium build system and gyp to know why it is an
>> order of magnitude slower, but this overhead is noticeable and annoying
>> there. I love the idea of a one project file system, but I have concerns
>> about project file generation on sync becoming the norm in WebKit. fwiw, I
>> checked how many gyp files were in chromium and it appeared within 20%.
> 
> There seem to be four approaches to improving this situation:
> 
> 1) Check in the generated project files.  In this approach, only one
> person pays the cost of generating the project files.
> 
> 2) Make generate-project-files run faster.  I haven't looked at what's
> taking 4 seconds, but it seems entirely possible that we can improve
> the performance.
> 
> 3) Avoid running generate-project-files when not necessary.  This
> approach would improve the performance of the trivial sync, for
> example.
> 
> 4) Run generate-project-files at time other than sync.  For example,
> we could run generate-project-files as part of build-webkit, which
> already takes more more than 4 seconds, leading to a lower percentage
> overhead.

People build much more frequently than the update, so 4 would have to be done 
in conjunction with 2 and/or 3.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 1:33 PM, David Levin  wrote:
> On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth  wrote:
>> $ time git svn rebase
>> [... update my working copy from changes during lunch (four revisions)
>> ...]
>> real    1m10.316s
>> user    0m8.194s
>> sys     0m16.400s
>>
>> $ time ./Tools/Scripts/generate-project-files
>> real    0m4.339s
>> user    0m3.888s
>> sys     0m0.269s
>>
>> which is about 6.1% overhead on an almost trivial update.  We can also
>> reduce this overhead to zero in many cases by detecting that we don't
>> need to re-generate the project files if the inputs to the generation
>> process haven't changed.
>
> It looks like you are using a slow mechanism for syncing. :)
> TLDR version: 8% overhead for updating 191 revisions. 49% overhead for
> trivial sync (3 revisions) -- in addition to the added complexity (when I
> sync or switch branches in git).
> Here's my results for updating 191 revisions (81605 through 81796).
>
> $ time git fetch && time git svn rebase
>
> fetch, svn rebase times
> real 0m21.071s, 0m36.195s
> user 0m2.271s, 0m3.205s
> sys 0m0.497s, 0m9.428s
> total 57 seconds for a nontrivial update.
> $ time ./Tools/Scripts/generate-project-files
> real 0m4.642s
> user 0m4.243s
> sys 0m0.322s
>
> An 8% overhead on a non-trivial sync.
>
> For a trivial update of 3 revisions:
> real 0m3.490s, 0m6.017s
> user 0m0.932s, 0m2.266s
> sys 0m0.184s, 0m2.824s
> For a total of 9.5 seconds.
>
> The generate project files step remained the same, so this adds a 49%
> overhead for a trivial sync.
> It also adds time (and complications) whenever I switch branches in git.
> dave
> PS For chromium, my experience is
> $ time gclient runhooks --force
> real 0m42.459s
> user 0m29.236s
> sys 0m2.543s
> I don't know enough about chromium build system and gyp to know why it is an
> order of magnitude slower, but this overhead is noticeable and annoying
> there. I love the idea of a one project file system, but I have concerns
> about project file generation on sync becoming the norm in WebKit. fwiw, I
> checked how many gyp files were in chromium and it appeared within 20%.

There seem to be four approaches to improving this situation:

1) Check in the generated project files.  In this approach, only one
person pays the cost of generating the project files.

2) Make generate-project-files run faster.  I haven't looked at what's
taking 4 seconds, but it seems entirely possible that we can improve
the performance.

3) Avoid running generate-project-files when not necessary.  This
approach would improve the performance of the trivial sync, for
example.

4) Run generate-project-files at time other than sync.  For example,
we could run generate-project-files as part of build-webkit, which
already takes more more than 4 seconds, leading to a lower percentage
overhead.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[David Levin]

On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth  wrote:
>
> $ time git svn rebase
> [... update my working copy from changes during lunch (four revisions) ...]
> real1m10.316s
> user0m8.194s
> sys 0m16.400s
>
> $ time ./Tools/Scripts/generate-project-files
> real0m4.339s
> user0m3.888s
> sys 0m0.269s
>
> which is about 6.1% overhead on an almost trivial update.  We can also
> reduce this overhead to zero in many cases by detecting that we don't
> need to re-generate the project files if the inputs to the generation
> process haven't changed.
>
> It looks like you are using a slow mechanism for syncing. :)

TLDR version: 8% overhead for updating 191 revisions. *49% overhead for
trivial sync* (3 revisions) -- in addition to the added complexity (when I
sync or switch branches in git).

Here's my results for updating 191 revisions (81605 through 81796).

$ time git fetch && time git svn rebase

fetch, svn rebase times
real 0m21.071s, 0m36.195s
user 0m2.271s, 0m3.205s
sys 0m0.497s, 0m9.428s

total 57 seconds for a nontrivial update.

$ time ./Tools/Scripts/generate-project-files

real 0m4.642s
user 0m4.243s
sys 0m0.322s


An 8% overhead on a non-trivial sync.

For a trivial update of 3 revisions:
real 0m3.490s, 0m6.017s
user 0m0.932s, 0m2.266s
sys 0m0.184s, 0m2.824s

For a total of 9.5 seconds.


The generate project files step remained the same, so this adds a 49%
overhead for a trivial sync.

It also adds time (and complications) whenever I switch branches in git.

dave

PS For chromium, my experience is

$ time gclient runhooks --force
real 0m42.459s
user 0m29.236s
sys 0m2.543s

I don't know enough about chromium build system and gyp to know why it is an
order of magnitude slower, but this overhead is noticeable and annoying
there. I love the idea of a one project file system, but I have concerns
about project file generation on sync becoming the norm in WebKit. fwiw, I
checked how many gyp files were in chromium and it appeared within 20%.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Mark Rowe]

On 2011-03-23, at 12:29, Adam Barth wrote:

> On Wed, Mar 23, 2011 at 12:26 PM, Mark Rowe  wrote:
>> On 2011-03-23, at 12:17, Adam Barth wrote:
>>> On Wed, Mar 23, 2011 at 11:38 AM, Mark Rowe  wrote:
 On 2011-03-23, at 03:33, Adam Barth wrote:
> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
>> On 2011-03-22, at 23:50, Adam Barth wrote:
>>> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>>> In any case, I'm glad we've found a technically feasible solution.
>> 
>> We've had at least one technically feasible solution from day zip: check 
>> in the generated project files.
> 
> From my perspective, approach (2) is more desirable than checking in
> generated project files because approach (2) encapsulates
> Apple-internal build process to Apple folks, more specifically to the
> Apple folks who interact with the Apple-internal build system.
> Checking in generated project files, on the other hand, imposes a
> maintenance burden on all WebKit contributors.
 
 The maintenance burden you mention is minuscule in comparison to the 
 existing requirement of updating umpteen different build systems, 
 including the impossible-to-hand-edit Xcode project files.  This is 
 particularly true when we're still going to be updating umpteen minus one 
 build systems for the foreseeable future.  If the Xcode project files were 
 the only remaining project files then I'd certainly take this argument 
 more seriously.
>>> 
>>> Yes, unifying all our various build systems is a long journey and this
>>> is just the first step.
>> 
>> I'm glad that we agree that checking in the generated project files would 
>> create only a minuscule burden.
> 
> I'm afraid you've misunderstood me.  I do not agree with that statement.

My apologies.  Typically leading out with "yes" indicates that you agree with a 
given statement.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 12:26 PM, Mark Rowe  wrote:
> On 2011-03-23, at 12:17, Adam Barth wrote:
>> On Wed, Mar 23, 2011 at 11:38 AM, Mark Rowe  wrote:
>>> On 2011-03-23, at 03:33, Adam Barth wrote:
 On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
> On 2011-03-22, at 23:50, Adam Barth wrote:
>> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>> In any case, I'm glad we've found a technically feasible solution.
>
> We've had at least one technically feasible solution from day zip: check 
> in the generated project files.

 From my perspective, approach (2) is more desirable than checking in
 generated project files because approach (2) encapsulates
 Apple-internal build process to Apple folks, more specifically to the
 Apple folks who interact with the Apple-internal build system.
 Checking in generated project files, on the other hand, imposes a
 maintenance burden on all WebKit contributors.
>>>
>>> The maintenance burden you mention is minuscule in comparison to the 
>>> existing requirement of updating umpteen different build systems, including 
>>> the impossible-to-hand-edit Xcode project files.  This is particularly true 
>>> when we're still going to be updating umpteen minus one build systems for 
>>> the foreseeable future.  If the Xcode project files were the only remaining 
>>> project files then I'd certainly take this argument more seriously.
>>
>> Yes, unifying all our various build systems is a long journey and this
>> is just the first step.
>
> I'm glad that we agree that checking in the generated project files would 
> create only a minuscule burden.

I'm afraid you've misunderstood me.  I do not agree with that statement.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Mark Rowe]

On 2011-03-23, at 12:17, Adam Barth wrote:

> On Wed, Mar 23, 2011 at 11:38 AM, Mark Rowe  wrote:
>> On 2011-03-23, at 03:33, Adam Barth wrote:
>>> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
 On 2011-03-22, at 23:50, Adam Barth wrote:
> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>> Product names for targets are redundantly declared in the Xcode project 
>> when they're already defined in the .xcconfig files.
> 
> My plan for this issue is to remove the product names from the
> xcconfig files once they're not needed by the generated xcodeproj
> files.
 
 That seems backwards.  JavaScriptCore.xcconfig defines how to create 
 JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) 
 is an important part of that, much like the install path, Info.plist file, 
 etc.  I don't see how we benefit from that information being spread around.
>>> 
>>> The information about how to create JavaScriptCore.framework is
>>> already spread around to a certain extent.  For example,
>>> JavaScriptCore.xcconfig does not contain the list of files that need
>>> to be built or information about the dependencies.  I'm having a hard
>>> time seeing what the practical difference is between specifying the
>>> product name in the xcodeproj file or the xcconfig file.
>> 
>> What's the argument for changing where it is specified?  Is it simply 
>> because gyp doesn't know better?
> 
> Yes.  Also, the names of the other targets are stored in the xcodeproj
> files.  I don't see this as a blocking issue, do you?
> 
>>> One area that I could use some help from one or more Apple folks is
>>> making sure that this build system integrates properly with Apple's
>>> internal build system.  Based on my (incomplete!) understanding of
>>> Apple's internal build system, there are at least two options:
>>> 
>>> 1) Apple's internal build system consumes Source in its entirety and
>>> builds a master WebKit.xcodeproj (or a Makefile), which abstracts
>>> further details about the build, such as how subsequent xcodeproj are
>>> created or how many libraries WebKit is factored into (e.g., letting
>>> us extract WTF from JavaScriptCore).
>> 
>> Making that particular change is completely unrelated to GYP.
> 
> My understanding is that it would solve the Apple internal build
> system integration issue because the Apple internal build system would
> transfer control to the master WebKit.xcodeproj, which could then
> invoke GYP to generate the remaining xcodeproj files.
 
 I'm not particularly keen on a solution that involves manually invoking 
 xcodebuild to build projects.  It becomes very complicated to ensure that 
 the correct settings, including any overridden settings, make it down to 
 the nested invocations of xcodebuild.
>>> 
>>> I'm not sure I've correctly communicated how I envision this approach
>>> working.  If approach (2) doesn't work out for whatever reason, I can
>>> build a mockup of how this would work, which will be more concrete.
>> 
>> You'll need to provide more detail then because I cannot see how this would 
>> work in a manner that doesn't cause the problems I have noted.
> 
> As I wrote above, we can discuss this more at a later date, if necessary.
> 
>>> 2) For each submission to Apple's internal build system, we create a
>>> branch, generate xcodeproj files, and check them into the branch.
>>> Apple's internal build system can then "svn export" the branch and see
>>> xcodeproj files, as today.
>> 
>> While this is certainly technically feasible, it would add a huge amount 
>> of overhead to the process of performing a submission.
> 
> How often do you submit WebKit to the Apple internal build system?  If
> that's sensitive information, I'm just looking for an order of
> magnitude (e.g., every revision, every hour, every day, every week).
> As a reference, the Chromium project creates one branch per day for
> daily builds.
 
 I don't see how the frequency is relevant.
>>> 
>>> The relevancy arises from the observation that the overhead is
>>> proportional to the frequency.  If we only submit WebKit to Apple's
>>> internal build system once a week, then this approach won't cause too
>>> much branch proliferation.  If, on the other hand, we're submitting
>>> every revision, then we're talking about doubling or tripling the
>>> revision burn rate, which might not be desirable.
>> 
>> The rate at which we use SVN revisions or the number of branches isn't of 
>> particular concern to me.  The simple fact is that your proposal turns a 
>> single, trivial operation (create a tag) in to a sequence of more 
>> complicated operations (create a branch, check it out, run a script to 
>> generate a bunch of files, test that it builds, commit the new files, create 
>> a tag).  What used to be a single command-line 

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 11:38 AM, Mark Rowe  wrote:
> On 2011-03-23, at 03:33, Adam Barth wrote:
>> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
>>> On 2011-03-22, at 23:50, Adam Barth wrote:
 On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
> Product names for targets are redundantly declared in the Xcode project 
> when they're already defined in the .xcconfig files.

 My plan for this issue is to remove the product names from the
 xcconfig files once they're not needed by the generated xcodeproj
 files.
>>>
>>> That seems backwards.  JavaScriptCore.xcconfig defines how to create 
>>> JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) 
>>> is an important part of that, much like the install path, Info.plist file, 
>>> etc.  I don't see how we benefit from that information being spread around.
>>
>> The information about how to create JavaScriptCore.framework is
>> already spread around to a certain extent.  For example,
>> JavaScriptCore.xcconfig does not contain the list of files that need
>> to be built or information about the dependencies.  I'm having a hard
>> time seeing what the practical difference is between specifying the
>> product name in the xcodeproj file or the xcconfig file.
>
> What's the argument for changing where it is specified?  Is it simply because 
> gyp doesn't know better?

Yes.  Also, the names of the other targets are stored in the xcodeproj
files.  I don't see this as a blocking issue, do you?

>> One area that I could use some help from one or more Apple folks is
>> making sure that this build system integrates properly with Apple's
>> internal build system.  Based on my (incomplete!) understanding of
>> Apple's internal build system, there are at least two options:
>>
>> 1) Apple's internal build system consumes Source in its entirety and
>> builds a master WebKit.xcodeproj (or a Makefile), which abstracts
>> further details about the build, such as how subsequent xcodeproj are
>> created or how many libraries WebKit is factored into (e.g., letting
>> us extract WTF from JavaScriptCore).
>
> Making that particular change is completely unrelated to GYP.

 My understanding is that it would solve the Apple internal build
 system integration issue because the Apple internal build system would
 transfer control to the master WebKit.xcodeproj, which could then
 invoke GYP to generate the remaining xcodeproj files.
>>>
>>> I'm not particularly keen on a solution that involves manually invoking 
>>> xcodebuild to build projects.  It becomes very complicated to ensure that 
>>> the correct settings, including any overridden settings, make it down to 
>>> the nested invocations of xcodebuild.
>>
>> I'm not sure I've correctly communicated how I envision this approach
>> working.  If approach (2) doesn't work out for whatever reason, I can
>> build a mockup of how this would work, which will be more concrete.
>
> You'll need to provide more detail then because I cannot see how this would 
> work in a manner that doesn't cause the problems I have noted.

As I wrote above, we can discuss this more at a later date, if necessary.

>> 2) For each submission to Apple's internal build system, we create a
>> branch, generate xcodeproj files, and check them into the branch.
>> Apple's internal build system can then "svn export" the branch and see
>> xcodeproj files, as today.
>
> While this is certainly technically feasible, it would add a huge amount 
> of overhead to the process of performing a submission.

 How often do you submit WebKit to the Apple internal build system?  If
 that's sensitive information, I'm just looking for an order of
 magnitude (e.g., every revision, every hour, every day, every week).
 As a reference, the Chromium project creates one branch per day for
 daily builds.
>>>
>>> I don't see how the frequency is relevant.
>>
>> The relevancy arises from the observation that the overhead is
>> proportional to the frequency.  If we only submit WebKit to Apple's
>> internal build system once a week, then this approach won't cause too
>> much branch proliferation.  If, on the other hand, we're submitting
>> every revision, then we're talking about doubling or tripling the
>> revision burn rate, which might not be desirable.
>
> The rate at which we use SVN revisions or the number of branches isn't of 
> particular concern to me.  The simple fact is that your proposal turns a 
> single, trivial operation (create a tag) in to a sequence of more complicated 
> operations (create a branch, check it out, run a script to generate a bunch 
> of files, test that it builds, commit the new files, create a tag).  What 
> used to be a single command-line operation that took a second to run is now a 
> series of operations that takes 5+ minutes to complete.

5 minutes doesn't sound like much of a burden given th

Re: [webkit-dev] Build system update

[David Levin]

On Wed, Mar 23, 2011 at 3:33 AM, Adam Barth  wrote:

> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
> >> In any case, I'm glad we've found a technically feasible solution.
> >
> > We've had at least one technically feasible solution from day zip: check
> in the generated project files.
>
> From my perspective, approach (2) is more desirable than checking in
> generated project files because approach (2) encapsulates
> Apple-internal build process to Apple folks, more specifically to the
> Apple folks who interact with the Apple-internal build system.
> Checking in generated project files, on the other hand, imposes a
> maintenance burden on all WebKit contributors.
>

Living with the chromium system of generating the files on the fly, I always
find it bothersome when the slowest step (by far) of my sync is generating
these project files.

So I personally prefer checking in the generated files (and letting this
delay be on the person making the change -- rather than distributing this
generation step to everyone). (As Mark mentions) this seems to also have the
benefit of disrupting people's workflow the least.

dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Mark Rowe]

On 2011-03-23, at 03:33, Adam Barth wrote:

> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
>> On 2011-03-22, at 23:50, Adam Barth wrote:
>>> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
> 
 Product names for targets are redundantly declared in the Xcode project 
 when they're already defined in the .xcconfig files.
>>> 
>>> My plan for this issue is to remove the product names from the
>>> xcconfig files once they're not needed by the generated xcodeproj
>>> files.
>> 
>> That seems backwards.  JavaScriptCore.xcconfig defines how to create 
>> JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) is 
>> an important part of that, much like the install path, Info.plist file, etc. 
>>  I don't see how we benefit from that information being spread around.
> 
> The information about how to create JavaScriptCore.framework is
> already spread around to a certain extent.  For example,
> JavaScriptCore.xcconfig does not contain the list of files that need
> to be built or information about the dependencies.  I'm having a hard
> time seeing what the practical difference is between specifying the
> product name in the xcodeproj file or the xcconfig file.

What's the argument for changing where it is specified?  Is it simply because 
gyp doesn't know better?

> One area that I could use some help from one or more Apple folks is
> making sure that this build system integrates properly with Apple's
> internal build system.  Based on my (incomplete!) understanding of
> Apple's internal build system, there are at least two options:
> 
> 1) Apple's internal build system consumes Source in its entirety and
> builds a master WebKit.xcodeproj (or a Makefile), which abstracts
> further details about the build, such as how subsequent xcodeproj are
> created or how many libraries WebKit is factored into (e.g., letting
> us extract WTF from JavaScriptCore).
 
 Making that particular change is completely unrelated to GYP.
>>> 
>>> My understanding is that it would solve the Apple internal build
>>> system integration issue because the Apple internal build system would
>>> transfer control to the master WebKit.xcodeproj, which could then
>>> invoke GYP to generate the remaining xcodeproj files.
>> 
>> I'm not particularly keen on a solution that involves manually invoking 
>> xcodebuild to build projects.  It becomes very complicated to ensure that 
>> the correct settings, including any overridden settings, make it down to the 
>> nested invocations of xcodebuild.
> 
> I'm not sure I've correctly communicated how I envision this approach
> working.  If approach (2) doesn't work out for whatever reason, I can
> build a mockup of how this would work, which will be more concrete.

You'll need to provide more detail then because I cannot see how this would 
work in a manner that doesn't cause the problems I have noted.

> 2) For each submission to Apple's internal build system, we create a
> branch, generate xcodeproj files, and check them into the branch.
> Apple's internal build system can then "svn export" the branch and see
> xcodeproj files, as today.
 
 While this is certainly technically feasible, it would add a huge amount 
 of overhead to the process of performing a submission.
>>> 
>>> How often do you submit WebKit to the Apple internal build system?  If
>>> that's sensitive information, I'm just looking for an order of
>>> magnitude (e.g., every revision, every hour, every day, every week).
>>> As a reference, the Chromium project creates one branch per day for
>>> daily builds.
>> 
>> I don't see how the frequency is relevant.
> 
> The relevancy arises from the observation that the overhead is
> proportional to the frequency.  If we only submit WebKit to Apple's
> internal build system once a week, then this approach won't cause too
> much branch proliferation.  If, on the other hand, we're submitting
> every revision, then we're talking about doubling or tripling the
> revision burn rate, which might not be desirable.

The rate at which we use SVN revisions or the number of branches isn't of 
particular concern to me.  The simple fact is that your proposal turns a 
single, trivial operation (create a tag) in to a sequence of more complicated 
operations (create a branch, check it out, run a script to generate a bunch of 
files, test that it builds, commit the new files, create a tag).  What used to 
be a single command-line operation that took a second to run is now a series of 
operations that takes 5+ minutes to complete.

>>> In any case, I'm glad we've found a technically feasible solution.
>> 
>> We've had at least one technically feasible solution from day zip: check in 
>> the generated project files.
> 
> From my perspective, approach (2) is more desirable than checking in
> generated project files because approach (2) encapsulates
> Apple-internal build process to Apple folks, more specifically 

Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Adam Roben]

On Mar 23, 2011, at 1:47 AM, Ojan Vafai wrote:

> People who work on WebKit2: should I check in the failing result and/or does 
> someone want to look into the focus issue?

Checking in failing results and filing a bug would be great.

-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)

[Avi Drissman]

On Wed, Mar 23, 2011 at 1:45 AM, Ojan Vafai  wrote:

> For example, the following fails on my SnowLeopard machine due to lacking
> the focus ring:
> run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p
> --tolerance 0
>

This sounds very familiar to me. On Snow Leopard (not on Leopard) there
exists a bug where the system fails to draw a focus ring when drawing a
control into a context. See
ThemeChromiumMac.mm's currentOSHasSetFocusRingStyleInBitmapBug() for more
details.

I solved it by doing an ugly interposing hack. It wasn't needed for WebKit
because its controls draw directly into the window. Perhaps it's needed for
WebKit2?

Email me if you need more info.

(For Apple peeps: rdar://7604051)

Avi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Adam Barth]

On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe  wrote:
> On 2011-03-22, at 23:50, Adam Barth wrote:
>> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>>> On 2011-03-22, at 19:16, Adam Barth wrote:
 WebKit-folk,

 With a bunch of help from Dimitri and Eric, we now have a functioning
 GYP-based build for the Apple Mac port.  There are still a couple bugs
 we need to fix before this build system is ready for production
 (they're filed as blocking Bug 55018, if you're curious).  If you'd
 like to try out the GYP-based build, you can invoke it (on a Mac) as
 follows:

 ./Tools/Scripts/build-webkit --gyp
>>>
>>> Is this expected to work?  Running the command quoted above results in a 
>>> build failure in JavaScriptCore for me (jsc is unable to find UString.h).
>>
>> I'm not sure how to test with a case-sensitive file system on Mac.  (I
>> didn't even know that was possible.)  How can I test that case?
>
> Short of formatting a volume as case-sensitive HFS+, you can use Disk Utility 
> to create a read/write disk image containing case-sensitive HFS+ and then 
> perform a build on that disk image.

Thanks.  This issue should be fixed as of
.  Note: I wasn't able to
completely test the build on a case-sensitive file system because I
made my disk image too small.  I'll verify that the issue is fixed
tomorrow.

>>> Product names for targets are redundantly declared in the Xcode project 
>>> when they're already defined in the .xcconfig files.
>>
>> My plan for this issue is to remove the product names from the
>> xcconfig files once they're not needed by the generated xcodeproj
>> files.
>
> That seems backwards.  JavaScriptCore.xcconfig defines how to create 
> JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) is 
> an important part of that, much like the install path, Info.plist file, etc.  
> I don't see how we benefit from that information being spread around.

The information about how to create JavaScriptCore.framework is
already spread around to a certain extent.  For example,
JavaScriptCore.xcconfig does not contain the list of files that need
to be built or information about the dependencies.  I'm having a hard
time seeing what the practical difference is between specifying the
product name in the xcodeproj file or the xcconfig file.

 One area that I could use some help from one or more Apple folks is
 making sure that this build system integrates properly with Apple's
 internal build system.  Based on my (incomplete!) understanding of
 Apple's internal build system, there are at least two options:

 1) Apple's internal build system consumes Source in its entirety and
 builds a master WebKit.xcodeproj (or a Makefile), which abstracts
 further details about the build, such as how subsequent xcodeproj are
 created or how many libraries WebKit is factored into (e.g., letting
 us extract WTF from JavaScriptCore).
>>>
>>> Making that particular change is completely unrelated to GYP.
>>
>> My understanding is that it would solve the Apple internal build
>> system integration issue because the Apple internal build system would
>> transfer control to the master WebKit.xcodeproj, which could then
>> invoke GYP to generate the remaining xcodeproj files.
>
> I'm not particularly keen on a solution that involves manually invoking 
> xcodebuild to build projects.  It becomes very complicated to ensure that the 
> correct settings, including any overridden settings, make it down to the 
> nested invocations of xcodebuild.

I'm not sure I've correctly communicated how I envision this approach
working.  If approach (2) doesn't work out for whatever reason, I can
build a mockup of how this would work, which will be more concrete.

 2) For each submission to Apple's internal build system, we create a
 branch, generate xcodeproj files, and check them into the branch.
 Apple's internal build system can then "svn export" the branch and see
 xcodeproj files, as today.
>>>
>>> While this is certainly technically feasible, it would add a huge amount of 
>>> overhead to the process of performing a submission.
>>
>> How often do you submit WebKit to the Apple internal build system?  If
>> that's sensitive information, I'm just looking for an order of
>> magnitude (e.g., every revision, every hour, every day, every week).
>> As a reference, the Chromium project creates one branch per day for
>> daily builds.
>
> I don't see how the frequency is relevant.

The relevancy arises from the observation that the overhead is
proportional to the frequency.  If we only submit WebKit to Apple's
internal build system once a week, then this approach won't cause too
much branch proliferation.  If, on the other hand, we're submitting
every revision, then we're talking about doubling or tripling the
revision burn rate, which might not be desirable.

>> In any case, I'm glad we've found a t

[webkit-dev] :any pseudoclass

[Ojan Vafai]

As of r81742, WebKit supports the :-webkit-any pseudoclass. Our current
implementation matches Mozilla's AFAIK. There's a couple changes I'd like to
make though.

1. Allow a group of selectors as the argument to :-webkit-any instead of a
sequence of simple selectors. See
http://lists.w3.org/Archives/Public/www-style/2011Mar/0486.html. I don't see
any objections to this, so I plan to just move forward with this unless
someone here objects.

2. Resolve the specificity question below. The ideal behavior would be
transparent to authors, so the specificity would depend on which argument of
the any pseudoclass matched. In order to make this work, I think we'd need
to add an out-param to checkSelector and then store a wrapper around
RuleData in CSSStyleSelector::m_matchedRules. Then we could get the right
data to sort the rules appropriately when needed.

That seems like a lot of complexity and it likely has memory implications.
Is there a better way? Should we just punt and keep the current specificity
(option 1 below)? Or should we pick the highest (option 5 below)?

My intuition is to keep it as is.

Ojan

-- Forwarded message --
From: Tab Atkins Jr. 
Date: Fri, Feb 26, 2010 at 10:25 AM
Subject: Re: Specificity of :any (was Re: [css3-selectors] Grouping)
To: "L. David Baron" 
Cc: www-st...@w3.org

On Thu, Feb 25, 2010 at 5:16 PM, L. David Baron  wrote:
> On Thursday 2010-02-25 17:58 -0500, Boris Zbarsky wrote:
>> At least in Gecko's case, what you wrote above would indeed be more
>> or less just syntax sugar.  But this:
>>
>>   :any(#authors, #publications) div
>>
>> would probably be faster to match than:
>>
>>   #authors div, #publications div
>>
>> In fact, we're looking into implementing this right now (as
>> :-moz-any()) to more efficiently deal with the numerous rules of
>> this form that appear in our UA stylesheet.
>
> So the one thing that I just realized I'm not sure how to implement
> is specificity.  (What I actually have implemented is treating :any
> as a pseudo-class and ignoring its arguments, which probably isn't
> what we want.)
>
> So given a selector like:
>
> p:any(:hover,#mypara)
>
> Should this selector have:
>
>  specificity 11 (p + :any)
>  specificity 111 (p + :hover + #mypara)
>  specificity 121 (p + :any + :hover + #mypara)
>  specificity 11 (p + :hover) or 101 (p + #mypara) depending on how it
>   matches (with 101 if it matches both ways)?
>  one of 11 or 101, not depending on how it matches (just always the
>   lowest or highest)
>
> I'd note that the next-to-last seems like it might be best, but I
> can't think of an obvious way to implement it in our code.

Yes, ideally the :any() is transparent wrt specificity, which is your
second-to-last option.  I'm not opposed to the first or last(with
highest) options, though, if either of them end up being sufficiently
simpler.

~TJ
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system update

[Mark Rowe]

On 2011-03-22, at 23:50, Adam Barth wrote:

> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>> On 2011-03-22, at 19:16, Adam Barth wrote:
>>> WebKit-folk,
>>> 
>>> With a bunch of help from Dimitri and Eric, we now have a functioning
>>> GYP-based build for the Apple Mac port.  There are still a couple bugs
>>> we need to fix before this build system is ready for production
>>> (they're filed as blocking Bug 55018, if you're curious).  If you'd
>>> like to try out the GYP-based build, you can invoke it (on a Mac) as
>>> follows:
>>> 
>>> ./Tools/Scripts/build-webkit --gyp
>> 
>> Is this expected to work?  Running the command quoted above results in a 
>> build failure in JavaScriptCore for me (jsc is unable to find UString.h).
> 
> I'm not sure how to test with a case-sensitive file system on Mac.  (I
> didn't even know that was possible.)  How can I test that case?

Short of formatting a volume as case-sensitive HFS+, you can use Disk Utility 
to create a read/write disk image containing case-sensitive HFS+ and then 
perform a build on that disk image.

>>> If you just want to look at the generated project files, you can
>>> generate them using this command:
>>> 
>>> ./Tools/Scripts/generate-project-files
>>> 
>>> That script will create
>>> Source/JavaScriptCore/gyp/JavaScriptCore.xcodeproj and
>>> Source/WebCore/gyp/WebCore.xcodeproj (as well as a JavaScriptGlue
>>> project file, which you should feel free to ignore).
>> 
>> Is it useful for me to file bugs about these generated projects?
> 
> Definitely.  I appreciate your feedback.  If you can file them as
> blocking Bug 55018, that will ensure that they don't get lost.  I can
> check to make sure all the webkit.org requirements are satisfied, but
> I'm unable to verify that all the Apple-internal requirements are
> satisfied because they are opaque to me.

None of the issues I mentioned about the project file are related to any 
specific constraints that our build system places on us.  My primary concern 
here is ensuring that the Mac build system is understandable, repeatable, and 
easy to debug.  While some of the issues I've raised may seem picky, they're 
all things that contribute to that goal.


>> A few issues I noticed while skimming the Xcode project files…
>> The source is all hidden two levels deep in the hierarchy (inside a group 
>> named ".."?).
>> There's an oddly-named BUILT_PRODUCTS_DIR group.
>> There's a mysterious ForwardingHeaders group.
>> The .xcconfig files are in the Source group.
>> The script build phases are unnecessarily verbose ('Action "…"' or 
>> 'Postbuild "…"' where only '…' is meaningful).
> 
> Yeah, these things are not very aesthetic.  They've been on my list to
> fix, but I haven't considered them to be a blocking issue to date.  Do
> you consider these blocking issues?  I'm happy to fix them, but I'd
> like to prioritize blocking issues.

These are the types of issues that make life confusing for anyone that wants to 
use the Xcode project for editing, debugging, or to simply get a feel for the 
project.  They certainly have no impact on the actual building of the code.

>> Product names for targets are redundantly declared in the Xcode project when 
>> they're already defined in the .xcconfig files.
> 
> My plan for this issue is to remove the product names from the
> xcconfig files once they're not needed by the generated xcodeproj
> files.

That seems backwards.  JavaScriptCore.xcconfig defines how to create 
JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) is an 
important part of that, much like the install path, Info.plist file, etc.  I 
don't see how we benefit from that information being spread around.

>> There are mysterious extra settings in the Xcode project that serve no 
>> apparent purpose (EXECUTABLE_PREFIX, INTERMEDIATE_DIR, 
>> SHARED_INTERMEDIATE_DIR, WRAPPER_PREFIX, ALWAYS_SEARCH_USER_PATHS?)
> 
> Are these harmful?  We could figure out how to stop GYP from
> generating them, but I'm not aware of any problem they cause.

They're only harmful in the sense that they make it harder to understand the 
configuration of the Xcode project, which makes it harder to track down 
build-related issues.

>> The default configuration is Debug rather than Production.
> 
> Thanks.  I thought I had fixed that, but I'll investigate this issue
> some more.  I understand that this is a hard requirement.
> 
>> Updating Info.plist is done via a separate aggregate target rather than 
>> simply being a script phase.
> 
> Does that cause a problem?  The two seem equivalent.

There are plenty of roundabout ways in which one can achieve the same result.  
That doesn't make them equally good.

>>> The main advantage of this build system over the existing Apple Mac
>>> build system is that the list of files is shared between this build
>>> system and the Chromium build system.  That means one fewer location
>>> to update when adding, removing, or renaming a file.  Over time, we
>>> should b

Re: [webkit-dev] Build system update

[Adam Barth]

On Tue, Mar 22, 2011 at 11:50 PM, Adam Barth  wrote:
> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe  wrote:
>> The default configuration is Debug rather than Production.
>
> Thanks.  I thought I had fixed that, but I'll investigate this issue
> some more.  I understand that this is a hard requirement.

Hopefully this issue should be fixed as of
.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev