Re: [webkit-dev] WebKit project in Coverity

2020-01-09 Thread David Kilzer
Hi,

Back on Sept 18, 2019, Semmle announced 
 that they would start 
scanning of projects on GitHub.com using their static analysis tool.

As of July/August 2019, the WebKit mirror on GitHub includes analysis results* 
on their website, likely for the GTK port being compiled on Ubuntu:



* However, the results are only for part of JavaScriptCore since (a) the 
build/analysis times out on DFGSpeculativeJIT.cpp, and (b) they’re using 
`Tools/Scripts/build-webkit --jsc-only` to do the build:



If someone from Igalia (or another GTK port maintainer) can get the attention 
of the LGTM staff, maybe they can get LGTM to update their WebKit build to fix 
the DFGSpeculativeJIT.cpp timeout and to build all of WebKit (not just 
JavaScriptCore) so we get analysis of ANGLE, libwebrtc, WebCore and WebKit.

Dave


On Jun 2, 2017, at 5:12 AM, Carlos Alberto Lopez Perez  
wrote:

> Hi,
> 
> Coverity is an static analysis tool that allows to find bugs and
> vulnerabilities on the source code via static analysis.
> 
> For open source projects, they offer free usage of their platform.
> 
> The WebKit project is already registered there since a while. [1]
> To read the reports in detail or run new scans you have to be
> member of the WebKit project in Coverity.
> 
> 
> I happen to be one of the admins there, and I will happily grant you
> access to this platform if you are a WebKit committer (listed in
> contributors.json).
> 
> So if you are interested in this, just send me an email requesting
> access.
> 
> Regards
> ---
> 
> [1] https://scan.coverity.com/projects/webkit

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


Re: [webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs

2019-09-19 Thread David Kilzer
I actually “missed” output from the stylebot insofar as I was expecting the 
errors to be posted, and then I was going to reply to that automated message.

I think it’s too easy to ignore style errors if you have to click to load 
another website, though, so I filed this bug with some thoughts:

Bug 201993: EWS style bot should show error output via semi-modal dialog rather 
than requiring to click through
>

Maybe we could do something similar for layout test failures (a semi-modal 
dialog that lists the errors, and links directly to the results rather than 
having to click (twice) through the buildbot landing page?

Dave


On Sep 19, 2019, at 9:45 AM, Aakash Jain  wrote:

> On Jun 16, 2019, at 2:14 PM, Darin Adler  > wrote:
> 
>> On Jun 15, 2019, at 9:13 PM, Aakash Jain > > wrote:
>> 
>>> 1) Do not upload archive (for layout-test-results) on bugzilla, instead 
>>> upload it to another server, unzip it and post a link to the results.html.
>>> Pros:
>>> a) Engineers won't have to download the attachment, unzip it, look for 
>>> failures, and then delete it from their disk. They can simply click the url 
>>> to view the results. 
>>> b) This approach will also reduce 2 comments per failure to 1 comment. 
>>> Currently there are two comments per failure, one for failure details, 
>>> second for bugzilla attachment.
>> 
>> Great improvement to do this.
> 
> We have implemented this in the new EWS. Layout test results are no longer 
> added to EWS as attachments. Instead they are available to view in browser or 
> download from the Buildbot build page.
> 
>> The most confusing thing about build bot comments is all the “creation of 
>> attachments” extra text with things like “attachment number” and “patch".
>> 
>> However, it’s really nice that I can download a directory full of test 
>> results easily. I’d like to see the EWS website still have that feature.
>> 
>>> 4) When a patch becomes 'obsolete', tag the corresponding EWS comments as 
>>> 'obsolete', so that they will be hidden.
>> 
>> Incredibly valuable.
>> 
>>> 5) Do not comment on bugzilla bug at all
>> 
>> I think this makes sense. I don’t see a reason that test results need to be 
>> comments. I think the “red bubble” in EWS already calls someone’s attention 
>> to failures.
>> 
>> If we want to augment it, we should think of what we are aiming at. I do 
>> find it useful to see which tests are failing, and when I click on the red 
>> bubble I don’t see that information. I have to click once to see the “log of 
>> activities” then click on “results”, then see a confusing giant file with 
>> lots of other information. At the bottom of that file the one thing I want 
>> to know.
>> 
>> A better hierarchy is to put that “what new tests are failing” summary right 
>> t the top and let the logs be fallbacks, not the primary place to see the 
>> features.
>> 
>>> instead send email to the author of the patch.
>> 
>> Why? I don’t think this should send any emails at all, unless the person 
>> requested it.
>> 
>>> Pros: less noisy, also this will allow to include more detailed information 
>>> about the failure in email.
>> 
>> I think the more detailed information should be on the webpage, not in an 
>> email.
>> 
>>> Cons: reviewers would have to click status-bubbles to see the failures, 
>>> failure information is not immediately present in the comments.
>> 
>> I think we should start with this approach, eliminating the comments 
>> entirely.
> 
> Following this suggestion, we eliminated the comments entirely in the new 
> EWS. However, some people mentioned that since there are no comments, they do 
> not get email notifications on failure, e.g.: https://webkit.org/b/200399 
> . Maybe we should have some kind of comments by 
> EWS. Few ideas:
> 
> 1) Comment on first failure for a patch, e.g.: "Some failures were noticed by 
> EWS, please check the status bubbles".
> 
> 2) Comment about success on all queues, e.g.: "Patch passed all EWS queues".
> 
> 
> What do you guys think?
> 
>> 
>> — Darin
> 

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


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-14 Thread David Kilzer
Filed:  

Dave


On Dec 14, 2018, at 2:18 PM, Adrian Perez de Castro  wrote:

> Hello,
> 
> On Fri, 14 Dec 2018 14:02:39 -0800, Saam Barati  wrote:
> 
>>> On Dec 14, 2018, at 1:59 PM, Chris Dumez  wrote:
>>> 
 On Dec 14, 2018, at 1:56 PM, Saam Barati >>> > wrote:
 
> On Dec 14, 2018, at 1:54 PM, Saam Barati  > wrote:
> 
>> On Dec 14, 2018, at 1:37 PM, Chris Dumez > > wrote:
>> 
>> Hi,
>> 
>> I have now been caught twice by std::optional’s move constructor. It 
>> turns out that it leaves the std::optional being moved-out *engaged*, it 
>> merely moves its value.
>> 
>> For example, testOptional.cpp:
>> #include 
>> #include 
>> 
>> int main()
>> {
>>   std::optional a = 1;
>>   std::optional b = std::move(a);
>>   std::cout << "a is engaged? " << !!a << std::endl;
>>   std::cout << "b is engaged? " << !!b << std::endl;
>>   return 0;
>> }
>> 
>> $ clang++ testOptional.cpp -o testOptional -std=c++17
>> $ ./testOptional
>> a is engaged? 1
>> b is engaged? 1
>> 
>> I would have expected:
>> a is engaged? 0
>> b is engaged? 1
> I would have expected this too.
> 
> This is also what I would have expected.
> 
>> This impacts the standard std::optional implementation on my machine as 
>> well as the local copy in WebKit’s wtf/Optional.h.
>> 
>> As far as I know, our convention in WebKit so far for our types has been 
>> that types getting moved-out are left in a valid “empty” state.
> I believe it's UB to use an object after it has been moved.
 I'm wrong here.
 Apparently objects are left in a "valid but unspecified state".
 
 https://stackoverflow.com/questions/32346143/undefined-behavior-with-stdmove
  
 
>>> I believe in WebKit, however, we’ve made sure our types are left in a valid 
>>> “empty” state, thus my proposal for our own optional type that would be 
>>> less error-prone / more convenient to use.
>> I think your proposal is reasonable. I agree it's less error prone.
>> 
>> I think if we make this change, we should pull optional out of std and put 
>> it in WTF, since we're now implementing behavior we will rely on being 
>> specified.
> 
> I am also in favor of having an implementation in WTF that empties the
> optional after moving the value out from it.
> 
> Cheers,
> 
> 
> -Adrián
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


[webkit-dev] Please start using RELEASE_ASSERT_WITH_SECURITY_IMPLICATION()

2017-10-17 Thread David Kilzer
Hello,

TL;DR:  Please start using RELEASE_ASSERT_WITH_SECURITY_IMPLICATION() in place 
of ASSERT_WITH_SECURITY_IMPLICATION() for new/updated code.

It turns out that having some of these debug asserts enabled in release builds 
would have prevented security issues, so we’re going through and changing the 
ones that won’t impact performance immediately, and we will eliminate the rest 
of the debug asserts over time.  (Changing them all at once would incur too 
many performance regressions.)

I’ve also added a webkit-style-checker check to warn when using 
ASSERT_WITH_SECURITY_IMPLICATION() to deter new instances of the debug macro.

For reference:

Bug 178269: Add RELEASE_ASSERT_WITH_SECURITY_IMPLICATION() macro
>
>

Dave

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


Re: [webkit-dev] Are there any plans to upgrade bugzilla server on bugs.webkit.org?

2016-05-05 Thread David Kilzer
Hi Ossy,

On Apr 27, 2016, at 8:15 AM, Darin Adler <da...@apple.com 
<mailto:da...@apple.com>> wrote:
> Yes, we definitely want to upgrade. It’s a bit of work. In the past, I think 
> David Kilzer did some upgrades.

I’ll try to find some time to do a Bugzilla upgrade soon.  Currently I’ve been 
busy helping to fix a number of libxml2 security bugs as I am maintaining that 
project here at Apple, which is why I haven’t been as active in WebKit 
recently.  However, most of these fixes directly impact WebKit security, so if 
you maintain a WebKit port and use libxml2, you should review security fixes in 
that project (and libxslt if you build with ENABLE(XSLT)).

In the meantime, today I added support for bugs.chromium.org 
<http://bugs.chromium.org/> URLs in the “See Also” field by merging an upstream 
patch in r200457 <https://trac.webkit.org/changeset/200457> that isn’t even in 
the latest shipping Bugzilla yet:

Bug 1252782 - can't add a "See Also" to a Chromium bug on bugs.chromium.org 
<http://bugs.chromium.org/>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1252782 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1252782>>

Happy bug linking!

Dave

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


[webkit-dev] Interdiff fixed on bugs.webkit.org

2014-12-15 Thread David Kilzer
I just fixed the ‘interdiff’ feature of Bugzilla.  Now you can diff your diffs 
while you diff!

The issue was apparently being tracked here:  Bug 82517: Bugzilla should 
provide diffs between two patches 
https://bugs.webkit.org/show_bug.cgi?id=82517

Example:  
https://bugs.webkit.org/attachment.cgi?oldid=243242action=interdiffnewid=243295headers=1
 
https://bugs.webkit.org/attachment.cgi?oldid=243242action=interdiffnewid=243295headers=1

Dave

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


[webkit-dev] bugs.webkit.org email outage; asynchronous mail queue enabled

2014-10-24 Thread David Kilzer
Hello,

The bugs.webkit.org site experienced a mail server outage from at least 10:55 
PM PDT on Thursday, October 23 (possibly earlier) until about 11:08 AM PDT 
today (Friday, October 24).

During this time, we enabled Bugzilla's asynchronous mail queue to unblock all 
other interaction with bugs.webkit.org.

All of the queued mail should now be delivered.

Please let us know if you experience any issues with mail delivery going 
forward.  Thanks!

Dave

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


[webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
Hi,

We’re planning on upgrading Bugzilla (bugs.webkit.org) from 3.2.3 to 4.2.11 on 
Thursday, October 16 from 8-10 AM PDT.

Sorry for the short notice.  I sent this message from the wrong address, and 
didn't see he bounce message until now.

Please let me know if you have questions or concerns.  Thanks!

Dave

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


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
Sorry, sent this from the wrong address before the update.

 On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 have you tried if the webkit-patch bugzilla tool (upload,
 apply-attachment, apply-from-bug, ... ), the review tool,
 the commit queue and EWS will work properly with the new
 bugzilla version?

I did verify webkit-patch upload works.  We don't have an easy way to test 
commit queue and EWS outside of the production environment.  (That is something 
we want to improve going forward.)

If those are too broken to fix quickly, the plan is to roll back.

 I think they are very fragile and highly rely on the generated
 HTML forms. I prefer fixing these tools before updating to
 breaking them and then trying to fix.


I wanted to upgrade as soon as possible to patch security issues that were not 
back-ported to the version we were running.

 Just out of curiosity, if we do an upgrade, why do we upgrade
 to the old stable release (4.2.11), why not the latest stable
 relase (4.4.6)? Is there a fundamental reason for it?


It was the quickest path to upgrade to a version where security patches were 
available.

I had upgraded to 4.2.5 about a year ago, and had qualified over 90% of the 
website, so it was quickest to upgrade to 4.2.11 rather than 4.4.6 (which could 
have introduced more compat issues with tools).

 There are many good fixes in 4.4 release. If we can't upgrade
 to 4.4 for some reason, it would be great to cherry-pick at
 least the following changes:
 
 It is now possible to add yourself to the CC list when uploading an 
 attachment and when editing an existing one. (note)
 -- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )
 
 Changes to the CC list no longer causes midair collisions. (note)
 -- It is very annoying if you are commenting a bug, and you
 have to start it again if somebody else cc-ed him/herself.
 Or if you clicked force, it would remove these new cc-s.


After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way to test the 
EWS and commit queue with our test environment).

 And one more question: Are you planning to check-in
 the new bugzilla to Websites/bugs.webkit.org ?


Yes.  That will be part of the upgrade.  It's split into many individual 
patches (and 3 merge patches); I didn't want to squash-merge it in case it was 
easier to fix a future bug based on these changes.

