On Tue, May 15, 2012 at 9:31 AM, Darin Adler 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 std::min"
On Tue, May 15, 2012 at 11:37 AM, Ryosuke Niwa wrote:
> On May 15, 2012 10:53 AM, "Peter Kasting" 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 Thu, May 17, 2012 at 9:26 AM, Dimitri Glazkov wrote:
> 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 name are much harder
fo
On Thu, May 17, 2012 at 12:02 PM, Ryosuke Niwa 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 of this,
and
On Thu, May 17, 2012 at 12:19 PM, Ryosuke Niwa wrote:
> On Thu, May 17, 2012 at 11:54 AM, Maciej Stachowiak wrote:
>>
>> Perhaps aligning the fields column after the bug URL would improve
>> readability (though it makes things a little harder to edit):
>>
>> We certainly could. We treat \s+ as \
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai 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 subtle. I'd rath
On Thu, May 17, 2012 at 2:11 PM, Ojan Vafai 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
___
webkit-dev mailing lis
On Wed, Jun 6, 2012 at 10:22 PM, Ryosuke Niwa 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 can't be inte
On Wed, Jun 6, 2012 at 11:28 PM, Ryosuke Niwa 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
> expect FAIL
On Thu, Jun 7, 2012 at 12:33 PM, Ryosuke Niwa 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 to TestExpec
On Wed, Jun 13, 2012 at 3:58 PM, Darin Adler wrote:
> On Jun 13, 2012, at 3:53 PM, Dirk Pranke 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 escape sequence.
>
Gotta a
On Wed, Jun 13, 2012 at 5:49 PM, Dirk Pranke wrote:
> Anyone not okay with:
>
> webkit.org/12345 [Win Mac Debug]
> animations/stop-animation-on-suspend.html [Crash Text Pass]
>
I withdraw my objections to this in the hopes of getting _some_ kind of
consensus and moving on with our lives :)
PK
_
On Thu, Jun 14, 2012 at 1:39 PM, Elliot Poger 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 if there is an
On Thu, Jul 12, 2012 at 3:17 PM, Ojan Vafai 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", which lets
On Thu, Jul 12, 2012 at 4:16 PM, Dirk Pranke 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
___
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
___
w
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
On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak 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 haven't touched t
On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo 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 desired behavior
On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo 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
notation about
On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo 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 protection against t
On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling wrote:
> So, I propose that we allow only these two signature formats for raw
> pointers:
>
> - const Foo* foo() const;
> - Foo* foo();
>
This was part of a discussion I had on this list (IIRC) a while back. The
context was the larger issue of cons
On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier 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 state themselve
On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak 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 the
> const ob
On Sun, Oct 28, 2012 at 2:29 PM, Filip Pizlo wrote:
> It is useful to say that "getting a pointer to T from an object of type S
> does not change S's state".
>
That's pretty much the definition of physical constness.
PK
___
webkit-dev mailing list
web
On Sun, Oct 28, 2012 at 3:12 PM, Filip Pizlo wrote:
> The point is that a rule mandating const methods to return const pointers
> prevents me from saying that getting a pointer from a container doesn't
> change the container.
>
Um, yes, that's exactly the point. My argument was that it's very r
On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak wrote:
> On Oct 28, 2012, at 10:09 PM, Peter Kasting wrote:
>
> On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak wrote:
>
>> I am not sure a blanket rule is correct. If the Foo* is logically related
>> to the obje
On Wed, Oct 31, 2012 at 1:32 PM, Ojan Vafai 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. clicking on the
On Wed, Oct 31, 2012 at 2:40 PM, Ojan Vafai wrote:
> On Wed, Oct 31, 2012 at 2:29 PM, Peter Kasting wrote:
>
>> 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
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
On Tue, Dec 11, 2012 at 1:11 PM, Emil A Eklund 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 understand yo
On Tue, Dec 11, 2012 at 1:19 PM, Emil A Eklund 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 patch
> w
On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt 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 responsible, an
On Tue, Dec 11, 2012 at 2:20 PM, Oliver Hunt 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
> the face of
On Wed, Jan 2, 2013 at 11:21 PM, Steve Block wrote:
> - 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 points" use you're des
On Thu, Jan 3, 2013 at 11:36 AM, Shawn Singh wrote:
> 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 as confusing as usi
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak 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
> stick to mergi
On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa 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 Windows (
On Mon, Mar 11, 2013 at 4:21 PM, Ryosuke Niwa wrote:
> On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting wrote:
>
>> On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa wrote:
>>
>>> Is it expected that overtype works on Windows or on Linux? e.g. If
>>> "Edit&qu
On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa 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
> even have to
On Mon, Mar 11, 2013 at 5:54 PM, Ryosuke Niwa 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 object, the
On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa 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 was to reiterate
On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig 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 the major WebKit
>
On Wed, Mar 20, 2013 at 11:46 PM, Robert Hogan wrote:
> 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, which is
> fin
On Tue, Mar 26, 2013 at 5:51 PM, Benjamin Poulain wrote:
> 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 to be someone who
On Tue, Jun 29, 2010 at 12:49 PM, Beth Dakin wrote:
> I would like to STRONGLY encourage other platforms to implement
> GraphicsContext::clipConvexPolygon() soon.
>
Should the clip be anti-aliased?
PK
___
webkit-dev mailing list
webkit-dev@lists.webki
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov wrote:
> I'd lean to the removal, unless there is a port that has work ongoing or
> planned soon for those implementations.
>
> Does anybody vote for #ifdefs?
>
I vote against removal if only because Chromium has really wanted these
badly for a long t
On Wed, Jul 21, 2010 at 2:40 PM, Ojan Vafai wrote:
> Here are my initial thoughts on what a review bot would do.
>
> *After a patch turns a week old, send the following email:*
> Patch 12345 of bug 6789 is a week old. It may just be because no reviewer
> has found time to review it. But there may
On Tue, Aug 24, 2010 at 12:21 PM, Chinmaya Sn wrote:
> I have special case in my hand; currently I maintain a custom branch
> of WebKit, I already have
> implemented a module which sits closely with WebCore and it works just
> fine. One of my
> goals is to deliver these changes back to community
On Sun, Oct 3, 2010 at 10:31 AM, Darin Adler wrote:
> What you say here about object lifetime is not correct. I thought the same
> thing a year or so back. But the C++ language keeps these objects alive
> until the end of the block.
>
Correct. One helpful section from the standard (12.2/5 "Temp
On Mon, Oct 4, 2010 at 4:23 AM, Leandro Graciá Gil <
leandrogra...@chromium.org> wrote:
> In summary, looking at code like this
>>
>> B& b = c->foo();
>> ...
>> b.m();
>>
>> If c->foo() returns a temporary ("return B();"), then it is safe.
>>
>
> Maybe I'm wrong, but are you completely sure abo
On Fri, Oct 22, 2010 at 11:02 AM, Kenneth Russell wrote:
> WebKit coding practice is to not set svn:eol-style
> on checked in text files
>
Darin Adler told me a while back that this is untrue, and that originally
all files had eol-style set and it was sloppiness/laziness/ignorance that
caused th
On Mon, Nov 1, 2010 at 9:40 AM, Brady Eidson wrote:
> I think this pattern increases readability of forward declarations in
> headers and we should change the style guidelines to specify its continued
> use.
>
> Thoughts?
>
I don't find either one significantly better than the other, personally.
webkit-dev is not a "help me with my website" list. It's for discussion of
development on WebKit itself.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote:
> It seems to me, that using bool types for function arguments is strictly
> worse than using an enum. An enum is always clearer and can be easily
> casted to a bool if needed.
>
> doSomething(something, false);
>
> Is much less readable than:
>
On Fri, Dec 3, 2010 at 2:42 PM, David Hyatt wrote:
> An example of nice boolean usage is:
>
> paintTextWithShadows(context, font, textRun, 0, length, length,
> textOrigin, boxRect, textShadow, textStrokeWidth > 0, isHorizontal());
> GOOD!
>
> The last parameter is a boolean indicating whether or
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 d
On Wed, Dec 8, 2010 at 12:57 PM, Darin Adler 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
> like.
>
I th
On Wed, Dec 8, 2010 at 1:04 PM, Darin Adler 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
On Wed, Dec 8, 2010 at 2:03 PM, Darin Adler 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 generally use top-
On Wed, Dec 8, 2010 at 3:24 PM, Maciej Stachowiak 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 testing
On Thu, Jan 27, 2011 at 4:27 PM, Simon Fraser wrote:
> 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 shouldn't be
> messing wit
On Fri, Jan 28, 2011 at 10:14 AM, Alexey Proskuryakov 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 to
reviewers a
On Sun, Jan 30, 2011 at 4:47 PM, Maciej Stachowiak 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 pretty
On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben 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 VS2010. We are wor
On Mon, Jan 31, 2011 at 12:47 PM, Maciej Stachowiak 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 numb
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 som
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 Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov wrote:
> 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 get an error pag
On Thu, Feb 10, 2011 at 7:32 AM, 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 at aligning the User Ag
On Tue, Feb 15, 2011 at 11:23 AM, Adam Barth 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 these things
> i
On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth 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 safe but slow.
P
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, th
On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting 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 dra
On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer wrote:
> 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 for testing.
>
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 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 s
On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting 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 S
On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe 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 numbers wer
On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe wrote:
> On 2011-03-25, at 12:56, Peter Kasting wrote:
>
> On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe wrote:
>
>> Is there some reason why these examples use manufactured Safari build
>> numbers? It's implausible that a v
On Fri, Mar 25, 2011 at 1:08 PM, Peter Kasting wrote:
> On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe 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
>>
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 comman
On Wed, Apr 20, 2011 at 10:46 PM, Ryosuke Niwa wrote:
> On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting wrote:
>>
>> * 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&#x
On Mon, May 2, 2011 at 11:47 AM, Alexey Proskuryakov wrote:
> Is this something that was requested by Chrome users?
>
There has definitely been interest from both consumers and enterprise on the
Chrome side.
PK
___
webkit-dev mailing list
webkit-dev@l
On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham 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 is fully upstre
On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard 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 most of the
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak 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 to
> the ob
On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak 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
> or ref
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak 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 our code no
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen 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
> needed -- oth
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler 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 non-const pointer
On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler 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
>
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak 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 const trave
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler wrote:
> On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
> > On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak
> wrote:
> >> 1) We definitely have consensus to fix the broken non-logically-const
> accessors by making them
On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler 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 beli
On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak 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 |this| to beg
On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak 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 implementatio
On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth 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 already marked o
On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub 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 higher
> precision
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 t
1 - 100 of 326 matches
Mail list logo
