Sorry, wrong address.
On Sat, Jul 12, 2014 at 10:55 AM, Eric Seidel esei...@google.com wrote:
I used to use http://isitup.org/ to watch the front page. It would be
trivial to extend the QueueStatusServer code to provide easier patches
for services like isitup to watch:
https://github.com
As Maciej notes, this is not the right mailing list to ask these sorts
of things. But since the answer appears simple, here it is:
http://en.wikipedia.org/wiki/Safari_version_history claims that Safari
5.1.8 means WebKit 534.58.2
which theoretically comes from:
FWIW, Blink is going through this right now too. We're attempting to
move completely away from prefixed development:
http://www.chromium.org/blink#vendor-prefixes
To do that, that requires making it possible enable/disable CSS
properties at runtime:
their respective bindings generators in,
perhaps we'll end up using the same parser library.
Best of luck!
On Wed, Apr 10, 2013 at 3:36 PM, Eric Seidel e...@webkit.org wrote:
I know some folks in our TOK office have expressed strong interest in
re-writing it in python for Blink. Perhaps
Unrelated to Dmitry's suggestion, but since I brought up emeritus
contributors earlier in the thread, I should explain my usage. The
emeritus class proposed in the ancient webkit-reviewers thread about
sunsetting was simply to answer the fact that committers.py has two
purposes:
1. It exists as
to recognize the
person within the project. It's symbolic, and it feels nicer than just
wiping them from the system.
The fact that it serves the purpose of supporting lookup (your point (2)) is
good, also.
-Filip
On Apr 10, 2013, at 12:37 AM, Eric Seidel e...@webkit.org wrote
I know some folks in our TOK office have expressed strong interest in
re-writing it in python for Blink. Perhaps there is an opportunity
for some x-project collaboration here.
On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
Can we rewrite CodeGenerator*.pm in Ruby or
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years. I believe there are some old threads on
webkit-reviewers about such.
I believe the timeout for
Sorry. Wrong address again.
On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel esei...@google.com wrote:
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years
We'll be in #webkit and happy to be helpful in any way we can.
I considered posting patches to remove *Chromium files yesterday
afternoon, but then abarth reminded me that the commit-queue currently
uses chromium-linux. I spoke with rniwa at some length yesterday in
#webkit about transitioning
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote:
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and
Resent from the right address.
On Thu, Apr 4, 2013 at 1:09 PM, Eric Seidel esei...@google.com wrote:
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote
I’m writing to say thank you, personally, and on behalf of the Chromium project.
Chromium could not have happened without WebKit and the help of its
contributors.
As you likely have seen, Adam just posted
http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html
announcing Blink,
It seems like it should be trivial to set up an EWS bot to track size changes.
It would (sadly) need to clobber, as my understanding is that
incremental builds are not deterministic in their sizes:
https://code.google.com/p/chromium/issues/detail?id=110002
(our bug about this for Chromium Try
things we have (ex. the 600 template expansions from StyleBuilder)
On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel e...@webkit.org wrote:
It seems like it should be trivial to set up an EWS bot to track size
changes.
It would (sadly) need to clobber, as my understanding is that
incremental
I think to expect folks to use these results, we're going to need to
give them nice tools, like:
https://bugs.webkit.org/show_bug.cgi?id=92033
On Thu, Mar 21, 2013 at 10:55 AM, Ryosuke Niwa rn...@webkit.org wrote:
Fixed it in http://trac.webkit.org/changeset/146443.
So yeah, don't add entries
Thank you very much for making the uploads (and thus the flaky test
reporter) work again!
On Thu, Mar 21, 2013 at 2:52 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Mar 21, 2013 at 2:50 PM, Eric Seidel e...@webkit.org wrote:
I think to expect folks to use these results, we're going to need
Thanks for following up Philip. I don't feel like this thread met
much consensus, more just went off into the weeds.
Given the history of that page, I'm not sure it truly reflects the
consensus of the project:
https://trac.webkit.org/wiki/CreatingLayoutTests?action=history
Regardless of
May our generated content (and general render safety and speed) live
long and prosper. :)
Grats Elliot!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
As of http://trac.webkit.org/changeset/144719
--profile and --profiler= work in run-webkit-tests, just like they do in
run-perf-tests.
For example you can find out why your/favorite/tests are so slow with:
run-webkit-tests your/favorite/tests --profile
RWT will sample each DRT instance and
Nice to have another hand for SVG reviews. :)
Grats to pdr!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
I've noticed as of late several different approaches being used when
adding/changing LayoutTests which need rebaselining on other platforms.
Obviously we cannot expect developers to test/rebaseline on all platforms
before landing given our current infrastructure.
But what should we expect them
I have no objection to us using this compiler feature.
On Fri, Feb 22, 2013 at 2:35 PM, Julien Chaffraix jchaffr...@webkit.orgwrote:
Hi WebKit folks,
over several reviews, I have been saying that the following line is a
coding style violation:
firstVariable = secondVariable = 0;
For a
App engine error perhaps?
http://webkit-commit-queue.appspot.com/active-bots
On Sun, Feb 17, 2013 at 4:15 AM, Mike West mk...@chromium.org wrote:
(Resending from the right address, sorry...)
Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
apparently died about 13
and was terminated. This is likely
to cause a new process to be used for the next request to your
application. If you see this message frequently, you may have a memory
leak in your application.
On Sun, Feb 17, 2013 at 9:31 AM, Eric Seidel esei...@google.com wrote:
App engine error perhaps?
http
I wonder if the git-taking-over-the-project trend has continued a year later.
I'm also glad to see efforts like
https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
on a simpler git workflow. :)
Thanks again for running the survey.
On Sat, Apr 7, 2012 at 4:58 PM, Maciej
this evening.
(For current svn users I assume using svn would become effectively
impossible; the only tool I could find to do this is server-side and
essentially maintains git and svn repositories in parallel.)
- Maciej
On Feb 17, 2013, at 9:00 PM, Eric Seidel e...@webkit.org wrote:
I wonder
On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel e...@webkit.org wrote:
On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com wrote:
There's probably proportionately more people using Git. Making these web
surveys is a pain, so I'd rather not do it again if we don't need to.
What
He's dead, Jim:
https://bugs.webkit.org/show_bug.cgi?id=107522
On Thu, Jan 17, 2013 at 5:54 PM, Maciej Stachowiak m...@apple.com wrote:
I think it's fine to shoot it in the head now. We do still want to come back
to it eventually, but it's now apparent that we won't in the next 1.5 months.
Having just spent all day removing NEW_XML cruft, I'm glad to see this
unused code go sooner rather than later. :)
On Mon, Feb 11, 2013 at 3:44 PM, Nico Weber tha...@chromium.org wrote:
Going once, going twice…
https://bugs.webkit.org/show_bug.cgi?id=109501
On Sat, Feb 2, 2013 at 3:09 PM,
This entire email thread makes me sad.
I'm sad because we did this to ourselves (our porting systems/policies
are lacking), we did this very abruptly (the last port we kicked out
of webkit.org took a year?), and we don't have any clear policy for
this sort of thing (adding/removing ports in
I'm curious if YAML was ever considered? I have very limited
experience with YAML, except for Google App Engine config files.
It's very python parse-able? :)
On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote:
You’re not supposed to use arbitrary Python, it’s highly
+1
Ninja is beyond-words amazing. http://martine.github.com/ninja/ For
better or worse, it is not designed to use human-editable build files,
but rather to be used by a meta build system, like GYP or CMake. So
using ninja is really an orthogonal discussion to the single build
system discussion
What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols. If both were to
convert to using EXPORT decorators instead, then we could remove needs for
fixing export lists.
Please correct me if I've misunderstood.
Other ports
be exported from WebKit on any port besides Internals symbols.
On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote:
What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols. If both were to
convert to using
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
Thanks for sharing this.
On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we only had one build system (it were easy to add/remove/move files).
I believe changes like http://trac.webkit.org/changeset
On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak m...@apple.com wrote:
Hi Eric,
These are great thoughts. I agree with you on all points. One informative
comment below:
On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we only had one build system (it were easy
On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez x...@gnome.org wrote:
Hi Eric,
On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we didn’t have to worry about platforms we couldn’t test.
It can’t be the job of the core maintainers to care about all the peripheral
ports
On Wed, Jan 30, 2013 at 3:24 PM, Patrick Gansterer par...@paroga.com wrote:
Hi,
Am 30.01.2013 um 22:28 schrieb Eric Seidel:
I wish we only had one build system (it were easy to add/remove/move files).
I've created CMake files for two different ports at [1] and [2] already, but
did't get
On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard ale...@webkit.org wrote:
On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we only had one build system (it were easy to add/remove/move files).
I believe changes like http://trac.webkit.org/changeset/74849
I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than that there is a defined set of
platform APIs and callbacks which it talks to (which should be the
exact same for every embedder).
(The export dependency dates back to the WebCore/WebKit
The future! Is now! :)
Very exciting. I hope some day we can use C++11 for the rest of WebCore too.
On Wed, Jan 30, 2013 at 12:17 PM, Anders Carlsson ander...@apple.com wrote:
Hello!
This is just a friendly heads-up that the Mac specific parts of WebKit2 will
soon start requiring C++11
*I wish we only had one build system (it were easy to add/remove/move
files).*
*
I believe changes like http://trac.webkit.org/changeset/74849 are an
unhealthy sign for the project. Adam is not the only person who has chosen
to empty files instead of removing them. The pain of updating 8 build
Thank you for sharing!
It appears that unless you're logged into WordPress (I had to go dig
up my credentials) you just get a 404.
On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson d...@apple.com wrote:
Related: when the unprefixed transitions are enabled by default, we plan
to make a
I'm surprised that chromium mac is 3x the size of Apple Mac... debug
even! Chromium build output should be much smaller... at least as of
late.
On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote:
Here are the largest results sets on the master in GB. We currently store
This question came up in:
https://bugs.webkit.org/show_bug.cgi?id=92393
Do any ports still disable SVG? Should we be removing the ENABLE_SVG
defines (and potentially unifying SVG and HTML style resolve more
closely)?
___
webkit-dev mailing list
Sorry. webkit-patch upload does not have very good error handling:
https://bugs.webkit.org/show_bug.cgi?id=72863
On Thu, Jan 17, 2013 at 10:49 AM, Raymond Toy r...@google.com wrote:
Hmm. I have a git checkout of webkit so svn-create-patch doesn't want to
work.
Yeah, the patch is probably
I believe the queue was actually cleared when they were brought
online. As Ossy notes, this is expected behavior.
Every time the feeder queue boots up (which is every 2 hours), it
sends *all* patches marked for review to queues.webkit.org.
queues.webkit.org makes sure that each individual EWS
, 2013 at 11:50 AM, Eric Seidel e...@webkit.org wrote:
I believe the queue was actually cleared when they were brought
online. As Ossy notes, this is expected behavior.
Every time the feeder queue boots up (which is every 2 hours), it
sends *all* patches marked for review to queues.webkit.org
rebase
on top of that, but that's a start.
On Thu, Jan 17, 2013 at 4:00 AM, Dominik Röttsches
dominik.rottsc...@intel.com wrote:
On 01/16/2013 10:07 PM, Eric Seidel wrote:
Do we know if there is a way to re-write our existing forks w/o
pulling the whole repo down, just to push it back up again
Do we know if there is a way to re-write our existing forks w/o
pulling the whole repo down, just to push it back up again? :)
On Wed, Jan 16, 2013 at 11:51 AM, Adam Barth aba...@webkit.org wrote:
If you were using GitHub to contribute to WebKit previously, you might
want to delete your fork of
I believe https://bugs.webkit.org/show_bug.cgi?id=91237 is the bug
you're looking for.
I've CC'd relevant chrome folks.
As Maciej notes, webkit-dev isn't really the place for bug reports. :)
It's a mailing list of over 2000 people. Most of whom don't care
about specific SVG bugs.
Regardless,
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing user-visible delays averaging 10 frames /
150ms).
be behind a feature flag and ports could opt-in to the
threaded-parsing path, as we must maintain the main-thread parsing
ability for innerHTML anyway.
--Oliver
On Jan 9, 2013, at 6:10 PM, Adam Barth aba...@webkit.org wrote:
On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote:
We're
in the future.
Thanks.
On Wed, Dec 19, 2012 at 10:12 PM, Kiran Muppala cmupp...@apple.com wrote:
Yup, the restart definitely fixed the issue. My patch progressed through
the queue and landed.
Thanks,
Kiran
On Dec 19, 2012, at 9:09 PM, Eric Seidel e...@webkit.org wrote:
I didn't see the feeder
are being processed. Eric Seidel and
Adam Barth, who usually manage the queue, I am told might be on vacation.
if theres anyone else who can take a look at the commit queue bots, please
do so.
Thanks,
Kiran
___
webkit-dev mailing list
webkit-dev
This time from @webkit.
On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel esei...@google.com wrote:
Ouch. I'll take a look.
On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.com wrote:
Hi folks,
All the bots on WebKit commit queue are in a loop of Starting Queue,
Stopping Queue
The Feeder queue is down (and thus likely sherrifbot and the style-queue
which are also hosted on the same EC2 instance). I'll see if I can restart
it.
Thanks for letting me know.
On Wed, Dec 19, 2012 at 8:53 PM, Eric Seidel e...@webkit.org wrote:
This time from @webkit.
On Wed, Dec 19
. Thanks for looking into it so quickly.
- Kiran
On Dec 19, 2012, at 8:55 PM, Eric Seidel e...@webkit.org wrote:
The Feeder queue is down (and thus likely sherrifbot and the style-queue
which are also hosted on the same EC2 instance). I'll see if I can restart
it.
Thanks for letting me
I recently added a --profile option to run-perf-tests to make it
easier to acquire cpu-profiles of PerformanceTests.
The option is available on Linux, Mac and Chromium Android.
You can see some minimal documentation here:
https://trac.webkit.org/wiki/Performance%20Tests#ProfilingPerformanceTests
This is now complete:
http://trac.webkit.org/changeset/137371
I'm watching the bots. Please contact me if you have any trouble.
Thank you all for your feedback.
On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger
/137375
On Tue, Dec 11, 2012 at 3:33 PM, Eric Seidel e...@webkit.org wrote:
This is now complete:
http://trac.webkit.org/changeset/137371
I'm watching the bots. Please contact me if you have any trouble.
Thank you all for your feedback.
On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke dpra
roll the WebKit deps in chromium and one of the MSVS bots starts failing.
Otherwise, I'm all for switching to ninja.
best
-jochen
On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote:
If you don't work on the Chromium port, feel free to ignore.
If you work on the Chromium port
If you don't work on the Chromium port, feel free to ignore.
If you work on the Chromium port of WebKit and do not use Ninja as you
build system (GYP_GENERATORS='ninja' or update-webkit --chromium
--ninja) I want to hear from you!
As far as I can tell, the vast majority of Chromium contributors
repository.
Ossy
Eric Seidel írta:
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote:
There's some problem
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote:
There's some problem with the commit-queue failing with some git
error.
On Tue, Dec 4, 2012 at 12:39 PM, Eric Seidel esei...@google.com wrote:
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote
This has come up in the past. I believe the current recommended path
is to use the github.com SHAs and just live in a github-only world.
https://lists.webkit.org/pipermail/webkit-dev/2012-March/020002.html
has some discussion.
https://trac.webkit.org/wiki/UsingGitHub
I am not aware of any plan
is the way to go now, then we will do the
transition...
Thanks,
Gergely
On Sat, Nov 24, 2012 at 10:48 PM, Eric Seidel e...@webkit.org wrote:
This has come up in the past. I believe the current recommended path
is to use the github.com SHAs and just live in a github-only world.
https
!DOCTYPE html
body style=margin: 0px
div style=height: 100px; width: 100px; background-color: green
Does seem pretty simple.
!DOCTYPE html
body style=margin: 0px
svgrect width=100px height=100px fill=greensvg
is even shorter. :)
I support getting rid of pixel tests. I suspect that some very
RenderArena was a perf optimization for the rendering tree, which
hyatt imported from Mozilla 10 years ago:
http://trac.webkit.org/changeset/2635
The prevailing lore has long been that RenderArena is no longer
useful, ugly, and should be killed!
My understanding was that *Inlines/*InlineMethods were more about
limiting includes in the main header. Maybe that's just a happy side
effect. :)
I also prefer the *Inlines naming. :)
On Fri, Nov 2, 2012 at 5:48 PM, Mark Lam mark@apple.com wrote:
FYI, some time in the near future (maybe
Is Snow Leopard deprecated?
Dave (WebKit's MathML guy) is reporting trouble building the Apple Mac
port on Snow Leopard. We don't seem to have a Snow Leopard bot on:
http://build.webkit.org/console?category=AppleMac
so it seems totally concievable that it's broken.
If it is deprecated, I'm
Thank you both for the clarification.
On Sun, Oct 21, 2012 at 2:21 PM, Dirk Pranke dpra...@chromium.org wrote:
On Sun, Oct 21, 2012 at 2:17 PM, Maciej Stachowiak m...@apple.com wrote:
Apple did not ship the last release of Safari to SnowLeopard and we have no
plans to maintain SnowLeopard
Bill and I have talked about this in the past. I don't remember what
the outcome was. Right now webkit-patch just uses Mechanize:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/net/bugzilla
We also might get some of this as part of the upgrade:
Does that mean our fallback graph is now finally a tree?? :)
https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit
On Wed, Oct 17, 2012 at 8:15 PM, Dirk Pranke dpra...@chromium.org wrote:
All of the Chromium ports will use baselines in their port-specific
Done.
On Fri, Oct 5, 2012 at 7:49 AM, Mihai Balan miba...@adobe.com wrote:
Hello,
Can anyone help me adding a new BugZilla keyword (as those over at
https://bugs.webkit.org/describekeywords.cgi )? We’d like it named
AdobeTracked. I need it for marking bugs that Adobe contributors are
I think that's an interesting idea. The bots don't have a mail
server. :) But we could presumably wire up some sort of service for
them.
On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote:
What if we mail the zip files to the person that uploaded the patch?
That way the
That stack is confusing.
It looks like it's in Mac._build_java_test_support:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/mac.py#L133
But that shouldn't be trying to execute run-webkit-tests?
Perhaps make is missing? or the java directory its trying to build is
This is Executive.run_command:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/system/executive.py#L378
I would suggest running test-webkitpy (which will go through and
delete any orphaned .pyc files which could be confusing things).
-eric
On Wed, Oct 3, 2012 at 9:19 AM, Eric
, at 9:19 AM, Eric Seidel e...@webkit.org wrote:
It looks like it's in Mac._build_java_test_support:
I don’t think I have Java installed on this computer. Maybe that’s somehow
related to the problem.
I would suggest running test-webkitpy (which will go through and delete
any orphaned .pyc
I would agree with Adam, and the more we can move to window.internals,
the less technical debt we incur with each new DRT feature.
I would love to see overridePreferences go away (or only be used for
preferences which need to test the WebKit-side plumbing).
TestExpectation files on all ports are
I was noticing today that http://www.webkit.org/ is quite old and out
of date. What xenon built 6 years ago, has stood up remarkably well,
but it may be time for a refresh.
(It also has no high-dpi support.)
I'm aware that I have the ability to change it. But I'm also inviting
others to do so:
I wish to subscribe to this product and or service. Count me in.
I'm not particularly worried about who has access. But maybe I should
be? Its not like the bad-guys can't run coverity themselves.
On Mon, Sep 17, 2012 at 6:11 PM, James Hawkins jhawk...@chromium.org wrote:
Hey folks,
TL;DR -
On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain benja...@webkit.org wrote:
On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins jhawk...@chromium.org
wrote:
A few details:
* Google will front the cost of the license (non-zero...very far from
zero) and the infrastructure.
* I'd leave it up to
The cr-linux bots used to upload the results to the bug itself. Maybe
that changed?
On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth aba...@webkit.org wrote:
Currently, there's no way to get results from the bots. You might
need to land your patch and see what the bots on build.webkit.org tell
The wiki might also note that:
String bar = ASCIILiteral(foo);
is not free. :) There is still a malloc() of a StringImpl under there.
On Mon, Aug 27, 2012 at 12:26 PM, Benjamin Poulain benja...@webkit.org wrote:
On Sun, Aug 26, 2012 at 10:15 AM, Ojan Vafai o...@chromium.org wrote:
So, is
Checking back in:
Curious if this effort is still underway. Adam and I would like to
delete the New XML Parser if it's not needed in order to simplify the
HTML 5 Parser again. :)
On Thu, Mar 15, 2012 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 15, 2012, at 1:29 PM, Eric Seidel
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
Enum members should user InterCaps with an initial capital letter.
[names-enum-members]
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams gl...@skynav.com wrote:
I'm implementing a patch for [1], namely to
Sorry, I was unclear. I haven't seen someone create a new enum using
E in years. LineBreakType or similar would be better than
ELineBreakType.
On Thu, Aug 23, 2012 at 11:57 PM, Eric Seidel e...@webkit.org wrote:
E is an old style from KHTML.
We should update our style guide to say more than
I'm attempting to fix some repaint bugs in WebKit, thus I'm using the
--pixel tests.
run-webkit-tests -p fast/repaint
shows a bunch of failures on my Mac Lion box.
I'd like to fix those failures, but I'm not sure what the proper procedure is.
run-webkit-tests -p fast/repaint --reset-results
Do we know what ports have CSS3_FLEXBOX enabled?
On Fri, Aug 17, 2012 at 6:47 PM, Ojan Vafai o...@chromium.org wrote:
Next week we plan to remove the CSS3_FLEXBOX define again. We had added it
back in because the spec was about to change a lot (mostly renaming). At
this point the spec is
Since it sounds like it doesn't do anything, then yes. Removing it
sounds like the correct course of action. Someone who later
implements ::marker or lands CSS3-list tests, can revert your patch.
On Wed, Aug 15, 2012 at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:
WebKit is the only
Bill would know.
On Tue, Aug 14, 2012 at 1:58 AM, Philippe Normand ph...@igalia.com wrote:
On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote:
I noticed today that some patches are authored by svns...@macosforge.org:
http://trac.webkit.org/search?q=svnsync
Is this behavior expected?
I
I think the notice was simply lost in all the bike-shedding of late. :)
Thank you Bill for taking care of the migration. I saw and
appreciated your email notice earlier.
-eric
On Thu, Jul 19, 2012 at 7:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
If it weren't too much trouble, it might be
to an IntRect than a LayoutRect.
- Ryosuke
On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote:
I would go with CSSRegion, and stick it in the css/ folder. Much of
the CSS folder is our implementation of the CSS Object Model (CSSOM).
At some point it might make sense to pull all the classes
the existing Region class now that the term region
has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion?
IntRegion? It seems closer to an IntRect than a LayoutRect.
- Ryosuke
On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote:
I would go with CSSRegion, and stick
Per:
You began by thread-jacking Dan's discussion of ChangeLogs, and now
appear to be attacking a seasoned contributors polite response with
sarcasm and derision.
I recommend you soften your words, and try again on another thread.
Commenting, or lack there of, has been discussed at great
You want the build-* scripts in this directory:
http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport
I also think you want the webkit-help mailing list instead of
webkit-dev. I believe it's supposed to cover these sorts of topics.
:)
Last I knew, Mark Rowe wrote those scripts and
If someone wanted to set up a --minimal bot, I'm sure that would be
welcome. We used to have a --qt --minimal bot at some point.
http://trac.webkit.org/wiki/BuildBot
On Mon, Jun 25, 2012 at 12:28 PM, Pablo Flouret pab...@motorola.com wrote:
On Mon, 25 Jun 2012 12:03:12 -0700, Arthur O'Dwyer
1 - 100 of 807 matches
Mail list logo