Dave


 (note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat
 
 br,
 Ossy
 
 David Kilzer írta:
 Hi,
 We’re planning on upgrading Bugzilla (bugs.webkit.org 
 http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 from 
 8-10 AM PDT x-apple-data-detectors://1.
 Sorry for the short notice.  I sent this message from the wrong address, and 
 didn't see he bounce message until now.
 Please let me know if you have questions or concerns.  Thanks!
 Dave
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
Update complete.

Please file bugs on bugs.webkit.org and reply to this thread with the bug.

Thanks!

Dave
--
Sent from my iPhone 6

 On Oct 16, 2014, at 10:56 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Sorry, sent this from the wrong address before the update.
 
 On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 have you tried if the webkit-patch bugzilla tool (upload,
 apply-attachment, apply-from-bug, ... ), the review tool,
 the commit queue and EWS will work properly with the new
 bugzilla version?
 
 I did verify webkit-patch upload works.  We don't have an easy way to test 
 commit queue and EWS outside of the production environment.  (That is 
 something we want to improve going forward.)
 
 If those are too broken to fix quickly, the plan is to roll back.
 
 I think they are very fragile and highly rely on the generated
 HTML forms. I prefer fixing these tools before updating to
 breaking them and then trying to fix.
 
 
 I wanted to upgrade as soon as possible to patch security issues that were 
 not back-ported to the version we were running.
 
 Just out of curiosity, if we do an upgrade, why do we upgrade
 to the old stable release (4.2.11), why not the latest stable
 relase (4.4.6)? Is there a fundamental reason for it?
 
 
 It was the quickest path to upgrade to a version where security patches were 
 available.
 
 I had upgraded to 4.2.5 about a year ago, and had qualified over 90% of the 
 website, so it was quickest to upgrade to 4.2.11 rather than 4.4.6 (which 
 could have introduced more compat issues with tools).
 
 There are many good fixes in 4.4 release. If we can't upgrade
 to 4.4 for some reason, it would be great to cherry-pick at
 least the following changes:
 
 It is now possible to add yourself to the CC list when uploading an 
 attachment and when editing an existing one. (note)
 -- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )
 
 Changes to the CC list no longer causes midair collisions. (note)
 -- It is very annoying if you are commenting a bug, and you
 have to start it again if somebody else cc-ed him/herself.
 Or if you clicked force, it would remove these new cc-s.
 
 
 After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way to test 
 the EWS and commit queue with our test environment).
 
 And one more question: Are you planning to check-in
 the new bugzilla to Websites/bugs.webkit.org ?
 
 
 Yes.  That will be part of the upgrade.  It's split into many individual 
 patches (and 3 merge patches); I didn't want to squash-merge it in case it 
 was easier to fix a future bug based on these changes.
 
 Dave
 
 
 (note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat
 
 br,
 Ossy
 
 David Kilzer írta:
 Hi,
 We’re planning on upgrading Bugzilla (bugs.webkit.org 
 http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 
 from 8-10 AM PDT x-apple-data-detectors://1.
 Sorry for the short notice.  I sent this message from the wrong address, 
 and didn't see he bounce message until now.
 Please let me know if you have questions or concerns.  Thanks!
 Dave
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
Two commit queue issues:

1. Patches are landing, but bugs aren't being closed.  Looks like webkit-patch 
is failing because a textarea is disabled by default.

2. Some commit queue patches fail to apply because 'OOPS!' is not being removed 
from ChangeLog entries.

Investigating.

Dave
--
Sent from my iPhone 6

 On Oct 16, 2014, at 10:58 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Update complete.
 
 Please file bugs on bugs.webkit.org and reply to this thread with the bug.
 
 Thanks!
 
 Dave
 --
 Sent from my iPhone 6
 
 On Oct 16, 2014, at 10:56 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Sorry, sent this from the wrong address before the update.
 
 On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 have you tried if the webkit-patch bugzilla tool (upload,
 apply-attachment, apply-from-bug, ... ), the review tool,
 the commit queue and EWS will work properly with the new
 bugzilla version?
 
 I did verify webkit-patch upload works.  We don't have an easy way to test 
 commit queue and EWS outside of the production environment.  (That is 
 something we want to improve going forward.)
 
 If those are too broken to fix quickly, the plan is to roll back.
 
 I think they are very fragile and highly rely on the generated
 HTML forms. I prefer fixing these tools before updating to
 breaking them and then trying to fix.
 
 
 I wanted to upgrade as soon as possible to patch security issues that were 
 not back-ported to the version we were running.
 
 Just out of curiosity, if we do an upgrade, why do we upgrade
 to the old stable release (4.2.11), why not the latest stable
 relase (4.4.6)? Is there a fundamental reason for it?
 
 
 It was the quickest path to upgrade to a version where security patches were 
 available.
 
 I had upgraded to 4.2.5 about a year ago, and had qualified over 90% of the 
 website, so it was quickest to upgrade to 4.2.11 rather than 4.4.6 (which 
 could have introduced more compat issues with tools).
 
 There are many good fixes in 4.4 release. If we can't upgrade
 to 4.4 for some reason, it would be great to cherry-pick at
 least the following changes:
 
 It is now possible to add yourself to the CC list when uploading an 
 attachment and when editing an existing one. (note)
 -- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )
 
 Changes to the CC list no longer causes midair collisions. (note)
 -- It is very annoying if you are commenting a bug, and you
 have to start it again if somebody else cc-ed him/herself.
 Or if you clicked force, it would remove these new cc-s.
 
 
 After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way to test 
 the EWS and commit queue with our test environment).
 
 And one more question: Are you planning to check-in
 the new bugzilla to Websites/bugs.webkit.org ?
 
 
 Yes.  That will be part of the upgrade.  It's split into many individual 
 patches (and 3 merge patches); I didn't want to squash-merge it in case it 
 was easier to fix a future bug based on these changes.
 
 Dave
 
 
 (note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat
 
 br,
 Ossy
 
 David Kilzer írta:
 Hi,
 We’re planning on upgrading Bugzilla (bugs.webkit.org 
 http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 
 from 8-10 AM PDT x-apple-data-detectors://1.
 Sorry for the short notice.  I sent this message from the wrong address, 
 and didn't see he bounce message until now.
 Please let me know if you have questions or concerns.  Thanks!
 Dave
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
On Oct 16, 2014, at 2:38 PM, David Kilzer ddkil...@webkit.org wrote:

 Two commit queue issues:
 
 1. Patches are landing, but bugs aren't being closed.  Looks like 
 webkit-patch is failing because a textarea is disabled by default.

Bug 137794: commit-queue: fails to close bugs after successfully landing patches
https://bugs.webkit.org/show_bug.cgi?id=137794
http://trac.webkit.org/changeset/174797

Tentatively fixed.  Still waiting for a cq+ patch to land with this fix 
applied.  (There are some in flight that will not have this fix yet.)

 2. Some commit queue patches fail to apply because 'OOPS!' is not being 
 removed from ChangeLog entries.

Bug 137795: commit-queue: fails to replace OO-PS! with reviewer name
https://bugs.webkit.org/show_bug.cgi?id=137795

Investigating this now.

Dave


 Investigating.
 
 Dave
 --
 Sent from my iPhone 6
 
 On Oct 16, 2014, at 10:58 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Update complete.
 
 Please file bugs on bugs.webkit.org and reply to this thread with the bug.
 
 Thanks!
 
 Dave
 --
 Sent from my iPhone 6
 
 On Oct 16, 2014, at 10:56 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Sorry, sent this from the wrong address before the update.
 
 On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba o...@inf.u-szeged.hu 
 wrote:
 
 Hi,
 
 have you tried if the webkit-patch bugzilla tool (upload,
 apply-attachment, apply-from-bug, ... ), the review tool,
 the commit queue and EWS will work properly with the new
 bugzilla version?
 
 I did verify webkit-patch upload works.  We don't have an easy way to test 
 commit queue and EWS outside of the production environment.  (That is 
 something we want to improve going forward.)
 
 If those are too broken to fix quickly, the plan is to roll back.
 
 I think they are very fragile and highly rely on the generated
 HTML forms. I prefer fixing these tools before updating to
 breaking them and then trying to fix.
 
 
 I wanted to upgrade as soon as possible to patch security issues that were 
 not back-ported to the version we were running.
 
 Just out of curiosity, if we do an upgrade, why do we upgrade
 to the old stable release (4.2.11), why not the latest stable
 relase (4.4.6)? Is there a fundamental reason for it?
 
 
 It was the quickest path to upgrade to a version where security patches 
 were available.
 
 I had upgraded to 4.2.5 about a year ago, and had qualified over 90% of the 
 website, so it was quickest to upgrade to 4.2.11 rather than 4.4.6 (which 
 could have introduced more compat issues with tools).
 
 There are many good fixes in 4.4 release. If we can't upgrade
 to 4.4 for some reason, it would be great to cherry-pick at
 least the following changes:
 
 It is now possible to add yourself to the CC list when uploading an 
 attachment and when editing an existing one. (note)
 -- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )
 
 Changes to the CC list no longer causes midair collisions. (note)
 -- It is very annoying if you are commenting a bug, and you
 have to start it again if somebody else cc-ed him/herself.
 Or if you clicked force, it would remove these new cc-s.
 
 
 After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way to test 
 the EWS and commit queue with our test environment).
 
 And one more question: Are you planning to check-in
 the new bugzilla to Websites/bugs.webkit.org ?
 
 
 Yes.  That will be part of the upgrade.  It's split into many individual 
 patches (and 3 merge patches); I didn't want to squash-merge it in case it 
 was easier to fix a future bug based on these changes.
 
 Dave
 
 
 (note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat
 
 br,
 Ossy
 
 David Kilzer írta:
 Hi,
 We’re planning on upgrading Bugzilla (bugs.webkit.org 
 http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 
 from 8-10 AM PDT x-apple-data-detectors://1.
 Sorry for the short notice.  I sent this message from the wrong address, 
 and didn't see he bounce message until now.
 Please let me know if you have questions or concerns.  Thanks!
 Dave
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-16 Thread David Kilzer
On Oct 16, 2014, at 4:04 PM, David Kilzer ddkil...@webkit.org wrote:

 On Oct 16, 2014, at 2:38 PM, David Kilzer ddkil...@webkit.org wrote:
 
 Two commit queue issues:
 
 1. Patches are landing, but bugs aren't being closed.  Looks like 
 webkit-patch is failing because a textarea is disabled by default.
 
 Bug 137794: commit-queue: fails to close bugs after successfully landing 
 patches
 https://bugs.webkit.org/show_bug.cgi?id=137794
 http://trac.webkit.org/changeset/174797
 
 Tentatively fixed.  Still waiting for a cq+ patch to land with this fix 
 applied.  (There are some in flight that will not have this fix yet.)
 
 2. Some commit queue patches fail to apply because 'OOPS!' is not being 
 removed from ChangeLog entries.
 
 Bug 137795: commit-queue: fails to replace OO-PS! with reviewer name
 https://bugs.webkit.org/show_bug.cgi?id=137795
 
 Investigating this now.

Tentative fix (for the first issue found) checked in:  
http://trac.webkit.org/changeset/174800

If neither of these work, please let me know.  I'll check in later tonight to 
see how things are going.

Dave


 Dave
 
 
 Investigating.
 
 Dave
 --
 Sent from my iPhone 6
 
 On Oct 16, 2014, at 10:58 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Update complete.
 
 Please file bugs on bugs.webkit.org and reply to this thread with the bug.
 
 Thanks!
 
 Dave
 --
 Sent from my iPhone 6
 
 On Oct 16, 2014, at 10:56 AM, David Kilzer ddkil...@webkit.org wrote:
 
 Sorry, sent this from the wrong address before the update.
 
 On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba o...@inf.u-szeged.hu 
 wrote:
 
 Hi,
 
 have you tried if the webkit-patch bugzilla tool (upload,
 apply-attachment, apply-from-bug, ... ), the review tool,
 the commit queue and EWS will work properly with the new
 bugzilla version?
 
 I did verify webkit-patch upload works.  We don't have an easy way to test 
 commit queue and EWS outside of the production environment.  (That is 
 something we want to improve going forward.)
 
 If those are too broken to fix quickly, the plan is to roll back.
 
 I think they are very fragile and highly rely on the generated
 HTML forms. I prefer fixing these tools before updating to
 breaking them and then trying to fix.
 
 
 I wanted to upgrade as soon as possible to patch security issues that were 
 not back-ported to the version we were running.
 
 Just out of curiosity, if we do an upgrade, why do we upgrade
 to the old stable release (4.2.11), why not the latest stable
 relase (4.4.6)? Is there a fundamental reason for it?
 
 
 It was the quickest path to upgrade to a version where security patches 
 were available.
 
 I had upgraded to 4.2.5 about a year ago, and had qualified over 90% of 
 the website, so it was quickest to upgrade to 4.2.11 rather than 4.4.6 
 (which could have introduced more compat issues with tools).
 
 There are many good fixes in 4.4 release. If we can't upgrade
 to 4.4 for some reason, it would be great to cherry-pick at
 least the following changes:
 
 It is now possible to add yourself to the CC list when uploading an 
 attachment and when editing an existing one. (note)
 -- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )
 
 Changes to the CC list no longer causes midair collisions. (note)
 -- It is very annoying if you are commenting a bug, and you
 have to start it again if somebody else cc-ed him/herself.
 Or if you clicked force, it would remove these new cc-s.
 
 
 After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way to test 
 the EWS and commit queue with our test environment).
 
 And one more question: Are you planning to check-in
 the new bugzilla to Websites/bugs.webkit.org ?
 
 
 Yes.  That will be part of the upgrade.  It's split into many individual 
 patches (and 3 merge patches); I didn't want to squash-merge it in case it 
 was easier to fix a future bug based on these changes.
 
 Dave
 
 
 (note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat
 
 br,
 Ossy
 
 David Kilzer írta:
 Hi,
 We’re planning on upgrading Bugzilla (bugs.webkit.org 
 http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 
 from 8-10 AM PDT x-apple-data-detectors://1.
 Sorry for the short notice.  I sent this message from the wrong address, 
 and didn't see he bounce message until now.
 Please let me know if you have questions or concerns.  Thanks!
 Dave
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman

Re: [webkit-dev] Fuzzinator, a mutation based web fuzzer

2013-06-26 Thread David Kilzer
On Jun 25, 2013, at 1:56 AM, Renáta Hodován hodo...@inf.u-szeged.hu wrote:

 Hi folks,
 
 as many of you know already I'm working on an universal web fuzzer, which is 
 able to generate random test cases for both svg, html, css and js, and test 
 them against any browser. With this method we can catch crashes, assertions, 
 memory corruptions and all the funny things.

This is great!

You mentioned in a follow-up that you were going to write an extension for 
WebGL.  Is it easy to write extensions for Fuzzinator?  I'm curious how much 
effort it would be to write a MathML extension as well.

Thanks!

Dave

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


Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

2013-02-08 Thread David Kilzer
On Feb 8, 2013, at 1:41 PM, Adam Barth aba...@webkit.org wrote:

 Context: https://bugs.webkit.org/show_bug.cgi?id=109071
 
 Adam Barth said:
 It's not clear to me that running WebCore on multiple interlocked threads is 
 a good idea.  That
 seems like a pretty major change to WebCore's architecture.  Is that 
 something that's up for
 discussion?
 
 Darin Adler said:
 I agree that it’s not something I’d do if I was starting a project now.
 
 In the iOS context, it’s fantastic for discussion as a possibly multi-year 
 major architecture
 change, but if we take a hard line on this, then we won’t have the iOS port 
 in the tree for
 years, and I think it would be good if we do. iOS WebKit has worked this way 
 for the entire
 history of iPhone, so it’s not a change that can be made easily.
 
 Darin Adler also said:
 I think where you and I may differ is on whether a good solution to the 
 problem would be
 valuable to the WebKit project. Is there some way I convince you of the 
 value of fitting
 an important existing port of WebKit into our tree in as clean as possible a 
 way?
 
 I don't really know how to respond to this thread.  I feel like I'm
 being offered the following choice:
 
 1) Give up the ability to have technical input to how WebCore works
 and simply accept all the design choices made in the iOS fork, whether
 they be good choices or bad.
 
 2) Keep the iOS port in an Apple-internal fork for a number of years.
 
 I feel like I'm being asked to make this choice in the context of a
 growing trend of unilateral action by Apple in this project.  Given
 that trend, I don't see how I can choose option (1).
 
 As much as I would like the iOS port merged into trunk, I'm not
 willing to give up having a technical say in the project.  Therefore,
 reluctantly, I'm forced to choose option (2).


The iOS port does not require re-architecting WebCore.

Bug 109071 was about coming up with a better name for a method that is 
primarily used in ASSERT()s in WebCore.  Without changing the implementation of 
that method, debug builds of WebCore on iOS assert instantly since WebCore 
execution can happen on one of two threads.

We can live with keeping the method name as isMainThread() and have already 
moved on to other things.

The rest of WebCore is largely unchanged for iOS, other than the usual 
port-specific code you need for a port, which will be posted for review as we 
continue to merge.

Dave

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


Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

2013-02-08 Thread David Kilzer
On Feb 8, 2013, at 2:52 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote:
 
 The iOS port does not require re-architecting WebCore.
 
 Bug 109071 was about coming up with a better name for a method that is 
 primarily used in ASSERT()s in WebCore.  Without changing the implementation 
 of that method, debug builds of WebCore on iOS assert instantly since 
 WebCore execution can happen on one of two threads.
 
 We can live with keeping the method name as isMainThread() and have 
 already moved on to other things.
 
 The rest of WebCore is largely unchanged for iOS, other than the usual 
 port-specific code you need for a port, which will be posted for review as 
 we continue to merge.
 
 How do these multiple interlocked threads interact with code that uses
 thread-local storage?


The UI (main) thread and the web thread share the same thread-local storage.  
Those code changes are in 4 or 5 files in WTF.

There are also a couple of additional mutexes in WebCore for WebSQL and the DOM 
wrapper cache.

Access to WebCore itself is mediated by a coarse-grained lock (the web thread 
lock), which is taken outside of WebCore.

Dave

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


[webkit-dev] 'ANGLE' component added to bugs.webkit.org

2013-01-15 Thread David Kilzer
I've added an 'ANGLE' component to bugs.webkit.org.

Dave

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


Re: [webkit-dev] iOS parsing of the viewport meta tag

2012-07-10 Thread David Kilzer
On Jul 10, 2012, at 8:48 AM, Adam Barth wrote:

 Parse the viewport meta tag like iOS
 https://bugs.webkit.org/show_bug.cgi?id=72722
 
 Is the parsing code for the viewport meta tag in iOS open source?

It's on http://opensource.apple.com/ in ViewportArguments.cpp.

Dave

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


Re: [webkit-dev] iOS parsing of the viewport meta tag

2012-07-10 Thread David Kilzer
On Jul 10, 2012, at 9:22 AM, Adam Barth wrote:
 On Tue, Jul 10, 2012 at 9:16 AM, David Kilzer ddkil...@webkit.org wrote:
 On Jul 10, 2012, at 8:48 AM, Adam Barth wrote:
 Parse the viewport meta tag like iOS
 https://bugs.webkit.org/show_bug.cgi?id=72722
 
 Is the parsing code for the viewport meta tag in iOS open source?
 
 It's on http://opensource.apple.com/ in ViewportArguments.cpp.
 
 Oh, I was under the mistaken impression that iOS didn't use
 ViewportArguments.cpp.

We do, but there are changes in the source file, so it's not strictly the same 
as ToT WebKit.  You'll want to use diff to see what's different.

Dave

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


Re: [webkit-dev] spinoff from webkit-patch -g discussion

2012-03-01 Thread David Kilzer
On Feb 29, 2012, at 3:28 PM, Dirk Pranke wrote:

 In my view, I would actually rather upload the combination of
 committed + staged + unstaged changes rather than be told I have to
 commit things; in other words, I actually prefer to commit what I've
 uploaded rather than upload what I've committed.

Ah!  This explains why I use webkit-patch differently.  With many local 
branches, leaving staged/unstaged changes in the source tree would make it 
impossible to switch branches easily.  I also don't think of bugs.webkit.org as 
an ancillary source code repository (if I delete my local changes), but maybe 
that's because I'm uploading fewer patches to bugs.webkit.org.

Dave

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


Re: [webkit-dev] webkit

2012-02-28 Thread David Kilzer
This account has been unsubscribed.

Dave


On Feb 25, 2012, at 6:57 PM, Eric Seidel wrote:

 Please ban this spammer.
 
 On Sat, Feb 25, 2012 at 1:27 PM, Tyler Cumberton tylercw...@gmail.com wrote:
 I have a question : webkit site
 
 --
 -Tyler.
 
 ___
 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] git.webkit.org is offline

2012-02-15 Thread David Kilzer
Bill is aware of the issue and is working on it right now.

Dave


On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote:

 Hi,
 
 It seems git.webkit.org is offline.
 Could you check what happened?
 
 br,
 Ossy
 ___
 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] new API for offline web applications

2012-01-10 Thread David Kilzer
How did you run the layout tests?  The run-webkit-tests script should take care 
of starting the Apache web server for you with all the configuration options 
set.  This is usually how you run just the http tests for a debug build (after 
running the build-webkit script):

./Tools/Scripts/run-webkit-tests --debug http

Do the same tests pass without your changes?  That would be the first thing to 
check.

You should also write at least one layout test that tests the new abort() 
method.  See Step 4 here:  http://www.webkit.org/coding/contributing.html

Dave


On Jan 10, 2012, at 6:46 AM, huangxueqing wrote:

 Hi Dave:
