On Apr 9, 2010, at 2:40 AM, Xan Lopez wrote:
> 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
> 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 anythi
On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima 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 [1].
-- Dirk
[1
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson 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.
>>
>
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 perf
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.
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson 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. For example, t
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
web
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
>
>>
>>
>>
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-def
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 con.
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 orde
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" wrote:
Hi, Eric,
In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692 tests) while ru
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 a
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:
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
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 wrote:
> Can anyone tell me is it possible and if possible how to bind a new
> scripting langua
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 browse
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
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 wrote:
>> - Ursprüngliche Nachricht -
>> Von: Adam Barth
>> Gesendet: 09.04.10 23:26 Uhr
>
>> An: webkit-...@lists.webkit.org
>> Betreff:
On Apr 9, 2010, at 2:36 PM, Darin Fisher wrote:
Perhaps we should discuss some of these problems that you perceive
to still exist with the Chromium port at the WebKit conference. I'd
like to understand better.
One thing Adam Barth and I discussed recently was unforking URL
processing.
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
> - 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/
- 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 being
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 wrote:
> Is t
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 (
On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher wrote:
> On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich wrote:
>
>> On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
>>
>> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat wrote:
>>
>>> On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
>>> > On Apr 8
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich wrote:
> On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
>
> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat 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
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 wrote:
> Is the Haiku port actively maintained?
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 community.
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 replaceme
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 anyon
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 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
On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich
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 movi
Which ports are considered unmaintained?
Kenneth
On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth wrote:
> On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich 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" p
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich 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
__
On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat 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
> > > developm
> I think the right way to achieve this will be with a simple typedef, but we
> won't know for sure until more ports try to adopt this API.
Looks like Sam went with a slightly different solution:
https://bugs.webkit.org/show_bug.cgi?id=37347.
Geoff
__
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 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 wor
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 wrote:
> On Apr 9, 2010, at 11:06 AM, Finnur Thorarinsson wrote:
>
> > Fair enough. I can see why it should ign
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
>
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 lo
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
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
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::setEn
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
> 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 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
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
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
We
On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson 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 major
> difference b
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
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,
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 showed
Hi,
It looks supporting multi-threaded model.
See WebProcessLauncher.mm for detail.
--
morita
On Fri, Apr 9, 2010 at 9:11 PM, zaheer ahmad wrote:
> hi ,
> why only multi-process and not multi-thread like android. It is useful for
> mobile environments.
> thanks,
> Zaheer
>
> On Fri, Apr 9, 2010
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.
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 wrote:
>
> On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:
>
>
> On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:
>
>
>> I ho
On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:
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
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 dif
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 desc
On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez 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 platforms
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat 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 community?
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
m
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 buil
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 x86-
66 matches
Mail list logo