Seems very broken:
http://queues.webkit.org/results/6184043
Could someone fix build-webkit or whatever piece is looking for the missing
Makefile?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
:
This is preventing me from building. Is there a solution that doesn't
require signing up for an Apple ID?
On Fri, Oct 29, 2010 at 3:17 AM, Tony Gentilcore to...@chromium.org
wrote:
On Wed, Oct 27, 2010 at 10:11 PM, Eric Seidel e...@webkit.org wrote:
Can we just include the headers
Generally I just open in another browser. Doesn't seem worth the
effort, but I don't think anyone is going to stop you. :)
On Wed, Nov 10, 2010 at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
Can we modify the bugzilla so that we can edit the details of attachments
without opening the
This conversation is heading in a dangerous direction... :)
Allowing QXML parser support to be added to WebKit was probably a
mistake. Adding custom QXPath or QXSLT support would be another.
WebKit is one platform. If XSLT or XPath 2.0 is good for the web, we
should add them to all ports, just
another EWS instance is as easy as running
webkit-patch win-ews (or gtk-ews, qt-ews, or whatever your port is).
Eventually I may put up a wiki page on the subject.
-eric
On Sun, Oct 24, 2010 at 8:53 AM, Eric Seidel e...@webkit.org wrote:
The EWS bots are mostly back.
The win-ews bot is getting
If you find a way to auto-install/auto-download the module as part of
run-webkit-tests that's fine.
On Fri, Nov 5, 2010 at 1:52 AM, Eric Seidel e...@webkit.org wrote:
This is a bad idea. Please don't do this.
Unless mod_bw comes installed in a normal Apache distribution, you're
asking
On Fri, Nov 5, 2010 at 8:19 AM, Eric Seidel esei...@google.com wrote:
On Fri, Nov 5, 2010 at 4:53 AM, Gustavo Noronha Silva g...@gnome.org wrote:
On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote:
This is a bad idea. Please don't do this.
Unless mod_bw comes installed in a normal Apache
I would like to restate Darin's request: Please upgrade to 3.2.4 or newer.
It would be really nice to end the developmentRegion = English war.
3.2.4 seems to work fine, and I'm told it might actually make distcc
work again. ;p
-eric
On Wed, Oct 6, 2010 at 5:00 PM, Darin Adler da...@apple.com
https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=D635F5C417E087A3B9864DAC5D25920C4E9442C9339FA9277951628F0291F620path=//devcenter/mac/index.action
is the direct download link. Will require you to log in, sadly.
-eric
On Mon, Nov 1, 2010 at 4:29 PM, Eric Seidel e
I guess I meant
https://developer.apple.com/ios/download.action?path=/ios/ios_sdk_4.1__final/xcode_3.2.4_and_ios_sdk_4.1.dmg
-eric
On Mon, Nov 1, 2010 at 4:31 PM, Eric Seidel e...@webkit.org wrote:
https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey
From teh right address.
On Sat, Oct 30, 2010 at 12:59 PM, Eric Seidel esei...@google.com wrote:
The correct fix is to fix the dependency issue in the build system.
Please file a bug so we can prevent these from occurring in the
future.
-eric
On Fri, Oct 29, 2010 at 11:59 PM, Osztrogonac
I'll just write a clean-room implementation of the headers. I've
never seen them, nor do I ever wish to. But if my compile breaks when
I update, I'll cobble together the necessary declarations in a new .h
file and stick it somewhere in WebKit. It will be just like the old
KWQ days! :)
-eric
Can we just include the headers in WebKit?
Or find some way to auto-download them?
This seems silly. Or certainly requiring an update to
http://webkit.org/building/tools.html.
-eric
On Thu, Oct 21, 2010 at 3:56 PM, Tony Gentilcore to...@chromium.org wrote:
Quick PSA: if you install the Java
It seems the EFL build is broken:
http://queues.webkit.org/queue-status/efl-ews
It also seems that the EFL-EWS is not restarting itself every 50
builds or so (since the build output is old-style).
Whoever is running that EWS, please use a wrapper like
need more capacity to keep up
with our 200-patch-a-day rate.
The rest of the bots seem fine for now.
I'll update webkit-dev when the rest are back online.
-eric
On Fri, Oct 22, 2010 at 11:11 AM, Eric Seidel e...@webkit.org wrote:
We made it so that the EWS system will always process a patch
We made it so that the EWS system will always process a patch if it
*ever* saw it with an r?. This means the EWS now will process r+
patches.
However, this is currently more capacity than the current EWS bots can
handle, so they're very back-logged at the moment.
There are several fixes we can
Thank you Adam.
We should look into more options here, including some of the ones
Maciej proposed.
Alternatively, we could have just skipped the tests which are flaking
so much. Alexey seemed to get CC'd on nearly every flake because they
seemed to mostly be tests he wrote. :(
-eric
On Wed,
is expected and desired?
-Bill
On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:
The most frequent consumer of the historical data is webkit-patch,
which uses it to map from revisions to builds:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109
It's
webkit-patch find-flaky-tests can also show you what tests are
recently flaky, but its not as nice as the dashboard.
-eric
On Tue, Oct 19, 2010 at 12:06 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
I agree that raising
On Tue, Oct 19, 2010 at 1:51 PM, Adam Barth aba...@webkit.org wrote:
Another option is to file a new bug about the flakiness and ping that
bug when we observe the test flake out.
I've considered this before. We'd have to write a bit of bugzilla.py
code to make this work though. :)
That's
Sorry, wrong account.
On Tue, Oct 19, 2010 at 1:59 PM, Eric Seidel esei...@google.com wrote:
On Tue, Oct 19, 2010 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
It looks like the bot is adding a comment to the bug with the patch that was
being processed when flakiness was detected
BTW, the commit-queue has started complaining publicly about flaky tests:
https://bugs.webkit.org/show_bug.cgi?id=47698#c5
Hopefully this will bring further awareness to the issue.
Test flakes are the second most common reason for delays with the
commit-queue (after the Snow Leopard build being
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
would be more compelling with a video. :)
I agree with Darin, this sounds like Browser-exposed DOM API. Not
something that WebKit has any business adding.
-eric
On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler
AM, Eric Seidel e...@webkit.org wrote:
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
would be more compelling with a video. :)
http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the
content didn't adjust to the dropdown size. You can play w
why WebKit needs to be
involved, since I would assume a browser would use a second-overlay
WebView for the navigation preview.
-eric
On Fri, Oct 15, 2010 at 10:46 AM, Eric Seidel e...@webkit.org wrote:
Please correct me if I'm wrong, but I can't think of any features
WebKit exposes which touch
On Thu, Sep 30, 2010 at 11:06 AM, Eric Seidel esei...@google.com wrote:
I've filed bugs for the top two:
19 media/audio-controls-rendering.html
https://bugs.webkit.org/show_bug.cgi?id=46924
50 compositing/geometry/limit-layer-bounds-transformed-overflow.html
https
I see:
[2010-09-30 16:52:57,560] [CRITICAL] root: [Errno 48] Address already in use
in my pywebsocket.ws.log-30Sep2010-165257-err.txt after an error. Not
sure if it's related, but sounds possible. :)
On Thu, Sep 30, 2010 at 3:10 PM, Adam Barth aba...@webkit.org wrote:
I'm investigating the
On Fri, Sep 24, 2010 at 11:42 AM, Eric Seidel esei...@google.com wrote:
https://bugs.webkit.org/show_bug.cgi?id=35460
On Fri, Sep 24, 2010 at 10:25 AM, Darin Adler da...@apple.com wrote:
It’s not great that if I review a patch that means it won’t get EWS results.
Maybe the EWS could
I agree they could be very useful. But right now, especially with so
many flaky tests in the tree, they're just spam.
I'd like to fix them and turn them back on, but I see no reason to
keep them spamming as is.
On Thu, Sep 23, 2010 at 1:43 PM, Mihai Parparita mih...@chromium.org wrote:
Perhaps
On Thu, Sep 9, 2010 at 9:45 AM, David Hyatt hy...@apple.com wrote:
On Sep 9, 2010, at 2:00 AM, Eric Seidel wrote:
Instead, we could change all elements to mark themselves (and their
parents) as needing style recalc during insertedIntoDocument(),
effectively attaching/lazyAttaching
to make a wider deployment of
lazyAttach after this lands. I think it could be a PLT win (and
certainly a parser benchmark win!)
On Thu, Sep 9, 2010 at 10:23 AM, David Hyatt hy...@apple.com wrote:
On Sep 9, 2010, at 12:17 PM, Eric Seidel wrote:
I'm not sure what you mean. You mean
I also attempted to look through pending-commit last week. I decided
to clean it out someone needs to write a script which can make a guess
if a bug is landed or not. I would guess that over half of
http://webkit.org/pending-commit are already landed and the lander
forgot to close the bug. [1]
You need to modify the WebCore target settings to have that header
marked as Private intead of public. There are various ways to do
that, either via the Targets area of the left side bar, or by getting
info on the header in the project file.
On Thu, Sep 2, 2010 at 4:29 AM, Yuzo Fujishima
Here are the list of files in the project which use ruby:
Scripts/check-for-inappropriate-files-in-framework:#!/usr/bin/env ruby
Scripts/check-for-webkit-framework-include-consistency:#!/usr/bin/env ruby
Scripts/clean-header-guards:#!/usr/bin/ruby
Scripts/roll-over-ChangeLogs:#!/usr/bin/env ruby
I'm very glad to see work being done to remove some of our redundant
layout test results:
http://trac.webkit.org/changeset/66124
I'm curious what the status of that work is. Do we expect all
duplicates are gone now? or just chromium's?
-eric
___
I recommend removing the XBL code. Hyatt started it years ago.
Jullien works on it for a summer as my GSoC mentee.
Anyone who wants to write a fully working XBL2 implementation can look
in svn history. As-is, it's untested, unbuildable, and a drag on the
project.
-eric
On Wed, Aug 25, 2010 at
25, 2010 at 11:47 AM, Eric Seidel e...@webkit.org wrote:
My comments apply to all of the enclose* APIs in that file.
On Wed, Aug 25, 2010 at 11:46 AM, Eric Seidel e...@webkit.org wrote:
/*!
Encloses the contents of this element with the result of parsing \a
markup.
This element
My comments apply to all of the enclose* APIs in that file.
On Wed, Aug 25, 2010 at 11:46 AM, Eric Seidel e...@webkit.org wrote:
/*!
Encloses the contents of this element with the result of parsing \a markup.
This element becomes the child of the deepest descendant within \a markup
/*!
Encloses the contents of this element with the result of parsing \a markup.
This element becomes the child of the deepest descendant within \a markup.
\sa encloseWith()
*/
void QWebElement::encloseContentsWith(const QString markup)
I think this callsite reads better w/o the QualifiedName*, but Darin
is right, that could just be htmlTag or whatever with a comment
explaining. This site could also crete its own:
static QualifiedName nullName(nullAtom, nullAtom, nullAtom) if it really wanted.
-eric
On Tue, Aug 24, 2010 at
Secret ports have an absolutely horrible track record of ever catching
up with public WebKit.
Only one has ever been successful to my knowledge (Chromium) and I'm
not even sure we could call it full success yet. (They've spent 2
years attempting to fully catch up, and yet you can't build a
This is fantastically wonderful.
Let me know what I can do to help. I'm happy to do reviews for what I can.
-eric
On Tue, Aug 24, 2010 at 12:05 PM, Chris Rogers crog...@google.com wrote:
Over the past months I've been refining the web audio API implementation
that I've been developing in the
I believe int tx, int ty -- which we see sprinkled around the
rendering tree -- are the offset from the top left corner of the
current renderer's parent to the containing block. Is that correct?
In SVG we use IntSize containingBlockOffset in the rare places we have
to deal with this
SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller
libraries fix these linker problems longer-term? For example,
breaking out platform into a .a, or the JS bindings? I guess we'd
have to make them .dylib instead of .a if we wanted to actually make
the linker happier.
On Mon,
Would this then combine with the Mac/Win port's RetainPtr in some way?
On Mon, Aug 23, 2010 at 9:49 AM, Martin Robinson mrobin...@webkit.org wrote:
Recently there was a need to make the smart pointer wrapping GLib
reference-counted types more general. In this case it was to extend it to
Has anyone looked at our coverage-generating scripts in a while?
Seems to die trying to build libANGLE these days, but I believe the
scripts have been dead for much longer.
I'm interested in finding (and removing) dead code from WebCore.
There is a whole bunch more dead code now that the
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called
Software Engineer
Google Inc.
On Mon, Aug 23, 2010 at 1:14 PM, Eric Seidel e...@webkit.org wrote:
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs
A reduction would be useful.
My general approach is: file a bug first, ask questions later. :)
Once we have a bug, we can attach a reduction and work towards
resolution (even if that means no change to WebKit).
-eric
On Mon, Aug 23, 2010 at 3:06 PM, Martin Sourada
martin.sour...@gmail.com
.
Simon
On Aug 23, 2010, at 2:54 PM, Eric Seidel wrote:
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed this weekend:
http://trac.webkit.org/search?q
Resig has a nice explanation:
http://ejohn.org/blog/dom-documentfragments/
or see the DOM spec.
DocumentFragments have little to do with parsing.
I'm actually writing a blog post about the DocumentParser system right
now. Should be on webkit.org/blog next week.
We already have profiling
I think the check-webkit-style rule for whatever the dominant case is
makes a lot of sense.
-eric
On Tue, Aug 17, 2010 at 1:41 PM, Jeff Johnson
opendar...@lapcatsoftware.com wrote:
Actually, this is caused by Xcode 4 (still in beta).
See rdar://problem/8295614 Xcode 4 fights with Xcode 3 over
of the
non-DOM-API out of the object called Document).
-eric
On Tue, Aug 17, 2010 at 2:01 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 17, 2010, at 9:35 AM, Eric Seidel wrote:
My theory on re-organizing document is we do the same thing we've been
doing to FrameLoader. Just start lopping off
I've had two WebCore full rebuilds today which currently I believe
were caused by this diff. (If that's true, then that too is an XCode
bug.) I have inconclusive evidence however, and will continue to test
and report back.
-eric
On Tue, Aug 17, 2010 at 2:00 PM, Darin Adler da...@apple.com
we have in webkitpy/thirdparty)
requires 2.5+. The cr-win bot has Python 2.3 (at least in its path).
I'm not yet sure what the right solution is. We may end up rolling out.
-eric
On Fri, Aug 13, 2010 at 10:21 PM, Eric Seidel e...@webkit.org wrote:
Sorry for the spam. I've found the error
http://build.webkit.org/builders/Chromium%20Win%20Release/builds/10478/steps/compile-webkit/logs/stdio
It seems that cr-win for some reason isn't generating the
HTMLEntityTable.cpp file like all the others are.
Is it missing python? (Or python from its path?)
Is there a gyp dependency problem?
\build\WebKitTools\Scripts\webkitpy\thirdparty\__init__.py,
line 101
1with codecs.open(readme_path, w, ascii) as file:
1 ^
1SyntaxError: invalid syntax
I'll figure out how to fix the sys.path to avoid including
thirdparty/__init__.py
-eric
On Fri, Aug 13, 2010 at 10:19 PM, Eric
If these tests are actually valuable, then maybe my question then
belongs: Why is Chromium no longer running these tests? (Assuming my
source is correct.)
-eric
On Wed, Aug 11, 2010 at 7:10 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote:
no expected results. So someone on the chromium team
skipped them all. There's a comment in
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt
that we probably don't want to run these, but I think that comment is just
wrong.
On Wed, Aug 11, 2010 at 9:31 AM, Eric
Chromium skips it (and if I remember correctly, they commissioned it?)
Why do we want to be running these 6000 tests and slowing down our
builds. I was talking with jamesr, and he seemed to think it adds
little value to run it every time? (It was supposedly written as more
of a development tool
Yes. The commit-queue uses svn-apply which knows how to fix the date using:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/VCSUtils.pm#L1231
-eric
On Mon, Aug 9, 2010 at 2:06 PM, Fady Samuel fsam...@google.com wrote:
What about the case where between the time you submit the patch and
I just spent a while debugging an error in code I wrote.
I added a couple new Foo* members to a class. And forgot to 0 them in
one of the constructors.
RefPtrT, OwnPtrT would have done this for me. But I wanted these
to be weak pointers.
How about we add a PtrT (or WeakPtrT or AutoNullT or
The Commit Queue will be down as of this afternoon, as we have to move
the machine this weekend.
Any patches you mark cq+ this weekend will get landed early next week
(likely monday).
I'll reply to this thread once it's back up and running.
Sorry for any inconvenience.
-eric
the queue with a
cq- to get it move on.. would be helpful to see what causes errors such as
those and the current one.
--
Cheers
Satish
On Wed, Aug 4, 2010 at 3:50 AM, Eric Seidel e...@webkit.org wrote:
It was down for the last 36 hours due to Leopard bustage and moving
machines. It's back
http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests)
We lost the slave over 3 days ago. :(
(The tree is also generally on fire right now...)
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
.
But there are ~90 pending
builds: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests)
For future reference, I'm curious if it is safe to cancel some older builds
so that it will catch up.
On Tue, Aug 3, 2010 at 11:37 AM, Eric Seidel e...@webkit.org wrote:
http://build.webkit.org
It was down for the last 36 hours due to Leopard bustage and moving
machines. It's back up and running again now. Apologies for (my
part) of the trouble.
http://queues.webkit.org/queue-status/commit-queue
-eric
___
webkit-dev mailing list
- 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
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
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
On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow jor...@chromium.org 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
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 ddkil...@webkit.org wrote:
On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak m...@apple.com wrote:
The main problem would be getting the right path to
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
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 e...@webkit.org wrote:
There is another DOM dump format which the html5lib tests use:
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected
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
On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak m...@apple.com 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
proactively seek
out reviewers. We're all busy, but when I'm asked to review a patch, I make
time for it or point the person at another reviewer.
Dave
--
Sent from my iPhone 4
On Jul 22, 2010, at 12:29 AM, Maciej Stachowiak m...@apple.com wrote:
On Jul 21, 2010, at 3:41 PM, Eric Seidel
or watch lists IMO because it's
automatically generated.
-eric
On Fri, Jul 23, 2010 at 8:04 AM, Alex Milowski a...@milowski.org wrote:
On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel e...@webkit.org wrote:
I've never really liked trac.webkit.org/wiki/WebKit%20Team. Its
always seemed more of place
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
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
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 aba...@webkit.org wrote:
A test has been crashing Leopard Intel Debug (Tests) for 24 hours. I
tried to look back on
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
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 o...@chromium.org wrote:
On Wed, Jul 14, 2010 at 7:54 PM, Eric Seidel e...@webkit.org wrote:
I will do what I
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,
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 mrobin...@webkit.org wrote:
On Wed, Jul 14, 2010 at 7:54 PM, Eric Seidel e...@webkit.org wrote:
We're removing redundant text nodes from
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 yz...@virginia.edu wrote:
Hi all-
I am newbie to webkit dev and I am trying to
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 pe...@lvp-media.com wrote:
Good day,
While going through WebCore for some
Please post a patch:
http://webkit.org/coding/contributing.html
On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org 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
*, 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 e...@webkit.org wrote:
/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release
/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
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.
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
andreas.delme...@telenet.be wrote:
On 17 Jun 2010, at 20:37, Alexey Proskuryakov wrote:
See
https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBIhl=en#
for a description of expected differences.
On Wed, Jun 16, 2010 at 2:18 AM, Adam Barth aba...@webkit.org wrote:
As of early this morning, we've enabled the HTML5 tokenizer on trunk.
I expect we've
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
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 e...@webkit.org wrote:
We
these are all symptoms of WebKit's total lack of real trybots. ;)
-eric
On Wed, Jun 16, 2010 at 3:27 PM, Maciej Stachowiak m...@apple.com 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
Stachowiak m...@apple.com 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
: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
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
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 m...@apple.com 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
401 - 500 of 807 matches
Mail list logo
