Re: [webkit-dev] Qt is now a "core builder"

[Eric Seidel]

Then again if Gtk and windows tests become and stay green, we don't
need "core builders" anymore.  They'll all be "core" at that point.

On Wed, Apr 14, 2010 at 3:37 AM, Maciej Stachowiak  wrote:
>
> On Apr 13, 2010, at 11:13 PM, Eric Seidel wrote:
>
> http://trac.webkit.org/changeset/57561
>
> Sheriff Bot will nag you when you break Qt.
> Commit Queue will block while any Qt builder is broken.
>
> Qt was green all day.  The Qt devs @ WKCon seemed very interested in
> keeping their bots green.
>
> The goal of the "core builder" list[1] is to be descriptive, not
> prescriptive.  It seemed through talks today/yesterday that the
> community is interested/ready to keep the Qt bots green, so I've told
> the bots to expect them green.
>
> Thanks!  If you've got questions, let me know.
>
> Per my previous comments, I'd really like it if the "core builders" list
> appeared on a separate Web page of buildbot output than the other builders.
> Is that a practical thing to do? Is our buildbot configuration in SVN?
> Regards,
> Maciej
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Windows Release bots

[Eric Seidel]

Linking is also timing out on the Release builders.  Filed:
https://bugs.webkit.org/show_bug.cgi?id=37593

On Wed, Apr 14, 2010 at 12:19 PM, Nikolas Zimmermann
 wrote:
>
> Am 14.04.2010 um 18:28 schrieb Adam Roben:
>
>> On 4/14/2010 7:48 AM, Nikolas Zimmermann wrote:
>>>
>>> can anyone with access to the windows release slaves have a look? They
>>> fail to build since a while,
>>
>> The Release builder seems to be doing OK (c.f.
>> ).
>> The test bots (both Release and Debug), on the other hand, are having a bit
>> of trouble. I think that my change in r57566 to skip
>> xss-DENIED-iframe-src-alias.html has somehow caused lots of other http tests
>> to start hanging. I guess I should roll out that change.
>
> Okay, that might resolve it.
>
>>
>>> the build bot tries to upload since ages
>>
>> I'm not sure what this means.
>
> Sorry I was a bit in hurry writing that mail. If you check
> http://build.webkit.org/builders/Windows%20Release%20%28Build%29 you'll
> notice that one build is hanging in the "Upload" step since 30.000+ seconds.
>
> Cheers,
> Niko
> ___
> 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] webkit-patch and SVN

[Eric Seidel]

Anders brought to my attention this afternoon that webkit-patch
currently does all SVN operations from the root directory instead of
being current-directory aware.  That behavior matches how Git
operates, but does not need to be how webkit-patch operates.

Question: Do SVN users wish to have webkit-patch be
current-working-directory aware?

Meaning:
"upload" will only prepare-ChangeLog for the current directory and
upload an svn diff under the current directory.
"land" will only land the current subdirectory.

The propose change will make webkit-patch inconsistent between VCS
tools, but consistent with the users choice of SVN vs. Git.  Is this
SVN users desired behavior?

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

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Eric Seidel]

I think 80 columns is a waste of time and hurts readability.

Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.

The optparse code which was recently re-wrapped is one example of 80c
fail.  Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.

That said.  I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping.  If the
consensus is 80c, I'll learn to deal. :)

The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).

I've chosen A. in the past.  Mostly to match my own personal bias I'm sure.

-eric



On Wed, Apr 14, 2010 at 5:02 PM, Dirk Pranke  wrote:
> Hi all,
>
> As I'm sure the discussions in the webkit meeting over the past two
> days made clear, it looks like most of our non-C++ code is getting
> written in Python. Back in January, Adam Barth posted this thread [1]
> where I thought it was agreed we would attempt to follow PEP 8 ([2] -
> the standard Python style guide) faithfully.
>
> The one (somewhat) controversial aspect of that style guide is that it
> requires a 79-column wide line length.
>
> More recently, as part of implementing a style checker for Python code
> [3], some have advocated that we should not follow that particular
> restriction, because (a) the WebKit C++ style guide does not follow
> that restriction, and (b) there is a reasonable amount of Python code
> that does not follow the rule today and would have to be brought into
> compliance. In particular, it was asked that we disable the long-line
> check until at least the existing code was brought into compliance.
>
> As far as (b) goes, there are currently (as of r57510) 1533 long lines
> out of the 35,616 lines found under WebKitTools/Scripts/webkitpy,
> occurring in 120 out 193 .py files. Most of the files that have any
> long lines have less than five [4].
>
> As far as disabling the check goes, I rather firmly believe that if we
> wish to follow an ~80 column line-length limitation, the check needs
> to be on by default, or else those who aren't used to this convention
> will not follow it and the problem will get worse, not better (as
> evidenced by [5]).
>
> So, do we want to follow an 80-column limit for Python code, or not,
> and if we do, should we enforce the rule by default or not?
>
> If the concern is the existing code base I also (reluctantly)
> volunteer to fix the long lines, if that influences the decisions.
> Although I personally believe that code that is less than 80 columns
> wide is easier to read and easier to maintain for a variety of
> reasons, I mostly volunteer to do this because it's just not many
> lines of code and I believe that having style guidelines that aren't
> followed are a Very Bad Thing and hence the fact that we have existing
> violations is a bad reason in this case to argue for not following the
> rule.
>
> Note that I do not particularly wish to argue the merits of this
> particular style choice, just make (and document) a decision. It's a
> religious position and the interweb is littered with existing
> arguments pro and con that we would likely just rehash here. I raise
> the issue at all only because I had thought that we made a decision
> and then it was changed in relative obscurity in a bug, rather than
> after being discussed here, whch struck me as not the right way to do
> this sort of thing.
>
> -- Dirk
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2010-January/011423.html
> [2] http://www.python.org/dev/peps/pep-0008/
> [3] https://bugs.webkit.org/show_bug.cgi?id=33639
> [4] Stats:
> % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
> \*.py | wc -l  # 193 .py files
> % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
> \*.py | xargs wc -l  # 35,316 lines of code
> % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
> \*.py | xargs awk '{ if (length($0) > 79) printf("%s:%d %s\n",
> FILENAME, FNR, $0);}' # all of the long lines
> % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
> \*.py | xargs awk '{ if (length($0) > 79) printf("%s\n", FILENAME);}'
> | sort | uniq -c | wc -l # 120 files w/ long lines
> % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
> \*.py | xargs awk '{ if (length($0) > 79) printf("%s\n", FILENAME);}'
> | sort | uniq -c # distribution by file
> [5] https://bugs.webkit.org/show_bug.cgi?id=37586
> ___
> 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://

Re: [webkit-dev] CMake as a build system?

[Eric Seidel]

I don't see this as a decision needing pre-approval.

This is a decision needing code.  No one has tried to make Mac, Win,
or other ports use a common system yet.  Obviously converting them in
the end requires buy-in from those ports.  But producing a demo
doesn't/shouldn't.

I eventually plan to look at this task.  When I do, I'll take a peek at CMake.

Someone just needs to sit down and build something.  Then we can make
an informed decision.

-eric

On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat  wrote:
> On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote:
>> Hi,
>>
>> Adam Treat (tr...@kde.org) suggested that I join this list to talk about
>> CMake as an option for a unified cross platform build solution.  My name
>> is Bill Hoffman.  I am the lead CMake developer.  My company Kitware
>> created and supports CMake.  I think CMake would have a lot to offer the
>> WebKit developers.
>>
>> If you are not familiar with CMake, I did a google tech talk in December
>> which can be found here:
>> http://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata
>>
>> Another article about how KDE switched to CMake can be found here:
>> "Why the KDE project switched to CMake -- and how"
>> http://lwn.net/Articles/188693/
>>
>> If you are interested in moving to CMake, I would be interested in
>> helping.  If you have any questions about CMake, fire away!
>>
>> Thanks.
>>
>> -Bill
>
> I asked Bill to introduce himself here because I think CMake represents the
> best hope for WebKit to find a way out of the current build system
> proliferation we are experiencing.  Of the meta-buildsystems in existence I
> think CMake is by far the most powerful and mature.  CMake is by far the most
> widespread and supported.  It is already used successfully by Open Source
> projects of a comparable scope to WebKit and with similar cross-platform
> needs: LLVM, KDE, Boost.
>
> I know that WebKit already has GYP and QMake meta-buildsystems, but to my
> knowledge both are inferior to CMake.  In fact, I do not think CMake is
> lacking in any important way to the features of GYP.
>
> What's more, the WebKit project has already had a CMake based buildsystem.
> This is what the 'Unity' nascent QtWebkit port used originally.  I think we
> should re-introduce it and seriously consider using CMake as a cross-platform
> solution to our build system proliferation issues.
>
> I highly encourage you all to view the google tech talk above as it gives a
> great introduction to CMake.
>
> Cheers,
> 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] GTK bots are now "core builders"

[Eric Seidel]

http://trac.webkit.org/changeset/57795

Sheriff Bot will nag you when you break GTK.
Commit Queue will block while any GTK builder is broken.
build.webkit.org will show GTK in the "core" set. [1]

The GKT bots have been green every time I've looked the last 5 days.
It would appear the WebKit community is keeping the GTK bots green, so
I've updated the core builder list [2] to reflect reality.

Thanks!  If you've got questions, let me know.

-eric

1. Thanks to _wms for this feature!  Requires a buildbot server
restart, should appear soon.
2. 
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L310
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Update: new-run-webkit-tests migration

[Eric Seidel]

new-run-webkit-tests is getting closer for general project-wide use.
If you're on a Mac and would like to experience sub-3-minute layout
test runs and are willing to deal with a few bugs, try
new-run-webkit-tests instead of run-webkit-tests next time you run the
tests.  We'd love to see questions/comments/complaints you have.

Additionally, run-webkit-tests was renamed to old-run-webkit-tests and
run-webkit-tests is now a perl script which automatically choses
old-run-webkit-tests or new-run-webkit-tests depending on your
platform/config. [1]  Right now it always uses old-run-webkit-tests.

We will be running trial conversions of a few of the builders later
this week. [2]  These conversions will happen outside of normal work
hours and should be invisible to the end users and bot administrators.

If you have any questions or I can be of further help, drop me a line.

-eric

1.  http://trac.webkit.org/changeset/57796
2.  We are able to switch individual platforms/users/machines between
old and new run-webkit-tests using:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-webkit-tests#L57
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Update: new-run-webkit-tests migration

[Eric Seidel]

On Mon, Apr 19, 2010 at 12:22 AM, Maciej Stachowiak  wrote:
> - Will these be permanent or temporary conversions?

Temporary.  Any permanent conversions will result in further mail to webkit-dev.

> - Which trains will be converted?

Eventually all of them.  The plan is to start with Snow Leopard and
test one at a time.

> - Is there anyone to contact besides you if anything goes wrong?

Well, the sheriff-bot knows how to roll out any patches. :)  Adam
knows this code as well.

The code to switch new/old on any builder is simply changing this
return statement:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-webkit-tests#L57
Right now all configurations use old-run-webkit-tests since
useNewRunWebKitTests() always returns false.

> P.S. I would personally prefer to see at least the following bugs fixed
> before any bot is permanently converted to using new-run-webkit-tests:
>
> https://bugs.webkit.org/show_bug.cgi?id=37736
> https://bugs.webkit.org/show_bug.cgi?id=37738
> https://bugs.webkit.org/show_bug.cgi?id=37739

Those are all good bugs.  Dirk, Adam, Chris and I are all continuing
to improve new-run-webkit-tests.  Others should feel encouraged to
hack on it as well.

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

Re: [webkit-dev] Update: new-run-webkit-tests migration

[Eric Seidel]

new-run-webkit-tests --child-processes=1
Will run all tests in the main thread with a single DRT process.

One of the things I would like to fix before foisting
new-run-webkit-tests onto everyone is to make the --help much clearer.
:)

-eric

On Mon, Apr 19, 2010 at 12:13 PM, Alexey Proskuryakov  wrote:
>
> On 18.04.2010, at 23:57, Eric Seidel wrote:
>
>> If you're on a Mac and would like to experience sub-3-minute layout
>> test runs and are willing to deal with a few bugs, try
>> new-run-webkit-tests instead of run-webkit-tests next time you run the
>> tests.  We'd love to see questions/comments/complaints you have.
>
>
> Is it possible to NOT run the tests in parallel? A useful method for dealing
> with flaky tests is to repeat them many times, and running them sequentially
> is better for this use case.
>
> run-webkit-tests --repeat-each 100 http/tests/appcache # uh-oh, filing a bug
>
> - WBR, Alexey Proskuryakov
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Warning: expect commit-queue delays

[Eric Seidel]

The commit-queue [1] is up to 28 patches (20 bugs) due to the tree
being red most of yesterday and all of last night.  It's green now and
landing things, but it will take it most of today to catch up.

Anything time-sensitive that you need landed should be landed manually. [2]

Sorry for the delay.  I'll let you know when we're back to normal.

-eric

1.  You can see the list of bugs here:
https://bugs.webkit.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&order=Last+Changed

2. webkit-patch can help with manual landing:
webkit-patch land-from-bug BUGNUMBER (--build and --test optional)
or
webkit-patch land (--build and --test optional)
if you already have it in your tree.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Volcano

[Eric Seidel]

I should have asked sooner...

Are any folks stuck here after the WebKit conference due to the volcano?

If so, drop me a line.  I'd like to at least offer lunch and possibly
some in-person hack-time.

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

Re: [webkit-dev] Warning: expect commit-queue delays

[Eric Seidel]

The tree is green again finally.  The CQ up to 35 patches now, but is
running.  It won't be empty by morning but it should make a big dent.

-eric

On Tue, Apr 20, 2010 at 12:36 PM, Eric Seidel  wrote:
> The commit-queue [1] is up to 28 patches (20 bugs) due to the tree
> being red most of yesterday and all of last night.  It's green now and
> landing things, but it will take it most of today to catch up.
>
> Anything time-sensitive that you need landed should be landed manually. [2]
>
> Sorry for the delay.  I'll let you know when we're back to normal.
>
> -eric
>
> 1.  You can see the list of bugs here:
> https://bugs.webkit.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&order=Last+Changed
>
> 2. webkit-patch can help with manual landing:
> webkit-patch land-from-bug BUGNUMBER (--build and --test optional)
> or
> webkit-patch land (--build and --test optional)
> if you already have it in your tree.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Volcano

[Eric Seidel]

What is this morning thing you speak of?   I've been up way late hacking, again.

I'll check in with any hackers still stranded in SF when I wake. :)

-eric

On Tue, Apr 20, 2010 at 3:02 PM, Philippe Normand  wrote:
> Currently in 1195 Oak st but it closes at 5pm. Eric suggested Cafe Abir
> on 1300 Fulton st.
>
> I have to go tomorrow afternoon to Sunnyvale for a meeting but in the
> morning I should be in the Cafe Abir :)
>
> I'm open to any suggestion anyway! Currently staying in Haight st around
> #800, I'd prefer to stay around if possible.
>
> Philippe
>
> On Tue, 2010-04-20 at 14:37 -0700, Evan Martin wrote:
>> I am down for a post-gathering SF hackathon.  Name a cafe and time.  :)
>>
>> On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand  
>> wrote:
>> > Hi,
>> >
>> > I'm stuck in SF until sunday, unless I can find a flight earlier...
>> > Hacking from a café there on some GTK fullscreen video support :)
>> >
>> > Philippe
>> >
>> > On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
>> >> I should have asked sooner...
>> >>
>> >> Are any folks stuck here after the WebKit conference due to the volcano?
>> >>
>> >> If so, drop me a line.  I'd like to at least offer lunch and possibly
>> >> some in-person hack-time.
>> >>
>> >> -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
>> >
>> >
>>
>
>
> ___
> 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] JSC String re-factorings are hosing the tree.

[Eric Seidel]

A large portion of the tree redness in the last 3 days is due to JSC
string re-factoring.

We need to build some better tools, or find some better method to land
these changes w/o hosing the tree.  I'm happy to help with building of
said tools if folks have requests/suggestions.

