You have improved my quality of life by several months.
On Thu, Jul 9, 2009 at 9:34 PM, Jeremy Orlowjor...@chromium.org wrote:
This makes me very, very, very happy. :-)
On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Dear WebKiteurs,
In our persisting quest
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- love
Learn more:
https://www.linkedin.com/e/isd/645478188/OoF5Gb3j/
--
(c) 2009, LinkedIn Corporation
___
webkit-dev mailing list
On Jul 8, 2009, at 6:58 PM, m...@apple.com wrote:
+print (-- Please remember to include a detailed description in
your ChangeLog entry. --\n-- See http://webkit.org/coding/contributing.html
for more info --\n);
Is this line supposed to end up in the ChangeLog? If so, it needs to
Hi Dimitri and all,
Congrats on getting this into WebKit! Actually, I'm in the middle of a
build system switch as well - to waf, a re-write of scons that removed
many of the performance issues related to searching and calculating
dependencies, and which has added some nice features as well
On Jul 10, 2009, at 11:59 AM, Simon Fraser wrote:
On Jul 10, 2009, at 8:46 AM, Adam Roben wrote:
On Jul 8, 2009, at 6:58 PM, m...@apple.com wrote:
+print (-- Please remember to include a detailed description
in your ChangeLog entry. --\n-- See
At one point, I started on a script (located in
WebKitTools/Scripts/update-sources-list.py) whose idea
was to take the list of common sources from one file,
and make changes to MSVC, Qt, GTK, etc. build systems,
so that WebKit devs need only add the file once, run
the script, and commit
On Fri, Jul 10, 2009 at 11:06 AM, David Kilzerddkil...@webkit.org wrote:
So, does anyone think this would be a bad idea, or have any
alternate suggestions on how to improve things?
What about adding support for waf to gyp?
+1. I think GYP took the right step back from project files to a
On Fri, Jul 10, 2009 at 2:20 PM, Dimitri Glazkovdglaz...@chromium.org wrote:
If you hand-edit Xcode project files enough times you start to understand
them, but you also may go insane in the process. I don't know that you have
to write a full parser for it, but there is some non-trivial,
To add to this, GYP also only generates files for _your_ platform on
checkout. Even to the degree that on Windows, it would generate VS2008
projects if you had it installed, and VS2005 otherwise. To be precise,
the selection is not automatic (you need an env variable) to avoid
dual-VS installs
Having used both Chromium's .gyp solution and WebKit's
.update-a-bunch-of-random-files solution, I'd like to add a huge +1 to
anyone interested in doing this for their own port. Especially since the
lack of trybots for webkit means that it's prohibitively difficult for
people to actually test
Ditto. The last time I wondered about this, I grepped through the
code and found [1] to be the most prevalent. So, in code reviews I
have been recommending people do [1].
I think that's the nicest style (just like a variable, no special
prefix). Let's go with that and update the coding
trying to understand this part of the webcore code, I faced a possibly
wrong impl:
(...)
VisiblePosition logicalStartOfLine(const VisiblePosition c)
{
VisiblePosition visPos = logicalStartPositionForLine(c);
if (visPos.isNull())
return
Hi,
honorEditableBoundaryAtOrAfter does check whether the visPos is null or not,
and if it's null, then it returns the original visible position, so it's
harmless (i.e. does not crash or has a side-effect). But I'm not sure what
the caller of logicalStartOfLine is expecting; maybe we're
Hi David,
On Jul 10, 2009, at 11:06 AM, David Kilzer wrote:
So, does anyone think this would be a bad idea, or have any
alternate suggestions on how to improve things?
What about adding support for waf to gyp?
If we're talking about Chromium, waf is much faster for building
WebKit than
On Fri, Jul 10, 2009 at 1:14 PM, Kevin Ollivier kev...@theolliviers.comwrote:
Hi David,
On Jul 10, 2009, at 11:06 AM, David Kilzer wrote:
So, does anyone think this would be a bad idea, or have any
alternate suggestions on how to improve things?
What about adding support for waf to
I think our number of different build systems is getting out of hand.
Since gyp is being successfully used to build across platforms, and
maintained by people who also work on some WebKit ports (and can thus
likely be adapted to our needs), I'd like to consider whether we can
use it for
We certainly would love to see that happen and gladly commit helping
to make this happen.
:DG
On Fri, Jul 10, 2009 at 3:15 PM, Maciej Stachowiakm...@apple.com wrote:
I think our number of different build systems is getting out of hand. Since
gyp is being successfully used to build across
On 2009-07-09, at 21:23, Dimitri Glazkov wrote:
Dear WebKiteurs,
In our persisting quest to be more like a common WebKit port, we have
added Chromium build files to the tree this afternoon. These files are
WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they
are the GYP
Hi everyone,
One common topic for discussion has been how to make our process
around patch submission better. As the project grows, it's becoming
more important for this process to work really smoothly, and we are
seeing some breakdowns. I've been doing a lot of thinking about this,
and
Geoff, Gavin, Sam, Maciej (and any other JSC experts):
Adam and I are fixing:
https://bugs.webkit.org/show_bug.cgi?id=27088
Fix: toJS needs to use the correct global object. The correct global
object should come from whatever this is calling into the native
code which is using toJS.
(e.g.
On Jul 10, 2009, at 3:55 PM, Maciej Stachowiak wrote:
Hi everyone,
One common topic for discussion has been how to make our process
around patch submission better. As the project grows, it's becoming
more important for this process to work really smoothly, and we are
seeing some
On 2009-07-10, at 16:17, Chris Marrin wrote:
On Jul 10, 2009, at 3:55 PM, Maciej Stachowiak wrote:
Hi everyone,
One common topic for discussion has been how to make our process
around patch submission better. As the project grows, it's becoming
more important for this process to work
On Jul 10, 2009, at 4:17 PM, Chris Marrin wrote:
The annoying part is the fact that I ALWAYS get conflicts in at
least one Changelog file when I try to check in. I have to fix these
by hand, do svn resolved, and try to check in again.
No you don’t. You can just use
On Jul 10, 2009, at 4:17 PM, Chris Marrin wrote:
On Jul 10, 2009, at 3:55 PM, Maciej Stachowiak wrote:
Hi everyone,
One common topic for discussion has been how to make our process
around patch submission better. As the project grows, it's becoming
more important for this process to
Hi Maciej
=== Action Plan ===
* Phase 1 *
snip
C) Improve the way we get attention from reviewers. I think we should do
three things here:
C.1) Split review queues, based on our emerging [Bracket] convention for
patches needing specialized review. If we find more areas of
On Jul 10, 2009, at 4:41 PM, Jan Michael Alonzo wrote:
Hi Maciej
=== Action Plan ===
* Phase 1 *
snip
C) Improve the way we get attention from reviewers. I think we
should do three things here:
C.1) Split review queues, based on our emerging [Bracket]
convention for patches needing
On Friday, July 10, 2009 3:55:59 PM, Maciej Stachowiak wrote:
A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to
being
there. I'm going to help him refine this tool to the point that submitting a
patch has only one step - a single command will make the patch, file
To add another tangent to this thread: one thing I don't like about
ChangeLog files is that they make it impossible to have multiple concurrent
changes in the same checkout. Yes I know that some people use git to get
around this, while others use the svn-apply/svn-unapply scripts. But I feel
Re-sent with correct address.
On Fri, Jul 10, 2009 at 5:55 PM, Adam Barthaba...@eecs.berkeley.edu wrote:
Eric and I spent some more time this afternoon looking at this. We
don't think the ExecState::thisValue() approach is going to work. We
implemented hacky version to experiment with, but
On Jul 10, 2009, at 5:55 PM, Adam Barth wrote:
Eric and I spent some more time this afternoon looking at this. We
don't think the ExecState::thisValue() approach is going to work. We
implemented hacky version to experiment with, but the problem is with
cases like this:
document.body
In
Sent again from the right address. Gmail hates me today.
On Fri, Jul 10, 2009 at 6:10 PM, Adam Barthaba...@eecs.berkeley.edu wrote:
On Fri, Jul 10, 2009 at 6:04 PM, Maciej Stachowiakm...@apple.com wrote:
On Jul 10, 2009, at 5:55 PM, Adam Barth wrote:
Eric and I spent some more time this
The workflow I'm looking for is something like svn/perforce changelists.
That way I could have multiple unrelated changes coexisting in the same
checkout.
An example of this is what we use on Chromium: gcl.py (see the latest
version at
Hi Jeremy,
On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote:
[snip]
Your argument makes sense if WebKit is only built for one platform/
build-system. Unfortunately it's not. So the question is whether
it's easier to maintain lots of different build files or whether
it's easier to
(Trimming Cc's since the relevant people are on webkit-dev anyway.)
On Jul 10, 2009, at 6:10 PM, Adam Barth wrote:
On Fri, Jul 10, 2009 at 6:04 PM, Maciej Stachowiakm...@apple.com
wrote:
Is it definitely right for document.body to make a wrapper using
prototypes
from the document's host
On Fri, Jul 10, 2009 at 6:26 PM, Kevin Ollivier kev...@theolliviers.comwrote:
Hi Jeremy,
On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote:
[snip]
Your argument makes sense if WebKit is only built for one
platform/build-system. Unfortunately it's not. So the question is whether
it's
The resolve-ChangeLogs script will fix it for you automatically.
Perhaps we should make update-webkit (or some new wrapper type tool)
run resolve-ChangeLogs automatically.
It's embarassing for me to admit, but I've been part of the WebKit
project for nearly a year and didn't know about
36 matches
Mail list logo