I have implemented abort(), but some of result of layout test in 
 Layout/http/tests/appcache was failed. And i copy appcache dir into htdocs 
 dir of apache raise failure again. I think due to some configuration 
 problems.  Should i configure something to correct it?
 thanks.
 
 huangxueqing
 
 The abort() method is defined here:  
 http://dev.w3.org/html5/spec/Overview.html#applicationcache
 
 There is no abort() method defined in 
 Source/WebCore/loader/appcache/DOMApplicationCache.idl.
 
 Please file a bug and attach a patch for review.  See:  
 http://www.webkit.org/coding/contributing.html
 
 Thanks!
 
 Dave
 
 
 On Jan 7, 2012, at 7:04 AM, huangxueqing wrote:
 
 hi all:
   The latest html5 specification add a API applicationCache.abort() for 
 offline web applications. I had implement offline web app for our browser 
 in main process this month except this interface since it need to make some 
 modifications in WebCore.
   I want to know whether any guys had planed to implement it? If not and 
 this feature was necessary, maybe i will file a bug and implement this api 
 in next month.
   thanks.
 
 huangxueqing
 Baidu, Inc.
 ___
 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] new API for offline web applications

2012-01-07 Thread David Kilzer
The abort() method is defined here:  
http://dev.w3.org/html5/spec/Overview.html#applicationcache

There is no abort() method defined in 
Source/WebCore/loader/appcache/DOMApplicationCache.idl.

Please file a bug and attach a patch for review.  See:  
http://www.webkit.org/coding/contributing.html

Thanks!

Dave


On Jan 7, 2012, at 7:04 AM, huangxueqing wrote:

 hi all:
The latest html5 specification add a API applicationCache.abort() for 
 offline web applications. I had implement offline web app for our browser in 
 main process this month except this interface since it need to make some 
 modifications in WebCore.
I want to know whether any guys had planed to implement it? If not and 
 this feature was necessary, maybe i will file a bug and implement this api in 
 next month.
thanks.
 
 huangxueqing
 Baidu, Inc.
 ___
 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] Using C++ constant local variables in WebKit

2011-11-30 Thread David Kilzer
On Nov 29, 2011, at 6:44 PM, Ryosuke Niwa wrote:

 On Tue, Nov 29, 2011 at 6:42 PM, Ryosuke Niwa rn...@webkit.org wrote: 
   - Prevents misuse of variable in a later patch (by a different author) 
 through enforcement of const-ness.
 
 Prevents one specific type of misuse: Setting the variable to another value. 
 And that may not be misuse despite the fact that the original author didn’t 
 plan on changing it.
 
 Right, but it tells us the intent of the author, and appears to be useful 
 even if the variable started with prefixes like old, original, and 
 previous.
 
 I'll add that I'd much prefer seeing a const in front of a local variable 
 over seeing a comment like This variable shouldn't be modified.


Thanks for the feedback everyone.  In retrospect, I see that my original 
question was too broad and too general.

What I (and Antti) really wanted to ask was whether it's okay to use const 
pointers on a case-by-case basis without making it a project-wide rule.

And this is the specific case I'm talking about:

diff --git a/Source/WebCore/platform/KURL.cpp b/Source/WebCore/platform/KURL.cpp
index e752bb8..cb033bd 100644
--- a/Source/WebCore/platform/KURL.cpp
+++ b/Source/WebCore/platform/KURL.cpp
@@ -486,7 +486,7 @@ void KURL::init(const KURL base, const String relative, 
const TextEncoding en
 parseBuffer.resize(bufferSize);
 
 char* bufferPos = parseBuffer.data();
-char* bufferStart = bufferPos;
+char* const bufferStart = bufferPos;
 
 // first copy everything before the path from the base
 unsigned baseLength = base.m_string.length();

But of course I couldn't stop there because there were other pointers that 
could be const in this method, so I ended up with:

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

Dave

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


[webkit-dev] Using C++ constant pointers (type_name * const) in WebKit

2011-11-28 Thread David Kilzer
In a discussion on Bug 71921, Antti, Darin Adler and I started a discussion 
about using C++ constant pointers in WebKit.  Does the WebKit community have a 
consensus opinion on the matter?

* Pros
  - Documents use of variable.
  - Prevents misuse of variable in a later patch (by a different author) 
through enforcement of pointer const-ness.
  - May help compiler optimize code.  (We weren't sure whether modern compilers 
do this on their own or not.)

* Cons
  - Darin Adler doesn't ever recall fixing a bug in WebKit where a constant 
pointer would have helped.
  - Slightly more verbose syntax for constant pointers to a constant string 
(const char * const pointer;) or even a constant pointer to a mutable string 
(char * const pointer;).

Dave

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


Re: [webkit-dev] Chromium Mac moving to Skia

2011-08-19 Thread David Kilzer
On Aug 18, 2011, at 12:24 PM, Adam Barth wrote:

 Moving the chromium-mac result directories caused more of a disruption
 that I expected in that it apparently broke the git WebKit mirror.
 I'd like to apologize for the disruption.  We've done SVN server-side
 moves before, so I'm not entirely sure why this one caused a problem.
 If any git experts understand what went wrong and can tell me how to
 avoid this problem in the future, I would be very appreciative.
 
 The only other large single operation in this process is when we
 delete the CG results.  Hopefully that won't trigger the same issue.

I'm not sure of the root cause of the failure.

We updated the installed version of git, ran git svn revert -r 93166 and then 
ran git svn fetch manually to fix the repository.

Dave

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


Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

2011-04-29 Thread David Kilzer
Hi Pavel,

You need to send the contents of the blog post via email.  Not everyone can 
read it (even after logging in).

Dave


On Apr 29, 2011, at 11:44 AM, Pavel Feldman wrote:

 Hi guys,
 
 I started drafting the blog post Remote Debugging with Web Inspector: 
 http://www.webkit.org/blog/?p=1620preview=true.
 
 I'd like to cover following topics there:
 
 - ability to use Web Inspector front-end with remote / embedded devices
 - ability to implement alternate front-ends for IDEs
 - share the update on the protocol work progress
 
 Calling for the early feedback.
 
 Thanks
 Pavel
 
 On Mon, Aug 9, 2010 at 11:48 PM, Pavel Feldman pfeld...@chromium.org wrote:
 Hi guys,
 
 As some of you know, we are working on a remote debugging feature in Web 
 Inspector. There are many good reasons behind the project including the 
 following:
 
 - Debugging WebKit on embedded devices
 - Shaping up a good protocol for ourselves
 - Introducing external SDKs on top of the protocol for IDE integrations and 
 alternate front-ends
 
 We've had serialized interaction with the out-of-process inspector for quite 
 a while in Chromium. We were upstreaming it into WebKit and have reached an 
 important milestone recently: all the interaction between the inspected page 
 and inspector is entirely serialized on the WebKit level. All the embedder 
 needs to do is to implement a socket that would serve the inspector front-end 
 files and provide our messaging with appropriate transport.
 
 Now this socket is likely to be platform-specific, implemented on the WebKit 
 and/or host browser levels. It also makes more sense to implement socket on 
 mobile platforms first. However, we've done a proof-of-concept implementation 
 in Chromium and it is now in a demoable state! See the screencast at 
 http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + 
 WebKit nightly to the right. WebKit nightly connects remotely to Chromium 
 over HTTP on the port 9222 and does remote debugging including DOM 
 inspection, breakpoints and such. The communication is established by means 
 of a WebSocket. The interesting thing about the implementation is that 
 inspector front-end is fetched from the host browser, so that there is no 
 mess with protocol versioning and no need in exposing the interaction 
 protocol any time soon.
 
 So I made the demo and it looked cool. I thought maybe we do a blog post on 
 it. The blog post would draw attention to the Web Inspector and its progress, 
 share the remote debugging vision with the interested parties and would 
 simply look cool. Front-end is working as a pure HTML5 application (obviously 
 full of WebKit-specific styles, but still) which is impressive. Now the 
 project is nowhere complete in terms of finalizing the message format and the 
 protocol itself, but there is no intention to expose it right now. We'd like 
 to let it live with fetchable front-end and mature before we expose the 
 protocol and commit to any level of interface support.
 
 What do you think, is it ready for a blog post?
 
 Thanks
 Pavel
 
 ___
 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] coding style and comments

2011-01-30 Thread David Kilzer
On Jan 28, 2011, at 9:36 AM, Peter Kasting wrote:

 On Thu, Jan 27, 2011 at 4:27 PM, Simon Fraser simon.fra...@apple.com wrote:
 I think we have a distinct lack of comments that help novices to understand 
 the code. I feel that we almost have a privileged few mentality in some 
 code; if you can't figure it out by reading the code, then you shouldn't be 
 messing with it.
 
 Indeed.  This sets a high barrier to entry when trying to learn about any 
 nontrivial subsystem.
 
 Even when functions are kept brief and well-named, local simplicity does not 
 eliminate global complexity; in fact it can mask it, making the system appear 
 saner than it really is.  In this sense, I disagree that self-documenting 
 code is possible on a large scale (even though I am certainly a fan of making 
 the small-scale units concise, clear, etc.).
 
 Back when we were writing the initial Chromium port, Brett Wilson and I had 
 to rewrite the Image subsystem three separate times, each time because we 
 realized we'd gotten the ownership semantics wrong and thought we now 
 understood things better.  In this case, a simple function that merely 
 allocates an object is deceptively self-documenting, because it's clear what 
 it does in a local sense, but not in the larger picture of how it fits into 
 the rest of the codebase.
 
 No one is suggesting that silly comments like for (int i = 0; i  10; ++i)  
 // Count to 10. are a good thing, but I have never had any reviewer 
 objections to adding more detailed comments about subtle bits.  At the very 
 least I agree with Simon's suggestion of class-level comments, especially 
 w.r.t. ownership.

An interesting case study would be the (still ongoing?) refactoring of the 
loader code over the past few months (thanks to Adam Barth and others).   Is it 
easier to understand now than before the refactoring started?  How many 
comments were added in the process (FIXMEs notwithstanding)?

Dave

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


Re: [webkit-dev] WebCore has moved: How to avoid merge conflicts

2011-01-11 Thread David Kilzer
For git, I'm assuming the following works:

Local changes:
1. git stash save WIP
2. git pull --rebase origin   (or git svn rebase)
3. git stash pop

Branches:
1. git checkout branchname
2. git rebase master

However, it would be interesting to know if diff.renames=true or if 
diff.renames=copy is required, or if diff.renameLimit needs to be set.

Dave


On Jan 8, 2011, at 9:44 AM, Dimitri Glazkov wrote:

 Thanks for your hard work, Adam!
 
 I tried this morning to follow your steps. It worked great, except
 there were a few .orig files left after webkit-patch had run. I
 removed them by hand and was on my way.
 
 :DG
 
 On Sat, Jan 8, 2011 at 2:47 AM, Adam Barth aba...@webkit.org wrote:
 As of r75314, WebCore is now located in Source/WebCore.
 If you have outstanding patches to WebCore, here's what you can
 do to avoid merge conflicts:
 
 1) *BEFORE* updating past r75314, create a patch for your change,
 either with svn-create-patch or by uploading your patch to
 bugs.webkit.org with webkit-patch.
 
 2) Clean your working copy.  I recommend using webkit-patch clean,
 but you can also use svn-unapply, svn revert, git reset, or
 whatever you're most confortable with.
 
 3) Update to top-of-tree.
 
 4) Apply your patch using svn-apply or webkit-patch
 apply-attachment.  As of r75315, svn-apply is smart enough to
 magically apply the WebCore parts of your patch to
 Source/WebCore.
 
 Please let me know if you have any merge trouble.  Hopefully we've got
 things set up so that the move is relatively painless.  Thanks again
 for your patience.
 
 Adam
 ___
 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] Random inspector crasher?

2010-12-23 Thread David Kilzer
On Dec 23, 2010, at 6:02 AM, Carl Lobo wrote:

 I'm not very sure if this is relevant but here goes:
 I'm working on a javascript hosting framework (it's open source:
 https://github.com/directi/webkit_titanium/tree/webkit_clean).
 I'd pulled webkit git a couple of weeks back and then again a few
 hours ago and I get apparently random crashes in the inspector after I
 pause the javascript debugger and then resume. Sometimes it happens
 while I'm stepping through the JS code - but it always happens within
 a few minutes of a JS resume and pretty much randomly. If I don't
 pause the debugger there's no crash even if the inspector is open.
 The stack dump I see in Visual Studio is fairly consistent and doesn't
 include any of our code (except the entry point). I've been trying to
 create some script which reproduces it so I can file a proper bug
 report but I haven't had much luck with that.

Please file a bug report and attach the crash logs to it.  Thanks!

Dave


 Since seeing this email I've been saving a few VS2005 stacks in case
 it is of any help. I'm attaching 3 of them that are significantly
 different (the first 9 or so frames are always consistent).
 There are no assertion failures except if I expand a Dojo Closure
 object in the inspector when the debugger is paused.
 I'm using a debug build of the Cairo port for testing.
 I hope this helps/would be glad to help any further.
 
 Regards,
 Carl
 
 PS. The 3 attachments are about 27k so I'm not sure if the mailing
 list will scrub them.
 
 inspector-crash.txtinspector-crash3.txtinspector-crash4.txt


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


Re: [webkit-dev] Stability problems involving Javascript GC

2010-12-19 Thread David Kilzer
On Dec 17, 2010, at 12:02 AM, Zoltan Herczeg wrote:

 On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:
 Crash in WTF::fastMalloc? Such things only happen if something overwrites
 memory areas belongs to the memory manager (i.e overwrites some bytes
 before or after a block returned by malloc). Try some valgrind equivalent
 on mac to detect those writings into red zones.
 
 How can you use valgrind to help on that? We had some symptoms similar
 to this and also came to the conclusion that probably something is
 overwriting the structures used by fast malloc, but couldn't find
 anything with valgrind. Overwriting in an area that has bee reserved
 is not an error vangrind finds, at least not with any options that I
 know.
 
 I haven't received your reply before. To capture this bug, you have to
 disable fastmalloc, and use the internal (trackable) memory allocator
 replacement of valgrind.
 
 Run build-webkit --system-malloc
 
 This will redirect all allocations to the system malloc.

In addition to valgrind, try running the test under guard malloc on Mac OS X 
with system malloc enabled.   See man libgmalloc:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html%23//apple_ref/doc/man/3/libgmalloc

Dave

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


Re: [webkit-dev] Client-based Geolocation

2010-12-10 Thread David Kilzer
On Dec 10, 2010, at 6:45 AM, John Knottenbelt jknot...@chromium.org wrote:

 It would be great if, ultimately, we could remove the non-client-based 
 geolocation code from WebCore (I already have plans to do this for Chromium's 
 WebKit layer). Such a removal would make the WebCore code more readable 
 because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives 
 would go away, more understandable because there would be less code, and more 
 maintainable because we would only need to fix bugs in one code path, rather 
 than two. 
 
 It seems that Android, Qt and GTK currently implement the non-client-based 
 design.

The iOS port also uses the non-client-based design.

 Is anybody working, or interested in working, on migrating these platforms to 
 the client-based design? 

I would file a bug for each port to start with.

Dave
--
Sent from my iPhone 4

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


Re: [webkit-dev] webkit-patch --suggest-reviewers

2010-10-23 Thread David Kilzer
Thanks guys!  I really like this feature, but it would be great if you could 
pick individuals from the list of suggested reviewers instead of all-or-none:

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

Dave





From: Adam Barth aba...@webkit.org
To: webkit-dev@lists.webkit.org
Sent: Thu, October 21, 2010 10:09:12 PM
Subject: [webkit-dev] webkit-patch --suggest-reviewers

Eric and I are working on a new feature of webkit-patch to make it
easier for you to find reviewers for your code.  When you upload a
patch with webkit-patch, you can try passing the --suggest-reviewers
option.  webkit-patch will look at your patch and try to guess who
might be good reviewers (and offer to CC them).  This feature is very
experimental, but I'd like to encourage you to give it a try and let
us know what you think.

At some point, we'd like to use this same idea in reverse and have a
way to ask http://webkit.org/pending-review for patches that you might
be the right person to review.

Enjoy!
Adam___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas component in Bugzilla

2010-09-19 Thread David Kilzer
On Sep 14, 2010, at 10:22 PM, Darin Adler da...@apple.com wrote:

 On Sep 14, 2010, at 5:54 PM, Andreas Kling wrote:
 
 I propose we add a Canvas component in Bugzilla. Thoughts?
 
 Sounds OK to me.

Done.

Dave
--
Sent from my iPhone 4

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


Re: [webkit-dev] Review tool changes

2010-09-19 Thread David Kilzer
On Sep 17, 2010, at 6:38 AM, Mike Pinkerton pinker...@chromium.org wrote:

 On Fri, Sep 17, 2010 at 2:39 AM, Adam Barth aba...@webkit.org wrote:
 
 The tool has some problems on iPad.  The issue is the bottom toolbar
 uses position: fixed, which seems to be frozen to the initial viewport
 on iPad.  When you scroll, the bar stays in the middle of the page.  I
 presume there's some way to fix this.  It's on my list.
 
 A lot of sites have this problem, it seems. What is it about the iPad
 in particular that causes this issue? I doubt it's a webkit bug but
 it manifests itself as only happening on the iPad so most site
 designers end up not caring to fix, or not being able to diagnose the
 problem for lack of hardware. I frequent at least two sites with this
 behavior.

It has to do with how iOS WebKit defines the viewport.

http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html

Dave
--
Sent from my iPhone 4

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


Re: [webkit-dev] Number of pending commits

2010-09-07 Thread David Kilzer
On Sep 7, 2010, at 9:51 AM, Eric Seidel e...@webkit.org wrote:

 I also attempted to look through pending-commit last week.  I decided
 to clean it out someone needs to write a script which can make a guess
 if a bug is landed or not.  I would guess that over half of
 http://webkit.org/pending-commit are already landed and the lander
 forgot to close the bug. [1]
 
 You should feel free to CQ as much of it as you like.  The CQ is far
 from capacity.  It's slower than it should be during peek hours
 (mostly due to flaky tests combined with ChangeLog/checkout
 contention), but I'm working on making it faster.
 
 -eric
 
 1.  FYI, if you prefer to land your patches w/o the assistance of
 webkit-patch land (which will update and close the bug for you), you
 might consider using webkit-patch mark-bug-fixed right after
 landing.  It's a command written by Dave Kiltzer which looks at the
 most recent revision and updates and closes the bug associated with
 that revision.