Broken in 58001  Fixes: 58003, 58006, 58007, 58008, 58010
Time: 55m

Broken in 57904   Fixes: 57908, 57911, 57912, 57917
Time 1hr 45m

Broken in 57829   Attempted fix: 57835, Rolled out in:57853
Time: 3h 21m

Re-broke in 57879   Fixes: 57883, 57884
Time: 3h 3m

Getting 57829 landed resulted in nearly a full work-day of tree
redness. :(  Also, even once a change is fixed, it will take 15 mins
or so for all the bots to cycle green.

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

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

[Eric Seidel]

On Wed, Apr 21, 2010 at 3:35 PM, Ojan Vafai  wrote:
> Also, maybe we could use one of the Windows test bots for the initial trial
> of new-run-webkit-tests. Do we know how may cores are on those windows
> machines? The improvement in running the tests will be roughly proportional
> to the number of cores on the machine.

We'll be starting NRWT testing on the bots tonight.  However, I don't
think NRWT works on Windows yet.  Adam Roben had some half-working
patches to that affect, but I don't think they're done yet.  Mostly
they involve ripping out chromium-specific windows assumptions. :)

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

[webkit-dev] DumpRenderTree Output

[Eric Seidel]

Am I correct that all text output from DumpRenderTree should be utf-8
(thus all expected.txt files as well)?

The Mac Code appears to use utf-8:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L1091

Obviously it also will spit raw bytes (like webarchives and pdf files)
over stdout as well.

I just want to confirm with the community that utf-8 for all
-expected.txt files is expected behavior?

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

Re: [webkit-dev] DumpRenderTree Output

[Eric Seidel]

Apple Win code too:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L686

Gtk too:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/gtk/DumpRenderTree.cpp#L390
(since Gtk supposedly uses utf8 for all of its strings)

And Qt:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTreeQt.cpp#L752

I think I've answered my own question.  Thanks.


On Fri, Apr 23, 2010 at 2:39 PM, Eric Seidel  wrote:
> Am I correct that all text output from DumpRenderTree should be utf-8
> (thus all expected.txt files as well)?
>
> The Mac Code appears to use utf-8:
> http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L1091
>
> Obviously it also will spit raw bytes (like webarchives and pdf files)
> over stdout as well.
>
> I just want to confirm with the community that utf-8 for all
> -expected.txt files is expected behavior?
>
> -eric
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?

[Eric Seidel]

DerivedSources are generated from here:
http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make

I think what your'e thinking of as DerivedSources is actually just the
javascript bindings, which will be useless to you w/o the actual
implementations in WebCore.

If for some reason you wanted to write your own custom bindings which
use JSC's public API instead of the internal one which WebCore uses,
you could make your own generator script:
http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/

You can see examples of those scripts being run in DerivedSources.make
or in run-bindings-tests:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests

In short, this is not a supported configuration. :)  I'm also not
really sure it's on topic for this list.

Best of luck!

-eric

On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam  wrote:
> Hi, I'm working on a project which makes use of JavaScriptCore as a
> scripting engine outside of WebKit.  It would be very helpful to us if we
> could get access to the DOMParser and XMLSerializer classes which are in
> WebKit's DerivedSources area.  However, it seems that those libraries are
> using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value,
> etc.) rather than the public interface expected by external users of
> JavaScript Core.
>
> We'd also like to avoid pulling in the internal WebKit headers anyway, as
> this would complicate our build system (for example, we'd like to be able to
> do this just using the header files provided by Ubuntu's libwebkit-dev
> package).  I'm fine with writing forward-declaration classes and stub
> methods for the purpose of letting the C++ linker figure it all out, but
> JSC::JSValue seems to get in the way of this idea, since the
> getConstructor() methods on the libraries we want return it by value rather
> than by reference (and it doesn't appear to be a simple reinterpret_cast
> like it is for the other public-API classes).
>
> Is there some official way that we can get at WebKit's DerivedSources
> library functionality in a non-WebKit JavaScript Core application, or can
> anyone think of some tricky-but-relatively-clean way to do it that doesn't
> involve our app having to see JSC's internal API?
>
> Thanks in advance.
>
>
> ___
> 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] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?

[Eric Seidel]

Various WebKit ports expose different bindings.  The JS bindings are
only exposed to scripts on pages run inside WebKit.

If you have your own separate javascript environment, you would need
to set up your own custom bindings for that environment.  We don't
really provide clean APIs for that, however, there has been talk over
the years of taking the bindings/scripts and making it possible for
clients of WebKit to generate JSC-API compatible autogenerated
bindings wrapping their own implementation objects.

You'd still have to write your own implementation objects which talked
to the right pieces of WebKit/WebCore however.

I think you'll run into a world of pain if you try and just expose
guts of WebCore to clients outside of WebCore w/o having gone through
the normal WebCore parsing mechanisms and created a Page, Frame,
Client objects, etc.

Anyway, best of luck and we look forward to seeing your contributions.

-eric

On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam  wrote:
> Thanks.  I apologize for mincing terminology - I'm not particularly versed
> in how WebKit is put together, where WebKit ends and JavaScriptCore begins,
> etc., and I've mostly been banging my head against this based on looking at
> work that some of my coworkers have done. :)
>
> I should be more specific that we are in fact linking against WebKit and so
> we will have the implementations available.  We are actually using full
> WebKit for another part of the system as well, but we'd like to be able to
> access WebKit's JS bindings from outside of the WebKit view.
>
> It looks like bindings/scripts bit will help me get on the right track, in
> any case.  Thanks for the pointer.
>
>
> Eric Seidel wrote:
>
> DerivedSources are generated from here:
> http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make
>
> I think what your'e thinking of as DerivedSources is actually just the
> javascript bindings, which will be useless to you w/o the actual
> implementations in WebCore.
>
> If for some reason you wanted to write your own custom bindings which
> use JSC's public API instead of the internal one which WebCore uses,
> you could make your own generator script:
> http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/
>
> You can see examples of those scripts being run in DerivedSources.make
> or in run-bindings-tests:
> http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests
>
> In short, this is not a supported configuration. :)  I'm also not
> really sure it's on topic for this list.
>
> Best of luck!
>
> -eric
>
> On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam 
> wrote:
>
>
> Hi, I'm working on a project which makes use of JavaScriptCore as a
> scripting engine outside of WebKit.  It would be very helpful to us if we
> could get access to the DOMParser and XMLSerializer classes which are in
> WebKit's DerivedSources area.  However, it seems that those libraries are
> using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value,
> etc.) rather than the public interface expected by external users of
> JavaScript Core.
>
> We'd also like to avoid pulling in the internal WebKit headers anyway, as
> this would complicate our build system (for example, we'd like to be able to
> do this just using the header files provided by Ubuntu's libwebkit-dev
> package).  I'm fine with writing forward-declaration classes and stub
> methods for the purpose of letting the C++ linker figure it all out, but
> JSC::JSValue seems to get in the way of this idea, since the
> getConstructor() methods on the libraries we want return it by value rather
> than by reference (and it doesn't appear to be a simple reinterpret_cast
> like it is for the other public-API classes).
>
> Is there some official way that we can get at WebKit's DerivedSources
> library functionality in a non-WebKit JavaScript Core application, or can
> anyone think of some tricky-but-relatively-clean way to do it that doesn't
> involve our app having to see JSC's internal API?
>
> Thanks in advance.
>
>
> ___
> 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] Testing changes to CodeGenerator*.pm

[Eric Seidel]

Since I'm in the bindings hall of shame, I guess I'm supposed to reply. ;)

The twice that I've used it, it was very helpful.  The few reviews
I've done of Adam's it was much better than what we had before.
However, I agree something better could be built.  I'm just not sure
what better looks like yet.  I expect when Adam finishes getting rid
of custom bindings code he'll have a better idea. :)

I'm surprised this thread so much attention.

-eric

On Thu, Apr 29, 2010 at 1:38 PM, Maciej Stachowiak  wrote:
>
>
> On Apr 29, 2010, at 1:05 PM, Adam Barth wrote:
>
> On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak  wrote:
>
> It seems to me a better model would be to regenerate the bindings test file
>
> automatically as part of the build. Then the changes can still be reviewed
>
> by you, or as part of a diff, but there would be no extra manual steps
>
> involved. And people making behaviorally transparent changes to codegen
>
> output would perhaps feel a little less burdened.
>
> That sounds like a good improvement.  I think it would be fine to
> regenerate the output as part of the build.  However, I think we
> should still preserve the ability to run the script along it "test"
> mode because that's about three orders of magnitude faster than
> performing a build after touching CodeGeneratorJS.
>
> Alexey (or others who don't like the new tests), do you think this change
> would address your concerns?
> On Apr 29, 2010, at 1:05 PM, Adam Barth wrote:
>
> What I hear from this conversation is the following:
>
> 1) A bunch of people who've used the tool saying that they've found it
> useful.
> 2) A bunch of people who haven't used the tool suggesting improvements.
>
> This tool impacts the handful of people who work on
> CodeGeneratorJS.pm.  Everyone else in the project can safely ignore
> it.  I'm all for improvements, and I invite anyone interested to
> either improve the tool or write a new tool that does the job better.
>
> If everyone has to use the tool for the tool to be useful, then ideally we
> want a system where the people who change the bindings frequently mostly buy
> into. Here is the list of people with more than 5 all-time commits in the
> WebCore/bindings/scripts directory. Ideally I'd like to hear from more of
> these what they think would be helpful and not burdensome.
>   59  wei...@apple.com
>   46  e...@webkit.org
>   35  da...@apple.com
>   32  jap...@chromium.org
>   29  oli...@apple.com
>   26  gga...@apple.com
>   26  dglaz...@chromium.org
>   16  aba...@webkit.org
>   14  zimmerm...@webkit.org
>   12 �...@webkit.org
>   10  aro...@apple.com
>    8  le...@chromium.org
>    7  ...@apple.com
>    7  da...@chromium.org
>    6  timo...@apple.com
>    6  s...@chromium.org
>    6  jia...@chromium.org
>    6  ddkil...@apple.com
>    6  cwzwar...@webkit.org
> Here is the command anyone can run to see the full list (assuming you have
> an SVN checkout):
> $ svn log WebCore/bindings/scripts | grep '|.*@' | sed -e 's/^[^|]* |//g; s/
> | .*$//g;' | sort | uniq -c | sort -rn
> The long tail of people who have made only a few bindings changes is rather
> large, so I suspect this tool affects more than a handful people, if it
> becomes a mandatory part of the process.
> 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

[webkit-dev] Python on the Tiger build bot

[Eric Seidel]

WebKitTools/Scripts/webkitpy python requires 2.5+.

We'd like to be able to use python 2.5 on the Tiger build bot (for
websocket tests among other things).

Would someone be able to install a newer Tiger on that machine?

Here is python 2.6.5 for the mac:
http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg

Thanks!

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

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

[Eric Seidel]

This issue has resurfaced again today.  We had 3 long breaks from 3
different people all related to JSC changes in the last 24 hours. :(

FYI, the WinEWS bot is up and running again (this time for good!) as
of 48 hours ago.  I don't think it's quite caught up yet, and it takes
about 60 mins to cycle for big builds.  However, it's at least able to
provide some information for patches which are up for review for an
hour or more.

-eric

On Wed, Apr 21, 2010 at 3:27 PM, Gavin Barraclough
 wrote:
> Hi Eric,
>
> Many apologies for the redness.  These changes are pretty much complete now,
> so hopefully there shouldn't be any more big file moves like this too soon.
>
> One thing that was hugely useful in minimizing the breakage as much as
> possible while making these changes was the ews bots – these generally
> helped me to get my patches building cleanly on all platforms bar Windows
> before committing.  It is a real shame that an ews bot isn't available for
> Windows, since this would be particularly useful - JSC changes frequently
> break Windows builds due to the .def files.
>
> I believe a big problem that caused the extended periods of redness was the
> slowness of the Windows test queues.  These can lag badly behind the builds,
> making failures here very are easy to miss - having landed a large change,
> and waited to watch the waterfall stay green for an extended period of time,
> it was easy to be under the misapprehension that everything was okay.  Only
> later would I discover windows test had started to fail.  Clearly there is a
> lesson I've learned here, but maybe we can find some more hardware to throw
> at these queues, to help them avoid getting quite so far behind.
>
> cheers,
> G.
>
>
> On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote:
>
>> A large portion of the tree redness in the last 3 days is due to JSC
>> string re-factoring.
>>
>> We need to build some better tools, or find some better method to land
>> these changes w/o hosing the tree.  I'm happy to help with building of
>> said tools if folks have requests/suggestions.
>>
>> Broken in 58001  Fixes: 58003, 58006, 58007, 58008, 58010
>> Time: 55m
>>
>> Broken in 57904   Fixes: 57908, 57911, 57912, 57917
>> Time 1hr 45m
>>
>> Broken in 57829   Attempted fix: 57835, Rolled out in:57853
>> Time: 3h 21m
>>
>> Re-broke in 57879   Fixes: 57883, 57884
>> Time: 3h 3m
>>
>> Getting 57829 landed resulted in nearly a full work-day of tree
>> redness. :(  Also, even once a change is fixed, it will take 15 mins
>> or so for all the bots to cycle green.
>>
>> -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] Python on the Tiger build bot

[Eric Seidel]

WebKit's gold-standard development system appears to be Leopard.  (I
would guess Snow Leopard, except the SL bots only finally turned green
about two weeks ago.)  Leopard's python is 2.5.1.

I agree that we should target making development as simple as possible
for the common/standard system.  I think WebKit does an excellent job
of this, although we could always do better.

However, for sub-standard systems (like Windows) we require a few
additional install steps (http://webkit.org/building/tools.html).
(Window's cygwin python is 2.5.5.)

1.  I think Python 2.3 is an example of a sub-standard system.

2.  Additionally, Tiger seems mostly ignored by WebKit (note examples
like https://bugs.webkit.org/show_bug.cgi?id=38743).  No one develops
on Tiger to my knowledge (note mjs last night in #webkit noting how he
had no access to a Tiger machine, I certainly don't have access to
one).

I'm happy to add a brief note to the tools.html page noting that
python 2.5 is required and linking to a page.

Our scripts already print:
webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
support your current Python version (2.4.6).  The minimum supported
version is 2.5.

I'm happy to augment that warning to provide a download URL.

In short, I don't think Tiger (which appears legacy and
maintenance-mode only at this point) should hold hostage our script
development on all platforms.  We should simply update the bot and be
done with things. :)

-eric


On Fri, May 7, 2010 at 11:29 AM, David Levin  wrote:
>
>
> On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov  wrote:
>>
>> I thought the agreement was that "essential" tools shouldn't add more
>> requirements on the installed tools. Is it not the case?
>
> fwiw, that wasn't how I understood this
> thread: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html
> Note I expressed that opinion early in the thread
> here: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10300.html
> But the discussion went on from there and seem to indicate
> that python 2.5 would be fine.
> dave
>>
>> - WBR, Alexey Proskuryakov
>>
>>
>> 06.05.2010, в 21:30, Eric Seidel написал(а):
>>
>> > WebKitTools/Scripts/webkitpy python requires 2.5+.
>> >
>> > We'd like to be able to use python 2.5 on the Tiger build bot (for
>> > websocket tests among other things).
>> >
>> > Would someone be able to install a newer Tiger on that machine?
>> >
>> > Here is python 2.6.5 for the mac:
>> >
>> > http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
>> >
>> > Thanks!
>> >
>> > -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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Buildbots now running test-webkitpy and test-webkitperl

[Eric Seidel]

If you don't touch our python or perl scripts you can stop reading.


If you do, you should be aware that all the buildbots [1] are now [2]
running test-webkitpy and test-webkitperl after every commit.  This
means python/perl changes can break the tree like any other change and
the sherriffbot will yell at you if you do. :)

Note the total testing time for the python and perl tests together is
slightly over 10 seconds. :)

-eric

1.  Tiger doesn't run test-webkitpy yet as its python version is too old.
2. wms restarted the master tonight,
https://bugs.webkit.org/show_bug.cgi?id=37976 is when the magic
happened.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Eric Seidel]

