On Tue, May 25, 2010 at 10:01 AM, Darin Adler da...@apple.com wrote:
On May 25, 2010, at 7:54 AM, Chris Jerdonek wrote:
I sometimes come across public member functions whose implementations do not
depend on private data.
There is a school of thought that such functions are better non-member
Hi, I have a question regarding WebKit's stance on free functions.
I sometimes come across public member functions whose implementations
do not depend on private data.
There is a school of thought that such functions are better non-member
because it reduces the number of functions coupled to
Hi, I have a basic question. What has been WebKit's stance on the use of the
explicit keyword (for higher-level objects in particular)? Do we prefer the
looser API's that conversion by constructor affords, or do we more often
discourage relying on conversion by constructor?
For comparison, the
On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote:
I think the best way for us to clarify our guideline for this would be to
discuss a few individual cases where we have a non-explicit constructor. We
can talk about why they are not explicit and see if we find they are just
Thanks, Ojan.
On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai o...@chromium.org wrote:
On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek cjerdo...@webkit.org
wrote:
In particular, --git-commit=HEAD.. should be just the
uncommitted changes (staged and unstaged).
This one I'm a bit iffy on. Should
Thanks for your responses, Ojan.
On Fri, May 14, 2010 at 6:29 PM, Ojan Vafai o...@chromium.org wrote:
Maybe it already does this, but would it be possible to make the default
behavior be to throw an error if there is more than one possibility for
what should be committed?
That's what it
On Thu, May 13, 2010 at 11:13 AM, Ojan Vafai o...@chromium.org wrote:
I finally updated this
page http://trac.webkit.org/wiki/UsingGitWithWebKit#webkit-patchcheck-webkit-styleandgit.
As is clear from that, my earlier description of --no-squash was totally
inaccurate. Sorry, I was being rushed.
[Re-sending from correct address]
On Fri, May 7, 2010 at 9:10 PM, Eric Seidel e...@webkit.org wrote:
I'm happy to add a brief note to the tools.html page noting that
python 2.5 is required and linking to a page.
A couple months ago I started a page that contains instructions on how
to upgrade:
Hi folks,
This e-mail is to let you know about a regression in svn-apply that
was discovered and fixed tonight and that may have affected you.
The regression is most likely to have affected you if, in the last 5
days (after r58495), you committed a patch that was an e-mail diff
using svn-apply's
On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote:
That reminds me, we should turn off the 80-column limit on bugs.webkit.org -
there's no need for it to hard-wrap your text.
Great, I was wondering about that. I filed a report for that here:
I wanted to add a couple comments and a question to this discussion.
On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote:
I haven't contributed to WebKit's Python code yet, but I will say that I
agree with Eric's sentiments here. 80-column limit is archaic and pointless.
Regarding the URL parsing code, could someone that attended the
session list what steps were proposed or tentatively agreed to (of
which the below is the first)?
Thanks a lot,
--Chris
On Tue, Apr 13, 2010 at 1:46 AM, Adam Barth aba...@webkit.org wrote:
Have you ever wanted WebKit's URL
No, you shouldn't flip the flag back to r? to continue discussing.
Generally speaking, people on the CC list do receive an e-mail when
you post an additional comment. After submitting a comment to
bugs.webkit.org, you can see for sure who will be receiving an e-mail
with the comment since the web
I started an unofficial sign-up list for the April 12-13 WebKit meeting here:
https://trac.webkit.org/wiki/April%202010%20Meeting
The page might be useful for other things as the meeting nears.
On Tue, Mar 9, 2010 at 2:27 PM, William Siegrist wsiegr...@apple.com wrote:
On Mar 9, 2010, at
Hi folks, I just wanted to let you know that the WebKit project's
Python code should be a lot easier to navigate and work in now.
Tonight, Adam Barth and I (along with Eric Seidel's blessing) moved
almost all of the modules in WebKitTools/Scripts/webkitpy into
appropriate subfolders of webkitpy
On Mon, Mar 22, 2010 at 10:46 PM, Maciej Stachowiak m...@apple.com wrote:
The most unavoidable exceptions seem to be for test cases that are
specifically testing what happens when you have a space in the filename, not
for third-party code. Does the no-spaces rule make it easier to write shell
wrote:
So it would appear then that www.webkit.org and nightly.webkit.org are
the odd men out. :)
On Mon, Mar 22, 2010 at 10:57 PM, Sam Weinig sam.wei...@gmail.com
wrote:
And our own http://planet.webkit.org/.
-Sam
On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.org
On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org wrote:
Interesting. Looks like the WebKit icon on CIA is different from
webkit.org. I could have sworn they used to be the same:
http://cia.vc/stats/project/webkit
That's also the icon used for the WebKit group on LinkedIn:
I was wondering if there are any reasons we would ever need files in
our repository whose file names contain spaces. The reason is that it
makes shell commands slightly trickier to write (e.g. using the bash
shell).
I found that we currently have these files whose file names have spaces:
find
On Mon, Mar 22, 2010 at 10:29 PM, Adele Peterson ad...@apple.com wrote:
On Mar 22, 2010, at 10:24 PM, Chris Jerdonek wrote:
I was wondering if there are any reasons we would ever need files in
our repository whose file names contain spaces. The reason is that it
makes shell commands
.
--Chris
On Sun, Mar 7, 2010 at 4:18 PM, Chris Jerdonek cjerdo...@webkit.org wrote:
On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org wrote:
On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
Since I have a Tiger machine handy, I tested this and was able to build
,
don't work in Python 2.4. My complaint in Bug 36063 is that we're
re-implementing Mechanize poorly. I'd rather we just upgraded the
machines that need to run-webkit-tests to a more modern version of
Python.
Adam
On Fri, Mar 19, 2010 at 7:41 AM, Chris Jerdonek cjerdo...@webkit.org wrote
On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org wrote:
On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
Since I have a Tiger machine handy, I tested this and was able to build
python
2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did not
[Resending from correct address.]
On Thu, Mar 4, 2010 at 1:05 PM, Maciej Stachowiak m...@apple.com wrote:
4) If we have a smooth way to do it, then locally installing a newer Python
as part of the WebKit development process might be acceptable as a part of
the WebKit. After all, everyone
Recently, there has been some off-list discussion about the minimum
Python version WebKit should support (i.e. for the Python scripts in
WebKitTools/Scripts).
Up to this point, we haven't been explicit about it. This ambiguity
has occasionally caused things to break for people using versions
On Fri, Feb 26, 2010 at 1:36 AM, Adam Barth aba...@webkit.org wrote:
2) Require pre-commit vetting of patches. We have the resources to
Here's how I would design the life and times of a patch:
1) Contributor uploads patch and nominates it for review.
2) Patch vetted by the EWS on numerous
On Tue, Feb 23, 2010 at 4:27 AM, arno a...@renevier.net wrote:
Hi,
I've recently submitted a few patches.
My workflow is as follow:
I use git repository.
Once I've made my modifications, I run WebKitTools/Scripts/prepare-ChangeLog,
then I git-commit changeset in a private branch, then I
FYI, check-webkit-style now supports the following via configuration variables:
(1) Suppressing certain style checks (based on category name) for
particular files/folders
(2) Enabling custom style checks (again based on category name) for
particular files/folders
(3) Skipping the style check
Hi Thangdd,
I have built libxt and xlib, gtk-directfb, gtk-x11 at all.
I search these errors in google, but there is any right answer.
Thanks for your helps.
Questions like these should be directed to webkit-help rather than webkit-dev.
The following page contains descriptions of the various
Hi Ismail, thanks for investigating this issue and for finding a possible fix.
I can't comment on the specifics, but usually the best way to deal
with issues like this is to file a bug report:
http://webkit.org/quality/reporting.html
The bugs database has a comment feature to allow for
On Fri, Jan 22, 2010 at 7:16 AM, Christopher White skullkn...@gmail.com wrote:
Is it possible to save the DOM resulting from the parsing of HTML / CSS into
a file and then read it back instead of re-parsing the HTML (similar to Java
object serialization). Does it save any time or is it a wash?
Quick question: if we would like to check in third-party code and it
is not obviously BSD-style (at least to me), what is the process for
checking whether the license is okay and clearing the license?
The WebKit Committer Guidelines say, This means that you should
verify that each source file
On Wed, Feb 3, 2010 at 10:46 PM, Conrad Taylor conra...@gmail.com wrote:
Chris, have you checked the licensing and/or spoke with the license
owners of the 3rd party source? If not, I would recommend starting
there.
[Sorry for the duplicate e-mails, Conrad.]
Yes, I have the license text. It
On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer ddkil...@webkit.org wrote:
(2) Consider phasing in support for an alternate workflow where new
ChangeLog entries for the next commit are stored separately from the
versioned ChangeLog files -- perhaps in individual .changelog files
for Subversion
On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer ddkil...@webkit.org wrote:
I think I mentioned this before, but for git users, this can be solved in the
short term by a merge driver that uses resolve-ChangeLogs (once it knows how
to be invoked by git as a merge driver):
This seems like a good
I was reading through the old I HATE CHANGELOGS messages from August:
https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html
The discussion attracted a lot of interest and ideas, but it looks
like it died out without reaching any conclusion.
It seems like the tools around
I noticed that the WebKit Team wiki page changed significantly this past week:
http://trac.webkit.org/wiki/WebKit%20Team
I was curious about the reasons behind the change, and whether people
like the change.
--Chris
___
webkit-dev mailing list
On Sun, Jan 24, 2010 at 2:02 PM, Adam Barth aba...@webkit.org wrote:
In the conversion process, I removed the areas of knowledge
information because it was often out of date or provincial. svn
blame, IRC, or social awareness is a more accurate way of figuring or
who to ask about a particular
Date: Thu, 14 Jan 2010 22:32:11 -0800
From: Alex Milowski a...@milowski.org
Subject: [webkit-dev] MathML Project Contact etc.
I'm presenting my MathML in WebKit work tomorrow at the Joint AMS/MAA
meeting here in San Francisco. After looking through my slides I feel
that I'm unsatisfied
On Thu, Jan 14, 2010 at 9:05 PM, David Kilzer ddkil...@webkit.org wrote:
On Thu, January 14, 2010 at 6:59:17 PM, Chris Jerdonek wrote:
While I'm asking, I might as well also ask -- what other subversion
properties do we use?
In the past, svn:eol-style has been applied so that when files
On Fri, Jan 15, 2010 at 2:01 PM, David Kilzer ddkil...@webkit.org wrote:
On Fri, January 15, 2010 1:52:19 PM, Chris Jerdonek wrote:
Thanks a lot for the response, David. To add to the list,
svn:executable is another one.
Yes, scripts don't work very well without execute permissions
Date: Wed, 13 Jan 2010 15:49:05 -0800
From: David Levin le...@google.com
3) Stop checking code in gtk/qt platform directories for underscores?
I think there are several other checks that code in some of these
directories typically fail due to various issues (public api that should
follow
I have some background questions about the allow-tabs property. I
imagine it pre-dates check-webkit-style by quite a while.
(1) What's the reason and history behind our use of the property?
(2) What component actually does the pre-commit check? I didn't find
a reference to allow-tabs in
Date: Thu, 7 Jan 2010 16:21:49 -0800
From: Eric Seidel e...@webkit.org
http://build.webkit.org/console
Will let you know.
If possible, it might be good to add this link to the
http://build.webkit.org/ home page. Is it linked elsewhere? It
doesn't look like the home page is stored in
On Wed, Dec 30, 2009 at 2:33 PM, Sam Weinig sam.wei...@gmail.com wrote:
I would prefer we stick with the run prefix.
I am also not sure why we would have separate testing scripts based by
language.
Thanks, Sam.
The language-specific scripts are more an artifact of the fact that
the Perl test
On Tue, Dec 29, 2009 at 11:07 AM, Adam Barth aba...@webkit.org wrote:
I'd prefer to have as few test commands as possible. Ideally, I
should just be able to run the grand unified test suite and know that
my patch is ok to commit. There's some advantages to breaking out the
JSC tests from the
Last night on IRC there was a brief discussion of the test scripts:
how they should be divided in the future and what they should be
called. These scripts are in WebKitTools/Scripts.
I believe we currently have at least (correct me if I'm wrong)--
run-webkit-tests
run-javascriptcore-tests
Date: Mon, 21 Dec 2009 01:25:31 -0600
From: Eric Seidel e...@webkit.org
Can we get consensus on if the WebKit style applies to all sections of
code? And if it does not, what style applies to the code it does not?
It does not apply to all sections since the web site has this to say at least--
I have a few questions related to patch length:
(1) Do reviewers take patch length into account when considering
whether to review a patch? This is useful to know for those who would
rather have a short patch reviewed more quickly than wait longer for a
longer patch to be reviewed.
(2) If
I have a few questions about the WebKit bug life cycle I was hoping
someone could answer. I'm going to be updating the bug life cycle
page soon:
http://webkit.org/quality/lifecycle.html
So any information you provide is something I can incorporate.
Here are the questions:
(1) Generally
At first glance these meta-guidelines seem fine. If they are going
to be written down somewhere, a couple minor comments:
On Dec 9, 2009, Maciej Stachowiak wrote:
I think something like
the following should be our meta-guidelines for when to change the
style guide:
It would be good to
On Mon, Dec 7, 2009 at 9:30 AM, Darin Adler da...@apple.com wrote:
Sorry, I wasn’t able to follow all the logic in the style guideline and the
email message nor fully understand what the script enforces. So I’ll give my
view on this and hope it helps.
Thanks. To be clear, I will restate
On Thu, Dec 3, 2009 at 10:17 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 3, 2009 at 6:24 PM, Chris Jerdonek chris.jerdo...@gmail.com
wrote:
For the people thinking about this, it would be nice if the final
policy minimizes (and does not increase) the likelihood of having
Date: Wed, 2 Dec 2009 21:00:59 -0800
From: Peter Kasting pkast...@google.com
This is a followup to my thread yesterday regarding consistent enforcement
of the style guide. Like Yong Li, I find the current rule about braces on
conditional arms to be suboptimal.
For the people thinking about
On Tue, Dec 1, Jeremy Orlow wrote:
Adam's right though: unlike most of the other style changes, if we don't fix
this one all at once, only new files will ever match the style guide. This
is different than most of the other guidelines where things eventually
converge as people touch lines of
On Sat, Nov 28, 2009, Adam Barth wrote:
One of the bots that Eric and I have been working on is about to come
online. This bot is a style bot that runs check-webkit-style on
patches that have been nominated for review.
This seems like a good effort, thanks. A couple minor comments below
on
On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth aba...@webkit.org wrote:
On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
chris.jerdo...@gmail.com wrote:
On Sat, Nov 28, 2009, Adam Barth wrote:
Hopefully, the script will improve over time, but it will
never be perfect.
Can you elaborate
On Tue, Nov 17, 2009 at 10:39 PM, Darin Adler da...@apple.com wrote:
On Nov 16, 2009, at 7:54 PM, Chris Jerdonek wrote:
So, I was wondering if we can clarify the rule to apply only to the
outermost namespace declaration.
Yes, I think we can.
(Consecutive declarations like namespace JSC
I am contemplating a script to normalize the namespace indenting
across our code to match our guidelines, so I wanted to clarify two
things. First, it seems like the original motive was to avoid
pointlessly indenting nearly the whole file:
On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler da...@apple.com wrote:
No using namespace statements are permitted in header files. The guidelines
are talking about non-header files. We should clarify that.
Thanks for your later reply explaining the history behind the using
WTF::... statements.
On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler da...@apple.com wrote:
No using namespace statements are permitted in header files. The guidelines
are talking about non-header files. We should clarify that.
Thanks for the clarification. I will go ahead and try adding that.
This is a good segue
I have a question regarding JSC's WTFNoncopyable::Noncopyable class
and argument-dependent lookup (ADL). It seems like an old decision
may have been unintentionally undone in changeset 46933 (first
attempted in 46877).
The Noncopyable class (currently JavaScriptCore/wtf/Noncopyable.h) was
Hi, I have a question about the last of the WebKit Coding Style Guidelines:
http://webkit.org/coding/coding-style.html
It's the second of these two:
1. Any using namespace statements for a nested namespace whose
parent namespace is also defined in a file must be declared within
that namespace
63 matches
Mail list logo