It's most useful immediately after landing a patch.  Otherwise, you may need to 
specify both the bug number and revision on the command-line.

It should work in both git and svn working directories, though.

Dave
--
Sent from my iPhone 4


 On Tue, Sep 7, 2010 at 1:09 AM, Adam Barth aba...@webkit.org wrote:
 I tried to clean out pending-commit a few weeks ago.  I found that
 many of the patches had already been landed but the bugs hadn't been
 closed.  The commit-queue should be able to handle as many patches as
 you throw at it, so that shouldn't be the limiting factor.
 
 Adam
 
 
 On Tue, Sep 7, 2010 at 1:03 AM, Holger Freyther ze...@selfish.org wrote:
 Hi,
 
 I was just seeing that we have about 84 bugs which are in the pending-commit
 state, on the Gtk+ bugs I clicked the patches need to be landed manually.
 
 It would be nice to get a hand landing these patches, or asking the commit
 queue to take care of them.
 
 thanks
holger
 ___
 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Build system complexity

2010-08-12 Thread David Kilzer
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote:

 i completely agree with jeremy. is it possible to at least drop the cryptic 
 hashcodes/timestamps? without them, the .xcodeproj files should at least be 
 editable by hand.

Doesn't gyp already generate Xcode projects for Chrome?  I think the issue is 
that gyp can't generate replacement project files for Apple's Mac port or other 
build systems yet.  That was my take-away from the last discussion--that gyp 
needed to be enhanced so that all build systems could be generated, making 
addition or removal of source files a trivial task.

As far as Jeremy's other points, perhaps bugs should be filed about each item 
so that more specific discussion can take place on each topic.

Dave

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


Re: [webkit-dev] Some new coding style rules

2010-08-05 Thread David Kilzer
On Wed, August 4, 2010 at 11:56:53 PM, Sam Weinig wrote:
 On Wed, Aug 4, 2010 at 1:29 AM, Nikolas Zimmermann 
zimmerm...@physik.rwth-aachen.de wrote:
 
 namespace WebCore {
 ...
 } // namespace WebCore
 
 2. ENABLE(FOO) #endif comments
 
 #if ENABLE(FOO)
 ..
 #endif // ENABLE(FOO)
 
 I like these two forms of comments.

As do I.  My preference for rules is:

- Always use } // namespace Foo comments with namespaces.

- Always use #endif // ENABLE(FOO) comments if there are more than 10-15 
lines  of code between the matching #if/#else/#elif, or if the #endif is 
nested.  But  do not treat it as a warning/error if an #endif macro has a 
well-formed comment  and doesn't obey the 'required' rules in the previous 
sentence (unless this inconsistency would drive anyone nuts).


I like both of these comments for the following reasons:


- You don't have to scroll up or otherwise jump around the source to know 
what the right curly brace or the #endif macro is used for.

In the namespace case, the block almost always spans most of the file, so 
there's rarely a case when it's less than 10 lines away from the left 
curly brace.  Or to put it another way, the namespace Foo { line is always 
near the top of the file, and the } // namespace Foo line is always near the 
bottom of the file, so it's rare that you see them both at the same time.

In the case of the #endif macro, I find that the comments are useful if 
the corresponding #if/#else/#elif is more than 10-15 lines away (e.g., more 
than 
a screenful), or if there is any #if macro nesting such that #endif statements 
can appear next to each other (see Platform.h).


- When merging, having these comments are a great help to both the person 
doing the merge and to merge algorithms.

New methods are often added near the end of a namespace, which means the } 
for the end of the method looks the same as the } for the end of a 
namespace (especially with our current namespace indent rules), so merges with 
conflicts sometimes end up repurposing the namespace curly brace for the end 
of a new method.  Providing an explicit comment prevents this behavior, and 
provides a common anchor point in both the original (ours) and new (theirs) 
files.

Likewise, #endif macros (especially when grouped together due to nesting) 
will frequently get repurposed by merge algorithms.  This can create more 
work (especially the way some macros are nested in Platform.h) if there are 
changes to both files being merged.

--

On a related note, I think we should also define rules for indenting #if 
macros.  I think this is orthogonal to using comments, though, and I prefer 
having comments regardless of the indent rules.

Note that macro indenting has already started (haphazardly) in Platform.h 
and perhaps a few other places.

Here are some examples:

#if ENABLE(FOO)
#if PLATFORM(BAR)
#if USE(BAZ)
...
#else
...
#endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
# if PLATFORM(BAR)
#  if USE(BAZ)
...
#  else
...
#  endif // USE(BAZ)
# endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
#if PLATFORM(BAR)
  #if USE(BAZ)
...
#else
...
  #endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

My original opinion was to never indent macros, but after staring at the 
above examples, I do think indenting makes them easier to read.  I'm still 
trying to decide whether I like the # anchored on the left or whether I 
prefer 
it anchored to if/else/elif/endif macro names, though.

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


Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)

2010-07-27 Thread David Kilzer
On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak m...@apple.com wrote:

 The main problem would be getting the right path to the script file. Unless 
 we duplicate it in every directory with script tests, it kinda has to be a 
 relative path that depends on the directory.

Subversion (and git) handle relative symbolic links just fine, so that is 
another option.

Dave
--
Sent from my iPhone 4

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


Re: [webkit-dev] review queue crazy idea

2010-07-22 Thread David Kilzer
We should also publicize/update these existing resources to help patch authors 
find reviewers for their patches:

http://trac.webkit.org/wiki/CodeReview
http://trac.webkit.org/wiki/WebKit%20Team

I think the most effective approach is when patch authors proactively seek out 
reviewers.  We're all busy, but when I'm asked to review a patch, I make time 
for it or point the person at another reviewer.

Dave
--
Sent from my iPhone 4

On Jul 22, 2010, at 12:29 AM, Maciej Stachowiak m...@apple.com wrote:

 
 On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:
 
 Wow.  I really like this idea of helping contributors better
 understand what's going wrong.
 
 But, I think that even better would be to build a better front-end for
 reviews.  Or a bot which knew how to suggest reviewers (based on
 annotate information from lines changed).
 
 
 I think a better UI for reviews, plus some better attempts at active 
 notification of potential reviewers, could go a long way. I'm a strong 
 believer in trying nudges and positive incentives before implementing harsher 
 policies.
 
 Regards,
 Maciej
 
 ___
 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] DerivedSources.make CPP DOM Bindings

2010-07-09 Thread David Kilzer
On Jul 8, 2010, at 11:04 AM, Kevin Ollivier kev...@theolliviers.com wrote:

 I'm working on making the CPP DOM bindings accessible to the wx port, and 
 while I've got the whole thing building, one thing I have yet to sort out is 
 how to add building of the CPP DOM bindings to the build system. 
 DerivedSources.make seems to be the appropriate place to put the code, and 
 it's where I've put things for now, but I wasn't sure if others would feel 
 this is the right place.

DerivedSources.make is the appropriate place for this.

 If I do add it, what is the appropriate way to do it? Should generation be 
 conditional on some define the port will set, like MAKE_CPP_BINDINGS, or 
 should we just directly check for BUILDING_PORT defines?

I would use BUILDING_PORT for now until such time as another port wants to 
enable it.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

2010-07-09 Thread David Kilzer
On Jul 9, 2010, at 7:34 AM, Adam Roben aro...@apple.com wrote:

 On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:
 
 Should we keep the master bug?
 
 Should we use it only for our implementation efforts and not
 make it depend on every random bug filed for the MathML
 component?
 
 I think an important question to ask is, When will you move the master bug 
 to Resolved/Fixed? This is basically another way of saying, What task(s) 
 does the master bug represent? Once you know that answer, the answers to 
 your other questions may be obvious.

IMO, it should be closed once MathML is enabled in the WebKit nightly builds 
and/or most ports.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Should Table Cell (TD) children inherit height?

2010-06-28 Thread David Kilzer
How do Firefox and MSIE render the test case?

Dave
--
Sent from my iPhone 3GS

On Jun 28, 2010, at 11:42 AM, Fady Samuel fsam...@chromium.org wrote:

 My understanding is that in quirks mode, table height=100% causes the 
 table to fill the entire client window. Now, I believe the height attribute 
 should trickle down to the TR and TD tags, correct? What about children of a 
 TD tag? If you add an empty div child to a table, should it fit the whole 
 cell, or should it have a size of 0?
 
 
 table width=100% border=0 style=height:100%;
 tr
 td style=background-color: red;
   div id=drawing style=background-color: green;/div
 /td
 /tr
 /table
 
 
 WebKit will show you red instead of green because the div does not have a 
 height of 100%.
 
 Now if you make the div's height 100%, you get green. 
 
 Should a cell's child inherit height?
 
 Thanks,
 
 Fady Samuel

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


Re: [webkit-dev] strategy for evaluating performance issues related to memory.

2010-06-21 Thread David Kilzer
On Jun 21, 2010, at 6:21 AM, Mike Marchywka marchy...@hotmail.com wrote:

 (and yes my disk light still comes on for minutes at a time locking me out of 
 doing antyhing with iceweasel or firefox)

Two things:

1. What hardware platform and O/S are you running a WebKit browser on that 
still uses a disk light?  (Do PC cases still have disk lights?  I guess I 
haven't looked recently.)

2. Why do you keep mentioning Iceweasel and Firefox?  Those browsers are based 
on Mozilla's Gecko engine, not WebKit.

Dave

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


Re: [webkit-dev] LayoutTest with a fragment reported as the document URL?

2010-06-10 Thread David Kilzer
I think you want:

window.location.hash = 'name1';

I'm sure there are other layout tests that set the hash property, so you might 
search for them to get some ideas about how to build your test.

Dave
--
Sent from my iPhone 3GS

On Jun 7, 2010, at 2:04 PM, Chris Fleizach cfleiz...@apple.com wrote:

 
 I'd like the loaded page to be a url like
 
 http://layouttest/new-test.html#segment
 
 so that
 
 m_renderer-document()-url();
 
 returns http://layouttest/new-test.html#segment
 
 
 On Jun 7, 2010, at 1:27 PM, Adam Barth wrote:
 
 I'd like to help you, but I don't know what you mean by the
 document's URL will be reported as.  Reported to whom via what?
 
 Adam
 
 
 On Mon, Jun 7, 2010 at 12:37 PM, Chris Fleizach cfleiz...@apple.com wrote:
 Hello,
 I need to write a layout test where the document's URL will be reported as
 http://layouttest/new-test.html#segment
 I tried
 window.location = url + #name1;
 but that doesn't work
 any ideas?
 thanks
 ___
 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] WebCore Build Times

2010-06-08 Thread David Kilzer
On Jun 8, 2010, at 3:17 PM, Eric Seidel e...@webkit.org wrote:

 On my Intel Core 2 Duo MBP a full build takes over 1 hour.  5 years
 ago, on my g4 laptop a full build took around 40m.  :(  We seem to be
 slowly moving in the wrong direction.

Was that before or after SVG was enabled in the engine?  :)  In general, I 
think the amount of code in WebCore has increased since 2005, which probably 
has more of an affect than unused headers.

Having said that, I thought it would be useful to write a script that would 
remove individual headers on a file-by-file basis and recompile WebKit to find 
unused header candidates.  I haven't had time to write such a script, though.

Dave

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


Re: [webkit-dev] Directory upload experimental feature

2010-06-03 Thread David Kilzer
Also, I was simply pointing out existing behavior, not arguing for/against the 
zip file format.

Dave





From: Sam Weinig sam.wei...@gmail.com
To: David Kilzer ddkil...@webkit.org
Cc: John Gregg john...@google.com; webkit-dev@lists.webkit.org; Adele 
Peterson ad...@apple.com
Sent: Wed, June 2, 2010 11:28:11 AM
Subject: Re: [webkit-dev] Directory upload experimental feature

I think this is only true for Mac OS X style bundles, not all folders.


On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer ddkil...@webkit.org wrote:

 Other alternatives?


I believe Safari will zip a folder and send it as a single file for you if you 
attach a folder to a file upload element instead of an individual file.


Dave






From: John Gregg john...@google.com
To: Sam Weinig sam.wei...@gmail.com
Cc: webkit-dev@lists.webkit.org
Sent: Tue, June 1, 2010 3:09:00 PM
Subject: Re: [webkit-dev] Directory upload experimental feature


My proposal for that is that all the files would be listed in the form 
submission the same way as if it were a input type=file multiple, but in 
the Content-Disposition header, the filename component would contain the path 
information. 


One alternative idea would be add a path component to the 
Content-Disposition header alongside the filename which remains unchanged, but 
I think that would be a much more difficult approach.  Other alternatives?


Example follows.


 -John



If you are have these files
/home/John/photos/vacation/1.jpeg
/home/John/photos/vacation/2.jpeg

/home/John/photos/conference/1.jpeg


and choose photos from the directory picker, you'd end up with
input.files[0].name = 1.jpeg
input.files[0].path = photos/vacation/1.jpeg
input.files[1].name = 2.jpeg
input.files[1].path = photos/vacation/2.jpeg
input.files[2].name = 1.jpeg
input.files[2].path = photos/conference/1.jpeg


Your POST would look like
Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo


WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; filename=photos/vacation/1.jpeg
Content-Type: image/jpeg


contents


WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; filename=photos/vacation/2.jpeg
Content-Type: image/jpeg


contents


WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; 
filename=photos/conference/1.jpeg
Content-Type: image/jpeg


contents




On Sat, May 29, 2010 at 10:22 AM, Sam Weinig sam.wei...@gmail.com wrote:

How will the directory structure and all the files therein be represented in 
the form submission?


-Sam


On Fri, May 28, 2010 at 3:17 PM, John Gregg john...@google.com wrote:

Hi WebKit,


I recently proposed adding directory upload support to HTML via a new 
input attribute to whatwg@, and the discussion arrived at try it out.  
Having written some code I think I have something that works pretty well, 
and I'd like to land it on an experimental basis in WebKit, but want to 
reach out early before trying to put any code in the tree.  The plan that 
comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open 
to other options.


Background (cf. the whatwg thread 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html): 
 - The use case for this is a photo album or file manager web application, 
 which wants the user to easily choose an entire directory to recursively 
 upload, while preserving the sub-directory structure.
 - The reason for the new attribute is to signal the UA to show a native 
 folder-picker rather than a file-picker, which on most OSs are two distinct 
 dialogs.
 
The approach I'm using has 2 parts and is a small amount of WebCore code 
(about 200 lines).
 - Extend HTMLInputElement to support the directory attribute, which is 
 passed up via FileChooser allowing the UA to display a folder-picker.  UA 
 enumerates all the files and returns them in the normal way.
 - Extend File to have a File.path property, which contains the path 
 information starting from the chosen directory as the root.  
 HTMLInputElement is responsible for generating these values from the list 
 of files when the directory attribute is set.


Thoughts? 


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


Re: [webkit-dev] Directory upload experimental feature

2010-06-02 Thread David Kilzer
 Other alternatives?

I believe Safari will zip a folder and send it as a single file for you if you 
attach a folder to a file upload element instead of an individual file.

Dave





From: John Gregg john...@google.com
To: Sam Weinig sam.wei...@gmail.com
Cc: webkit-dev@lists.webkit.org
Sent: Tue, June 1, 2010 3:09:00 PM
Subject: Re: [webkit-dev] Directory upload experimental feature

My proposal for that is that all the files would be listed in the form 
submission the same way as if it were a input type=file multiple, but in 
the Content-Disposition header, the filename component would contain the path 
information. 

One alternative idea would be add a path component to the Content-Disposition 
header alongside the filename which remains unchanged, but I think that would 
be a much more difficult approach.  Other alternatives?

Example follows.

 -John


If you are have these files
/home/John/photos/vacation/1.jpeg
/home/John/photos/vacation/2.jpeg
/home/John/photos/conference/1.jpeg

and choose photos from the directory picker, you'd end up with
input.files[0].name = 1.jpeg
input.files[0].path = photos/vacation/1.jpeg
input.files[1].name = 2.jpeg
input.files[1].path = photos/vacation/2.jpeg
input.files[2].name = 1.jpeg
input.files[2].path = photos/conference/1.jpeg

Your POST would look like
Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo


WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; filename=photos/vacation/1.jpeg
Content-Type: image/jpeg

contents

WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; filename=photos/vacation/2.jpeg
Content-Type: image/jpeg

contents

WebKitFormBoundaryFoo
Content-Disposition: form-data; name=input; 
filename=photos/conference/1.jpeg
Content-Type: image/jpeg

contents



On Sat, May 29, 2010 at 10:22 AM, Sam Weinig sam.wei...@gmail.com wrote:

How will the directory structure and all the files therein be represented in 
the form submission?


-Sam


On Fri, May 28, 2010 at 3:17 PM, John Gregg john...@google.com wrote:

Hi WebKit,


I recently proposed adding directory upload support to HTML via a new input 
attribute to whatwg@, and the discussion arrived at try it out.  Having 
written some code I think I have something that works pretty well, and I'd 
like to land it on an experimental basis in WebKit, but want to reach out 
early before trying to put any code in the tree.  The plan that comes to mind 
is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open to other 
options.


Background (cf. the whatwg thread 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html): 
 - The use case for this is a photo album or file manager web application, 
 which wants the user to easily choose an entire directory to recursively 
 upload, while preserving the sub-directory structure.
 - The reason for the new attribute is to signal the UA to show a native 
 folder-picker rather than a file-picker, which on most OSs are two distinct 
 dialogs.
 