I am not certain as to which "agreement" you refer.  However, I can
understand that historically we viewed the python tools as less
"essential" than they appear to have become.

Just as we moved from CVS to SVN and at that time required all Tiger
machines to install an SVN package, so too today are an increasingly
large number of our scripts moving from depending on perl 5 to Python
2.5+.

I would appreciate assistance from the bot maintainer to update the
one Tiger machine, as it is the only machine which uses such an old
copy of Python.  All other operating systems/machines already use much
newer versions of Python.  The WebKit project requires Leopard's 2.5
python as a minimum installed version.

I will post a patch to update the tools.html page to note the
requirement shortly.

-eric

On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov  wrote:
>
> I thought the agreement was that "essential" tools shouldn't add more 
> requirements on the installed tools. Is it not the case?
>
> - WBR, Alexey Proskuryakov
>
>
> 06.05.2010, в 21:30, Eric Seidel написал(а):
>
>> WebKitTools/Scripts/webkitpy python requires 2.5+.
>>
>> We'd like to be able to use python 2.5 on the Tiger build bot (for
>> websocket tests among other things).
>>
>> Would someone be able to install a newer Tiger on that machine?
>>
>> Here is python 2.6.5 for the mac:
>> http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
>>
>> Thanks!
>>
>> -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] prepare-Changelog crashing on cygwin

[Eric Seidel]

On Mon, May 10, 2010 at 11:31 AM, Eric Seidel  wrote:
> I have seen this on the win-ews ec2 instance.
>
> On May 10, 2010 1:35 PM, "John Abd-El-Malek"  wrote:
>
> After reimaging my Windows 7 machine, prepare-Changelog always crashes for
> me now.  It seems to have problems running "svn diff".  I installed cygwin
> through the installer on webkit.org.  I don't have any anti-virus programs
> running, and DEP is turned off for cygwin.exe and svn.exe.  Has anyone else
> seen this?
>
> Thanks,
> John
>
> jabdelma...@jabdelmalek0-w /cygdrive/d/WebKit/WebKit/chromium
> $ ../../WebKitTools/Scripts/prepare-ChangeLog
>   Running status to find changed, added, or removed files.
> ?       svn.exe.stackdump
>   Reviewing diff to determine which lines changed.
>       0 [main] svn 1652 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 1652 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 7828 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>       0 [main] svn 7828 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION   1863 [main] svn 7828 open_stackdumpfile: Dumping
> stack trace
>  to svn.exe.stackdump
>    1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 6132 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 6132 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       1 [main] svn 15284 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       1 [main] svn 15284 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 9296 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>    2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 10444 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 10444 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 12428 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 12428 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 3940 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>       0 [main] svn 3940 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION   1538 [main] svn 3940 open_stackdumpfile: Dumping
> stack trace
>  to svn.exe.stackdump
>    1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 15008 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>    2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 14496 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
>       0 [main] svn 14496 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
>    1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
> svn.exe.stackdump
> exec of 'diff' failed: Bad addresssvn: 'diff' returned 255
>   Extracting affected function names from source files.
>   Change author: John Abd-El-Malek .
>   Running 'svn update' to update ChangeLog files.
>     At revision 59081.
>   Editing the ./ChangeLog file.
> -- Please remember to include a detailed description in your ChangeLog
> entry. --
> -- See <http://webkit.org/coding/contributing.html> for more info --
>
> ___
> 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] Yet another bug-less change hosed the tree.

[Eric Seidel]

This is the 3rd in the last few days.

http://trac.webkit.org/changeset/59086

I thought it was generally good practice to have bug.webkit.org bugs
with changes?

webkit-patch upload certainly attempts to make that easy.  If there
are other tools we can build to make it easier to always commit with a
bug URL in ChangeLogs I'm happy to build them.  Thoughts?

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

Re: [webkit-dev] prepare-Changelog crashing on cygwin

[Eric Seidel]

Is this caused by the base load address of both perl and svn
conflicting/overlapping?  (I don't really know how CYGWIN works.)

Is this something we should detect in our scripts and warn about?

On Mon, May 10, 2010 at 12:41 PM, John Abd-El-Malek  wrote:
> btw, I finally solved this.  credit to tonyg:
> 1) close cygwin
> 2) C:\cygwin\bin>ash rebaseall
>
> On Mon, May 10, 2010 at 12:20 PM, Eric Seidel  wrote:
>>
>> On Mon, May 10, 2010 at 11:31 AM, Eric Seidel  wrote:
>> > I have seen this on the win-ews ec2 instance.
>> >
>> > On May 10, 2010 1:35 PM, "John Abd-El-Malek"  wrote:
>> >
>> > After reimaging my Windows 7 machine, prepare-Changelog always crashes
>> > for
>> > me now.  It seems to have problems running "svn diff".  I installed
>> > cygwin
>> > through the installer on webkit.org.  I don't have any anti-virus
>> > programs
>> > running, and DEP is turned off for cygwin.exe and svn.exe.  Has anyone
>> > else
>> > seen this?
>> >
>> > Thanks,
>> > John
>> >
>> > jabdelma...@jabdelmalek0-w /cygdrive/d/WebKit/WebKit/chromium
>> > $ ../../WebKitTools/Scripts/prepare-ChangeLog
>> >   Running status to find changed, added, or removed files.
>> > ?       svn.exe.stackdump
>> >   Reviewing diff to determine which lines changed.
>> >       0 [main] svn 1652 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 1652 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 7828 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >       0 [main] svn 7828 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION   1863 [main] svn 7828 open_stackdumpfile:
>> > Dumping
>> > stack trace
>> >  to svn.exe.stackdump
>> >    1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 6132 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 6132 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       1 [main] svn 15284 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       1 [main] svn 15284 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 9296 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >    2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 10444 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 10444 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 12428 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 12428 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >    1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 3940 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION
>> >       0 [main] svn 3940 exception::handle: Exception:
>> > STATUS_ACCESS_VIOLATION   1538 [main] svn 3940 open_stackdumpfile:
>> > Dumping
>> > stack trace
>> >  to svn.exe.stackdump
>> >    1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to
>> > svn.exe.stackdump
>> >       0 [main] svn 15008 exception::

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

[Eric Seidel]

Correct.  Bill is not the blocker on the
fix-the-author-to-be-not-e...@webkit.org-in-postcommit-patch.  The
blocker how fast I'm able to pop items off my work queue.  I'm happy
to hand this item to someone else.  Bill will have to be involved in
the end.

The plan was detailed here:
https://lists.webkit.org/pipermail/webkit-dev/2010-April/012350.html

I just filed https://bugs.webkit.org/show_bug.cgi?id=38870
If anyone would like to lead that to completion, I'm happy to pass it off.

-eric

On Mon, May 10, 2010 at 2:49 PM, William Siegrist  wrote:
> On May 10, 2010, at 2:44 PM, Adam Barth wrote:
>
>> On Mon, May 10, 2010 at 2:31 PM, Geoffrey Garen  wrote:
>>>> If you'll allow me to climb higher on my horse, I'll advocate for
>>>> landing patches like this through the commit queue.
>>>
>>> Personally, I find the output of the commit queue incredibly confusing, 
>>> since it claims that Eric Seidel wrote every patch.
>>
>> Indeed.  Fortunately, we know how to solve that problem.  It just
>> requires a post-commit hook to change the svn author to match the
>> ChangeLog.  I think Eric already wrote the hook.  We just need someone
>> on the server side to install it.
>>
>
> I don't believe I've seen a patch for this yet. We discussed it at the 
> contributors meeting, but I think Eric was going to file a bug with a patch.
>
> -Bill
> ___
> 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] New in-rietveld patch flag

[Eric Seidel]

As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
new flag to bugzilla patches called "in-rietveld".

This flag may be changed or removed in the coming weeks.  If you have
questions/comments/concerns please bring them up with Ojan or Julie on
the bug.

Thanks to both of them for doing the leg-work to try and improve our
reviewing experience!

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

Re: [webkit-dev] New in-rietveld patch flag

[Eric Seidel]

There is an "is Active" checkbox, which I could uncheck:
https://bugs.webkit.org/editflagtypes.cgi?action=edit&id=4

I'm not sure how the tools would be able to set this flag if I did that.

We could also hack the various UI to hide the flag?

-eric

On Mon, May 10, 2010 at 4:41 PM, Adam Barth  wrote:
> Can we hide this in the UI?  My understanding is that it will be used
> only by the tools.
>
> Adam
>
>
> On Mon, May 10, 2010 at 4:37 PM, Eric Seidel  wrote:
>> As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
>> new flag to bugzilla patches called "in-rietveld".
>>
>> This flag may be changed or removed in the coming weeks.  If you have
>> questions/comments/concerns please bring them up with Ojan or Julie on
>> the bug.
>>
>> Thanks to both of them for doing the leg-work to try and improve our
>> reviewing experience!
>>
>> -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] New in-rietveld patch flag

[Eric Seidel]

I have made the flag inactive.  it was driving my poor little eyes
bonkers.  I will work with Julie/Ojan on some less UI-hateful
solution.

-eric

On Mon, May 10, 2010 at 4:46 PM, Eric Seidel  wrote:
> There is an "is Active" checkbox, which I could uncheck:
> https://bugs.webkit.org/editflagtypes.cgi?action=edit&id=4
>
> I'm not sure how the tools would be able to set this flag if I did that.
>
> We could also hack the various UI to hide the flag?
>
> -eric
>
> On Mon, May 10, 2010 at 4:41 PM, Adam Barth  wrote:
>> Can we hide this in the UI?  My understanding is that it will be used
>> only by the tools.
>>
>> Adam
>>
>>
>> On Mon, May 10, 2010 at 4:37 PM, Eric Seidel  wrote:
>>> As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
>>> new flag to bugzilla patches called "in-rietveld".
>>>
>>> This flag may be changed or removed in the coming weeks.  If you have
>>> questions/comments/concerns please bring them up with Ojan or Julie on
>>> the bug.
>>>
>>> Thanks to both of them for doing the leg-work to try and improve our
>>> reviewing experience!
>>>
>>> -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] Python on the Tiger build bot

[Eric Seidel]

On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak  wrote:
> My feeling about requiring a higher Python version for Tiger remains this:
>
> "I'd prefer that we provide an easy means to do the install of Python 2.6
> (ideally a single script you can run, and ideally without affecting the
> system copy), rather than making every Tiger developer figure it out on
> their own."
> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html
>
> For those of us who still need to support Tiger, it would be a huge hassle
> to have to figure out how to update Python manually to even run the layout
> tests. The fact that it's not a primary development platform doesn't mean
> that it's ok to add stumbling blocks to the development process. In fact, it
> kinda makes it less ok, because then it takes more work to shift gears when
> fixing a Tiger-specific bug.

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

> At minimum, there should be instructions here, and ideally the install
> should be one step:
> http://webkit.org/building/tools.html

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

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

Re: [webkit-dev] prepare-Changelog crashing on cygwin

[Eric Seidel]

More information about rebase here:
http://www.tishler.net/jason/software/rebase/rebase-2.2.README

I still haven't found any way to detect the problem so we could warn
people before scripts start blowing up.

-eric

On Mon, May 10, 2010 at 1:33 PM, Peter Kasting  wrote:
> On Mon, May 10, 2010 at 1:27 PM, Tony Gentilcore  wrote:
>>
>> On Mon, May 10, 2010 at 1:07 PM, Eric Seidel  wrote:
>>>
>>> Is this caused by the base load address of both perl and svn
>>> conflicting/overlapping?  (I don't really know how CYGWIN works.)
>>
>> I'm by no means a cygwin expert. I just happened to run into the same
>> problem last week.
>> This thread is where I found that solution (first suggested by evan):
>>
>> http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/bac1846c2678152d/4b9548cdd7214e4e
>
> Note that the official webkit.org instructions tell you to do this:
> http://webkit.org/building/tools.html
>>>
>>> Is this something we should detect in our scripts and warn about?
>
> I believe it's possible by checking the existing base addresses of the
> modules.  I'm not sure on exactly how to do it.
> PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit Nightly website scripts

[Eric Seidel]

Those which can be found in SVN can be found here:
http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/

Last I heard, the rest are on Mark Rowe's harddrive, somewhere.

-eric

On Sat, May 8, 2010 at 5:10 PM, Trevor Downs  wrote:
> Hi. I'm trying to find the scripts for , but I
> can't find them in the SVN. Would someone be kind enough to direct me to
> them?
>
> Sincerely,
>
> Trevor Downs,
>
> un-certified looney
>
> ___
> 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] Yet another bug-less change hosed the tree.

[Eric Seidel]

On Mon, May 10, 2010 at 6:04 PM, Brent Fulgham  wrote:
> On Mon, May 10, 2010 at 2:44 PM, Adam Barth  wrote:
>> On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen  wrote:
 2) Your patch can be vetted by the various bots that analyze patches
 posted for review.
>>>
>>> True, if what you're really asking for is not just a bug report but also a 
>>> "cooling off period" during which
>>> you wait for a result from the EWS bot, even if you get a review right 
>>> away. You get greater value in the
>>> case of a bad patch, but also greater cost in the case of every patch.
>>
>> Yes, this way of doing things has more overhead for you personally but
>> saves overhead for everyone else in the project.  The question, as I
>> see it, is which of these quantities is larger.  The more people that
>> work on the project, the bigger the multiplier on the right.
>
> I'm not sure this is totally correct.  I'm sure more people than
> ggaren find the TPS cover sheet / cooling off period to be an added
> cost.  These added costs apply to *all* developers, whether they land
> bad patches or not.

I would like to debunk the "cooling off period myth".  There is no one
telling you (besides your reviewer) that you need to wait for all the
EWS bots to cycle.  They're there for informational (Warning, it's in
their name even) purposes only.  If your reviewer is happy to r+
before the bots have cycled, go for it. :)

> You seem to be advocating a system that imposes a (perhaps small) cost
> on every development 'transaction' as insurance against the (possibly
> high) cost of a build breakage.  I'm not sure the cost/benefit is
> clear here.

As Maciej states, webkit-patch upload is pretty quick (at least for
git users).  Quicker to me, than trying to send an email, or get
paste-bin review.  The other advantage for me (personally) of using
bugzilla for all my reviews is that I can mark them commit-queue=? and
then chuck them from my tree.  I understand that that doesn't
necessarily work for everyone as well, especially with the tree being
red enough as of late that the cq has been blocked for sometimes days
at a time.
___
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.

[Eric Seidel]

Sent from the wrong email address the first time, sorry.

>> 2) Your patch can be vetted by the various bots that analyze patches
>> posted for review.
>
> True, if what you're really asking for is not just a bug report but also a 
> "cooling off period" during which you wait for a result from the EWS bot, 
> even if you get a review right away. You get greater value in the case of a 
> bad patch, but also greater cost in the case of every patch.

I'm not a big fan of the current delay.  We need to make the EWS
cycletime shorter.  That said, I commonly see the Qt bot and Style
bots cycle before I even get a chance to go pull up my bug URL to send
it to someone.  The bots themselves are generally very quick (except
windows), but they only poll every 5 minutes, which makes them feel
slow.

In either case, there is no minimum cooling off period.  You can
always chose to ignore the bots.  But not posting to a patch means you
asked someone to do a review without critical data like "does it
build". :)  Personally I reject any patches which aren't submitted to
me via bugzilla, the bots take care of so much of the reviewing for
me. :)

>> 3) The but serves as a coordination point for dealing with bustage
>> caused by a patch and for regressions detected later.
>
> Isn't it just as easy to open a bug on demand, if regressions are detected?

Opening bugs after the fact is possible.  The sherriffbot knows how to
do that, iirc.  But it's much easier if the commit itself has the bug
number so that no one has to go searching for a bug number after the
fact. :)

>>> Personally, I'd prefer it if we kept the TPS reports in our project to a
>>> minimum. In this case, a TPS report would have been more typing than the
>>> patch itself.
>>
>> That's part of what motivated us to create webkit-patch, which makes
>> creating and managing bugs and patches quite easy.

Less TPS is entirely the reason for webkit-patch. :)  At least my reasons.

