On Tue, Mar 26, 2013 at 5:51 PM, Benjamin Poulain benja...@webkit.orgwrote:
Hackabilty is a project goal. Compile time is not.
Well, in fairness, I think anyone contributing seriously to a codebase will
get more hacking done if they're spending significantly less time
recompiling :).
I happen
On Wed, Mar 20, 2013 at 11:46 PM, Robert Hogan li...@roberthogan.netwrote:
On Wednesday, 20 March 2013, Ryosuke Niwa wrote:
Please don't add lines to TestExpectations saying that they just need
rebaselines and then leave.
OK. That means I will have to pull the new results from the bots,
On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
Is it expected that overtype works on Windows or on Linux? e.g. If Edit
and RichEdit window classes both support this feature natively on Windows
(which I bet they do), then the answer is yes.
The non-rich edit control on
On Mon, Mar 11, 2013 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting pkast...@google.comwrote:
On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
Is it expected that overtype works on Windows or on Linux? e.g. If
Edit
On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
Of course, each application can implement overtype in Edit window class
and manually disable it in RichEdit window class but I don't think that's
an interesting fact since that's a customization. An application doesn't
On Mon, Mar 11, 2013 at 5:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
Having said that, I object to implementing a behavior doesn't match
RichEdit or Edit window classes on Windows. We should match either
native edit window class.
Are you referring to my comments about the cursor? Do you
On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa rn...@webkit.org wrote:
Yes, we should disable triple-click-to-select-all on Windows
You realize that Wordpad, Word, and Internet Explorer all support this,
though, right? My point was not just to raise a behavior that seems like a
clear win, it
On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig shezbaig...@gmail.com wrote:
I feel like I should give some background to this discussion.
Thanks for this context. It's helpful.
So I guess the question boils down to something like: if we have
changes that are generally useful, but not used in
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
There are certainly pros and cons to merging. It would be great get input
from the broader WebKit community on the tradeoff of merging sooner vs
avoidance of weird legacy code in the main tree. In the meantime, we'll
On Thu, Jan 3, 2013 at 11:36 AM, Shawn Singh shawnsi...@chromium.orgwrote:
Cons of making a separate vector class:
- offsets are sometimes treated as relative point locations, and other
times treated as vectors that can be added to points. Deciding when to use
which one could become just
On Wed, Jan 2, 2013 at 11:21 PM, Steve Block stevebl...@chromium.orgwrote:
- Would people welcome changes to encourage that policy?
FWIW, in Chromium (downstream, non-WebKit) we ended up adding a vector
(as in math, not the STL) class recently to address the sort of
offset/delta between two
On Tue, Dec 11, 2012 at 1:11 PM, Emil A Eklund e...@chromium.org wrote:
That said, if your strong reason turned out to be incorrect, you should
recommit the patch, no?
That seems like a bad idea, someone that understands the patch should
recommit it. Ideally the original author.
I don't
On Tue, Dec 11, 2012 at 1:19 PM, Emil A Eklund e...@chromium.org wrote:
I don't understand your logic. A patch landed, the sheriff thinks maybe
it
was bad and rolls it out, then it turns out it was a red herring. Why
is it
not now the sheriff's responsibility to re-land? After all, the
On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why anyone is _speculatively_ rolling out patches.
You should only be rolling it out if you _know_ the patch is bad.
Sometimes something bad happens to the tree, the sheriff doesn't know which
patch is
On Tue, Dec 11, 2012 at 2:20 PM, Oliver Hunt oli...@apple.com wrote:
Or the sheriff could actually see if rolling out a patch locally fixes the
problem. I'm not sure why they're considering not testing to be a valid
behaviour for someone who is ostensibly meant to be keeping things going in
It seems worth noting over here that on the whatwg discussion for this,
native really means Mac and Ubuntu. Notably it's not clear whether
this matches Windows, which is 90+% of the userbase for Chrome. I am a
little nervous making blanket statements like this is native behavior
when we're not
On Wed, Oct 31, 2012 at 1:32 PM, Ojan Vafai o...@chromium.org wrote:
Every native platform that has scrollbars does *not* move focus when you
click on them. Every browser engine, except Gecko, moves focus when you
click on scrollbars *unless* you're clicking on the viewport scrollbar
(e.g.
On Wed, Oct 31, 2012 at 2:40 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Oct 31, 2012 at 2:29 PM, Peter Kasting pkast...@chromium.orgwrote:
Is there rationale for Gecko's behavior? It sounds a bit strange.
Not that I know of. I haven't talked to anyone at Gecko about it though.
Might
On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 28, 2012, at 10:09 PM, Peter Kasting pkast...@chromium.org wrote:
On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote:
I am not sure a blanket rule is correct. If the Foo* is logically
On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote:
I am not sure a blanket rule is correct. If the Foo* is logically related
to the object with the foo() method and effectively would give access to
mutable internal state, then what you say is definitely correct. But if
On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier caban...@gmail.com wrote:
It is valid for a const method to return you a new object ie a const
factory object.
In that case, const-ness would not be desired.
Not really. The point of this thread is that such functions may not modify
an object's
On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo fpi...@apple.com wrote:
I believe that the cognitive load is greater than any benefit from
catching bugs incidentally by continuing to run a (1-fail) or (3) test, and
continuing to evaluate whether or not the expectation matches some notions
of
On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo fpi...@apple.com wrote:
The typical approach used in situations that you describe is to rebase,
not skip.
Which is precisely what Dirk is proposing. Literally the only difference
here is that the rebased test expectation would contain an optional
On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo fpi...@apple.com wrote:
2) Possibility of the sheriff getting it wrong.
(2) concerns me most. We're talking about using filenames to serve as a
kind of unchecked comment. We already know that comments are usually bad
because there is no
On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote:
Why not start asynchronous decoding immediately as the image is loading,
and synchronize at paint time? What is the benefit of waiting until layout
time to start decoding the image data?
Uninformed guess (since I
It looks like the timeline has once again stopped updating.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
The Trac timeline doesn't seem to have updated since last night. It's
missing about 15 commits right now. Trying to link to one of these -- e.g.
http://trac.webkit.org/changeset/123971 -- doesn't work.
Not sure to whom to direct this problem.
PK
___
On Thu, Jul 12, 2012 at 3:17 PM, Ojan Vafai o...@chromium.org wrote:
https://trac.webkit.org/wiki/Rebaseline
I've recently consolidated the various rebaseline commands and made the
tool work for non-Chromium ports.
I especially like webkit-patch rebaseline
path/to/test/i/just/broke.html,
On Thu, Jul 12, 2012 at 4:16 PM, Dirk Pranke dpra...@chromium.org wrote:
At the top of the garden-o-matic page there is a line like Latest
revision processed by every bot: 122499 (trunk is at 122524). I think
that does what you want?
Ah, I hadn't noticed that. That sounds promising!
PK
On Thu, Jun 14, 2012 at 1:39 PM, Elliot Poger epo...@chromium.org wrote:
Can someone please remind me why IMAGE+TEXT even exists?
Wouldn't it be simpler to just mark a test as follows?
- IMAGE : allow image failure; go red if there is a text failure
- TEXT: allow text failure; go red
On Wed, Jun 13, 2012 at 3:58 PM, Darin Adler da...@apple.com wrote:
On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote:
* we use \ (backslash) as a delimiter instead of : and =
Seems worse to me. When I see a backslash I assume it’s a line
continuation character or a C
On Wed, Jun 6, 2012 at 11:28 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't think DIFF is any better. It sounds like it means the output is
different than what we wanted, thus it effectively means didn't pass,
and one would expect it to match MISSING/CRASH/TIMEOUT as much as one would
On Thu, Jun 7, 2012 at 12:33 PM, Ryosuke Niwa rn...@webkit.org wrote:
Not if the test was padding. I'm talking about the case where you're
modifying WebCore and know that some tests are going to need rebaselines.
People have advised in the past that patch authors add failing test
expectations
On Wed, Jun 6, 2012 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
Now that everyone knows the problem, I propose to rename FAIL to DIFF.
FAIL should mean that the test fails, not that it fails with image, text,
or image and text failures.
DIFF, on the other hand, has no ambiguity. It
On Thu, May 17, 2012 at 9:26 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
I actually quite like
the clear delineation between test modifiers and test expectations.
Me too. Please please please leave them on opposite sides. All these
proposals that try to put them both before the test
On Thu, May 17, 2012 at 12:02 PM, Ryosuke Niwa rn...@webkit.org wrote:
It appears to me using fully qualified names (e.g. std::max(~) at call
site) is far superior to using directive for individual symbols (e.g. using
std::max).
It sounds in general like a number of people have been in favor
On Thu, May 17, 2012 at 12:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 11:54 AM, Maciej Stachowiak m...@apple.com wrote:
Perhaps aligning the fields column after the bug URL would improve
readability (though it makes things a little harder to edit):
We certainly
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai o...@chromium.org wrote:
2. Make outcomes optional. If they are left out, then the test is skipped
(unless the test is marked SLOW, in which case it's expected to pass).
There is no SKIP modifier.
I don't think we should do this. It seems very
On Thu, May 17, 2012 at 2:11 PM, Ojan Vafai o...@chromium.org wrote:
Oh, I supposed I misread Peter's earlier email as being opposed to this.
You didn't misread me. I have the same opinion as you: this would be a
change for the worse.
PK
___
On Tue, May 15, 2012 at 9:31 AM, Darin Adler da...@apple.com wrote:
On May 15, 2012, at 5:48 AM, Allan Sandfeld Jensen wrote:
To me it seems like an odd practice, so I would like to ask what
original rationale behind that style guideline is
Adding a list of using declarations like using
On Tue, May 15, 2012 at 11:37 AM, Ryosuke Niwa rn...@webkit.org wrote:
On May 15, 2012 10:53 AM, Peter Kasting pkast...@chromium.org wrote:
Given how little of std:: we actually use (since WTF is used instead for
most things), what about just explicitly qualifying usages with std::
directly
On Fri, Feb 24, 2012 at 11:13 AM, Ashod Nakashian
ashodnakash...@yahoo.comwrote:
In short, the issue is that some bash scripts have their svn:eol-style set
to native, which is CRLF on Windows. This is causing build failures on some
version of cygwin-bash that don't like CR in the scripts.
I
On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote:
We're creating a branch in order to demonstrate that it's useful and
that it does not negatively impact hackability or performance.
It hadn't occurred to me to view the goals of the WebKit project as
applying only to
On Mon, Nov 28, 2011 at 1:38 PM, David Kilzer ddkil...@webkit.org wrote:
In a discussion on Bug 71921https://bugs.webkit.org/show_bug.cgi?id=71921,
Antti, Darin Adler and I started a discussion about using C++ constant
pointers in WebKit. Does the WebKit community have a consensus opinion on
On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar ararunpra...@gmail.com
wrote:
Why don't we follow chrome style of file inclusions rather than the usual.
For example,
*#include WebCore/Page/Chrome.h*
This will be more convient way of representing the inclusion. Hope it will
avoid long
On Fri, Nov 18, 2011 at 2:38 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Nov 18, 2011 at 2:27 PM, Adam Barth aba...@webkit.org wrote:
We move files around all the time. If we're afraid to move files for
these reasons, we'll be stuck with bad organizational choices we made
in the
On Thu, Nov 3, 2011 at 7:32 PM, Ryan Leavengood leaveng...@gmail.comwrote:
The primary problem with our port right now is some of the developers
made the choice (which I objected to) to make our own Subversion repo
containing the WebKit code to make it easier (in their eyes) to
develop the
On Wed, Oct 12, 2011 at 3:58 PM, Alexey Proskuryakov a...@webkit.org wrote:
Quoting what I actually said in the bug, I don't think that we should
accept an implementation of a spec that's so immature that it doesn't even
have a meaningful name.
That the name is not meaningful, and that this
On Thu, Oct 6, 2011 at 11:50 AM, Alexey Proskuryakov a...@webkit.org wrote:
I don't want to take a particularly strong stance against Joystick/Gamepad
specifically, but I see codifying input device fragmentation in Web specs
and APIs as a move in a wrong direction.
Why are you convinced
On Thu, Oct 6, 2011 at 1:42 PM, Alexey Proskuryakov a...@webkit.org wrote:
06.10.2011, в 13:23, Peter Kasting написал(а):
Why are you convinced there is input device fragmentation here? My
understanding is that the spec as proposed already handles multi-axis
digital and analog controls so
On Tue, Oct 4, 2011 at 2:22 AM, Joe LaFritte joelafri...@yahoo.fr wrote:
What is the fastest image format for wekbit ? I mean which image format
(jpg, png, gif, etc.) is decoded and displayed fastest than the other ones
?
That likely depends on the image, the decoder, and the system in
On Tue, Oct 4, 2011 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
In my understanding, we use pass by reference for out arguments when they
have to be modified in callees.
I had not heard this.
Personally I weakly prefer pointers to non-const refs for outparams, but if
there is convention
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.org wrote:
Anyway, I'm not sure if we already agreed that mouse lock is only desirable
in full screen. I think that the spec has the goal of enabling it in browser
windows.
Indeed, this is explicitly a use case we want to
On Mon, Sep 12, 2011 at 1:56 PM, David Levin le...@chromium.org wrote:
On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting pkast...@chromium.orgwrote:
In particular, if we have pixel tests that don't need to be pixel tests at
all, or font rendering differences due to explanatory text that could
On Fri, Sep 9, 2011 at 7:21 PM, Simon Fraser simon.fra...@apple.com wrote:
I think we should be consistent about color profiles, and in a way that
doesn't break pixel tests. Does anyone want to vote one way or the other?
I suspect no profiles is the only way that will work across both ports
The way I make this work is to set up a full Chromium checkout with a trunk
(rather than DEPS-controlled) WebKit checkout. (There are some instructions
for this in the Chromium developer pages.) Then I can use VS2008 to build
and test whatever I want. And I use Cygwin.
I don't know much about
On Thu, Aug 25, 2011 at 10:07 AM, Mikhail Naganov mnaga...@chromium.orgwrote:
I'm not sure we are on the same page. I'm talking about Chromium port
of WebKit, where Chromium checkout is _inside_ WebKit's
Source/WebKit/chromium, as opposed to when you have full WebKit
checkout inside
On Thu, Aug 25, 2011 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
FWIW, I use the former exclusively on Mac.
Yes, please regard my comments as only applying to Windows.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub le...@chromium.org wrote:
To address this we plan to convert the rendering tree to float to allow for
better zooming and scaling support. Furthermore this could be expanded to
support sub-pixel layout and positioning which in turn would allow
On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org wrote:
2) Mark the patch as obsolete / clear the review flag if we're not
going to land the patch.
Does the slash mean do both? I have
https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the only r+ed
patch on it is
On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak m...@apple.com wrote:
I'm not really convinced that casting away const from a return value is
intrinsically safer than casting away const from this.
Allowing the caller to mutate the return value is fine because the caller
had a non-const
On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak m...@apple.com wrote:
In principle, the return value could have been retrieved from a container
that the immediate callee only has a const reference to. So then casting
away const on the return value would be a hazard.
You're right; if the
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them non-const; consensus on also adding const accessors
is less clear.
There are a surprising number of places that actually do
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler da...@apple.com wrote:
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com
wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them non
On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler da...@apple.com wrote:
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
I'm perfectly happy removing const from accessors in the first
category. I can post a change that does that before going any further.
Yes, I believe that’s what both Maciej
On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler da...@apple.com wrote:
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
From the perspective of Node itself, I'm not sure why this would be a
big task. There shouldn't be any const accessors that return non-const
pointers. Simply removing
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler da...@apple.com wrote:
From a const Node* you can get:
- a non-const pointer to a parent, sibling, or child
- a non-const pointer to the document
- a non-const pointer to the renderer
- a non-const pointer to the style
- a
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen gga...@apple.com wrote:
Perhaps we could at least encourage const-correctness for newly-written
classes? By this I mean both adherence to the logical-constness rules you
stated earlier as well as not adding non-const accessors and members unless
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak m...@apple.com wrote:
The following would be valid but would require us to cast away const all
over the place and would therefore in my opinion be a net negative:
const Node* previousSibling() const { return m_previous; }
And what's in
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote:
A linked list node or tree node could useful have const methods, which give
only const pointers/references to other nodes. If there is a reason const
references to DOM nodes or renew objects are not useful, it is not due
On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak m...@apple.com wrote:
I agree that const should be used for logical constness. The rule should
not be merely doesn't alter any data members of this object but rather
does not alter observable state of this object or vend any type of pointer
On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard ch...@jumis.com wrote:
I think Brent's question to the list may have some merit if looked at from
a different perspective.
Let me try it... Peter: Are there any lessons learned about that process
Chromium went through?
Darin Fisher shared
On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.org wrote:
Google
used this same approach with their Chromium port, the side effects of
which find us in year two (or three?) of the effort to merge those
changes back into the core WebKit archive.
Um, what? The Chromium port
Hi Brent,
In a past thread, I noted that we could do a couple of things to reduce
platform-specific results, and the overall size of layout test results. In
order of increasing difficulty:
* Convert pixel tests to dumpAsText tests when pixel output is unnecessary
(merely requires adding a
On Wed, Apr 20, 2011 at 10:46 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting pkast...@google.comwrote:
* Convert tests to reftests
I don't think we should do this until all ports start using
new-run-webkit-tests on their bots.
It's the most
On Fri, Mar 25, 2011 at 1:08 PM, Peter Kasting pkast...@google.com wrote:
On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe mr...@apple.com wrote:
Safari 5.0.3 will always report a build version of 533.19.4. Safari 5.0.4
will always report a build version of 533.20.27. You already used the former
Hello WebKit developers,
I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about
the recent changes I and others have made to the UA string. I'm interested
in any feedback you might have.
I've written a similar blog post, but focused on Chrome and aimed at a wider
audience,
On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting pkast...@google.com wrote:
I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about
the recent changes I and others have made to the UA string. I'm interested
in any feedback you might have.
Note, since this is a draft, you
On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer par...@paroga.comwrote:
If you take a look at
http://trac.webkit.org/browser/trunk/Source/WebKit/wince/WebCoreSupport/FrameLoaderClientWinCE.cpp#L57I’m
not sure if point 5 is correct. ;-)
The WinCE port has still my initial UA string
I've incorporated all the existing feedback into the draft. Feel free to
take another look.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Mar 25, 2011 at 11:54 AM, David Levin le...@google.com wrote:
The blog post begs the question made me wonder.
Why was Macintosh; kept when it is redundant with Intel Mac OS X
10_6_7?
The reasoning seem analogous to what was given for why Windows; was
removed.
Unlike Windows, the
On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.com wrote:
I've incorporated all the existing feedback into the draft. Feel free to
take another look.
Since some folks seem to be unable to see the draft even while logged in,
here's the new fulltext.
PK
---
User Agent
On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote:
Is there some reason why these examples use manufactured Safari build
numbers? It's implausible that a version of Safari with a build number of
534.24 would ever claim to be version 5.0.3.
Sorry, I wasn't sure what the right
On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe mr...@apple.com wrote:
On 2011-03-25, at 12:56, Peter Kasting wrote:
On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote:
Is there some reason why these examples use manufactured Safari build
numbers? It's implausible that a version
On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth aba...@webkit.org wrote:
Indeed. I suspect (2) and (3) are worth doing regardless.
AFAIK, gyp currently always regenerates everything and then compares the new
versions to the old to see if it actually needs to touch the files on disk.
This seems
On Tue, Feb 15, 2011 at 11:23 AM, Adam Barth aba...@webkit.org wrote:
This has been discussed on IRC when it started - everyone present seemed
to be OK with that, and didn't want to revert. Please feel free to revert,
of course.
I must have missed that discussion. Maybe we should note
On Thu, Feb 10, 2011 at 7:32 AM, laszlo.1.gom...@nokia.com wrote:
QtWebKit is considering dropping the language tag part of the User Agent
string - following Firefox (
http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/).
I think the WebKit community did a reasonable job
On Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov apav...@chromium.orgwrote:
I have put together a Web Inspector blog post draft (
http://webkit.org/blog/?p=1463) concerning the latest style editing
improvements. Please speak up if you think something should be changed,
added, or removed.
I
My understanding is that it is supposed to be possible to build all ports
without PCH support.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Sun, Jan 30, 2011 at 4:47 PM, Maciej Stachowiak m...@apple.com wrote:
Well, I didn't mean to pick on the authors of this file. This is the
impression I get from a lot of code that some call well-commented, by
which they mean lots of comments.
I agree that the comments you pointed out are
On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben aro...@apple.com wrote:
Please let me (and the list) know if this change will cause you trouble,
and if there's something we can do to make the transition easier.
This may make life hard on Chromium as right now we don't support building
with
On Mon, Jan 31, 2011 at 12:47 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 31, 2011, at 11:01 AM, Peter Kasting wrote:
I think people who favor comments tend to produce a lot of exactly this
kind of comment. Except in some cases its verbose multiline comments that
exceed the number
This thread has probably gone the way of all webkit-dev threads on comments
or ChangeLog files -- people's opinions vary, it turns into a bikeshed, and
nothing really changes about how we code. Repeat in a year.
w.r.t. ImageDecoder specifically, as I mentioned before I do agree that
there are
On Thu, Jan 27, 2011 at 4:27 PM, Simon Fraser simon.fra...@apple.comwrote:
I think we have a distinct lack of comments that help novices to understand
the code. I feel that we almost have a privileged few mentality in some
code; if you can't figure it out by reading the code, then you
On Fri, Jan 28, 2011 at 10:14 AM, Alexey Proskuryakov a...@webkit.org wrote:
Do you have any specific mechanism in mind for keeping global comments
accurate?
No more than I have for keeping API usage or function implementations
correct; that is, if we have comments, they must be as important
If you never write layout tests, you can stop reading.
Right now few ports run pixel tests (a shame). One reason is because we
frequently need different reference images for each port, and creating
hundreds or thousands of these is a hassle. Maintenance burden also
increases.
We could greatly
On Wed, Dec 8, 2010 at 12:57 PM, Darin Adler da...@apple.com wrote:
I’m worried a bit, though, that if we can’t use any text in them at all,
the tests are then not at all self explanatory. You have to be an expert on
the test to understand what it’s testing and what success and failure look
On Wed, Dec 8, 2010 at 1:04 PM, Darin Adler da...@apple.com wrote:
On Dec 8, 2010, at 1:02 PM, Peter Kasting wrote:
the number of tests that fall into this bucket is hopefully small?
Maybe we should talk about some specific tests. I can‘t think of many tests
with no text that are self
On Wed, Dec 8, 2010 at 2:03 PM, Darin Adler da...@apple.com wrote:
You both have convinced me that HTML comments could be fine for explaining
what a test is testing. Maybe we could come up with a format that makes it
likely we’ll spot those comments.
In the (few) tests I've written, I
On Wed, Dec 8, 2010 at 3:24 PM, Maciej Stachowiak m...@apple.com wrote:
Maybe we could come up with a way to print the explanation in the browser
only, and not in DumpRenderTree. A simple convention could be:
if (!window.layoutTestController)
document.write(Explanation of what the test is
1 - 100 of 266 matches
Mail list logo