The approach I'm using has 2 parts and is a small amount of WebCore code 
(about 200 lines).
 - Extend HTMLInputElement to support the directory attribute, which is 
 passed up via FileChooser allowing the UA to display a folder-picker.  UA 
 enumerates all the files and returns them in the normal way.
 - Extend File to have a File.path property, which contains the path 
 information starting from the chosen directory as the root.  
 HTMLInputElement is responsible for generating these values from the list of 
 files when the directory attribute is set.


Thoughts? 


Thanks, 
 -John



___
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] svn-apply: ideal fuzz value to merge changelogs

2010-05-27 Thread David Kilzer
Providing 8 lines of context instead of 3 lines to the ChangeLog part of a 
patch isn't going to help with reviewing or merging patches.  If you want to 
provide more context to the rest of the patch, I think you should find a way to 
keep the number of lines of context for ChangeLog diffs to 3 lines.  (Perhaps 
git has some way to provide per-file settings for the diff command, much like 
it does for the merge driver in .gitattributes?)

It's unfortunate that git doesn't include -U8 in the diff --git a/foo b/foo 
line in the patches it generates.  If it did, then the tools could be updated 
to parse the number of lines of context and use that in the patch command.

Dave





From: tonikitoo (Antonio Gomes) toniki...@gmail.com
To: webkit-dev Development webkit-dev@lists.webkit.org
Sent: Mon, May 24, 2010 11:55:03 AM
Subject: [webkit-dev] svn-apply: ideal fuzz value to merge changelogs

Hi.

Lately I've noticed that most of my patches uploaded to bugzilla could
not get processed by any of the EWS bots at all (see purple balloons
in https://bugs.webkit.org/show_bug.cgi?id=36463 , for example). Chris
Jerdonek guess that I was generating my patches with special
parameters that were making svn-apply to fail to apply them, and it
seems he was right: as an attempt to give reviewers more context to
review my patches I will generating them with 8 lines of context.

$ git format-patch -1 HASH_OF_THE_PATCH -U8

According to him, ... the ChangeLog diffs are applied with fuzz=3
to allow the patch to apply (and be inserted at the top) ..., and so
my 8-lines context'ed patches are failing to apply due to that.
Options that were given to me are:

* generate myself a diff that has 3 lines of context just for the ChangeLog part
* change the fuzz=3 to fuzz=8 in svn-apply for ChangeLogs.

I support the later, but before anything I would like to know if you
guys have any objection? known issues?

Cheers,

-- 
--Antonio Gomes
___
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] webkit-patch, check-webkit-style and git now support --squash and --git-commit

2010-05-14 Thread David Kilzer
On Fri, May 14, 2010 at 6:29:05 PM, Ojan Vafai wrote:

 tonikitoo, aroben, ddkilzer: You are the three who I remember
 voicing yourselves about wanting webkit-patch to support
 committing/uploading multiple patches from the same branch.
 Would Chris's suggestion below (last couple paragraphs) be
 acceptable to you? I prefer it as it makes webkit-patch less
 confusing to people who aren't very comfortable with git, but
 it does not 100% meet the needs you've asked for in the past.


Since webkit-patch doesn't meet my needs for posting a patch series to a 
single bug today, I have no opinion either way on the matter other than 
simpler is better, so I would support Chris' suggestion.

Personally, I don't see why both models (single patches and multiple patches) 
couldn't be supported based on the arguments passed to webkit-patch.  git 
itself seems to be able to figure out if the user is referring to a single 
commit or a series of commits (based on the context of the command-line 
arguments and what the command does), so I don't see why we have to introduce 
additional command-line switches for various behavior. (See the git-send-email 
command as an example since it's designed to send email for a single patch or a 
series of patches.)

In my opinion, webkit-patch should default to single commit behavior unless the 
user specifies a range.  That way, git neophytes and the majority of existing 
users get the single-commit-to-a-single-bug behavior by default.  However, if a 
range of commits is given, then webkit-patch would be smart enough to post the 
series of patches to a single bug.

Dave

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


Re: [webkit-dev] Yet another bug-less change hosed the tree.

2010-05-12 Thread David Kilzer
On Tue, May 11, 2010 at 2:30:45 PM, Geoffrey Garen wrote:

 I don't know how to do either of these steps in an easy way:
 
 1. Once I have a patch with a ChangeLog, say, File a new 
 bug and upload this patch for review. (Bonus points if the
 tool automatically made the first line of the ChangeLog the
 title of the bug.)


The little-known, little-used webkit-patch create-bug command does this today 
with the --no-prompt switch.  However, you can't limit it to a single 
directory for svn (like other webkit-patch commands), you can't give it a patch 
file to upload (interesting idea), and it's probably only been tested (by me) 
with git.

The webkit-patch upload command is the preferred alternative, although it 
still doesn't have a way to make the first line of the ChangeLog the title of 
the bug (which is the main reason I haven't switched to using it), and it has 
over 3x the number of command-line switches as create-bug.  (I must read 
through the switches for any webkit-patch subcommand because I don't use it 
frequently enough to remember them.)

 2. Once the patch has been reviewed, say, Add bug # and
 reviewer information from Bugzilla, commit, and close the
 bug. (Bonus points if the commit happens via the bugzilla 
 patch, so I can move on to working on another patch.)

My initial thought for doing this was to provide a placeholder (like 
http://webkit.org/b/0;) with prepare-ChangeLog so that webkit-patch could 
update it at the right time, just like it does with the reviewer.

Another approach would be to write a rule that adds the bug number at a 
particular location in the ChangeLog each time--as long as it was smart enough 
not to duplicate bug links if one was already present.

Dave

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


Re: [webkit-dev] Bugzilla Triaged keyword

2010-04-27 Thread David Kilzer
I've renamed Triaged to QtTriaged.

Dave



- Original Message 
 From: Jocelyn Turcotte jocelyn.turco...@nokia.com
 To: webkit-dev@lists.webkit.org
 Sent: Tue, April 27, 2010 10:02:36 AM
 Subject: Re: [webkit-dev] Bugzilla Triaged keyword
 
 On 4/27/2010 5:38 PM, ext Alexey Proskuryakov wrote:
 27.04.2010, в 
 00:56, Tor Arne Vestbø написал(а):


 
 As far as I know QtWebKit uses this keyword to indicate that the
 
 corresponding bug has been checked and prioritized based on its 
 severity
 by a triaging group of two QtWebKit 
 developers.

 
 href=https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs; target=_blank 
 https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs
  
   
 That's correct. It's an attempt at using 
 Bugzilla for all our bugs, and to manage them with some sense of control 
 over 
 what's there :)
  
 I can imagine ongoing 
 confusion about this keyword. Would it makes sense to rename to something 
 like 
 QtTriaged?


If you believe that for other ports 
 it will bring more confusion than 
use, then please do 
 so.

Jocelyn

___
webkit-dev 
 mailing list

 href=mailto:webkit-dev@lists.webkit.org;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] Buildbot Updates

2010-04-13 Thread David Kilzer
On Tue, April 13, 2010 at 9:02:39 AM, William Siegrist wrote:


 Our buildbot master has been updated to the latest python and buildbot 
 versions. 
 We also have new Qt bots per the previous webkit-dev thread as well as a bot 
 using new-run-webkit-tests (mac-leopard). Let me know if you see any 
 anomalies 
 with the new setup. 


Thanks Bill!

Dave

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


Re: [webkit-dev] Git meeting notes

2010-04-12 Thread David Kilzer
It's not immediately clear how to sort a list of commit hashes into a 
sequential list, e.g., if using a list of nightly builds for a binary 
regression search.

Perhaps there is a git command that sorts them for you given an existing 
repository?

Dave



On Mon, April 12, 2010 at 8:15:40 PM, Timothy Hatcher wrote:

 Only the first 5-7 characters are needed to identify a single commit (enough 
 of 
 the hash prefix to be unique). So REGRESSION(96c3b0) vs 
 REGRESSION(r12345).

On Apr 12, 2010, at 6:28 PM, Alexey Proskuryakov 
 wrote:

 One thing that wasn't mentioned at the meeting is that git 
 doesn't seem to have the same monotonously increasing revision numbers as svn 
 does. It will be a problem to replace REGRESSION(r12345) with 
 REGRESSION(96c3b0300ccf16b64efc260c21c85ba9030f2e3a).

— Timothy 
 Hatcher


___
webkit-dev 
 mailing list

 href=mailto:webkit-dev@lists.webkit.org;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] Proposal: commit-queue to fix usernames after commit

2010-04-12 Thread David Kilzer
On Mon, April 12, 2010 at 4:56:51 PM, Eric Seidel wrote:


 I would love to hear your feedback!

Sounds great!

Dave

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


Re: [webkit-dev] Git meeting notes

2010-04-12 Thread David Kilzer
Sure, but you have to rebuild WebKit for each test during the git-bisect.  
Being able to use pre-built binaries is faster, especially if they're already 
downloaded.

Dave


From: Daniel Cheng dch...@chromium.org
To: David Kilzer ddkil...@webkit.org
Cc: Timothy Hatcher timo...@apple.com; Alexey Proskuryakov 
a...@webkit.org; WebKit Development webkit-dev@lists.webkit.org
Sent: Mon, April 12, 2010 9:07:13 PM
Subject: Re: [webkit-dev] Git meeting notes

git-bisect can be used for a binary regression search.


Daniel

On Mon, Apr 12, 2010 at 9:05 PM, Daniel Cheng dch...@google.com wrote:

git-bisect can be used for a binary regression search.


Daniel



On Mon, Apr 12, 2010 at 8:45 PM, David Kilzer ddkil...@webkit.org wrote:


It's not immediately clear how to sort a list of commit hashes into a 
sequential list, e.g., if using a list of nightly builds for a binary 
regression search.

Perhaps there is a git command that sorts them for you given an existing 
repository?

Dave




On Mon, April 12, 2010 at 8:15:40 PM, Timothy Hatcher wrote:

 Only the first 5-7 characters are needed to identify a single commit 
 (enough of
 the hash prefix to be unique). So REGRESSION(96c3b0) vs
 REGRESSION(r12345).

On Apr 12, 2010, at 6:28 PM, Alexey Proskuryakov
 wrote:

 One thing that wasn't mentioned at the meeting is that git
 doesn't seem to have the same monotonously increasing revision numbers 
 as svn
 does. It will be a problem to replace REGRESSION(r12345) with
 REGRESSION(96c3b0300ccf16b64efc260c21c85ba9030f2e3a).

— Timothy
 Hatcher


___
webkit-dev
 mailing list

 href=mailto:webkit-dev@lists.webkit.org;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


[webkit-dev] git.webkit.org is missing svn revision r49890

2010-03-16 Thread David Kilzer
It was discovered recently that the git repository on git.webkit.org is missing 
svn revision r49890.  http://trac.webkit.org/changeset/49890

This causes problems if you're using a single git repository, pulling from 
git.webkit.org, and using git-svn-fetch from svn.webkit.org (so that you can 
push commits back to the svn repository from your git repo).

Fixing git.webkit.org to include the missing revision will be disruptive for 
anyone pulling from the repository, but it would be more correct than leaving 
it alone.

Please add comments to this bug instead of replying to this message:

git.webkit.org repository is missing svn revision r49890
https://bugs.webkit.org/show_bug.cgi?id=36193

Thanks.

Dave

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


Re: [webkit-dev] changelogs: a reprise

2010-01-28 Thread David Kilzer
On Thu, January 28, 2010 at 4:10:11 AM, Chris Jerdonek wrote:


 On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer wrote:
  (2) Consider phasing in support for an alternate workflow where new
  ChangeLog entries for the next commit are stored separately from the
  versioned ChangeLog files -- perhaps in individual .changelog files
  for Subversion users and in the commit message for Git users.
 
  I'm not a big fan of wrapper scripts, mostly because I'll probably
  forget about using them since I'm so used to using the basic
  git/svn commands.  (I guess svn-create-patch is a counter-argument
  to that, but I rarely use svn directly anymore.)
 
  Using .changelog-bugnum files should probably be optional if it's
  implemented, e.g., tools should still be smart enough (or at least
  as smart as they are today) to operate on ChangeLog files directly
  if developers choose to continue doing that.  I say that because
  once there is a git merge driver for ChangeLog files, the need for
  an alternative ChangeLog workflow drops to zero, at least for me.
 
 I ran into an issue today where git diff didn't generate me a patch
 with the ChangeLog portion in the standard format.  Namely, the
 ChangeLog diff had non-empty leading context (which can happen since
 it doesn't run fixChangeLogPatch like the svn-create-patch wrapper
 script).  Is there a way to address this issue for Git users without
 using wrapper scripts or a change to the ChangeLog workflow?


I'm not sure if there is a way to fix up patches when they're created using 
git-diff, e.g., some kind of diff hook.  Note that there is no loss of 
information if a ChangeLog patch isn't fixed up immediately after it's 
created, so the fix-up can always happen when the patch is applied later.  It 
just looks a little ugly in the meantime.  :)

I also replied with more thoughts in Bug 32834.

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

Dave

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


Re: [webkit-dev] Signing up to help with some SVG bugs

2010-01-28 Thread David Kilzer
To contributed to WebKit, see:  http://webkit.org/coding/contributing.html

To contact other developers, see:  http://webkit.org/contact.html

Dave


From: Mark Wyszomierski mar...@gmail.com
To: webkit-dev@lists.webkit.org
Sent: Thu, January 28, 2010 8:24:48 PM
Subject: [webkit-dev] Signing up to help with some SVG bugs

Hi,


I am experiencing a bug with the SVG module, I believe defined by the 
following two bug entries:


  https://bugs.webkit.org/show_bug.cgi?id=34301
  https://bugs.webkit.org/show_bug.cgi?id=17043


The problem I'm having is that creating an animateMotion element in 
javascript will never get executed (works fine if defined in the body of the 
document though). So issue #17043 states that there is a missing idl file for 
animateMotion. I am guessing this is why elements created via javascript do 
nothing.


That issue hasn't been updated since 2008, I'm wondering if I can help out 
with it? Is there a group already focusing on the SVG module? I'd like to help 
out with some of these other bugs SVG bugs too. I'm not sure how people are 
organizing themselves to tackle bugs with webkit, if there is another method 
for helping out, please let me know,


Thanks,
Mark



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


Re: [webkit-dev] changelogs: a reprise

2010-01-26 Thread David Kilzer
On Mon, January 25, 2010 at 10:35:00 PM, Chris Jerdonek wrote:

 I was reading through the old I HATE CHANGELOGS messages from August:
 
 https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html
 
 The discussion attracted a lot of interest and ideas, but it looks
 like it died out without reaching any conclusion.
 
 It seems like the tools around ChangeLogs have improved somewhat since
 then, but we still have, for example, the fundamental
 conflict-on-commit annoyance.
 
 What do people think about these two possibilities for short- and
 mid-term strategies, respectively?
 
 (1) Provide a simple wrapper around svn commit and git svn dcommit
 that encapsulates the retry logic in case of ChangeLog conflicts.
 This way, the end-user will never have to resolve ChangeLog conflicts
 on commit.  Higher-level commands like webkit-patch could use this
 under the hood, if they wanted, to cope with race conditions.
 
 (2) Consider phasing in support for an alternate workflow where new
 ChangeLog entries for the next commit are stored separately from the
 versioned ChangeLog files -- perhaps in individual .changelog files
 for Subversion users and in the commit message for Git users.  The
 commands in (1) would be smart enough to read the new ChangeLog
 information from these alternate locations, and then add the ChangeLog
 information to the ChangeLog files at the last moment -- prior to
 commit.  Users of this workflow would never have to resolve ChangeLog
 conflicts during the review process, since new entries are stored
 separately.  It may be easiest to support this new workflow for Git
 users first.
 
 The second idea is essentially Ojan's proposed modification of one of
 Maciej's ideas:
 
 https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html
 
 It is a mid-term rather than short-term strategy since it involves
 changes to several scripts (e.g. svn-create-patch) to allow the review
 process to support this alternate workflow.


I think I mentioned this before, but for git users, this can be solved in the 
short term by a merge driver that uses resolve-ChangeLogs (once it knows how to 
be invoked by git as a merge driver):

http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers


I started hacking on resolve-ChangeLogs to be invoked by three arguments this 
way, but haven't had time to finish it.

I'm not a big fan of wrapper scripts, mostly because I'll probably forget about 
using them since I'm so used to using the basic git/svn commands.  (I guess 
svn-create-patch is a counter-argument to that, but I rarely use svn directly 
anymore.)

Using .changelog-bugnum files should probably be optional if it's implemented, 
e.g., tools should still be smart enough (or at least as smart as they are 
today) to operate on ChangeLog files directly if developers choose to continue 
doing that.  I say that because once there is a git merge driver for ChangeLog 
files, the need for an alternative ChangeLog workflow drops to zero, at least 
for me.

Dave

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


Re: [webkit-dev] Showing Baseline and Container Box

2010-01-25 Thread David Kilzer
On Mon, January 25, 2010 10:42:56 AM, Alex Milowski wrote:

 On Mon, Jan 25, 2010 at 10:31 AM, Maciej Stachowiak wrote:
 
  It's reasonable to use an ENABLE() flag for debugging features like this, 
  in 
 my opinion. I don't know if we have any direct precedent.
 
 Doesn't ENABLE() require a feature define?


No, not necessarily.  If the ENABLE() macro doesn't require something like a 
different set of export symbols on Mac OS X builds, then you don't have to do 
the whole feature define thing.  Some ENABLE() macros are only defined in 
JavaScriptCore/wtf/Platform.h.

If the macro resides in just one source file, I've seen render tree debugging 
macros added to just the source file and defined at the top.  (If you can get 
by with putting the macro in one header file, that would work as well.)

Dave

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


Re: [webkit-dev] webkit team wiki page