> Maybe I would use webkit-patch if it really were quite easy. I tried it in 
> earnest for a while, but I had to give it up because:
> * I couldn't find a ChangeLog workflow that fit its demands, so using it was 
> actually more complicated than doing everything by hand

- I would be interested to know more.

> * It didn't handle subdirectory-only work

- Yes, not being an SVN user I don't feel this pain, but I agree this
needs fixing.  https://bugs.webkit.org/show_bug.cgi?id=28445 is one
related bug.

> * It often failed with mysterious error messages

- Would love to know more. :)

>> When you go cowboy and commit without
>> building and testing, you impose costs on everyone else in the
>> project.
>
> Probably not fair to conflate shooting a six-shooter with committing without 
> filling out a bugzilla form first.

Well, in the 3 commits in question all of them broke Snow Leopard,
which means that either whoever wrote them isn't using a Mac, or they
just didn't build themselves.  Including a bug number has numerous
benefits, but it certainly isn't a panacea and certainly doesn't solve
the general shoot-from-the-hip-and-run-away behavior. :)

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

[webkit-dev] Gtk bots are failing due to too many new tests

[Eric Seidel]

http://build.webkit.org/console

If someone with a Gtk build could post come baselines that would be fantastic!

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

[webkit-dev] Commit Queue Users: expect delays.

[Eric Seidel]

In the last 3 days the commit-queue has not been keeping up.  Due
partially to tree redness, and partially to graphics card troubles on
the machine (https://bugs.webkit.org/show_bug.cgi?id=38912) .  The
tree is green now, but I do not expect the commit-queue to be able to
keep up until we solve the graphics card issues.

My apologies for anyone waiting on their patches.  I'll send an update
when I know more.

-eric

List of patches:
https://bugs.webkit.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&order=Last+Changed

Queue status:
http://webkit-commit-queue.appspot.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Commit Queue Users: expect delays.

[Eric Seidel]

I have a (non-sustainable) hack in place where I have downgraded the
version number on the commit-queue's CoreVideo.framework to trick
WebKit into disabling hardware compositing (due to radar 7969612), and
I've hacked the commit-queue not to run compositing/iframes tests
(since they fail when HW compositing is disabled).

One longer term solution is to fix
https://bugs.webkit.org/show_bug.cgi?id=35897.

For now the commit-queue should be rolling again and should make it
through the 30 (!!) patches waiting in its queue tonight and tomorrow.

-eric

On Wed, May 12, 2010 at 10:48 AM, Eric Seidel  wrote:
> In the last 3 days the commit-queue has not been keeping up.  Due
> partially to tree redness, and partially to graphics card troubles on
> the machine (https://bugs.webkit.org/show_bug.cgi?id=38912) .  The
> tree is green now, but I do not expect the commit-queue to be able to
> keep up until we solve the graphics card issues.
>
> My apologies for anyone waiting on their patches.  I'll send an update
> when I know more.
>
> -eric
>
> List of patches:
> https://bugs.webkit.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&order=Last+Changed
>
> Queue status:
> http://webkit-commit-queue.appspot.com
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Eric Seidel]

That error looks like its trying to use python < 2.5.

Skipping the websocket tests on Tiger (manually at least) is bad.
Would be better to do it based on detected python.  Filed:
https://bugs.webkit.org/show_bug.cgi?id=39058
about doing just that.

-eric

On Thu, May 13, 2010 at 2:14 AM, Fumitoshi Ukai (鵜飼文敏)
 wrote:
> I heard on #webkit that the Tiger bot has been on Python 2.5 for some time,
> and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886
> and https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have
> consensus to use Python 2.5 (or later) for webkit development environment.
> I tried to land autoinstalled pywebsocket
> 0.5 https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on
> tiger bot when launching websocket server as below.
> Is python on the tiger bot still 2.3?
> I'm wondering why the script raises SyntaxError at with-statement, although
> it uses "from __future__ import with_statement" at the beginning of the same
> file.
> Doesn't python raise error when it tries to import with_statement, rather
> than it sees with statement later?
> Anyway, I just marked to skip websocket/tests on tiger for now, hoping
> python2.5 is available on tiger bot soon.
> This is log:
>  http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio
> websocket/tests .Traceback (most recent call last):
>   File "WebKitTools/Scripts/new-run-webkit-websocketserver", line 38, in ?
>     import webkitpy.layout_tests.port.websocket_server as websocket_server
>   File
> "/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py",
> line 241
>     with codecs.open(self._pidfile, "w", "ascii") as file:
>               ^
> SyntaxError: invalid syntax
> websocket/tests/bad-handshake-crash.html -> failed
> .
> websocket/tests/bad-sub-protocol-control-chars.html -> failed
> .
> websocket/tests/bad-sub-protocol-empty.html -> failed
> .
> websocket/tests/bad-sub-protocol-non-ascii.html -> failed
> .
> websocket/tests/bufferedAmount-after-close.html -> failed
> .
> websocket/tests/close-on-navigate-new-location.html -> failed
> .
> websocket/tests/close-on-unload-and-force-gc.html -> failed
> .
> websocket/tests/close-on-unload-reference-in-parent.html -> failed
> .
> websocket/tests/close-on-unload.html -> failed
> .
> websocket/tests/cross-origin.html -> failed
> .
> websocket/tests/error-detect.html -> failed
> .
> websocket/tests/frame-length-longer-than-buffer.html -> failed
> .
> websocket/tests/frame-length-skip.html -> failed
> .
> websocket/tests/frame-lengths.html -> failed
> .
> websocket/tests/handshake-error.html -> failed
> .
> websocket/tests/handshake-fail-by-cross-origin.html -> failed
> .
> websocket/tests/handshake-fail-by-sub-protocol-mismatch.html -> failed
> .
> websocket/tests/httponly-cookie.pl -> failed
> .
> websocket/tests/long-invalid-header.html -> failed
> .
> websocket/tests/multiple-connections.html -> failed
> Exiting early after 20 failures. 17934 tests run.
> 762.46s total testing time
> Traceback (most recent call last):
>   File "WebKitTools/Scripts/new-run-webkit-websocketserver", line 38, in ?
>     import webkitpy.layout_tests.port.websocket_server as websocket_server
>   File
> "/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py",
> line 241
>     with codecs.open(self._pidfile, "w", "ascii") as file:
>               ^
> SyntaxError: invalid syntax
> --
> ukai
> On Tue, May 11, 2010 at 15:07, Maciej Stachowiak  wrote:
>>
>> On May 10, 2010, at 11:01 PM, Eric Seidel wrote:
>>
>>> On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak  wrote:
>>>>
>>>> My feeling about requiring a higher Python version for Tiger remains
>>>> this:
>>>>
>>>> "I'd prefer that we provide an easy means to do the install of Python
>>>> 2.6
>>>> (ideally a single script you can run, and ideally without affecting the
>>>> system copy), rather than making every Tiger developer figure it out on
>>>> their own."
>>>> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html
>>>>
>>>> For those of us who still need to support Tiger, it would be a huge
>>>> hassle
>>>> to have to figure out how to update Python manually to even run the
>>>> layout
>>>> tests. The fact that

[webkit-dev] Cr Linux bot Hosed

[Eric Seidel]

Could someone with access to the Cr-Linux bot give it a kick?

http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/6703/steps/svn/logs/stdio

it's filesystem seems to have turned read-only.

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

Re: [webkit-dev] Broken test

[Eric Seidel]

Filed https://bugs.webkit.org/show_bug.cgi?id=39285 about that last night.

On Tue, May 18, 2010 at 10:15 AM, Adam Barth  wrote:
> The same test is failing on essentially all the bots:
>
> fast/files/file-reader.html
>
> http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r59670%20(10305)/fast/files/file-reader-pretty-diff.html
>
> The blame list computed by the bots is as follows:
>
> http://trac.webkit.org/changeset/59660
> http://trac.webkit.org/changeset/59661
> http://trac.webkit.org/changeset/59662
>
> However, that list doesn't make much sense.  If you touched some code
> related to this test yesterday, can you help figure out why its
> failing?
>
> Thanks,
> 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] Gtk Bot is out of space

[Eric Seidel]

http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug/builds/6146/steps/compile-webkit/logs/stdio

If someone could give it a kick, that'd be great.

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

[webkit-dev] Gtk 32-bit Release Bot Wedged

[Eric Seidel]

The Gtk 32-bit Release bot has wedged itself.  If someone could kick
it that would be grand:
http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html

Do we understand why this happens so we can prevent it in the future
(this is not the first time)?

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

Re: [webkit-dev] Gtk 32-bit Release Bot Wedged

[Eric Seidel]

Thank you.  Maybe run-webkit-tests should check to make sure plusaudio
is around before running?  Or is that specific to that machine's
config?

Thank you for looking into it.

-eric

On Thu, May 20, 2010 at 7:12 AM, Gustavo Noronha Silva  wrote:
> On Thu, 2010-05-20 at 00:20 -0700, Eric Seidel wrote:
>> The Gtk 32-bit Release bot has wedged itself.  If someone could kick
>> it that would be grand:
>> http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html
>>
>> Do we understand why this happens so we can prevent it in the future
>> (this is not the first time)?
>
> I kicked it. What happened was pulseaudio died. What I'll do is I'll
> have a daemon monitor make sure the pulseaudio server is running at all
> times, and automatically restart it if it drops again, since I could not
> investigate this bug.
>
> If this kind of thing happens when I'm not around, poking infinity or
> Mithrandir (IRC names of people who are also admins of the machines) is
> an option. They are always in #telepathy at FreeNode.
>
> Thanks!
>
> --
> Gustavo Noronha Silva 
> GNOME Project
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Gtk 32-bit Release Bot Wedged

[Eric Seidel]

On Thu, May 20, 2010 at 12:54 PM, Eric Seidel  wrote:
> We have various other bot support tools checked in under:
> http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/
> and
> http://trac.webkit.org/browser/trunk/WebKitTools/EWSTools
>
> You should feel encouraged to add more.
>
> -eric
>
> On Thu, May 20, 2010 at 12:52 PM, Adrian Perez  wrote:
>> On Thu, 20 May 2010 11:12:01 -0300
>> Gustavo Noronha Silva  wrote:
>>
>>> On Thu, 2010-05-20 at 00:20 -0700, Eric Seidel wrote:
>>> > The Gtk 32-bit Release bot has wedged itself.  If someone could kick
>>> > it that would be grand:
>>> > http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html
>>> >
>>> > Do we understand why this happens so we can prevent it in the future
>>> > (this is not the first time)?
>>>
>>> I kicked it. What happened was pulseaudio died. What I'll do is I'll
>>> have a daemon monitor make sure the pulseaudio server is running at
>>> all times, and automatically restart it if it drops again, since I
>>> could not investigate this bug.
>>
>> When we set up the Gtk+ debug bots, I was a bit concerned about the
>> fact that Pulseaudio or Xvfb could die, so I decided to run them under
>> daemontools [1], which nicely restarts services when they crash. I can
>> share the supervise scripts if, just ask if you want to a similar setup.
>> Also, we ended up running Buildbot itself and a small crash dump grabber
>> under daemontools, too.
>>
>> Cheers,
>>
>>
>> ---
>> [1] http://cr.yp.to/daemontools.html
>>
>> --
>> Adrian Perez 
>> Igalia - Free Software Engineering
>>
>> ___
>> 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] Update on HTML5 parser

[Eric Seidel]

You haven't missed much.  We didn't actually start until after
Mozilla's announcement.  http://trac.webkit.org/changeset/59638 was
the first commit (11 days ago).

On Fri, May 28, 2010 at 10:50 AM, Peter Kasting  wrote:
> On Fri, May 28, 2010 at 6:18 AM, Adam Barth  wrote:
>>
>> As some of you know, Eric and I have been working on implementing the
>> HTML5 parsing algorithm in WebKit.  This morning, at 5:58am, we
>> reached an important milestone: we got Gmail working.  :)
>
> Great progress, guys!  I had been wondering about the status of HTML5
> parsing in WebKit since Mozilla has recently flipped the switch on Firefox'
> HTML5 parser.  Glad to hear it's coming along :)
> PK
> ___
> 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] Disabling the scrollbars

[Eric Seidel]

This is a question for webkit-help, not webkit-dev, please move the
discussion there.

However, you can disable scrollbars on any frame using some CSS:

html {
overflow: none;
}

or similar.

On Mon, May 31, 2010 at 8:46 AM, Aram Hăvărneanu  wrote:
> On Mon, May 31, 2010 at 6:00 PM, Aram Hăvărneanu  wrote:
>> On Mon, May 31, 2010 at 5:06 PM, Aram Hăvărneanu  wrote:
>>> I'd like to disable the scrollbar
>>
>> To answer my own question, I need to call HRESULT
>> WebFrame::setAllowsScrolling(BOOL flag). To get an IWebFrame
>> interface, I call WebView::mainFrame().
>
> But it doesn't seem to work. Scrollbars still appear. What am I doing
> wrong? Is it not the main frame my main interest?
>
> Thanks.
>
> --
> Aram Hăvărneanu
> ___
> 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] DRAG_SUPPORT Wrappers missing in WebCore/page/gtk/EventHandlerGtk.cpp ????

[Eric Seidel]

"How do I compile" questions are best sent to webkit-help.  In this
case, it sounds like you've simply found a compile error with a
certain flag disabled.  Please file a bug at http://bugs.webkit.org
and post any patches there.

-eric

On Tue, Jun 1, 2010 at 8:31 AM, Deepak Mundra  wrote:
> Dear All,
>
> I was trying to compile webkit without DRAG_SUPPORT. So i set flag
> ENABLE_DRAG_SUPPORT to 0 in JavaScriptCore/wtf/Platform.h.
> But while compiling i got some errors and found that
>
> #if ENABLE(DRAG_SUPPORT)   wrappers are missing in file
> WebCore/page/gtk/EventHandlerGtk.cpp  for
>
> PassRefPtr EventHandler::createDraggingClipboard()
> and
> const double EventHandler::TextDragDelay = 0.0;
>
> So it will give compile error if you disable DRAG_SUPPORT and
> compile... I added these wrappers and compilation is going well so
> far..
>
> Please tell if this will cause any error..
>
> Thanks
> Deepak
> ___
> 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] Style question: static, protected, or public members

[Eric Seidel]

Let me summarize to see if I understand what should be updated in the
style guide/check-webkit-style:

Class static member variables should have an s_ prefix.
Protected and public member variables should be disallowed.
Private member variables should have an m_ prefix.
Struct member variables should have no prefix.

Did I understand correctly?


What about global statics?  Currently I believe most have no prefix.
Some have "k" or "g".

-eric

On Tue, May 25, 2010 at 9:44 AM, Darin Adler  wrote:
> On May 25, 2010, at 3:05 AM, TAMURA, Kent wrote:
>
>>> Generally speaking I suggest we do not use the "m_" prefix for the members 
>>> of structs. And I suggest that classes with public data members be structs 
>>> instead of classes. Classes that have public data members only for 
>>> historical reasons should be changed so the data members are not public. We 
>>> should talk some specific examples.
>>
>> As for protected data members, many classes use "m_" prefix. I found 
>> protected members without "m_" in HTMLTableCellElement and 
>> HTMLTableColElement. I guess they are legacy code and we should use "m_" for 
>> protected members too.
>
> Older classes did not use the "m_" prefix consistently. Public and protected 
> members were a little slower to get changed than others because they affected 
> more source files. We want to use "m_" for all non-static data members, but 
> data members should also be private.
>
> Generally speaking, protected data members should be avoided entirely. 
> Existing protected data members should generally be replaced with private 
> data members and we can add protected accessor functions as needed.
>
>    -- 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

[webkit-dev] WebCore Build Times

[Eric Seidel]

Has anyone spent any time trying to reduce the number of includes in
WebCore?  I know we have:
https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes

But I feel like we still have way too many unnecessary includes.  I
failed to find any tools for reducing build times or includes with my
brief Google searching.  But perhaps others have looked into this
problem for WebKit or other projects?

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.

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

Re: [webkit-dev] WebCore Build Times

[Eric Seidel]

