Hi!
We have some stable Qt bots on http://www.sed.hu/webkit/qtbuildbot/
which we would like to connect to the Apple buildbot master.
The bot names are:
x86-32 Windows Qt Release - QtWebKit release build on x86-32
architecture
x86-32 Windows Qt Debug - QtWebKit debug build on
I'm strongly in favor of more builders.
However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.
Right now Windows, Qt and Gtk builders at build.webkit.org are red and
mostly ignored by the project. Would these new
On Apr 9, 2010, at 1:02 AM, Eric Seidel wrote:
I'm strongly in favor of more builders.
However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.
Right now Windows, Qt and Gtk builders at build.webkit.org are red and
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
Can someone please point to the bug report and the forum where this
development was discussed by the greater WebKit
On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez x...@gnome.org wrote:
I suppose I could wait until you land the patches and see by myself, but:
- In the wiki you mention that one goal of the new framework is to
provide a stable C-based API. Is this meant as a public API for
WebKit, the same in all
On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:
I hope this post clarifies why the Chromium WebKit port is not
really a viable solution for our needs as it stands today.
It was _very_ helpful. Thanks for taking the time to explain it so
well. (It might be worth moving some of that
Hi!
Your wiki says:
DrawingArea - an abstraction for a cross-process drawing area. Multiple
drawing strategies are possible, the simplest is just a shared memory
bitmap.
Could you tell me more about it? I am working on a parallel painting
feature (GraphicsContext commands can be forwarded to
hi ,
why only multi-process and not multi-thread like android. It is useful for
mobile environments.
thanks,
Zaheer
On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:
On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:
On Fri, 2010-04-09 at 01:20 -0700, Maciej Stachowiak wrote:
Perhaps build.webkit.org should have a multi-page setup like how
build.chromium.org does where the main page is builders that are
expected to be green, and other pages are FYI were builders may or
may not always be green.
I
Hi,
It looks supporting multi-threaded model.
See WebProcessLauncher.mm for detail.
--
morita
On Fri, Apr 9, 2010 at 9:11 PM, zaheer ahmad zaheer@gmail.com wrote:
hi ,
why only multi-process and not multi-thread like android. It is useful for
mobile environments.
thanks,
Zaheer
On
Hi,
Of course we would like to add only very stable bots to build.webkit.org .
The bots in question are two Windows builders (release and debug), one
Linux builder (release with --minimal option, which guards the #ifded
guards) and two ARM-Linux builders (ARMv5, ARMv7).
The URL that Gábor
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote:
Given what proportion of overall maintenance work on WebKit I done by
Apple, I don't think anyone is entitled to veto us adding a new API
Whaa? Who is talking about veto of Apple's work? Rather, I am suggesting
that it would have
Hi,
Alexey Proskuryakov írta:
FIXME! is different from FIXME: in that Xcode doesn't recognize
it. I'm surprised that style guide doesn't say anything about FIXME vs.
TODO.
I wasn't aware of this, thanks for your
advice, I will use FIXME: next time.
+ // [Qt]r57240 broke Qt build (might
On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson ander...@apple.com wrote:
WebKit2 is designed from the ground up to support a split process model,
where the web content (JavaScript, HTML, layout, etc) lives in a separate
process. This model is similar to what Google Chrome offers, with the
The OpenGL approach to this problem is to have two layers with the
same API. (Sorry my diagrams aren't as awesome as Maciej's.)
Application
--- WebKit2 API ---
Multiproc client implementation
=== Process Boundary ===
Multiproc server implementation
--- WebKit2 API ---
Singleproc implementation
The prototype works with both a threaded model and a multiple process model,
chosen at runtime. It seems worthwhile to keep this feature.
Anders told me he often turns on the threaded model to debug since the
development tools we have work better with a single process and multiple
threads than
On 4/9/2010 9:06 AM, Darin Adler wrote:
The prototype works with both a threaded model and a multiple process model,
chosen at runtime.
That's good to hear, because also there are some platforms where
creating multiple user processes is not allowed.
-Benbuck
Another issue seems to be that parts of the public C API expose
CoreFoundation, which definitely would be an issue for the other
ports. I'm told on the side that this was just done as a quick
solution to have something running and that if there's interest by
other ports in using this we'd
On Apr 8, 2010, at 5:58 PM, Maciej Stachowiak wrote:
- Does your new framework require any significant changes in WebCore?
Could you briefly summarize them?
No WebCore changes are required - it works with the existing WebCore.
Right now WebCore needs to be built with some different flags
Hi all,
I need a WebKit Ranger for this question:
Imagine I have the word Foo inside an edit field (input type=text
value=Foo) and the word bar outside of it, like so: [Foo]bar
If I try to create a Range of the text Foobar, the range will get collapsed.
It collapses because Range::setEnd has a
This is how we are designing the Pepper API [1] by the way. It is designed
to be layered in order to support an optional, out-of-process
implementation.
I've always been interested in a similar model for WebKit.
-Darin
[1] https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI
On Fri, Apr
On Apr 9, 2010, at 10:52 AM, Finnur Thorarinsson wrote:
I need a WebKit Ranger for this question:
Imagine I have the word Foo inside an edit field (input type=text
value=Foo) and the word bar outside of it, like so: [Foo]bar
If I try to create a Range of the text Foobar, the range will
Thanks for a super quick response Darin. One followup question:
The find code in markAllMatchesForText needs to not consider matches that
cross the boundary between the inside of an edit field and the rest of the
document.
Fair enough. I can see why it should ignore those matches, but if you
On Apr 9, 2010, at 11:06 AM, Finnur Thorarinsson wrote:
Fair enough. I can see why it should ignore those matches, but if you look at
the details for the bug (https://bugs.webkit.org/show_bug.cgi?id=25868) it
states that the markAllMatchesForText function not only ignores the match but
it
Excellent.
If anyone has good ideas on how to improve it, I'm willing to come up with a
patch, test it in my tree and submit it for review...
On Fri, Apr 9, 2010 at 11:07, Darin Adler da...@apple.com wrote:
On Apr 9, 2010, at 11:06 AM, Finnur Thorarinsson wrote:
Fair enough. I can see why
On Apr 9, 2010, at 7:14 AM, Adam Treat wrote:
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote:
Given what proportion of overall maintenance work on WebKit I done by
Apple, I don't think anyone is entitled to veto us adding a new API
Whaa? Who is talking about veto of Apple's
Dear everyone,
I am new to study Webkit. In short, I used dump render tree for Google
page: http://www.google.com :
layer at (0,0) size 800x600
RenderView at (0,0) size 800x600
layer at (0,0) size 800x371
RenderBlock {HTML} at (0,0) size 800x371
RenderBody {BODY} at (8,3) size 784x352
On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
Can someone please point to the bug report and the forum where this
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active maintainer.
IMHO, that's a good thing. I wonder if we should archive ports that
don't have an active maintainer (e.g., by moving them into a branch).
Adam
Which ports are considered unmaintained?
Kenneth
On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active maintainer.
IMHO, that's a good thing.
On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich
cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active
maintainer.
IMHO, that's a good thing. I wonder if we should archive ports that
don't have an active
On Apr 9, 2010, at 2:09 PM, Maciej Stachowiak wrote:
On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active maintainer.
IMHO, that's a good thing. I wonder if
On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote:
There were in fact bugs opened with patches attached, and webkit-dev
was notified before any of the patches were committed afaik. However,
Indeed, but the post to webkit-dev had no link to the patches and no time was
given for anyone
On Friday 09 April 2010 04:53:31 pm Cameron Zwarich wrote:
In the past we have accepted the Chromium port despite it having a new JS
engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated
changes, numerous layering violations, and seemingly unnecessary changes
or replacements
Is the Haiku port actively maintained?
http://trac.webkit.org/browser/trunk/WebKit/haiku/
Looking at the ChangeLog, I don't see any real activity:
http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog
Maybe we should archive it? I certainly don't want to exclude Haiku
from the
SVN already is an archive. Were we to archive a port, we would just
remove the ifdefs and associated files. We already have scripts for
doing this (buried in bugzilla, or in WebKitTools/Scripts).
-eric
On Fri, Apr 9, 2010 at 2:26 PM, Adam Barth aba...@webkit.org wrote:
Is the Haiku port
On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.orgwrote:
On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:
On Thursday 08 April 2010
Is my question too stupid?
rikutse wrote:
Dear everyone,
I am new to study Webkit. In short, I used dump render tree for Google
page: http://www.google.com :
layer at (0,0) size 800x600
RenderView at (0,0) size 800x600
layer at (0,0) size 800x371
RenderBlock {HTML} at (0,0)
Last I looked there are still patches up for review for Haiku. It
would be nice to know why it is not being maintained. Is that due to
having no interest from their community or due to the fact that noone
are reviewing the patches?
Kenneth
On Fri, Apr 9, 2010 at 6:26 PM, Adam Barth
- Ursprüngliche Nachricht -
Von: Kenneth Christiansen
Gesendet: 09.04.10 23:52 Uhr
An: Adam Barth
Betreff: Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that
jazz)
Last I looked there are still patches up for review for Haiku. It
would be nice to know why it is not
- Ursprüngliche Nachricht -
Von: Adam Barth
Gesendet: 09.04.10 23:26 Uhr
An: webkit-dev@lists.webkit.org
Betreff: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that
jazz)
Is the Haiku port actively maintained?
http://trac.webkit.org/browser/trunk/WebKit/haiku/
On Apr 9, 2010, at 2:13 PM, Adam Treat wrote:
On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote:
the new piece of tech really is just a new API layer for the Mac
and
Win ports. We are interested in other people being able to reuse this
technology, but fundamentally, this is an
Woah, ok. It seems there is still significant interest in the Haiku
port. No offense intended.
Adam
On Fri, Apr 9, 2010 at 3:09 PM, Stephan Assmus supersti...@gmx.de wrote:
- Ursprüngliche Nachricht -
Von: Adam Barth
Gesendet: 09.04.10 23:26 Uhr
An: webkit-...@lists.webkit.org
Can anyone tell me is it possible and if possible how to bind a new
scripting language to webkit?
cheers,
Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi,
I'm officially the main maintainer of the Haiku port. But
considering my university course I have little time to work on it.
(I had plan to do so next summer though.) Another Haiku developer,
Stephan Assmus, did lately some great improvements on the port,
but is now focused on the web browser
It is possible, although a lot of work. You might be interested in
the code in WebCore/bindings, which shows how to bind JavaScript and
Objective-C.
Adam
On Fri, Apr 9, 2010 at 3:26 PM, yunpheng lau yunpheng@gmail.com wrote:
Can anyone tell me is it possible and if possible how to bind a
On Apr 9, 2010, at 2:45 PM, rikutse wrote:
Is my question too stupid?
No, but it is directed at the wrong mailing list. You should read
http://webkit.org/contact.html and probably contact webkit-help.
- Adele
rikutse wrote:
Dear everyone,
I am new to study Webkit. In short,
Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
numerous other engineers, WebKit now has a new test harness for
running the Layout Tests.
It's FAST:
4-core Mac Pro, Debug build:
run-webkit-tests: 11m25s
new-run-webkit-tests: 3m24s
new-run-webkit-tests --experimental-fully-parallel:
Hi, Eric,
In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692 tests) while run-webkit-tests none. Is this expected?
Are all of the errors what you mean by Exposes more flaky tests due to
running tests in a non-deterministic order ?
Yuzo
On Sat, Apr 10, 2010 at
Sounds like a bug. You should expect 0 failures on leopard or snow leopard.
Please file a bug with a log of the failures and I will fix.
On Apr 9, 2010 4:11 PM, Yuzo Fujishima y...@google.com wrote:
Hi, Eric,
In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692
On Apr 9, 2010, at 3:35 PM, Eric Seidel wrote:
Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
numerous other engineers, WebKit now has a new test harness for
running the Layout Tests.
...
Cons:
- Exposes more flaky tests due to running tests in a non-deterministic order.
On 09.04.2010, at 16:32, Brady Eidson wrote:
- Exposes more flaky tests due to running tests in a non-
deterministic order.
This sounds like a pro to me.
Existing run-webkit-tests can also do that, via a non-default option.
Unreproducible results with default options do sound like a
On Apr 9, 2010, at 4:41 PM, Alexey Proskuryakov wrote:
On 09.04.2010, at 16:32, Brady Eidson wrote:
- Exposes more flaky tests due to running tests in a non-deterministic
order.
This sounds like a pro to me.
Existing run-webkit-tests can also do that, via a non-default option.
Thanks a lot, Adele
Adele Peterson wrote:
On Apr 9, 2010, at 2:45 PM, rikutse wrote:
Is my question too stupid?
No, but it is directed at the wrong mailing list. You should read
http://webkit.org/contact.html and probably contact webkit-help.
- Adele
rikutse wrote:
Sorry, (mostly) false positives.
I've synced to r57383 and all but 3 failures are gone.
I don't see /tmp/layout-test-results. Where are the errors logged?
The following is the console output.
$ ./WebKitTools/Scripts/new-run-webkit-tests
stopping DumpRenderTree timed out, killing it
killed
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson beid...@apple.com wrote:
We should make the new tool record the order so order-specific failures can
be explored.
That sounds like a good idea. If the tool doesn't do this yet, we can
certainly add that.
Fixing some of these have been easy so far.
The new tool had a much tighter timeout than the old tool. We'll
probably have to increase that. You can also mark a test as SLOW in
test_expectations.txt, and then it will be given a longer timeout. It
might be worth having a shorter timeout for developers so we know when
we write slow tests.
Chromium has a bunch of perf bots that we run continuously. Most of these
are just page cyclers that loop through pages. They're grouped by different
types. You can see some graphs here:
http://build.chromium.org/buildbot/perf/dashboard/overview.html. The more
stable bots will also turn red on
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson beid...@apple.com wrote:
On Apr 9, 2010, at 4:41 PM, Alexey Proskuryakov wrote:
On 09.04.2010, at 16:32, Brady Eidson wrote:
- Exposes more flaky tests due to running tests in a non-deterministic
order.
This sounds like a pro to me.
On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima y...@google.com wrote:
I don't see /tmp/layout-test-results. Where are the errors logged?
/tmp/run-chromium-webkit-tests-layout-test-results/*
This was done intentionally at the time to not collide with
run-webkit-tests, but it should be changed
We should make the new tool record the order so order-specific failures
can be explored.
A custom random generator would be enough. The seed can be given by a user
or a just starts with a random value which is reported when the test
finish. Much easier to share seed-revision pairs than
61 matches
Mail list logo