2010-01-24 Thread David Kilzer
On Sun, January 24, 2010 at 7:09:26 PM, Maciej Stachowiak wrote:

 I think deleting the areas of knowledge is a regrettable loss of information. 
 I 
 think it's helpful to give people at least a few starting points for their 
 questions, because not everyone is going to be comfortable firing random 
 questions at IRC, and svn blame i not a very useful tool if you don't know 
 the 
 code very well yet. Further, even for experienced contributors, I think this 
 information could be useful as a guide to whom you might hassle to review 
 your 
 patch, if it doesn't get reviewed right away. I mean, I've been involved in 
 the 
 project for a pretty long time, and I can't honestly say I know the right 
 people 
 to ask for advice on every possible topic in the code, without a reference.


One possible alternative would be to update the bugs.webkit.org Component page 
with a list of reviewers by component:

https://bugs.webkit.org/describecomponents.cgi?product=WebKit

It puts the information closer to where it's needed.  The only down sides are 
that it's not necessarily easy to find (click on the link of the Component: 
label on any bug page) and it requires special access to bugs.webkit.org to 
edit the component descriptions.

Dave

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


Re: [webkit-dev] questions about allow-tabs

2010-01-15 Thread David Kilzer
On Fri, January 15, 2010 1:52:19 PM, Chris Jerdonek wrote:

 On Thu, Jan 14, 2010 at 9:05 PM, David Kilzer wrote:
  On Thu, January 14, 2010 at 6:59:17 PM, Chris Jerdonek wrote:
  While I'm asking, I might as well also ask -- what other subversion
  properties do we use?
 
 
  In the past, svn:eol-style has been applied so that when files are checked 
  out 
 on Windows, they have the proper line endings.  There is also a concerted 
 effort 
 to keep svn:mime-type set correctly on *-expected.png results for pixel tests 
 committed via git.
 
 Thanks a lot for the response, David.  To add to the list,
 svn:executable is another one.


Yes, scripts don't work very well without execute permissions.  :)

However, the git-svn script is smart enough to set that one, though.  The 
others you don't get for free when using git to push patches to an svn 
repository.

Dave

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


Re: [webkit-dev] webkit.org/pending-review

2010-01-14 Thread David Kilzer
I'm pretty sure it's set up as a redirect in the Apache config for webkit.org.

$ curl -I http://webkit.org/pending-review
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Jan 2010 17:19:39 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 
mod_python/3.3.1 Python/2.5.4
Location: 
https://bugs.webkit.org/request.cgi?action=queuerequester=product=type=reviewrequestee=component=group=requestee
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

Based on the web form, I don't see a way to filter out commit-queue? 
attachments while keeping request? flagged attachments, though.

Dave



- Original Message 
 From: Eric Seidel e...@webkit.org
 To: WebKit Development webkit-dev@lists.webkit.org
 Sent: Thu, January 14, 2010 12:25:15 AM
 Subject: [webkit-dev] webkit.org/pending-review
 
 Oliver Hunt mentioned this evening that he found the
 webkit.org/pending-review page confusing because it lists both
 commit-queue? patches and review? patches.  I agreed.
 
 I filed https://bugs.webkit.org/show_bug.cgi?id=33656 to track
 updating /pending-review to more modern review URL and made some
 possible suggestions as to better URLs.  Maciej is the man with the
 real URL magic though. :)
 
 I'm not sure how /pending-review is managed, it does not seem to be
 stored in WebKitSite/, perhaps someone on this list would know how to
 change it?  Or would maybe folks have their own suggestions as to what
 URL we should use for /pending-review (if so please update the bug).
 
 /pending-review is used by http://nightly.webkit.org/start and may be
 linked to from other places in the site, I don't know.
 
 -eric
 ___
 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] questions about allow-tabs

2010-01-14 Thread David Kilzer
On Thu, January 14, 2010 at 6:59:17 PM, Chris Jerdonek wrote:
 I have some background questions about the allow-tabs property.  I
 imagine it pre-dates check-webkit-style by quite a while.
 
 (1) What's the reason and history behind our use of the property?


The allow-tabs property (and the svn commit pre-hook) are the ultimate in style 
enforcement.  The project didn't want tabs in source files (or ChangeLog files) 
committed accidentally, so any file with tabs needs the special allow-tabs svn 
property set.

 (2) What component actually does the pre-commit check?  I didn't find
 a reference to allow-tabs in WebKitTools/, but maybe I searched
 incorrectly.


It's on the server itself.  I don't think it's available from the repository.

 (3) Roughly speaking, how many and what types of files have the property set?


Mostly test files and (potentially) legacy source files are the only ones with 
the property set.

 (4) Are there any issues to be aware of with it when using a Git
 repository for development?


No, just that you won't be able to use git svn dcommit when committing new 
files with tabs (or adding tabs to existing files).

 While I'm asking, I might as well also ask -- what other subversion
 properties do we use?


In the past, svn:eol-style has been applied so that when files are checked out 
on Windows, they have the proper line endings.  There is also a concerted 
effort to keep svn:mime-type set correctly on *-expected.png results for pixel 
tests committed via git.

Dave

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


Re: [webkit-dev] File::Spec-tmpdir() on Leopard and Snow Leopard bots

2010-01-08 Thread David Kilzer
On Fri, January 8, 2010 at 12:39:41 AM, Andras Becsi wrote:

   in the process of making it possible to run more than one instance of 
 run-webkit-tests at the same time 
 (https://bugs.webkit.org/show_bug.cgi?id=33153), I'm trying to make the 
 handling 
 of running httpd processes more platform independent.
 My tries failed only on the Leopard bots. Unfortunately I have no access to a 
 Leopard machine, so I had to guess, but now I have a strong supposition why 
 the 
 new script fails.
 The Leopard bots (Leopard and Snow Leopard) have set something like this: 
 TMPDIR=/var/folders/FF/FFsVLEwYHre8vU9Sax877k+++TI/-Tmp-/ shown in the bot 
 logs 
 (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/4018/steps/layout-test/logs/stdio).
 My assumption is, that calling File::Spec-tmpdir() in perl returns this 
 path, 
 not /tmp as expected, that is why there is no PID file where the script 
 expects 
 it to be (httpd.conf sets it to /tmp/WebKit).
 Is there any particular reason for setting a non-POSIX standard TMPDIR on 
 these 
 machines, especially because Tiger does not set this and thus has no problems 
 with File::Spec-tmpdir()? Or am I wrong with my assumption?


On Leopard and newer, the tmp directory under /var/folders is a per-user tmp 
directory (IIRC), which the Perl module apparently prefers over the shared tmp 
directory at /tmp.

If you read the man page for File::Spec, tmpdir() simply returns the first 
directory in a list, and its implementation is platform-specific.  It sounds 
like this method should not be used if there is code that expects the same 
directory to be returned on every platform.

Dave

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


Re: [webkit-dev] how to map local file extension to the MIMEType

2010-01-04 Thread David Kilzer
On Mon, January 4, 2010 at 5:19:46 PM, Fei Wang wrote:


 I define my own MIMEType like application/foo with file extension .foo. It 
 works 
 fine if I serve file through web server ( inside web server configuration, I 
 add 
 application/foo  foo to the mime type map). In the webkit, I modify the 
 MIMETypeRegistry.cpp file, add those MIMEType in. It works if I serve the 
 file 
 from webserver. 
 
 But it does not work if I want to open the file xxx.foo locally.
 
 I use build-webkit script to build it in my mac. But if I want to open safari 
 to 
 open local file with .foo extension, it grey out that file.
 
 Does anyone know how to add customized MimeType with local file extension to 
 the 
 webkit?


See:

WebCore/platform/MIMETypeRegistry.cpp
WebCore/platform/mac/MIMETypeRegistryMac.mm

Dave

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


Re: [webkit-dev] build system for wince port

2009-12-24 Thread David Kilzer
On Thu, December 24, 2009 at 1:51:43 AM, Patrick Roland Gansterer wrote:
 On Thu, Dec 24, 2009 at 02:53:18, Adam Barth:
  I'm worried that the port will rot without an active maintainer, no
  matter which build system you choose.
 If i choose my preferred solution, there will be many changes in the current 
 sln/vcproj/vsprops files. Who is maintaining this files at the moment? I'd 
 like to hear his/her opinion on this before.


You can use svn/git log to see who commits changes to these files.  I know 
Apple uses them for their Windows build, but we're on break until Jan 4, so 
please don't expect a reply until after that date.  (I don't work on the 
Windows port much, so I don't have an opinion about your proposal.)

Dave

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


Re: [webkit-dev] [webkit-changes] [52439] trunk/WebCore

2009-12-23 Thread David Kilzer
On Wed, December 23, 2009 at 4:34:06 AM, Evan Martin wrote:

 On Mon, Dec 21, 2009 at 12:20 PM, David Kilzer wrote:
  Setting [diff] renames = copies in ~/.gitconfig or in your
  .git/config file for each project will make git diff try to
  do rename detection when creating a patch.  (You may also
  use --find-copies-harder or --find-copies-harder -C 
  switches on the command line.)  This will provide hints in
  the git diff about file renames, but it still only uses a
  heuristic, and svn-apply currently doesn't know about these
  hints:
 
 This sort of thing has been a persistent problem for Chrome as well.
 
 Since our code review tool and our trybot also rely on SVN-specific
 features (including stuff like revprops, as well as the way it handles
 new files and renames), we are already doing work in multiple places
 to extend these tools to either understand git-style diffs or produce
 SVN-style diffs from Git.
 
 See for example GetMungedDiff in:
 http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/git-try?revision=34087view=markup
 
 One option I've been considering is extending git-svn to include a
 git svn diff that produces an SVN-style patch.  That would fix
 this problem at the source, at the cost of needing to retrain everyone
 to use it when submitting WebKit patches.  :\


Upstreaming a solution in git-svn would be great!  Does current svn (1.6?) add 
hints to its patches for moved and copied files?  How about moved/copied and 
then modified files?  Does it handle binary file diffs?

WebKitTools/Scripts/svn-create-patch was originally created to work around 
these deficiencies in plain svn-diff, and handles all of the above cases 
(although the binary diffs aren't efficient by any stretch).

Dave

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


Re: [webkit-dev] HELP - Need Information ****URGENT****

2009-12-22 Thread David Kilzer
Please stop sending these messages to webkit-dev.  They're getting through, but 
you're asking on the wrong list.

Try webkit-h...@lists.webkit.org instead.  You only need to post it once.  
Thanks.

Dave


From: R Kalyan r.kal...@tcs.com
To: webkit-dev@lists.webkit.org
Sent: Tue, December 22, 2009 6:53:28 AM
Subject: [webkit-dev] HELP - Need Information URGENT


Hi All, 

Can anyone let me know the institutes
offering training on Webkit across India.  We have very
urgent requirement to train few of our associates. 

Thanks  Regards, 
Kalyan 
9908800688 
 



=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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


Re: [webkit-dev] How to add a new interface for ObjC bindings?

2009-12-22 Thread David Kilzer
All the magic for the Obj-C DOM headers happens in:

WebCore/DerivedSources.make
WebKit/mac/MigrateHeaders.make

It should be added as a PrivateHeader first, if at all.  Someone else will have 
to address COM bindings since I don't know much about those.

Dave


From: Jian Li jia...@chromium.org
To: webkit-dev@lists.webkit.org
Sent: Tue, December 22, 2009 3:05:08 PM
Subject: [webkit-dev] How to add a new interface for ObjC bindings?

Hi,


I am working on adding Blob interface based on the latest File API spec. I 
have one question about the various kinds of bindings we need to put up for 
this new interface. I got JSC and V8 bindings generated and built 
successfully. I have some problem with ObjC bindings. What's the right 
procedure to add a new interface for ObjC bindings? I could see DOMBlob.h 
being created under Debug/DerivedSources/WebCore, but not under 
Debug/WebCore.framework/PrivateHeaders and Debug/WebKit.framework/Headers as 
other interfaces do. How could I change WebCore.xcodeproj to add the build 
steps for these? Any other things I need to pay attention to?


In addition, where do we use COM bindings? Is it only used when building 
WebKit under Windows?


Thanks,


Jian

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


Re: [webkit-dev] How to add a new interface for ObjC bindings?

2009-12-22 Thread David Kilzer
The Headers directory is for public API exposed by a framework on Mac OS X.  
The PrivateHeaders directory is a staging area for API that will be made public 
some day.  Note that WebCore.framework is not a public framework on Mac OS 
X--it's an implementation detail of WebKit.framework--so the only Headers 
(public API) directory between the two is WebKit.framework/Headers.

Since the DOMFile.h header is only in WebCore.framework/PrivateHeaders, you 
only have to worry about putting DOMBlob.h there as well.  The easiest way to 
do this is to look for every place the DOMFile.h header is referenced in 
WebCore.  This is a bit tricky since File is so generic, so let's use 
DOMFileList.h instead (and leave off the DOM prefix since that's added as 
needed):

$ grep -l -r FileList WebCore
WebCore/bindings/objc/DOMInternal.h
WebCore/ChangeLog
WebCore/ChangeLog-2008-08-10
WebCore/DerivedSources.cpp
WebCore/DerivedSources.make
WebCore/GNUmakefile.am
WebCore/html/File.h
WebCore/html/FileList.cpp
WebCore/html/FileList.h
WebCore/html/FileList.idl
WebCore/html/HTMLFormElement.cpp
WebCore/html/HTMLInputElement.cpp
WebCore/html/HTMLInputElement.h
WebCore/html/HTMLInputElement.idl
WebCore/page/Chrome.cpp
WebCore/page/DOMWindow.idl
WebCore/rendering/RenderFileUploadControl.cpp
WebCore/WebCore.order
WebCore/WebCore.pro
WebCore/WebCore.scons
WebCore/WebCore.vcproj/WebCore.vcproj
WebCore/WebCore.xcodeproj/project.pbxproj
WebCore/WebCoreSources.bkl

(Yes, I'm using an older tree because I'm in the middle of a bisect right now.)

Ignoring the places where it's used as an include or in the build system files, 
we have:

WebCore/DerivedSources.cpp
WebCore/DerivedSources.make

So basically what you want to do is mimic how FileList is referenced in these 
files for Blob.  (Note that if there is no generated DOMBlobPrivate.h or 
DOMBlobInternl.h, then you don't have to include those in the changes.)

It's also a good idea to mimic how FileList (or File) is used in the build 
files as well.  That will make it easier to prevent broken builds in various 
ports when this change lands.

Hope that helps!

Dave


From: Jian Li jia...@chromium.org
To: David Kilzer ddkil...@webkit.org
Cc: webkit-dev@lists.webkit.org
Sent: Tue, December 22, 2009 6:54:29 PM
Subject: Re: [webkit-dev] How to add a new interface for ObjC bindings?


Thanks for all your information. Do you mean to add files into 
MigrateHeaders.make as the following?
$(PRIVATE_HEADERS_DIR)/DOMBlob.h \
$(INTERNAL_HEADERS_DIR)/DOMBlobInternal.h \


What's the difference between adding into PRIVATE_HEADERS_DIR and adding into 
PUBLIC_HEADERS_DIR? Blob interface is indeed the new superclass introduced for 
the existing File interface per the File API spec. Since File has already been 
added into PUBLIC_HEADERS_DIR, do we need to do the same thing for Blob?


I still can't get the generated DOMBlob.h and DOMBlobInternal.h copied into 
PrivateHeaders of WebCore.framework. From the build output, I can see that 
PBXCp is called for DOMFile.h, but not for DOMBlob.h. Do I need to change 
other script file or makefile? Or I should change WebCore.xcodeproj to add the 
generated header files. If so, which group should I add to?


On Tue, Dec 22, 2009 at 4:04 PM, David Kilzer ddkil...@webkit.org wrote:

All the magic for the Obj-C DOM headers happens in:


WebCore/DerivedSources.make
WebKit/mac/MigrateHeaders.make


It should be added as a PrivateHeader first, if at all.  Someone else will 
have to address COM bindings since I don't know much about those.


Dave




From: Jian Li
 jia...@chromium.org
To: webkit-dev@lists.webkit.org
Sent: Tue, December 22, 2009 3:05:08 PM
Subject: [webkit-dev] How to add a new interface for ObjC bindings?


Hi,


I am working on adding Blob interface based on the latest File API spec. I 
have one question about the various kinds of bindings we need to put up for 
this new interface. I got JSC and V8 bindings generated and built 
successfully. I have some problem with ObjC bindings. What's the right 
procedure to add a new interface for ObjC bindings? I could see DOMBlob.h 
being created under Debug/DerivedSources/WebCore, but not under 
Debug/WebCore.framework/PrivateHeaders and Debug/WebKit.framework/Headers as 
other interfaces do. How could I change WebCore.xcodeproj to add the build 
steps for these? Any other things I need to pay attention to?


In addition, where do we use COM bindings? Is it only used when building 
WebKit under Windows?


Thanks,


Jian


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


Re: [webkit-dev] [webkit-changes] [52439] trunk/WebCore

2009-12-22 Thread David Kilzer
You mean it's using git-svn instead of just git now?

In my original message, I meant that it should be using a local svn working 
directory (no git at all) to fix the file history issue.  I'm sure that would 
present a number of issues, though, not the least of which would be much slower 
operation.

Dave



On Tue, December 22, 2009 8:29:09 PM, Eric Seidel wrote:

 Done.  The commit-queue is now using an SVN checkout of Git.
 
 -eric
 
 On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak wrote:
 
  On Dec 21, 2009, at 12:22 PM, Eric Seidel wrote:
 
  I'm happy to move the commit-queue to use an SVN checkout instead if
  that would be a desired change. :)
 
  Yes please.
 
   - Maciej
 
 
  -eric
 
  On Mon, Dec 21, 2009 at 2:20 PM, David Kilzer wrote:
 
  If you want to make sure you're not going to lose history, you should use
  svn directly.  The svn-apply script already knows all the magic to do the
  right thing...if you used svn-create-patch to create the patch *and* if
  you're committing to an svn repository.
 
  The git svn dcommit command (especially in newer versions of git) will
  try to relate source files that are moved or copied, but it only uses a
  heuristic when committing.  Using the --dry-run switch may provide some
  insight into whether git will show copied/moved files or not, but I've 
  never
  tested it to make sure how accurate it is compared to the actual commit.
 
  If the commit-queue is using a git repository, it will only work as well
  as git's heuristic does.
 
  Setting [diff] renames = copies in ~/.gitconfig or in your .git/config
  file for each project will make git diff try to do rename detection when
  creating a patch.  (You may also use --find-copies-harder or
  --find-copies-harder -C switches on the command line.)  This will 
  provide
  hints in the git diff about file renames, but it still only uses a
  heuristic, and svn-apply currently doesn't know about these hints:
 
  Bug 32834: svn-apply should handle git patches with similarity index,
  rename and copy directives
  https://bugs.webkit.org/show_bug.cgi?id=32834
 
  Also note that --find-copies-harder doesn't work on small files (files
  under a certain number of lines), although I don't know what that 
  threshold
  is off the top of my head.
 
  I've also seen git think that a new header file (whose license text is
  larger than the header code itself) is actually a copy of another 
  similarly
  short header file when doing large merges.
 
  Again, you should use svn if you want to ensure file history.
 
  Dave
 
 
  On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote:
 
  If such git magic exists, it would be possible to teach svn-apply to use
  it.
 
  -eric
 
  On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler wrote:
 
  On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote:
 
  Sorry about that - it was git's decision.
 
  It that’s the case, then please consider not using git for this type of
  change
 
  in the future. We don’t want to unnecessarily lose repository history
  when such
  changes occur.
 
  If a git expert can show you how to do such changes with git while
  preserving
 
  the Subversion history, then that gives you another option.
 