I think were I to try attacking this, I would write a script to
generate a list of includes, and the number of cpp files which include
them.

Then I would work from the most-included end of that list, trying to
reduce the number of files include each include.

-eric

On Tue, Jun 8, 2010 at 4:04 PM, David Kilzer  wrote:
> On Jun 8, 2010, at 3:17 PM, Eric Seidel  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

[webkit-dev] Windows Release Slaves?

[Eric Seidel]

Looks like we lost them. :(

http://build.webkit.org/builders/Windows%20Release%20(Build)

Anyone know how to kick them?

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

Re: [webkit-dev] Windows Release Slaves?

[Eric Seidel]

Arguably a bug in buildbot.py [1], but currently the offline slave is
being treated as red, and thus the commit-queue is blocked until the
Windows slave is brought back online.

-eric

1. 
https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L337

On Wed, Jun 9, 2010 at 12:52 AM, Eric Seidel  wrote:
> Looks like we lost them. :(
>
> http://build.webkit.org/builders/Windows%20Release%20(Build)
>
> Anyone know how to kick them?
>
> -eric
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebCore Build Times

[Eric Seidel]

I've made one attempt at this with
https://bugs.webkit.org/show_bug.cgi?id=40350

It seems accessibility, javascriptcore and svg are the worst over-includers.

There are also a bunch of core element/node methods which are inline and
bring in a long list of header dependencies. We should consider creating a
new ElementInlines.h at some point, then only files which actually need the
inlines could include those.

On Jun 8, 2010 4:19 PM, "Eric Seidel"  wrote:
> I think were I to try attacking this, I would write a script to
> generate a list of includes, and the number of cpp files which include
> them.
>
> Then I would work from the most-included end of that list, trying to
> reduce the number of files include each include.
>
> -eric
>
> On Tue, Jun 8, 2010 at 4:04 PM, David Kilzer  wrote:
>> On Jun 8, 2010, at 3:17 PM, Eric Seidel  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

[webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

[Eric Seidel]

This causes a huge header dependency cascade, bloating object files
and slowing down builds.  I can't imagine avoiding the pointer
indirection is actually a measurable runtime savings (at least in most
cases).

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

Re: [webkit-dev] sick of forgetting bugzilla email addresses?

[Eric Seidel]

A real data feed from bugs.webkit.org of the user names would be best.
:)  If we had one for svn.webkit.org then we wouldn't need
commiters.py at all.  Commiters.py is a hack around lack of available
data from our servers.

Also, we keep hacking bugzilla, and yet our bugzilla is still
years-out-of date.  Seems we should upgrade to 3.x before we hack it
much more.  (One of the reasons why working outside of bugzilla via
 to the EWS status server for the bubbles, or a browser
extension for the autocomplete data is better than trying to hack our
ancient bugzilla.)

-eric

On Thu, Jun 10, 2010 at 4:08 PM, Ojan Vafai  wrote:
> On Thu, Jun 10, 2010 at 3:55 PM, Maciej Stachowiak  wrote:
>>
>> On Jun 7, 2010, at 2:30 PM, Julie Parent wrote:
>>>
>>> Thank you thank you thank you!
>>>
>>> I'm happy using this as a Chrome extension, but if there is enough
>>> interest to have it added to Bugzilla directly, I can do it (I already have
>>> a local bugzilla running for the Rietveld work).
>>
>> I think this would be a good addition to bugzilla itself.
>
>
>
> I agree. I just did it as a Chrome extension because I could do so as a <1
> day project. It would be relatively simple to do if the CORS headers were
> added to trac or svn.webkit.org as Adam suggested.
>
> Also, I tried porting the Chrome extension to a Safari extension. After much
> wrangling, I couldn't get any content scripts to load though. The other bits
> of the extension (e.g. the global page) loaded fine though, so it's not just
> like I don't have extensions enabled. If someone from Apple wants to help me
> debug, I'd be happy to get this working.
>
> Ojan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

[Eric Seidel]

Example.  Use of a mutable member for AnimationController:
https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L346

Causes us to pull in AnimationController.h:
https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L31

Which pulls in additional headers of its own.

Frame.h is included by lots and lots of cpp files, most of which never
need AnimationController.h.  Thus all of those intermediate files
(preprocessor output, assembler output, .o file, etc.) are larger than
necessary, causing longer builds.  Also any time someone edits an
AnimationController.h (or a dependent .h) we end up re-building every
file which includes Frame.h (hundreds of files).

-eric

On Thu, Jun 10, 2010 at 3:56 PM, Maciej Stachowiak  wrote:
>
> On Jun 10, 2010, at 12:04 AM, Eric Seidel wrote:
>
>> This causes a huge header dependency cascade, bloating object files
>> and slowing down builds.  I can't imagine avoiding the pointer
>> indirection is actually a measurable runtime savings (at least in most
>> cases).
>
> Can you give a specific example of a data member where you think OwnPtr would 
> be better?
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] sick of forgetting bugzilla email addresses?

[Eric Seidel]

Apologies, it appears I was misinformed.

On Thu, Jun 10, 2010 at 4:44 PM, Alexey Proskuryakov  wrote:
>
> 10.06.2010, в 16:18, Eric Seidel написал(а):
>
>> A real data feed from bugs.webkit.org of the user names would be best.
>
> There may be some expectation of privacy from users who never file bugs or
> add comments. I don't think there is a way for non-admin users to get a user
> list from Bugzilla.
>
>> Also, we keep hacking bugzilla, and yet our bugzilla is still
>> years-out-of date.  Seems we should upgrade to 3.x before we hack it
>> much more.
>
> We're currently at version 3.2.3.
>
> - WBR, Alexey Proskuryakov
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Windows Builders Wedged on WebKitAuxiliaryLibrary

[Eric Seidel]

Checking Last-Modified date of WebKitAuxiliaryLibrary.zip...
Downloading WebKitAuxiliaryLibrary.zip...

Couldn't check Last-Modified date of new WebKitAuxiliaryLibrary.zip.
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

100   408  100   4080 0  27200  0 --:--:-- --:--:-- --:--:-- 27200
100   408  100   4080 0  27200  0 --:--:-- --:--:-- --:--:-- 0
[/tmp/webkitlibsjvqbQta/WebKitAuxiliaryLibrary.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of
/tmp/webkitlibsjvqbQta/WebKitAuxiliaryLibrary.zip or
/tmp/webkitlibsjvqbQta/WebKitAuxiliaryLibrary.zip.zip, and
cannot find /tmp/webkitlibsjvqbQta/WebKitAuxiliaryLibrary.zip.ZIP,
period.
Couldn't unzip WebKitAuxiliaryLibrary.zip. at
./WebKitTools/Scripts/update-webkit-auxiliary-libs line 82.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

[Eric Seidel]

I'm all for PLT speedups (despite it running too fast on modern
hardware to be useful, it's all we got).  But I'm very against
build-time explosion. :(

I bet we don't need to inline all of these.  Would be nice to know which ones.

Inlines requiring additional headers (especially for Frame.h) increase
the .o size of most WebCore .cpp files and increase overall build
time.  I need to write some sort of scripts to help us check for
header includes we don't need.

-eric

On Fri, Jun 11, 2010 at 5:54 PM, Sam Weinig  wrote:
>
>
> On Fri, Jun 11, 2010 at 3:03 AM, Maciej Stachowiak  wrote:
>>
>> On Jun 10, 2010, at 4:22 PM, Eric Seidel wrote:
>>
>> > Example.  Use of a mutable member for AnimationController:
>> > https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L346
>> >
>> > Causes us to pull in AnimationController.h:
>> > https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L31
>> >
>> > Which pulls in additional headers of its own.
>>
>> I think what requires including the additional headers is the fact that
>> it's a data member of class type instead of a pointer; the mutable
>> declaration is unrelated.
>>
>> >
>> > Frame.h is included by lots and lots of cpp files, most of which never
>> > need AnimationController.h.  Thus all of those intermediate files
>> > (preprocessor output, assembler output, .o file, etc.) are larger than
>> > necessary, causing longer builds.  Also any time someone edits an
>> > AnimationController.h (or a dependent .h) we end up re-building every
>> > file which includes Frame.h (hundreds of files).
>>
>> Making the helper classes of Frame into separately allocated objects could
>> certainly help compile time. It used to be they were all held in a separate
>> FramePrivateData class. I'm not sure when that changed. I don't know of any
>> considerations besides performance and memory use that would favor the
>> current approach. Testing would show whether it actually matters. It might
>> also be worthwhile to find the checkin that removed the separate private
>> data struct for Frame, to see if that was done for a particular reason.
>>
>> Regards,
>> Maciej
>>
>
> We moved away from the private approach in
> http://trac.webkit.org/changeset/40024 for a PLT speedup (I apparently did
> not mention a percentage gain weinig--).  It lately has also allowed us to
> inline access to some of those properties for another PLT speedup.
> -Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

[Eric Seidel]

Oh, certainly page speed wins.  I suspected such was the original
desire.  I continue to doubt their all needed.

The project continues to be paralyzed by a lack of a real public benchmark. :(

-eric

On Fri, Jun 11, 2010 at 6:23 PM, Maciej Stachowiak  wrote:
>
> On Jun 11, 2010, at 6:17 PM, Eric Seidel wrote:
>
>> I'm all for PLT speedups (despite it running too fast on modern
>> hardware to be useful, it's all we got).  But I'm very against
>> build-time explosion. :(
>>
>> I bet we don't need to inline all of these.  Would be nice to know which 
>> ones.
>>
>> Inlines requiring additional headers (especially for Frame.h) increase
>> the .o size of most WebCore .cpp files and increase overall build
>> time.  I need to write some sort of scripts to help us check for
>> header includes we don't need.
>
> I'd be happy to see any build time speedups that don't cause a measurable 
> speed hit. It should be easy to find through testing whether some of these 
> data members can be changed to smart pointers without a speed hit.
>
> Note: inlining methods that access these is still possible even if they are 
> in separate headers, the methods just need to go into that separate header. 
> So the main costs at issue are extra allocations and extra indirection.
>
> If it's a tradeoff between page load speed and faster compile time though, I 
> think page load speed wins.
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [svg] rect with invalid stroke value

[Eric Seidel]

Fill defaults to black, stroke to none.  Whether invalid values are
ignored or treated as black I don't remember.  In general the SVG spec
is useless in this regard.

http://www.w3.org/TR/SVG/painting.html#FillProperties
http://www.w3.org/TR/SVG/painting.html#StrokeProperties

-eric


On Mon, Jun 14, 2010 at 4:00 AM, Yuzo Fujishima  wrote:
> Hi, SVG gurus,
> I have a question regarding LayoutTests/svg/custom/invalid-fill-hex.svg .
> It contains:
>   
> From the comment there I understand that the rect should be filled with
> black.
> But how about the stroke?
> I guess black stroke should be rendered, because #0 is also invalid.
> Is it true? The current test data (expected output) doesn't contain the
> stroke.
> I'm asking this https://bugs.webkit.org/show_bug.cgi?id=24742 fixes hex
> color parsing
> and as a result, the stroke above starts to be rendered with black.
> I'd like to find out whether the above test (or test data) is wrong or I am
> making a mistake.
> I think we should either:
> Rewrite
>   
>  to
>   
> or rebaseline the test data. Which do you prefer (assuming the test needs to
> be changed?)
> Yuzo
>
>
> ___
> 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] HTML5 tokenizer landing soon

[Eric Seidel]

The new parser will certainly be faster than the old, mostly because
it's now hackable.  The old parser was un-touchable for fear of
breaking the world.  This one is tested, perf-tested, documented and
much better designed. May the optimizing begin!

-eric

On Mon, Jun 14, 2010 at 12:07 PM, Adam Barth  wrote:
> On Mon, Jun 14, 2010 at 11:05 AM, Oliver Hunt  wrote:
>> Have you done perf testing?
>
> Yes.  We've been working with our parsing benchmark:
>
> http://trac.webkit.org/browser/trunk/WebCore/benchmarks/parser/html-parser.html
>
>> What's the change?
>
> Last time we measured, the new parser was ~1% slower than the old
> parser.  I believe parsing accounts for <5% of PLT, so that
> corresponds to a <0.05% slowdown on PTL, which is, AFAIK,
> unmeasurable.  We'll double check perf before we switch over.
>
> We think the new parser will end up being faster than the old parser.
> We've done just enough performance optimization to remove perf as a
> blocking issue for switching over.  There's a bunch more we can do.
> For example, we're currently wasting a bunch of time converting
> new-style tokens into old-style tokens to feed them to the old tree
> constructor.  Once we start working on phase 2 (the HTML5 tree
> constructor), we won't need to waste time there.
>
> Adam
>
>
>> On Jun 13, 2010, at 10:21 PM, Adam Barth wrote:
>>
>>> People of WebKit,
>>>
>>> As mentioned recently on webkit-dev, Eric, Tonyg, and I have been
>>> working on implementing the HTML5 parsing algorithm in WebKit:
>>>
>>> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11472.html
>>>
>>> We're now ready to turn the new tokenization algorithm on by default
>>> (probably early this week).  The new code passes all the existing
>>> LayoutTests, with the exception of roughly 40 tests that "expect"
>>> behavior that violates the HTML5 specification [1].
>>>
>>> There are some differences between the old parser and the HTML5
>>> parser.  We've written up a brief document outlining those
>>> differences:
>>>
>>> https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBI&hl=en
>>>
>>> If these differences cause real compatibility issues on the web, we
>>> should contribute this information to the working group so we can
>>> improve the specification.  If these differences cause compatibility
>>> issues for WebKit-specific HTML (e.g., for Dashboard widgets), we
>>> might need to add a flag to support some subset of these parsing
>>> quirks for non-web uses of WebKit.
>>>
>>> Please be on the lookout for parsing-related regressions and CC Eric,
>>> Tonyg, and me on the bugs.  There's still a lot of work to do
>>> (including implementing the tree construction algorithm), but turning
>>> the tokenization code on by default is an important milestone for the
>>> project.
>>>
>>> Happy parsing,
>>> Adam
>>>
>>> [1] See 
>>> https://spreadsheets.google.com/ccc?key=0AppchfQ5mBrEdDFJUW5DOGNsdmtvZkN0ZmIzMjdaT0E&hl=en
>>> for details.
>>> ___
>>> 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] HTML5 tokenizer enabled

[Eric Seidel]

See 
https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBI&hl=en#
for a description of expected differences.

On Wed, Jun 16, 2010 at 2:18 AM, Adam Barth  wrote:
> As of early this morning, we've enabled the HTML5 tokenizer on trunk.
> I expect we've broken a lot of things.  Please file bugs and CC Eric,
> Tonyg, and myself.  Thanks for your patience.
>
> You can get the old parser back by passing --legacy-parser to
> DumpRenderTree or typing the command "defaults write com.apple.Safari
> WebKitHTML5ParserEnabled -bool NO"
>
> Adam
>
> PS: The new code has a lot of ASSERTs.  If you're think parsing in
> debug builds is too slow, we can remove some of these.
> ___
> 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] BuildBot issues, including /console outage

[Eric Seidel]

/console lost some data tonight due to various server flakiness
issues.  /waterfall is still displaying all builds fine, but /console
is missing many.  Bill worked on it for a while and hopefully all will
be better going forward.

Unfortunately the data loss came at a bad time, as we were landing the
HTML5 parser changes (which required test updates on all platforms).

I believe the tree is green or about to roll green, but it's hard to
tell with /console missing the last 60 revisions.  I'll work on it
again in the morning if it isn't.

Gtk Release slave is still broken.  Gtk folks know about it and are
hopefully fixing.

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

Re: [webkit-dev] HTML5 tokenizer enabled

[Eric Seidel]

Mac passed 100% when we landed it. :)

On Wed, Jun 16, 2010 at 9:57 AM, Cameron Zwarich  wrote:
> Was anything preventing you from running these tests before you turned it on?
>
> Cameron
>
> On Jun 16, 2010, at 8:32 AM, Adam Barth  wrote:
>
>> Apologies for the red tree.  There are still a handful of LayoutTests
>> we're trying to understand.  Hopefully we'll have everything cleared
>> up by noon.
>>
>> Thanks,
>> Adam
>>
>>
>> On Wed, Jun 16, 2010 at 2:20 AM, Eric Seidel  wrote:
>>> See 
>>> https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBI&hl=en#
>>> for a description of expected differences.
>>>
>>> On Wed, Jun 16, 2010 at 2:18 AM, Adam Barth  wrote:
>>>> As of early this morning, we've enabled the HTML5 tokenizer on trunk.
>>>> I expect we've broken a lot of things.  Please file bugs and CC Eric,
>>>> Tonyg, and myself.  Thanks for your patience.
>>>>
>>>> You can get the old parser back by passing --legacy-parser to
>>>> DumpRenderTree or typing the command "defaults write com.apple.Safari
>>>> WebKitHTML5ParserEnabled -bool NO"
>>>>
>>>> Adam
>>>>
>>>> PS: The new code has a lot of ASSERTs.  If you're think parsing in
>>>> debug builds is too slow, we can remove some of these.
>>>> ___
>>>> 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] HTML5 tokenizer enabled

[Eric Seidel]

Bots are back green as of 11:30am.  Thanks for your patience.

-eric

On Wed, Jun 16, 2010 at 11:01 AM, Eric Seidel  wrote:
> Mac passed 100% when we landed it. :)
>
> On Wed, Jun 16, 2010 at 9:57 AM, Cameron Zwarich  
> wrote:
>> Was anything preventing you from running these tests before you turned it on?
>>
>> Cameron
>>
>> On Jun 16, 2010, at 8:32 AM, Adam Barth  wrote:
>>
>>> Apologies for the red tree.  There are still a handful of LayoutTests
>>> we're trying to understand.  Hopefully we'll have everything cleared
>>> up by noon.
>>>
>>> Thanks,
>>> Adam
>>>
>>>
>>> On Wed, Jun 16, 2010 at 2:20 AM, Eric Seidel  wrote:
>>>> See 
>>>> https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBI&hl=en#
>>>> for a description of expected differences.
>>>>
>>>> On Wed, Jun 16, 2010 at 2:18 AM, Adam Barth  wrote:
>>>>> As of early this morning, we've enabled the HTML5 tokenizer on trunk.
>>>>> I expect we've broken a lot of things.  Please file bugs and CC Eric,
>>>>> Tonyg, and myself.  Thanks for your patience.
>>>>>
>>>>> You can get the old parser back by passing --legacy-parser to
>>>>> DumpRenderTree or typing the command "defaults write com.apple.Safari
>>>>> WebKitHTML5ParserEnabled -bool NO"
>>>>>
>>>>> Adam
>>>>>
>>>>> PS: The new code has a lot of ASSERTs.  If you're think parsing in
>>>>> debug builds is too slow, we can remove some of these.
>>>>> ___
>>>>> 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] increase the number of tests before bailing?

[Eric Seidel]

We could add a separate option to DumpRenderTree to disable
ReportCrash (sign up for all the crashing signals and simply exit(2)
or similar).  That would be useful in many instances besides the bots.

Yes, --exit-after-N-failures was designed to prevent crashers from
eating the bots.

On Wed, Jun 16, 2010 at 1:59 PM, Geoffrey Garen  wrote:
> Hi Ojan.
>
> I wonder if it would help to distinguish --exit-after-n-failures from 
> --exit-after-n-crashes.
>
> I think that crashing tests are the biggest problem, since they can cause a 
> bot to lag behind quite a bit.
>
> Geoff
>
> On Jun 16, 2010, at 1:57 PM, Ojan Vafai wrote:
>
>> Currently, --exit-after-n-failures on the bots is set to 20. I like the idea 
>> of exiting early, but I think 20 is too low. We should up it to 100. Is 
>> anyone opposed to that?
>>
>> There are some straightforward, mechanical patches that cause more than 20 
>> tests to fail where they just need new expected results (e.g. changing form 
>> control or scrollbar metrics). Right now, to make such a change you need 
>> access to every platform so you can create new results or you need to get 
>> someone who has access to that platform to pull in your change and create 
>> new results.
>>
>> The problem that confounds this is that many people have trouble ever 
>> getting all the tests to pass on Windows. I've never succeeded. There are 
>> always ~50 tests that fail for me and it's not due to lack of trying. So, 
>> even though I have access to Windows, it's hard for me to get new expected 
>> results for Windows changes.
>>
>> Long-term we really need a solution that lets you get expected results for a 
>> platform you don't have access to without committing code, e.g., the EWS 
>> archiving results for failing tests.
>>
>> Ojan
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] increase the number of tests before bailing?

[Eric Seidel]

We could also look into BreakPad (Chromium's solution) for the bots.
That doesn't seem to hang for 5 minutes a crash like ReportCrash does.
 But maybe that's related to how Chromium builds (symbol-wise) more
than ReportCrash.

On Wed, Jun 16, 2010 at 2:04 PM, Eric Seidel  wrote:
> We could add a separate option to DumpRenderTree to disable
> ReportCrash (sign up for all the crashing signals and simply exit(2)
> or similar).  That would be useful in many instances besides the bots.
>
> Yes, --exit-after-N-failures was designed to prevent crashers from
> eating the bots.
>
> On Wed, Jun 16, 2010 at 1:59 PM, Geoffrey Garen  wrote:
>> Hi Ojan.
>>
>> I wonder if it would help to distinguish --exit-after-n-failures from 
>> --exit-after-n-crashes.
>>
>> I think that crashing tests are the biggest problem, since they can cause a 
>> bot to lag behind quite a bit.
>>
>> Geoff
>>
>> On Jun 16, 2010, at 1:57 PM, Ojan Vafai wrote:
>>
>>> Currently, --exit-after-n-failures on the bots is set to 20. I like the 
>>> idea of exiting early, but I think 20 is too low. We should up it to 100. 
>>> Is anyone opposed to that?
>>>
>>> There are some straightforward, mechanical patches that cause more than 20 
>>> tests to fail where they just need new expected results (e.g. changing form 
>>> control or scrollbar metrics). Right now, to make such a change you need 
>>> access to every platform so you can create new results or you need to get 
>>> someone who has access to that platform to pull in your change and create 
>>> new results.
>>>
>>> The problem that confounds this is that many people have trouble ever 
>>> getting all the tests to pass on Windows. I've never succeeded. There are 
>>> always ~50 tests that fail for me and it's not due to lack of trying. So, 
>>> even though I have access to Windows, it's hard for me to get new expected 
>>> results for Windows changes.
>>>
>>> Long-term we really need a solution that lets you get expected results for 
>>> a platform you don't have access to without committing code, e.g., the EWS 
>>> archiving results for failing tests.
>>>
>>> Ojan
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

[Eric Seidel]

I wonder if any browser has investigated using a bool (or char or
whatever) on Element to mean "there is a \n text node after me" or
"there is a text node with N \n after me".  I'm not sure it would
actually be a win, and would certainly add code complexity to "lie" in
the DOM like that.  But it would be one way of getting rid of most of
these text nodes.

On Wed, Jun 16, 2010 at 2:12 PM, David Hyatt  wrote:
> Whitespace nodes most commonly occur between elements, so they can't be 
> coalesced.
>
> dave
>
> On Jun 14, 2010, at 7:00 PM, Matt 'Murph' Finnicum wrote:
>
>> Why are there so many Text nodes in the DOM? I had a look at the initial DOM 
>> tree from rendering slashdot, and there are 1959 Text nodes. Of those 1959, 
>> 1246 were whitespace-only nodes.
>>
>> Does there need to be this many nodes? Why can't whitespace be combined with 
>> the nodes next to it?
>>
>> Thanks,
>> --Murph
>> ___
>> 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] increase the number of tests before bailing?

[Eric Seidel]

I think --exit-after-N-failures is actually very useful as-is.  I
think peopel just use it for different things.  For teh commit-queue
--exit-after-N-failures is great for keeping it quick.

Perhaps people want to use the bots more like try-bots and have
--exit-after-N-failures higher.

I think these are all symptoms of WebKit's total lack of real trybots. ;)

-eric

On Wed, Jun 16, 2010 at 3:27 PM, Maciej Stachowiak  wrote:
>
> On Jun 16, 2010, at 2:04 PM, Eric Seidel wrote:
>
>> We could add a separate option to DumpRenderTree to disable
>> ReportCrash (sign up for all the crashing signals and simply exit(2)
>> or similar).  That would be useful in many instances besides the bots.
>>
>> Yes, --exit-after-N-failures was designed to prevent crashers from
>> eating the bots.
>
> I think --exit-after-n-crashes is probably the most expedient solution to the 
> problem.
>
> I think when only a few tests crash, having the crash report is very useful, 
> particularly if the developer of the patch cannot reproduce the crash off the 
> bot. All we need to do is limit the number of crashes to prevent the bots 
> falling way behind.
>
> Regards,
> Maciej
>
>>
>> On Wed, Jun 16, 2010 at 1:59 PM, Geoffrey Garen  wrote:
>>> Hi Ojan.
>>>
>>> I wonder if it would help to distinguish --exit-after-n-failures from 
>>> --exit-after-n-crashes.
>>>
>>> I think that crashing tests are the biggest problem, since they can cause a 
>>> bot to lag behind quite a bit.
>>>
>>> Geoff
>>>
>>> On Jun 16, 2010, at 1:57 PM, Ojan Vafai wrote:
>>>
>>>> Currently, --exit-after-n-failures on the bots is set to 20. I like the 
>>>> idea of exiting early, but I think 20 is too low. We should up it to 100. 
>>>> Is anyone opposed to that?
>>>>
>>>> There are some straightforward, mechanical patches that cause more than 20 
>>>> tests to fail where they just need new expected results (e.g. changing 
>>>> form control or scrollbar metrics). Right now, to make such a change you 
>>>> need access to every platform so you can create new results or you need to 
>>>> get someone who has access to that platform to pull in your change and 
>>>> create new results.
>>>>
>>>> The problem that confounds this is that many people have trouble ever 
>>>> getting all the tests to pass on Windows. I've never succeeded. There are 
>>>> always ~50 tests that fail for me and it's not due to lack of trying. So, 
>>>> even though I have access to Windows, it's hard for me to get new expected 
>>>> results for Windows changes.
>>>>
>>>> Long-term we really need a solution that lets you get expected results for 
>>>> a platform you don't have access to without committing code, e.g., the EWS 
>>>> archiving results for failing tests.
>>>>
>>>> Ojan
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

[Eric Seidel]

A does not follow from B in that sentence, that current memory
fragmentation means we need to strip whitespace nodes.

It would also be possible to create a special shared "\n" text node,
and have some sort of Copy On Write behavior.  Again, more complexity.
 Not sure if the complexity would be worth the perf win.

-eric

On Thu, Jun 17, 2010 at 12:45 PM, Gustavo Sverzut Barbieri
 wrote:
> David, it's bit more than annoying, it's fragmenting memory for no
> good. In the long run on systems will small memory it does make a
> difference :-/
>
> I'd like to see some option, maybe compile-time, to strip these
> useless whitespaces.
>
> BR,
>
> On Thu, Jun 17, 2010 at 3:51 PM, David Hyatt  wrote:
>> Although it's annoying that these extra whitespace nodes are in the DOM, we 
>> do at least make sure not to create renderers for them most of the time.
>>
>> dave
>>
>> On Jun 17, 2010, at 1:37 PM, Alexey Proskuryakov wrote:
>>
>>>
>>> 17.06.2010, в 9:53, Andreas Delmelle написал(а):
>>>
 If WebKit chooses, for example, to ignore character events from the parser 
 in nodes where logically it doesn't make sense to have stray characters
>>>
>>>
>>> That would break e.g. Web sites where JS accesses DOM in ways such as 
>>> node.firstChild.nextSibling, or node.childNodes[3]. We've previously seen 
>>> similar breakage happen after changing WebCore parsing code.
>>>
>>> - WBR, Alexey Proskuryakov
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> ___
> 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] Why so many text nodes in the DOM? (especially ones with just whitespace)

[Eric Seidel]

firstElementChild already exists in modern browsers:
http://www.w3.org/TR/ElementTraversal/#interface-elementTraversal

Anyway, this thread is done.

On Fri, Jun 18, 2010 at 10:27 AM, Andreas Delmelle
 wrote:
>
> On 17 Jun 2010, at 20:37, Alexey Proskuryakov wrote:
>
>>
>> 17.06.2010, в 9:53, Andreas Delmelle написал(а):
>>
>>> If WebKit chooses, for example, to ignore character events from the parser 
>>> in nodes where logically it doesn't make sense to have stray characters
>>
>>
>> That would break e.g. Web sites where JS accesses DOM in ways such as 
>> node.firstChild.nextSibling, or node.childNodes[3]. We've previously seen 
>> similar breakage happen after changing WebCore parsing code.
>
> Wow, good point! Suddenly I feel foolish, not having thought of that 
> hyper-trivial scenario. Obviously a very good reason to keep those nodes in.
>
> Still, one wonders from time to time how much bandwidth is actually wasted by 
> sending over all these extraneous bytes that ultimately compel JS developers 
> to write code like the above. I don't think I have ever seen a website that 
> does /not/ serve its HTML pretty-printed... That seems like an awful lot of 
> spaces, tabs and linefeeds!
>
> On the other hand, node.firstChild.nextSibling just seems like asking for 
> trouble. One could argue that people who do use that to get to the first 
> element node do not need to be accommodated. It would suffice for one of the 
> page's authors to insert a small comment node to break that code.
>
> One could just as easily extend Node with a firstElement() method that would 
> work under all circumstances --but, oh yes, IE didn't support that back 
> then... ;-)
>
>
> Regards,
>
> Andreas Delmelle
> ---
>
> ___
> 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 of a new committer

[Eric Seidel]

Completely agreed!  That's why Adam and I are trying an experiment of
removing the "wait for all bots to be green" check from the
commit-queue:
http://trac.webkit.org/changeset/61831

So far so good.  It's probably too extreme to remove the check
entirely, but we'll know better after a few days.

The queue was over 50 entries last night, but it's down to 25 now and
should be 0 by tomorrow.  With the green check gone, time from cq+ to
landing should only be how long it takes to build and test your patch.

-eric

On Fri, Jun 25, 2010 at 11:49 AM, Tony Gentilcore  wrote:
> Is there any policy or guideline regarding when it is appropriate to use the
> commit queue vs landing directly?
> I feel like there is an unfortunate "positive feedback" loop right now:
> 1. Commit queue gets slightly backed up either due to a breakage or just
> heavy volume.
> 2. Because the queue is backed up, it is more tempting to land directly.
> 3. Directly landed patches are more likely to break the tree and the new
> breakage backs up the queue even more.
> 4. Goto #2.
> Long queues punish developers not because of the wait for the patch to land,
> but because those patches are more likely to have merge conflicts. So the
> incentive seems to be to land without the queue. I'm just curious if this
> has been brought up before and if folks more experienced than myself have
> ideas about how we could improve this.
> Tony
> ___
> 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] Snow Leopard Bot went down

[Eric Seidel]

/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212:
fatal error: error writing to -: Broken pipe
compilation terminated.
i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program as)
Please submit a full bug report.
See http://developer.apple.com/bugreporter> for instructions.

http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio

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

Re: [webkit-dev] Snow Leopard Bot went down

[Eric Seidel]

The ICE appears to have spread to other bots as well:

..\..\..\JavaScriptCore\runtime\ArrayPrototype.cpp: In function 'void*
JSC::arrayProtoFuncJoin(JSC::ExecState*)':
..\..\..\JavaScriptCore\runtime\ArrayPrototype.cpp:263:30: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

http://build.webkit.org/builders/Qt%20Windows%2032-bit%20Release/builds/4266/steps/compile-webkit/logs/stdio