-- Darin
 
 
  ___
  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] [webkit-changes] [52439] trunk/WebCore

2009-12-21 Thread David Kilzer
If you want to make sure you're not going to lose history, you should use svn 
directly.  The svn-apply script already knows all the magic to do the right 
thing...if you used svn-create-patch to create the patch *and* if you're 
committing to an svn repository.

The git svn dcommit command (especially in newer versions of git) will try to 
relate source files that are moved or copied, but it only uses a heuristic when 
committing.  Using the --dry-run switch may provide some insight into whether 
git will show copied/moved files or not, but I've never tested it to make sure 
how accurate it is compared to the actual commit.

If the commit-queue is using a git repository, it will only work as well as 
git's heuristic does.

Setting [diff] renames = copies in ~/.gitconfig or in your .git/config file 
for each project will make git diff try to do rename detection when creating a 
patch.  (You may also use --find-copies-harder or --find-copies-harder -C 
switches on the command line.)  This will provide hints in the git diff about 
file renames, but it still only uses a heuristic, and svn-apply currently 
doesn't know about these hints:

Bug 32834: svn-apply should handle git patches with similarity index, rename 
and copy directives
https://bugs.webkit.org/show_bug.cgi?id=32834

Also note that --find-copies-harder doesn't work on small files (files under a 
certain number of lines), although I don't know what that threshold is off the 
top of my head.

I've also seen git think that a new header file (whose license text is larger 
than the header code itself) is actually a copy of another similarly short 
header file when doing large merges.

Again, you should use svn if you want to ensure file history.

Dave


On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote:

 If such git magic exists, it would be possible to teach svn-apply to use it.
 
 -eric
 
 On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler wrote:
  On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote:
 
  Sorry about that - it was git's decision.
 
  It that’s the case, then please consider not using git for this type of 
  change 
 in the future. We don’t want to unnecessarily lose repository history when 
 such 
 changes occur.
 
  If a git expert can show you how to do such changes with git while 
  preserving 
 the Subversion history, then that gives you another option.
 
 -- Darin

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


Re: [webkit-dev] Should we put the webkit.org mailing lists on Gmane?

2009-12-14 Thread David Kilzer
On Mon, December 14, 2009 at 6:47:50 PM, Adam Roben wrote:

 On Jun 13, 2009, at 9:00 AM, Adam Roben wrote:
 
  I think it would be good to put our mailing lists on Gmane (including 
 importing the archives of the lists).
 
 The lists are now all on Gmane. Archives for the newer lists have not been 
 imported, but Gmane already has data going back to July 2009. The newsgroups 
 all 
 fall under the gmane.os.opendarwin.webkit prefix, to match the 
 already-existing gmane.os.opendarwin.webkit.devel group. The group names (and 
 their equivalent lists.webkit.org lists) are:
 
 gmane.os.opendarwin.webkit.
 devel (webkit-dev)
 gtk (webkit-gtk)
 jobs (webkit-jobs)
 qt (webkit-qt)
 user (webkit-help)
 
 (user was chosen by the Gmane administrators, presumably to match other 
 projects' groups.)


Can we drop the os.opendarwin part?  The project formerly known as opendarwin 
is mostly (http://www.opendarwin.org/) dead.

I think gmane.org.webkit would be better.

Dave

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


Re: [webkit-dev] TARGET_OS_EMBEDDED

2009-12-04 Thread David Kilzer
On December 4, 2009 at 9:29:11 AM, Maciej Stachowiak wrote:

 On Dec 4, 2009, at 5:51 AM, Zoltan Herczeg wrote:
 
  Hi,
  
  it would be a great to have a macro in WebKit, which would be enabled on
  embedded systems. We could replace macros like PLATFORM(SYMBIAN) in
  TextCodecQt.cpp to this new macro. However, TARGET_OS_EMBEDDED macro
  enables WTF_PLATFORM_IPHONE. Well, not only symbian and iPhone exist in
  embedded domain. What is your suggestion?
 
 I think we should probably phase out TARGET_OS_EMBEDDED, as it seems too 
 general 
 to be useful.


TARGET_OS_EMBEDDED is only used to define PLATFORM(IPHONE) (which expands to 
WTF_PLATFORM_IPHONE).  TARGET_OS_EMBEDDED was not intended and should not be 
used within any of the WebKit projects itself.

If other platforms are defining the TARGET_OS_EMBEDDED macro separately which 
is causing PLATFORM(IPHONE) to be defined unintentionally, then we should 
qualify the definition of PLATFORM(IPHONE) to include PLATFORM(DARWIN) (or 
similar) so that this doesn't happen.

I don't see a need for a generic PLATFORM(EMBEDDED) macro currently.  I think 
it's best to define specific platforms with the PLATFORM() macro and enable 
features on a per-platform basis as we're currently doing.

Dave

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


Re: [webkit-dev] Question on standards mode vs. site compatibility

2009-11-10 Thread David Kilzer
Both Firefox http://bugzilla.mozilla.org/ and WebKit 
https://bugs.webkit.org/ allow you to file evangelism bugs on any web site.  
Perhaps it would be best to try that approach first?

Dave




From: Chris Evans cev...@chromium.org
To: Darin Adler da...@apple.com
Cc: webkit-dev@lists.webkit.org
Sent: Tue, November 10, 2009 8:59:39 PM
Subject: Re: [webkit-dev] Question on standards mode vs. site compatibility

On Tue, Nov 10, 2009 at 8:37 PM, Darin Adler da...@apple.com wrote:

On Nov 2, 2009, at 11:19 PM, Chris Evans wrote:

Whilst mining a large list of URLs, I came across some sites that render 
incorrectly in WebKit but fine in IE.


It turns out there exist some sites which declare themselves standards 
complaint in their HTML via their DTD. These sites then proceed to try and 
load CSS resources with the incorrect MIME type. This promptly fails due to 
standards mode.


e.g.
http://web.pcc.gov.tw/ uses application/x-pointplus
http://www.emart.co.kr/index.jsp uses application/css
http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in 
place of a slash)
application/octet stream also appears to be a favourite.


That's unfortunate. Out of curiosity, how do these sites behave in Firefox?


Broken, in the same way. Fine in IE.




What is enforceCSSMIMETypeInStrictMode()? Is it a global setting or is 
there some per-page metadata somewhere?

It’s a setting for applications. For web browsers it is set to true. It is 
not per-page.




We can relax the MIME type list we enforce for strict mode without breaking 
ACID3, although I'm not even sure that's desirable? Is it worth me worrying 
about this at all or is the correct solution that these sites are just broken 
and need to fix themselves at some stage? (Pragmatically, I worry that these 
sites will never fix themselves so users of WebKit-based browsers are SOL).

Sounds like a tough choice. It would be unfortunate to have to have a white 
list of sites that violate this rule.


I agree we don't want to be listing sites.
Our options would seem to be:
- Do nothing
- Permit application/x-point-plus and application/css as valid CSS MIME types. 
This would fix some unknown number of sites, and retain ACID3 compatibility. 
(ACID3 checks for CSS load failure with text/plain, I think).


Cheers
Chris



-- Darin


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


Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing

2009-10-19 Thread David Kilzer
Why are there 17 patches with review+ that never get landed?

This has bothered me in the past, but I wasn't sure if it was the same group of 
patches or not.

Dave


On Mon, October 19, 2009 at 7:08:50 PM, Adam Barth wrote:

 WebKit, you are awesome.  We're down to our usual 17 now.
 
 Thanks everyone!
 Adam
 
 
 On Mon, Oct 19, 2009 at 3:27 PM, Eric Seidel wrote:
  We're back down to 25 after Yong's epic cq+ing this morning.  The
  queue had a record 13 patch backlog for a while.  Thank you Yong for
  cleaning the pending-commit list!
 
  Still 25 to go.  All of which require manual attention from committers.
 
  -eric
 
  On Mon, Oct 19, 2009 at 11:52 AM, Eric Seidel wrote:
  On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth wrote:
  2) If you see a patch on the list that's ready to land (almost all of
  them), you can mark it commit-queue+ to have the commit bot land it.
  When you do this, please be sure to watch the tree for regressions,
  just like you would if you typed svn commit yourself.
 
  FYI, if you're using commit-queue+, you should know about:
  http://webkit-commit-queue.appspot.com/
 
  which gives you a little window into commit-queue's tiny brain.
  Eventually I hope to move that to http://commit.webkit.org/ or
  something easier to remember.
 
  -eric
 
 
 ___
 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] MIPS JIT Supports

2009-10-06 Thread David Kilzer
If you'd like a patch reviewed, please set the review? flag on the patch in 
bugs.webkit.org.

For more information, see:  http://webkit.org/coding/contributing.html

Dave



- Original Message 
 From: Fu, Chao-Ying f...@mips.com
 To: webkit-dev@lists.webkit.org
 Sent: Tuesday, October 6, 2009 5:34:04 PM
 Subject: [webkit-dev] MIPS JIT Supports
 
 Hi All,
 
   Please check the patch for MIPS JIT supports.
 https://bugs.webkit.org/show_bug.cgi?id=30144
 
   Thanks!
 
 Regards,
 Chao-ying
 ___
 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] I *HATE* CHANGELOGS!!!

2009-08-28 Thread David Kilzer
On Friday, August 28, 2009 at 1:05:57 PM, Jeremy Orlow wrote:

On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson wrote:

Mark Rowe already pointed out - doing an automated step for
each checkin that causes another checkin would be ridiculous.
But how about a nightly script that checks in a ChangeLog
accounting for the day's commits?

Agreed.  If it's done daily, Trac would be a good way to look
at what's happened very recently.


This would make it impossible to track a single ChangeLog entry back to the 
original commit using git/svn annotate/blame, but the new process could add the 
commit revision to each ChangeLog entry automatically when it generates the 
update, thus achieving some level of ChangeLog-nirvana.

Dave

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


Re: [webkit-dev] Bugzilla Data Loss

2009-08-21 Thread David Kilzer
On Friday, August 21, 2009 at 7:59:11 AM, Ryan Leavengood wrote: 


 On Fri, Aug 21, 2009 at 1:54 AM, Peter Kastingwrote:
 
  but patches that were merely attached to bugs have vanished.
  Hopefully you still have local copies and can re-attach them!
 
 This sort of thing tends to put a kibosh on some people's workflow of
 using bugzilla as a source control tool (as recently read in #webkit.)
 Well at least abarth does this.


This is one place were local branches in a git repository work well.

Dave

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


Re: [webkit-dev] r45939 broke my workflow

2009-08-21 Thread David Kilzer
  Is there an easy fix to svn-apply and svn-unapply that you can make?
 
 I believe there is an easy fix for this particular workflow, which is to make 
 svn-apply and svn-unapply behave the same way as svn-create-patch.


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

Dave

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


Re: [webkit-dev] svn-* scripts

2009-08-21 Thread David Kilzer
On Friday, August 21, 2009 at 5:32:14 PM, Darin Adler wrote:

 I’m a little irritated that we’re changing our Subversion scripts, 
 svn-create-patch, svn-apply, and svn-unapply into WebKit-specific scripts. 
 Previously, they were scripts that were independent of the particular project 
 that enhanced Subversion in a non-project-specific way. I used the WebKit 
 version on many projects other than the WebKit project.


The only dependency these scripts have is VSCUtils.pm, which contains common 
routines used by (almost) all the scripts.  If these scripts are used 
elsewhere, VCSUtils.pm is the only additional file that needs to be copied with 
them.  (VCSUtils.pm itself doesn't depend on anything else in WebKit as of 
r46669.)

The only non-svn functionality they have now is that svn-apply is able to 
apply patches to either an svn or a git repository.  (The other two scripts are 
still svn-only.)

I'm not sure how this makes them WebKit-specific?

Dave

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


Re: [webkit-dev] Towards a commit-queue

2009-08-01 Thread David Kilzer

On Saturday, August 1, 2009 10:16:39 AM, Adam Barth wrote:
 On Sat, Aug 1, 2009 at 8:43 AM, tonikitoo (Antonio Gomes)wrote:
  Adam, as I suggedted previously, bugzilla supports KEYWORDs, so that
  would be a matter of adding a special support for bugs where patches
  are ready to go in.
 
  'checkin-needed' keyword would work , i believe. What do you think ?
 
 In addition to the point Ojan made about applying to individual
 patches, a flag also has the advantage that it implicates who approved
 the patch to be committed.  Sure, the information is available for
 keywords if you dig deep enough, but the system has more
 accountability if the name is right there.


Bugzilla has the ability to create additional 4-state flags at both the 
attachment level and at the bug level.  (Note that bugs.webkit.org does not 
have bug-level flags enabled.)

For example, we could create a commit attachment flag which would have four 
states (just like the review flag):  none, commit?, commit+, commit-.

I'm not sure if this helps or hurts, though it would have made abarth's desired 
workflow much nicer.

Mozilla also uses a superreview flag and various approval flags as seen on 
the attachments on this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=342677

Dave

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


Re: [webkit-dev] Towards a commit-queue

2009-08-01 Thread David Kilzer

On Saturday, August 1, 2009 11:45:43 AM, Ojan Vafai wrote:

On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth aba...@webkit.org wrote:
On Sat, Aug 1, 2009 at 11:04 AM, David Kilzerddkil...@webkit.org wrote:
 Bugzilla has the ability to create additional 4-state flags at
 both the attachment level and at the bug level.  (Note that
 bugs.webkit.org does not have bug-level flags enabled.)
 
 For example, we could create a commit attachment flag which
 would have four states (just like the review flag):  none,
 commit?, commit+, commit-.
 
 I'm not sure if this helps or hurts, though it would have
 made abarth's desired workflow much nicer.
 
 Yeah, that sounds great.  Should we try that out for a while
 and see if it's useful?
 
 This seems fine to me, except it adds yet another layer of
 complexity to the review process. I think getting patches
 landed more quickly is probably worth it though. This is
 essentially a slightly more complicated (but easier to
 implement?) version of Maciej's proposal from a few weeks
 ago to get rid of r* and have the following four review
 states:
 
 REQUESTED
 DENIED
 APPROVED WITH MODIFICATIONS
 APPROVED
 
 One benefit over the above is that, I don't think we need
 to restrict commit+ to people with svn commit bit, as long
 as a patch is r+'ed or r+'ed with modifications.


This would require a non-trivial amount of modification to Bugzilla, and it 
would make future upgrades much more difficult.

Basically, Adam's asking for a flag to make it easier for bugzilla-tool to know 
when to land patches without human intervention.  Currently, a committer must 
look at each patch's review comments to make this determination.

Either we should change the review process to only set the review+ flag if the 
patch is ready to go with zero modifications, or we should use the commit+ flag 
to signify that.

I could go either way on this.  I don't like the idea of setting review- flags 
for trivial fixes that could be landed with minor modifications.  On the other 
hand, being able to commit patches directly from bugs.webkit.org with 
bugzilla-tool is really handy.

Dave

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


Re: [webkit-dev] Memory leak or should I clear content of QWebPage?

2009-07-29 Thread David Kilzer

On Wednesday, July 29, 2009 8:40:59 AM, Zongheng Zhou wrote:

After I load www.cnn.com; for 800 times consecutively,
the virtual memory size of my little program has reached
1600M; while the resident memory is 1500M

This is horribleIs this kind of memory leak expected?  

Of course not.  File a bug on https://bugs.webkit.org/ with more detail than 
you've provided in your email messages (which Qt port you're compiling, e.g., 
where you got the source code, the revision/commitish of the source, which 
processor and operating system, which compiler, etc.).

Also, please move this discussion to webkit-h...@lists.webkit.org.  The 
webkit-dev mailing list is to discuss future development of the WebKit engine.  
Thanks!

Dave

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


Re: [webkit-dev] Patch process - let's make it better

2009-07-15 Thread David Kilzer