On Fri, Jul 9, 2010 at 3:22 PM, Tony Gentilcore  wrote:
> No theories. But another data point; Tiger started doing the same a few
> revisions earlier:
>
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:
> In function 'void -[WebView(WebPrivate)
> _commonInitializationWithFrameName:groupName:usesDocumentViews:](WebView*,
> objc_selector*, NSString*, NSString*, BOOL)':
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:628:
> internal compiler error: Segmentation fault
>
> On Fri, Jul 9, 2010 at 3:13 PM, Eric Seidel  wrote:
>>
>>
>> /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212:
>> fatal error: error writing to -: Broken pipe
>> compilation terminated.
>> i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program
>> as)
>> Please submit a full bug report.
>> See http://developer.apple.com/bugreporter> for instructions.
>>
>>
>> http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio
>>
>> Any theories?
>> ___
>> 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

[Eric Seidel]

Sounds like an easy patch to post.  I'm in favor of removing this
support.  Reducing the number of non-standard CSS properties we
support seems like a good thing.

-eric

On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo  wrote:
> Good day,
>
> While going through WebCore for some CSS research I'm currently doing,
> I came across a piece of code[1] which translates all "-khtml-" and
> "-apple-" vendor-prefixes to "-webkit-". This effectively means
> "-apple-transform" and "-khtml-transform" can both be used instead of
> "-webkit-transform". I am unaware of the rationales behind the apple
> vendor-prefix, but I'd like to propose removing support for the
> KHTML-prefix.
>
> My main argument for this is that WebKit and KHTML are, in my opinion,
> two separate engines by two separate vendors. The port occurred eight
> years ago, and code in both projects has changed significantly ever
> since. When Microsoft announced support for "-webkit-text-size-adjust"
> in IE Mobile it was argued that browsers should not implement
> properties with prefixes "belonging" to other vendors, which seems to
> be exactly what WebKit is doing with the KHTML prefix.
>
> I understand the history of supporting -khtml-, and have heard from
> the KHTML project that they implement the -webkit- prefix as well.
> However, considering that WebKit has grown significantly in the past
> few years and that all code changes basically made KHTML and WebKit
> two individual rendering engines, with individual CSS support, I
> believe it would be appropriate for support to be dropped.
>
> Regards,
> Peter Beverloo
> http://peter.sh/
>
> [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
> [2] 
> http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
> ___
> 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

[Eric Seidel]

Please post a patch:
http://webkit.org/coding/contributing.html

On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel  wrote:
> Sounds like an easy patch to post.  I'm in favor of removing this
> support.  Reducing the number of non-standard CSS properties we
> support seems like a good thing.
>
> -eric
>
> On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo  wrote:
>> Good day,
>>
>> While going through WebCore for some CSS research I'm currently doing,
>> I came across a piece of code[1] which translates all "-khtml-" and
>> "-apple-" vendor-prefixes to "-webkit-". This effectively means
>> "-apple-transform" and "-khtml-transform" can both be used instead of
>> "-webkit-transform". I am unaware of the rationales behind the apple
>> vendor-prefix, but I'd like to propose removing support for the
>> KHTML-prefix.
>>
>> My main argument for this is that WebKit and KHTML are, in my opinion,
>> two separate engines by two separate vendors. The port occurred eight
>> years ago, and code in both projects has changed significantly ever
>> since. When Microsoft announced support for "-webkit-text-size-adjust"
>> in IE Mobile it was argued that browsers should not implement
>> properties with prefixes "belonging" to other vendors, which seems to
>> be exactly what WebKit is doing with the KHTML prefix.
>>
>> I understand the history of supporting -khtml-, and have heard from
>> the KHTML project that they implement the -webkit- prefix as well.
>> However, considering that WebKit has grown significantly in the past
>> few years and that all code changes basically made KHTML and WebKit
>> two individual rendering engines, with individual CSS support, I
>> believe it would be appropriate for support to be dropped.
>>
>> Regards,
>> Peter Beverloo
>> http://peter.sh/
>>
>> [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
>> [2] 
>> http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
>> ___
>> 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] Debugging Webkit?

[Eric Seidel]

I don't have answers for you.  But the information should be added to:
http://webkit.org/building/debug.html
or
http://trac.webkit.org/wiki/QtWebKit
once found. :)

-eric

On Tue, Jul 13, 2010 at 7:22 PM, Yuchen Zhou  wrote:
> Hi all-
>
> I am newbie to webkit dev and I am trying to debug Webkit with gdb. I tried
> to build the Qtwebkit with ./build-webkit --debug --qt, and then gdb
> WebKitBuild/Debug/bin/QtTestBrowser, however seems gdb was not able to add
> breakpoints for class::functions. It cannot find them. I wonder what is the
> debugging process for Qtwebkit.
>
> Thanks all,
>
> 2010-07-13
> 
> Yuchen
> ___
> 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] I am about to break your tree.

[Eric Seidel]

I am sorry.

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


We're removing redundant text nodes from the parsed DOM tree.
Unfortunately, given our current setup, there is no way for me to
generate results for all platforms which may have them forked.

I will do what I can from the bot results, but bots only show the
first 20 failures.

I'll be in IRC to assist any port-maintainers who would join me in the
fire-fighting.

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

Re: [webkit-dev] I am about to break your tree.

[Eric Seidel]

Tree successfully broken in http://trac.webkit.org/changeset/63403.

Picking up the pieces now.

-eric

On Wed, Jul 14, 2010 at 7:56 PM, Martin Robinson  wrote:
> On Wed, Jul 14, 2010 at 7:54 PM, Eric Seidel  wrote:
>> We're removing redundant text nodes from the parsed DOM tree.
>> Unfortunately, given our current setup, there is no way for me to
>> generate results for all platforms which may have them forked.
>
> Awesome! I'll be here to generate new results when it lands.
>
> Martin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] I am about to break your tree.

[Eric Seidel]

Excellent!  That makes the rebaseline script I wrote last night even
more useful. :)

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

-eric

On Thu, Jul 15, 2010 at 8:26 AM, Ojan Vafai  wrote:
> On Wed, Jul 14, 2010 at 7:54 PM, Eric Seidel  wrote:
>>
>> I will do what I can from the bot results, but bots only show the
>> first 20 failures.
>
> This is no longer true. Now the bots only bail after 20 crashes and/or
> timeouts.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SIL Open Font License and WebKit

[Eric Seidel]

A little web searching produced:

It's OSI approved:
http://www.opensource.org/licenses/openfont.html

GNU thinks it's OK, albeit having an "unusual requirement":
http://www.gnu.org/licenses/license-list.html#Fonts

Fedora recommended:
https://fedoraproject.org/wiki/Licensing#Font_Licenses

It would appear to be "the font license".

-eric

On Fri, Jul 16, 2010 at 5:05 AM, Alex Milowski  wrote:
> We have a licensing issue we need to address for MathML.  We need the STIX
> fonts as they will provide consistent rendering for Mathematics.  I highly
> suspect these fonts will find themselves on our desktops somewhere down
> the road.  Meanwhile, we need them for our testing infrastructure to
> actually work across all the platforms.
>
> The STIX Fonts are available under the SIL Open Font License:
>
>   http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL_web
>
> You can see the patch that adds these fonts here:
>
>   https://bugs.webkit.org/show_bug.cgi?id=41961
>
> I think we need to adjust our licensing policy to include font licenses
> like the above.  It is unlikely that the STIX consortium will change their
> font licensing.  In reality, they don't need to do so.  The font license is
> intended to support "open source" fonts.
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> 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] svg/filters/filter-empty-g.svg ASSERTs on Leopard Intel Debug (Tests)

[Eric Seidel]

Won't "webkit-patch failure-reason" tell you when it started?  It
knows how to handle looking past the end of the waterfall.

-eric

On Sun, Jul 18, 2010 at 8:48 AM, Adam Barth  wrote:
> A test has been crashing Leopard Intel Debug (Tests) for >24 hours.  I
> tried to look back on buildbot to see when the issue started, but it's
> past the end of the waterfall (much like a rainbow).  If you touched
> SVG filters recently, would you be willing to investigate?
>
> Thanks,
> Adam
>
>
> Tests that caused the DumpRenderTree tool to crash:
>
> svg/filters/filter-empty-g.svg  stderr
>
> Sun Jul 18 08:33:06 il0301a-dhcp09.apple.com DumpRenderTree[17669]
> : CGImageCreate: invalid image size: 0 x 0.
> ASSERTION FAILED: frameCount()
> (/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebCore/platform/graphics/cg/ImageSourceCG.cpp:273
> bool WebCore::ImageSource::frameIsCompleteAtIndex(size_t))
> ___
> 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] review queue crazy idea

[Eric Seidel]

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 encourage you to write any sort of better review tool/bot, turn it
on, and see what happens.  That's kinda what we did with the EWS and
commit-queue.  Initial reactions (to both) were strongly negative, but
we fixed a bunch of stuff from initial feedback, and I (would like to)
believe we have two useful systems now.  I see the same pattern
happening for someone trying to build some better review tools.

-eric

On Wed, Jul 21, 2010 at 5:40 PM, Ojan Vafai  wrote:
> There are currently 38 (of 171 total) patches in the review queue where the
> bugs have not been modified in over 1 month old. I propose we have a bot
> that educates people about writing easy to review patches and auto-rejects
> any patches in bugs that haven't been touched in over a month. For people
> new-ish to the WebKit project, it is often confusing both degree of
> responsibility that lies with the contributor to make the patch easy to
> review and the need to get reviewers' attention for a given patch.
> This is just an initial proposal. I'm not wed to any of the details of how
> this would work. I do think that auto-rejecting old patches is valuable to
> the project as a whole. Having the review queue be so large makes
> it daunting for any reviewer to try and tackle it. On the other hand,
> knowing that patches will magically fall off the end of the queue might
> encourage reviewers to just ignore some patches.
> An alternative to auto-rejecting patches would be to send a nag email once a
> week to webkit-reviewers@ with the list of patches that are over a month
> old.
>
> Here are my initial thoughts on what a review bot would do.
> After a patch turns a week old, send the following email:
> Patch 12345 of bug 6789 is a week old. It may just be because no reviewer
> has found time to review it. But there may be steps you can take to help get
> your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few
> suggestions.
> -WebKit review bot
> After the patch is three weeks old:
> Patch 12345 of bug 6789 is three weeks old. If it is still unreviewed in a
> week, it will automatically be rejected. It may just be because no reviewer
> has found time to review it. But there may be steps you can take to help get
> your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few
> suggestions.
> -WebKit review bot
> After the patch is a month old:
> Patch 12345 of bug 6789 has been rejected because it is too old. This is
> likely because no webkit reviewer has been able to review it. If you would
> still like the patch reviewed, then please do the following:
>
> Make sure your patch still applies to tip of tree.
> Do as many of the suggestions at http://trac.webkit.org/wiki/CodeReview as
> possible.
> Upload your patch for review again.
>
> -Webkit Review Bot
> ___
> 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] review queue crazy idea

[Eric Seidel]

Patches sit in the queue for numerous reasons.  Some of us used to
scan the queue every day.  But I've stopped doing that.  Now I scan it
more like once a week or two.

There is no good way to find "which patches might I have a chance of
reviewing", so you end up spending 30 minutes just to find a patch you
could actually review.

Most patches get rejected for easily-bot-detectable reasons.  Like bad
or missing ChangeLogs, poor comment style, tabs, breaking EWS bots.
Now that the style bot and EWS bots work better we should at least cq-
patches which fail those bots (or fail to apply).

I think reviewing would be much easier if we had some better site by
which to review.  I'm not sure how we solve the social problem of
getting people to review patches which didn't come from the person
sitting next to them in their office however.  Then again, that's
sorta OK.  part of contributing to webkit is integrating into the
community.  It's importnat to know your reviewers and to discuss
things with them in channels other than the bug.  But I still think
some minimal technical work would go a long way to making reviewing
better.

-eric

On Wed, Jul 21, 2010 at 7:34 PM, Zoltan Horvath  wrote:
> Hey,
>
> I just don't understand how can the patches can sit in bugzilla unreviewed for
> weeks? There are 76 reviewers in the trac's team list.
>
> I think the reviewers have to do what they have assumed... Reviewing patches!
>
> I agree with Maciej automatic rejection is unfriendly. (Of course we can
> reject patches which are no longer applies on trunk. Yes, we should do this!)
> I think we should find a good way to advise the reviewers of the patch's 
> topic.
> I prefer this way of automation.
>
> Regards,
>
> Zoltan
>
> On Wednesday 21 July 2010, at 23:40, Ojan Vafai wrote:
>> There are currently 38 (of 171 total) patches in the review queue where the
>> bugs have not been modified in over 1 month old. I propose we have a bot
>> that educates people about writing easy to review patches and auto-rejects
>> any patches in bugs that haven't been touched in over a month. For people
>> new-ish to the WebKit project, it is often confusing both degree of
>> responsibility that lies with the contributor to make the patch easy to
>> review and the need to get reviewers' attention for a given patch.
>>
>> This is just an initial proposal. I'm not wed to any of the details of how
>> this would work. I do think that auto-rejecting old patches is valuable to
>> the project as a whole. Having the review queue be so large makes
>> it daunting for any reviewer to try and tackle it. On the other hand,
>> knowing that patches will magically fall off the end of the queue might
>> encourage reviewers to just ignore some patches.
>>
>> An alternative to auto-rejecting patches would be to send a nag email once
>> a week to webkit-reviewers@ with the list of patches that are over a month
>> old.
>>
>>
>> Here are my initial thoughts on what a review bot would do.
>>
>> *After a patch turns a week old, send the following email:*
>> Patch 12345 of bug 6789 is a week old. It may just be because no reviewer
>> has found time to review it. But there may be steps you can take to help
>> get your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a
>> few suggestions.
>>
>> -WebKit review bot
>>
>> *After the patch is three weeks old:*
>> Patch 12345 of bug 6789 is three weeks old. If it is still unreviewed in a
>> week, it will automatically be rejected. It may just be because no reviewer
>> has found time to review it. But there may be steps you can take to help
>> get your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a
>> few suggestions.
>>
>> -WebKit review bot
>>
>> *After the patch is a month old:*
>> Patch 12345 of bug 6789 has been rejected because it is too old. This is
>> likely because no webkit reviewer has been able to review it. If you would
>> still like the patch reviewed, then please do the following:
>>
>>    1. Make sure your patch still applies to tip of tree.
>>    2. Do as many of the suggestions at
>>    http://trac.webkit.org/wiki/CodeReview as possible.
>>    3. Upload your patch for review again.
>>
>> -Webkit Review Bot
> ___
> 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] review queue crazy idea

[Eric Seidel]

I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
always seemed more of place to brag about webkit involvement, than a
useful reference.  I think we could build a much better "who should I
ask to review this" tool based on SVN information.

-eric

On Fri, Jul 23, 2010 at 12:15 AM, David Kilzer  wrote:
> 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  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] review queue crazy idea

[Eric Seidel]

Given a patch file, you have its line number ranges.

Given a git checkout, you can very quickly find who has made changes
to what lines in that file.

You then can have a bot post to the bug, saying that 10 people have
touched the lines you're touching in your patch.  3 of them are active
reviewers, here are their names:

You could even educate such a script/bot about "whitespace" or
"rename" changes so they're excluded from any "who touched this"
lookup.

I would like to build (or see built) this (or a similar) script.  I
just haven't had the time to do it.

It's better than manual owner files or watch lists IMO because it's
automatically generated.

-eric

On Fri, Jul 23, 2010 at 8:04 AM, Alex Milowski  wrote:
> On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel  wrote:
>> I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
>> always seemed more of place to brag about webkit involvement, than a
>> useful reference.  I think we could build a much better "who should I
>> ask to review this" tool based on SVN information.
>
> Were you thinking of some kind of automated "harvesting" of this information?
>
> I seems like a simple data file that can be processed by systems
> would be a good way to start.  Then people can submit patches (or
> commit changes) to file changing the areas that they are willing
> to review and others can see/review that commitment.
>
> People who are looking for a reviewer can look through that file for
> individuals.
>
> If a review doesn't want to get reminder e-mails or requests from
> systems or individuals, they would then have to remove that
> review "area" for themselves from that data file.
>
> I would personally use an XML format ... but that's me.  ;)
>
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> 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] Introducing dumpAsMarkup

[Eric Seidel]

There is another DOM dump format which the html5lib tests use:
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt

Note, it's a DOM Dump, not a Markup dump, but it serves a similar purpose.

I I think I like the html5lib format better for a few reasons:
1.  All lowercase (UPPERCASE TAGS ARE SO HTML4)
2.  The DOM tree indent is nice.
3.  <#text> is takes less space.

-eric

On Mon, Jul 26, 2010 at 6:06 PM, Ryosuke Niwa  wrote:
> If tests you write only require comparing DOMs, you want to read this.
> We've recently added dump-as-markup. It allows your tests to be platform
> independent and gives output that is easier to read than render tree dumps.
> For example, if I have:
> 
> This is a dumpAsMarkup test.
> window.getSelection().selectAllChildren(foo);
> Then I get:
> 
> 
> 
> <#text>
> 
> 
> 
> 
> <#text>This is a dumpAsMarkup
> test.
> 
> <#text>
> 
>  window.getSelection().selectAllChildren(foo); 
> <#text>
> 
> 
> 
> See Writing DumpAsMarkup Tests for more ways you can use dump-as-markup.js
> Best regards,
> Ryosuke Niwa
>
> ___
> 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] Introducing dumpAsMarkup

[Eric Seidel]

Thinking about it more, I'm not sure "markup" is as useful as DOM is.
We should have tests which test our DOM->Markup serialization.  Maybe
all the editing tests want that.  But I think most tests just want to
test the DOM, which (as demonstrated by the html5lib tests) can be
sterilized in a shorter format and exposes slightly different (and I
think in most cases more relevant) information.

On Mon, Jul 26, 2010 at 6:13 PM, Eric Seidel  wrote:
> There is another DOM dump format which the html5lib tests use:
> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt
>
> Note, it's a DOM Dump, not a Markup dump, but it serves a similar purpose.
>
> I I think I like the html5lib format better for a few reasons:
> 1.  All lowercase (UPPERCASE TAGS ARE SO HTML4)
> 2.  The DOM tree indent is nice.
> 3.  <#text> is takes less space.
>
> -eric
>
> On Mon, Jul 26, 2010 at 6:06 PM, Ryosuke Niwa  wrote:
>> If tests you write only require comparing DOMs, you want to read this.
>> We've recently added dump-as-markup. It allows your tests to be platform
>> independent and gives output that is easier to read than render tree dumps.
>> For example, if I have:
>> 
>> This is a dumpAsMarkup test.
>> window.getSelection().selectAllChildren(foo);
>> Then I get:
>> 
>> 
>> 
>> <#text>
>> 
>> 
>> 
>> 
>> <#text>This is a dumpAsMarkup
>> test.
>> 
>> <#text>
>> 
>>  window.getSelection().selectAllChildren(foo); 
>> <#text>
>> 
>> 
>> 
>> See Writing DumpAsMarkup Tests for more ways you can use dump-as-markup.js
>> Best regards,
>> Ryosuke Niwa
>>
>> ___
>> 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] Introducing dumpAsMarkup

[Eric Seidel]

You can see many more examples of dom2string in the non-html5 results
(where there are a zillion failure cases):
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt

dom2string.js came from http://code.google.com/p/html5lib I thought,
but I couldn't find the source for it there.

I'm not wedded in any way to dom2string.  But I do like the output it
produces slightly more than the current dumpAsMarkup.  I agree,
standardization might be nice.

dom2string uses " for <#text> and .  newlines return you to
the start of the line as you would expect.  (see the
runner-expected.txt above).

-eric

p.s. Would be nice if we could just inject certain javascript into
every page.  Sorta like how v8 allows you to define engine-level
functions in javascript.  Would be nice to just make dumpAsMarkup()
part of DRT, but write it in javascript. :)


On Mon, Jul 26, 2010 at 7:15 PM, Ojan Vafai  wrote:
> I like the idea of standardizing the dump output and the dumping code for
> that matter. If we can resolve the below, then we can make sure all the
> dumping logic in dom2string gets moved into dump-as-markup and standardize
> on that. As best I can tell, there's only 2 uses of dom2string.
>
>> There is another DOM dump format which the html5lib tests use:
>>
>> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt
>> Note, it's a DOM Dump, not a Markup dump, but it serves a similar
>> purpose.
>
> I'm not really sure what distinction you're drawing here. They both just
> dump the DOM. When this came up before, people preferred the name
> dump-as-markup to dum-as-dom.
>
>> I I think I like the html5lib format better for a few reasons:
>> 2. The DOM tree indent is nice.
>
> What does the indenting do with linebreaks? For example, "foo\nbar\nbaz". In
> dump-as-markup, that gets printed as:
> <#text>foo
> bar
> baz
>
> I guess I'd be OK with indenting, but having anything after a newline not
> indent.
>
>> 3. <#text> is takes less space.
>
> Meh. I find the quotes confusing, e.g. if there are quotes in the text node:
> "And then I said, "wot?""
>
> But I guess that's not too bad and it is a bit easier on the eyes overall.
> I'm ok with changing this if that's what others think is better.
>
>> I suggest adding # signs to the selection pseudo-elements,
>> just to avoid the tiny risk of conflicting with an actual element in a
>> test. Also, perhaps it would be better to show tag names in lowercase -
>> that can be achieved by using localName instead of nodeName or tagName.
>
> Both of these make sense.
>
> Filed https://bugs.webkit.org/show_bug.cgi?id=43015.
>
> Ojan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Eric Seidel]

On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak  wrote:
>
> On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:
>
>> You can see many more examples of dom2string in the non-html5 results
>> (where there are a zillion failure cases):
>> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
>>
>> dom2string.js came from http://code.google.com/p/html5lib I thought,
>> but I couldn't find the source for it there.
>>
>> I'm not wedded in any way to dom2string.  But I do like the output it
>> produces slightly more than the current dumpAsMarkup.  I agree,
>> standardization might be nice.
>>
>> dom2string uses " for <#text> and .  newlines return you to
>> the start of the line as you would expect.  (see the
>> runner-expected.txt above).
>>
>> -eric
>>
>> p.s. Would be nice if we could just inject certain javascript into
>> every page.  Sorta like how v8 allows you to define engine-level
>> functions in javascript.  Would be nice to just make dumpAsMarkup()
>> part of DRT, but write it in javascript. :)
>
> That's easy to do, DRT could just force loading of the JS file that 
> implements dumpAsMarkup() (or whatever we end up calling it). But I'm not 
> sure that is better than including a JS file in the test explicitly. For one 
> thing, most of the logic to dumpAsMarkup() (other than forcing a text dump) 
> should work in any other browser, so it would make it easier to try our tests 
> in other browsers if the JS code implementing it is included explicitly 
> instead of magically. It would also make the tests more useful to try in a 
> WebKit-based browser like Safari or Chrome, for that matter - you wouldn't 
> need DRT to see the output.

Hmmm True.  This reminds me of my previous thoughts of making
DRT's controllers entirely a NPAPI plugin.   (Might make it possible
to run DRT-like tests in Safari or chrome renderers easier, and opens
the door for possible x-browser testing using expanded javascript
APIs.)  But that also has the same trouble of DRT being "too smart"
where explicit HTML is easier to run x-browser.

The idea behind auto-injecting JS appeals to me more for making
script-tests easier.

Then again it should be possible to re-write our script-test support
so that this is all you need to write:



description("foo");
shouldBe("foo", "bar");



Instead of the current (cumbersome) templating system.  Should be
possible to even get rid of the final "end-script-test.js" tag if
we're smart.

-eric
___
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)

[Eric Seidel]

I think symlinks would be an excellent option, assuming Git and SVN
have some solution for win32.

On Tue, Jul 27, 2010 at 11:50 AM, David Kilzer  wrote:
> On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak  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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Patches saying “Unreviewed”

[Eric Seidel]

This was added to enable a sane "you filled in a reviewer" check.
Requiring patch submitters to be explicit that the patch was not
reviewed instead of the case where they got the reviewer information
wrong.

We *very* commonly have cases where contributors (especially new ones)
just delete the "Reviewed by" line, or fill it in with "Reviewed by
nobody." or similar.  Not understanding our (admittedly confusing)
system.

I'm definitely open to other/better solutions.  Including removing (at
least the "unreviewed" part of) the check when not in commit-queue
mode.

-eric

On Fri, Jul 30, 2010 at 4:23 PM, Adam Barth  wrote:
> On Fri, Jul 30, 2010 at 1:10 PM, Darin Adler  wrote:
>> It’s come to my attention that some webkit-patch or some other script 
>> requires that patches without review contain the string “Unreviewed” 
>> somewhere in their change log message. I personally think this is not 
>> helpful. In my opinion patches that are don’t need review, such as some 
>> simple build fixes, need not list a reviewer, but also need not call 
>> attention to that fact.
>
> The commit-queue requires something like that to make sure it succeeds
> in filling in the reviewer information from bugs.webkit.org.  Running
> webkit-patch on the command line shouldn't require that.  We can
> figure out another mechanism to make sure the commit-queue fills in
> the proper reviewer.
>
> 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

Re: [webkit-dev] Patches saying “Unreviewed”

[Eric Seidel]

Last time I did that, I was accused of shouting... :)

http://trac.webkit.org/changeset/45647

But I support making prepare-ChangeLog less confusing.  Our "fix up
one of the OOPS, but don't touch the other!" expectation of
contributors is the source of much confusion. :)

-eric

On Fri, Jul 30, 2010 at 6:57 PM, Darin Adler  wrote:
> It’s totally reasonable for the bot to require a reviewer line, because the 
> bot requires a reviewer on the bug too.
>
> It’s in non-bot contexts that I think it’s not good. I think that means I 
> agree with you both who said that running webkit-patch on the command line 
> shouldn't require it. We can have the commit bot use an option to tell 
> webkit-patch it wants that rule.
>
> As far as the confusion factor is concerned, we could change the wording of 
> the "Reviewed by" line added by prepare-ChangeLog to make it more explicit.
>
>     Reviewed by  (OOPS).
>
> Or something nicer than that but with a similar flavor.
>
>    -- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Sharing WebKit mocks across platforms

[Eric Seidel]

On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow  wrote:
> Why wasn't it done that way originally?  That sounds (to my uneducated ear)
> much better than what's done today.
> J

The world was very different back then. :)

- WebKit was only on one platform (Mac).
- Much of what is now WebCore, was up in WebKit.
- (As Adam also mentions) LayoutTestController was initially more
about faking click events, etc.

A lot has changed in 6, 7, 8.. whatever it is now... years.

I agree, I think that a better modern solution would be to move huge
chunks of DRT into WebCore itself, and have them compiled in Debug and
Release builds and removed from Production builds (controlled by some
flag).

WebKit ports would just pipe another method
"exposeTestObjectsToJavaScript" or similar up to the various DRT
ports.

We could get rid of a huge amount of boiler-plate DRT code (much of
which deals with type conversions).

-eric

> On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth  wrote:
>>
>> WebCore::LayoutTestController would be exposed to JavaScript running
>> in LayoutTests directly (like the DOM), so we can skip the type
>> conversions.
>>
>> Adam
>>
>>
>> On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath  wrote:
>> > With a WebCore::LayoutTestController, would there be a need for code in
>> > WebKit to convert the call parameters from WebKit types (which DRT uses)
>> > to
>> > WebCore types (which the mocks may use) ? If yes seems like we need
>> > wrappers
>> > to proxy the mock calls anyway on different platforms..
>> > Cheers
>> > Satish
>> >
>> >
>> > On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth  wrote:
>> >>
>> >> Thanks for bring this question to the list.  I don't have a strong
>> >> opinion here, but I want to make sure we think project-wide and pick
>> >> something scalable.
>> >>
>> >> This discussion is also related to the discussion about adding
>> >> something like a layoutTestController object to WebCore.  Plumbing
>> >> this mock API all the way through WebKit for each port seems like a
>> >> waste.  If we had something like a WebCore::LayoutTestController, it
>> >> would make a lot more sense to expose that functionality there.
>> >>
>> >> Adam
>> >>
>> >>
>> >> On Wed, Jul 28, 2010 at 11:30 AM, Steve Block 
>> >> wrote:
>> >> > I'm in the process of adding a mock client for DeviceOrientation,
>> >> > which will be used in DumpRenderTree to test the feature. In order to
>> >> > share the mock across platforms, I'd like to add the mock to
>> >> > WebCore/platform/mock.
>> >> >
>> >> > An interface to the mock will have to be exposed to the embedder
>> >> > through the platform's WebKit API, so that it can be configured by
>> >> > DRT, eg ...
>> >> >
>> >> > mWebView.getDeviceOrientationClientMock().setOrientation(...);
>> >> >
>> >> > To avoid each platform having to produce it's own WebKit wrapper for
>> >> > the mock, I'm considering adding a common WebKit wrapper, perhaps to
>> >> > WebKit/common, and I wanted to get some feedback on the idea. The
>> >> > mock
>> >> > would be shared between all C++ WebKit platforms. (Note that this is
>> >> > for convenience only, a platform could equally use it's own WebKit
>> >> > wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or
>> >> > use its own mock altogether.)
>> >> >
>> >> > Of course we also need WebKit wrappers for all of the non-POD types
>> >> > used by the mock's interface, and these have to be common between all
>> >> > platforms. One obvious potential difficulty is the wrapper for
>> >> > WebCore::String. Each platforms already has a wrapper for this type,
>> >> > but there's no guarantee of interoperability, so we'd need to write a
>> >> > new common interface if we're to use the string type.
>> >> >
>> >> > If a wrapper for string ends up being too problematic, the approach
>> >> > could still be used for mocks that don't need the string type (of
>> >> > which DeviceOrientation is one), but the approach then seems less
>> >> > compelling.
>> >> >
>> >> > Do people think that this is a reasonable proposal and worth
>> >> > pursuing?
>> >> > Has there been any attempt to do anything similar before? Or is any
>> >> > attempt to write this kind of common WebKit code not worth the effort
>> >> > and destined to failure?
>> >> >
>> >> > You can see the work in progress for DeviceOrientation at
>> >> > https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for
>> >> > SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603
>> >> >
>> >> > I'd appreciate any feedback you may have.
>> >> >
>> >> > Thanks,
>> >> > Steve
>> >> >
>> >> > --
>> >> > Google UK Limited
>> >> > Registered Office: Belgrave House, 76 Buckingham Palace Road, London
>> >> > SW1W 9TQ
>> >> > Registered in England Number: 3977902
>> >> >
>> >
>> >
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
_

[webkit-dev] commit-queue switching to Snow Leopard this week

[Eric Seidel]

- CQ will block on the SL Release builder
- CQ will test on SL Release before committing.

Most users shouldn't notice or care.

Email me if you have questions.

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

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

[Eric Seidel]

Woh.  I think that's an awesome idea. :)

Would also make sure that all reviewers are blog-enabled.

Might be a bit to ask of new reviewers though.

-eric

On Mon, Aug 2, 2010 at 11:56 AM, Tony Gentilcore  wrote:
> The Surfin' Safari blog seems to have fairly wide readership in the web dev
> community. Google Reader reports 35k Reader subscribers. For comparison:
> blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last
> post with descriptive content was back on April 18th. Since that post, we've
> written 8 "X is a now a WebKit reviewer" posts. One recent commenter said:
> "I don’t suppose there’s anything more interesting going on in WebKit land
> worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t
> nearly as interesting as whatever new hotness is coming down the pipe. And I
> know I’m not the only one who thinks so… Feel like blogging about WebKit
> awesomeness?"
>
> I propose we increase the amount of blogging about WebKit awesomeness by
> changing the tradition for new reviewer posts.
>
> Instead of defaulting to:
>
>   So-and-so is now a WebKit reviewer
>   Posted by Someone-else
>   So-and-so has worked on awesome-feature or awesome-infrastructure...
>
> We encourage (or just allow?) a format more like:
>
>   How awesome-infrastructure works
>   Posted by So-and-so, the latest WebKit reviewer
>   Here's my description of how awesome-infrastructure works in WebKit...
>   -OR-
>
>   Awesome-feature is the new hotness
>   Posted by So-and-so, the latest WebKit reviewer
>   Web developers can now use awesome-feature. Here's how it works...
>
> Thoughts?
> -Tony
> ___
> 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