On Saturday, July 11, 2009 11:55:36 AM, Maciej Stachowiak wrote:

 On Jul 11, 2009, at 9:39 AM, Darin Adler wrote:
 
  On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote:
  
  Perhaps we should make update-webkit (or some new wrapper type tool)
  run resolve-ChangeLogs automatically.
  
  Dave Kilzer had the same idea when he created resolve-ChangeLogs,
  so update-webkit does run resolve-ChangeLogs automatically. See 
  from October 2007.
 
 I guess the reason I hadn't noticed is that I often to svn update to update 
 only the directory I'm working on. Maybe we need an update-subtree command.


Why don't you update your whole source directory at once?  I would think that 
updating only subdirectories could make the source tree out-of-sync and cause 
build problems later.

Dave

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


Re: [webkit-dev] Documentation on internals of WebKit

2009-07-14 Thread David Kilzer

On Tuesday, July 14, 2009 3:28:27 AM, Jack Wootton wrote:

 I'm sure there are other good blog entries, and the standard seems to
 be quite high, unfortunately I haven't found a page which lists the
 entries away from all the ...is now a webkit reviewer or allows a
 search of them.  All I can do is provide this link:
 http://webkit.org/blog/ where you can trawl through all the blog
 entries searching for something useful.


You may use Google to search the blog entries for you using the site: keyword:

site:webkit.org/blog render tree

http://www.google.com/search?client=safarirls=enq=site:webkit.org/blog+%22render+tree%22ie=UTF-8oe=UTF-8

Dave

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


Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)

2009-07-10 Thread David Kilzer

 At one point, I started on a script (located in 
 WebKitTools/Scripts/update-sources-list.py) whose idea
 was to take the list of common sources from one file,
 and make changes to MSVC, Qt, GTK, etc. build systems,
 so that WebKit devs need only add the file once, run
 the script, and commit the results. I got it as far as
 theoretically generating the Qt and GTK file lists, but
 I don't think anyone on those ports tried integrating
 it into their build system, and I sort of moved on to
 other things.

I should add that I haven't felt enough pain (maybe my threshold is too high?) 
to attempt to write a script that updates all of the build systems when adding 
a new source file.

Instead of regenerating parts of the build files, I though such a script should 
simply do in-place edits of each of the build files.  My current thinking was 
that if you could provide an example source file that would be in the same 
group as the new source file, then you could embed less knowledge about each 
build format in the tool and just make it smart enough to add new lines for the 
source file for each build file.  (For example, on Xcode project files, the 
only extra thing you'd need to do when adding a new file is to generate an ID 
for the new file(s) that didn't already exist in the current project file.)  I 
think this would probably handle the most common cases.

Dave



- Original Message 
 From: Kevin Ollivier kev...@theolliviers.com
 To: Dimitri Glazkov dglaz...@chromium.org
 Cc: Mark Mentovai m...@chromium.org; WebKit Development 
 webkit-dev@lists.webkit.org
 Sent: Friday, July 10, 2009 8:52:57 AM
 Subject: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to 
 the our dysfunctional build family)
 
 Hi Dimitri and all,
 
 Congrats on getting this into WebKit! Actually, I'm in the middle of a build 
 system switch as well - to waf, a re-write of scons that removed many of the 
 performance issues related to searching and calculating dependencies, and 
 which 
 has added some nice features as well (such as .app bundle building). I 
 haven't 
 completed the switch so I can't do preliminary benchmarks, but I'm pretty 
 sure 
 it's actually as fast or faster than make on *nix/Mac. (And BTW, it will 
 probably make Apple devs happy to hear that I'm no longer using the horrid 
 build-wxwebkit bash script to manage the build, but instead have integrated 
 everything into build-webkit finally!)
 
 The main reason I bring this up, though, is because I think this sort of 
 thing 
 shows that we're unlikely to centralize our build systems any time soon, and 
 I 
 feel a bit sorry for the core devs who, as they accept new ports, are 
 probably 
 finding it more and more tedious, if not difficult, to make sure all the 
 projects get updated by a change to the common parts of the build. They've 
 been 
 very helpful in terms of trying to keep the ports in shape when they make 
 changes, and I feel like I'd like to do what I can to make it easier and 
 faster 
 to keep the other ports in sync.
 
 At one point, I started on a script (located in 
 WebKitTools/Scripts/update-sources-list.py) whose idea was to take the list 
 of 
 common sources from one file, and make changes to MSVC, Qt, GTK, etc. build 
 systems, so that WebKit devs need only add the file once, run the script, and 
 commit the results. I got it as far as theoretically generating the Qt and 
 GTK 
 file lists, but I don't think anyone on those ports tried integrating it into 
 their build system, and I sort of moved on to other things.
 
 Unfortunately, right now I'm really swamped (my build system rewrite was 
 prompted by WebKit exceeding internal, hardcoded, Bakefile limits, not by 
 choice), but if a common location for the source files list could be decided 
 upon, I really think a script would be a simple matter to write up (even in 
 Perl 
 :P ), and I think it would probably save developers time and reduce build 
 breakages as well, which I think would add up to a lot of saved time for a 
 lot 
 of people over the long term. The only format I'm not sure if we could 
 automate 
 reliably would be the XCode format (at least, on non-Mac machines), because 
 IIUC 
 we'd need some sort of parser for it, but Apple is the only port maintaining 
 those directly IIUC, as now Chromium will be using GYP to update their XCode 
 projects. So even if we couldn't solve the XCode issue, that would drop it to 
 updating two locations tops.
 
 So, does anyone think this would be a bad idea, or have any alternate 
 suggestions on how to improve things? If not, is anyone willing to take the 
 ball 
 and run with it? I'd be willing to invest some more time in it, but my 
 ability 
 to commit to it over the next couple weeks at least would be very limited.
 
 Thanks,
 
 Kevin
 
 On Jul 9, 2009, at 9:23 PM, Dimitri Glazkov wrote:
 
  Dear WebKiteurs,
  
  In our persisting quest to be more like a common WebKit port, we have
  added Chromium build 

Re: [webkit-dev] Patch process - let's make it better

2009-07-10 Thread David Kilzer

On Friday, July 10, 2009 3:55:59 PM, Maciej Stachowiak wrote:


 A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to 
 being 
 there. I'm going to help him refine this tool to the point that submitting a 
 patch has only one step - a single command will make the patch, file a bug if 
 needed, attach the patch to the bug, and flag it for review.


I already took a first pass at this for git, which probably gets you 60-70% of 
the way there for svn:

bugzilla-tool: Add create-bug command
https://bugs.webkit.org/show_bug.cgi?id=27119

 B) Make it really easy to commit a patch. Again, I think bugzilla-tool is the 
 right path to achieving this.


bugzilla-tool already does this.  Today.  It's freaking awesome.  You can even 
specify whether you want to build and/or test the patch!  (N.B. I haven't tried 
it with an svn working directory, but the support is already there.)

Dave

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


Re: [webkit-dev] Changes to prepare-ChangeLog

2009-07-09 Thread David Kilzer

 2009-07-08  Maciej Stachowiak  m...@apple.com
 
   - http://webkit.org/b/27098 Make prepare-ChangeLog less shouty
   Reviewed by Mark Rowe.
 
   Hypothetical long description goes here. Yeah. Very long and detailed 
 it is.
 
   * Scripts/prepare-ChangeLog:


Random nits (since you asked):

* Please do not put a - in front of the bug line.  What does that buy you 
besides (sometimes) a bullet in trac.webkit.org?

* What does the format look like for bugs with multiple URL links, e.g., to 
rdar://problem/NNN or to http://crbug.com/N?  (The title should not 
have to be repeated--you should be fixing the same issue for all of them.)

* Is the Reviewed by line going to have a blank line above it?  (I think it 
should, but I could be persuaded otherwise.)

And from The-World-is-Not-Enough Department:

* The commit-log-editor should be smart about condensing duplicate content 
after the date-name-email lines for each ChangeLog entry, and it should move 
those lines to the top of the commit message.  (This also makes git users happy 
since the first line would be the bug URL and description, making git log 
--oneline more useful.)

Dave



- Original Message 
 From: Maciej Stachowiak m...@apple.com
 To: Maciej Stachowiak m...@apple.com
 Cc: WebKit Development webkit-dev@lists.webkit.org
 Sent: Thursday, July 9, 2009 1:47:16 AM
 Subject: Re: [webkit-dev] Changes to prepare-ChangeLog
 
 
 I discussed with Mark Rowe on IRC a bit and it seems like it would be nice if 
 the bug URL could be short enough to just go on one line with the summary. 
 Which 
 turns out to be totally doable. Thus the latest format proposal (the /b/ URL 
 is 
 a redirect):
 
 2009-07-08  Maciej Stachowiak  
 
- http://webkit.org/b/27098 Make prepare-ChangeLog less shouty
   Reviewed by Mark Rowe.
 
   Hypothetical long description goes here. Yeah. Very long and detailed 
 it is.
 
* Scripts/prepare-ChangeLog:
 
 On Jul 9, 2009, at 1:32 AM, Maciej Stachowiak wrote:
 
  
  Now that my attention has been called to it, it's starting to bug me that 
 everyone formats their ChangeLog entries slightly differently. How about this 
 as 
 the canonical format (with prepare-ChangeLog encouraging it)?
  
  2009-07-08  Maciej Stachowiak  
  
 Make prepare-ChangeLog less shouty
 https://bugs.webkit.org/show_bug.cgi?id=27098
  
 Reviewed by Mark Rowe.
  
 * Scripts/prepare-ChangeLog:
  
  
  
  So specifically:
  
  - Reviewed by line would go below, not above, to make git users happy 
  (well, 
 happi*er*)
  - Bug URL remains below one-line description, for git joy and scannability
  - No angle brackets around URL, so that you can cut/paste or drag it from a 
 URL field without extra work
  - No line between URL and summary
  
  Is that a format everyone can live with for ChangeLogs and commit messages? 
  If 
 so, I'll post a patch to update prepare-ChangeLog accordingly.
  
  Regards,
  Maciej
  
 
 ___
 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] Changes to prepare-ChangeLog

2009-07-09 Thread David Kilzer

On Thursday, July 9, 2009 11:06:58 AM, Maciej Stachowiak wrote:

On Jul 9, 2009, at 4:33 AM, David Kilzer wrote:

* What does the format look like for bugs with multiple URL
links, e.g., to rdar://problem/NNN or to 
http://crbug.com/N?  (The title should not have to be
repeated--you should be fixing the same issue for all of them.)

I could think of two reasonable options?

 http://webkit.org/b/27098rdar://problem/12345 Make prepare-ChangeLog 
 less shouty
 Reviewed by Mark Rowe.


 http://webkit.org/b/27098 Make prepare-ChangeLog less shouty
 rdar://problem/7123456 
 Reviewed by Mark Rowe.

Preferences?


#2 please.

* Is the Reviewed by line going to have a blank line above it?
  (I think it should, but I could be persuaded otherwise.)


I don't think it should, if it's one of two special lines at the
top. Otherwise the whole ChangeLog entry looks double-spaced and
gets harder to read.


Yeah, I've noticed that.

And from The-World-is-Not-Enough Department:

* The commit-log-editor should be smart about condensing
duplicate content after the date-name-email lines for each
ChangeLog entry, and it should move those lines to the top of
the commit message.  (This also makes git users happy since the
first line would be the bug URL and description, making
git log --oneline more useful.)

I'm not sure I understand this suggestion.


An illustrated example of pulling common lines out of each subsection (with 
double-spacing):

http://trac.webkit.org/changeset/44095
http://trac.webkit.org/changeset/44096

Dave

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


Re: [webkit-dev] Max http connection per host ?

2009-07-06 Thread David Kilzer
Hi Jérôme,

The method to change the connection count is not public API, and it's not 
supported on all platforms (hence the reason it always returns 4).

Dave





From: Jérôme Lebel jer...@fotonauts.com
To: webkit-dev@lists.webkit.org
Sent: Monday, July 6, 2009 11:42:25 AM
Subject: [webkit-dev] Max http connection per host ?

Hi,

I'm trying to change the max http connection count per host in WebKit on OS X. 
I'm not sure if this mechanism by WebCore or by CFNetwork. I found 
wkInitializeMaximumHTTPConnectionCountPerHost(), but I'm not sure how it worked 
(since first parameter is 6 and it returns 4). I tried to change the parameter 
and the returned value, but nothing changed in WebKit.

I was not able to find any information in the CFNetwork documentation.

Thanks for the help

Jérôme,___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Changes to prepare-ChangeLog

2009-07-03 Thread David Kilzer

On Friday, July 3, 2009 3:20:58 AM, Alexey Proskuryakov wrote:

 02.07.2009, в 18:05, Adam Roben написал(а):
 
  Here's an example entry that follows the format that I (and
  I think Dave) like:
 
  +2009-04-20  Adam Roben  aro...@apple.com
  +
  +Change MemoryStream::createInstance to return a COMPtr
  +
  +Part of Bug 25294: All WebKit/win classes should return COMPtrs 
  from
  +their static constructor members
  +https://bugs.webkit.org/show_bug.cgi?id=25294
 
 FWIW, I rarely need to know the bug number alone - I need its
 URL to click or to copy/paste. On the other hand, the
 suggested format makes it so that one needs to skip over Part
 of Bug 25294:  just to read the bug description, which is not
 an improvement.

This probably isn't a typical example since it's a Part N of M bug fix, but 
the important part is that the change is summarized on the first line (after 
the date and patch author) to give a quick overview of the patch.

 - I like putting angle brackets  around the URL to set
 it off visually from other text.
 
 Typing those brackets is more work. It's also more difficult
 to copy/paste the URL (you could just copy the whole line and
 paste it into Safari address bar when there were no garbage
 symbols around the URL)


Actually, Safari will strip the  characters for you if you paste them into 
the address bar!  I didn't know this until a couple of months ago, either.

Dave

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


Re: [webkit-dev] ChangeLog

2009-07-03 Thread David Kilzer

On Friday, July 3, 2009 1:01:33 PM, Joe Mason wrote:


 Even if sticking with svn, you just need to run svn2cl once when
 you update to  get a local copy of the changelog.


If each developer had to run that command to get a local changelog, I can't 
imagine the svn server would be very responsive if two or more people ran it at 
the same time.

Also, if you're already disconnected from the network, it's too late to run 
svn2cl if you want the full history.

--

Personally, I think git is the long-term solution since (a) git-format-patch 
includes the commit log comments in the patch format, which makes them easily 
reviewable and (b) it operates in an off-line mode making not only the log 
comments but the full repository history available.

However, not everyone on the project is comfortable with git (or is willing to 
give up svn), so I don't see a near-term solution at the moment other than 
improving the existing tools (prepare-ChangeLog, resolve-ChangeLogs, etc.).

Finally, I should note that I've found the detailed ChangeLogs created by 
prepare-ChangeLog--and written with the correct level of detail--to be 
extremely valuable in the past, especially when merging commits to a port.  I 
don't think these should ever go away.

Dave

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


Re: [webkit-dev] Changes to prepare-ChangeLog

2009-07-03 Thread David Kilzer

On Friday, July 3, 2009 2:19:51 PM, Maciej Stachowiak wrote:

 What I do (and I think many of us do) is use a script that
 automatically fills in the commit message from the ChangeLog.

The script is WebKitTools/Scripts/commit-log-editor.  Setting one of these 
environment variables (depending on whether you're using svn or git) works 
great (replace $WEBKIT_SRC_DIR with the path to your webkit source, or just 
set them to commit-log-editor if you've added WebKitTools/Scripts to your 
PATH):

GIT_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor
SVN_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor

You'll also want to set the EDITOR environment variable unless you use vi to 
edit your svn/git commit logs.  :)

Dave

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


Re: [webkit-dev] Changes to prepare-ChangeLog

2009-07-02 Thread David Kilzer
On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel e...@webkit.org wrote:


 Results in:
 2009-07-01  Eric Seidel  e...@webkit.org
 
 Reviewed by NOBODY (OOPS!).
 
 prepare-ChangeLog should have a --bug= argument and use it for
url autofill
 https://bugs.webkit.org/show_bug.cgi?id=26383
 
 DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
 http://webkit.org/coding/contributing.html FOR MORE INFORMATION
 
 Tests: fast/foo.html
 
 * foo.cpp: Added.


- I prefer having Bug N:  before the actual bug description so I don't 
have to parse the URL myself for the bug number.  It also acts as a visual 
marker when I read the ChangeLog entry.

- I like putting angle brackets  around the URL to set it off visually from 
other text.

- I generally move the Reviewed by line after the bug number/description/URL. 
 When you're reading a ChangeLog entry/commit message (especially an older 
one), it's generally much more interesting which bug is being fixed rather than 
knowing who reviewed it.  (Also, putting the bug description first makes git's 
one-line description of each commit much more useful than either having a list 
of dates and the person who wrote the patch or having a list of patch 
reviewers.)

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


[webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 2009 at 7:00 PM PDT (-0700)

2009-07-01 Thread David Kilzer
The bugs.webkit.org server will be down for maintenance starting at 7:00 PM PDT 
(-0700) on Thursday, July 2, 2009 for a Bugzilla upgrade.  We expect the server 
to be down for about 30 minutes.

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

Apologies in advance for any inconvenience this may cause.

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


Re: [webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 2009 at 7:00 PM PDT (-0700)

2009-07-01 Thread David Kilzer
The UTF-8 upgrade of the database takes much longer than expected.  The 
downtime may be closer to 45 minutes.

Dave





From: David Kilzer ddkil...@webkit.org
To: webkit-dev@lists.webkit.org
Sent: Wednesday, July 1, 2009 11:32:02 AM
Subject: [webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 
2009 at 7:00 PM PDT (-0700)


The bugs.webkit.org server will be down for maintenance starting at 7:00 PM PDT 
(-0700) on Thursday, July 2, 2009 for a Bugzilla upgrade.  We expect the server 
to be down for about 30 minutes.

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

Apologies in advance for any inconvenience this may cause.

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


  1   2   3   >