After a long hiatus, I'm back working on NRWT.
As of this evening all of the blocking issues to switching the WK2 bot
are resolved:
https://bugs.webkit.org/show_bug.cgi?id=56729
Just waiting for the WK2 bot to have some smaller number of failures,
then I'll pull the trigger.
After WK2 is switch
Trailing whitespace guidelines aren't part of the WebKit style guide on
purpose.
Thus, it wasn't a style clean-up, so I guess that would make it a change to
fit someone's preference.
dave
On Wed, Oct 19, 2011 at 6:38 PM, Ojan Vafai wrote:
> I saw a patch get committed recently that just fixes
On Wed, Oct 19, 2011 at 6:32 PM, Adam Barth wrote:
> On Wed, Oct 19, 2011 at 6:24 PM, Ryosuke Niwa wrote:
> > Also... VC++'s debugger happens to have some issues around unnamed
> > namespaces:
> > http://msdn.microsoft.com/en-us/library/0888kc6a%28VS.80%29.aspx
> >
> > Don't recall if this affec
I saw a patch get committed recently that just fixes trailing whitespace
across a large swath of the codebase.
In general, we prefer that pure style cleanups are only done as a precursor
to actually modifying the code. Otherwise, while they serve to make the
style consistent, they also make it con
On Wed, Oct 19, 2011 at 6:24 PM, Ryosuke Niwa wrote:
> Also... VC++'s debugger happens to have some issues around unnamed
> namespaces:
> http://msdn.microsoft.com/en-us/library/0888kc6a%28VS.80%29.aspx
>
> Don't recall if this affected classes inside unnamed namespace though.
> I think VC++ 2005'
Also... VC++'s debugger happens to have some issues around unnamed
namespaces:
http://msdn.microsoft.com/en-us/library/0888kc6a%28VS.80%29.aspx
Don't recall if this affected classes inside unnamed namespace though.
I think VC++ 2005's support for unnamed namespace is better than nested
classes (c
Another benefit to using the "static" keyword is that you can tell at a glance
that the function is internal to the translation unit, while you may not notice
the anonymous namespace.
-Sam
On Oct 19, 2011, at 3:45 PM, Darin Adler wrote:
> The guideline is not to disallow anonymous namespaces.
Dominic Cooney said:
> Hi webkittens,
>
> Is there a spec for -webkit-inline-box?
Yup, it's the old Flexbox spec. Currently being removed/replaced by
Ojan and Tony's work.
> I am investigating an assertion failure I can tickle using
> -webkit-inline-box. But to fix this, I first need to unders
On Wed, Oct 19, 2011 at 4:29 PM, Ryosuke Niwa wrote:
> On Wed, Oct 19, 2011 at 4:00 PM, Darin Adler wrote:
>>
>> On Oct 19, 2011, at 3:58 PM, Ryosuke Niwa wrote:
>> > On Wed, Oct 19, 2011 at 3:51 PM, Darin Adler wrote:
>> >>> How about classes that are only used in one cpp file? Should we be
>>
On Wed, Oct 19, 2011 at 4:00 PM, Darin Adler wrote:
> On Oct 19, 2011, at 3:58 PM, Ryosuke Niwa wrote:
> > On Wed, Oct 19, 2011 at 3:51 PM, Darin Adler wrote:
> >>> How about classes that are only used in one cpp file? Should we be
> wrapping those in an anonymous namespace?
> >> I’d suggest no
On Oct 19, 2011, at 3:58 PM, Ryosuke Niwa wrote:
> On Wed, Oct 19, 2011 at 3:51 PM, Darin Adler wrote:
>>> How about classes that are only used in one cpp file? Should we be
>>> wrapping those in an anonymous namespace?
>> I’d suggest not wrapping them in an anonymous namespace. Debugging tools
On Wed, Oct 19, 2011 at 3:51 PM, Darin Adler wrote:
>
> > How about classes that are only used in one cpp file? Should we be
> wrapping those in an anonymous namespace?
>
> I’d suggest not wrapping them in an anonymous namespace. Debugging tools
> work better when classes have unique names.
>
Ha
I’m open to changing our style.
The compiler many of us used in the past, gcc, had problems generating correct
debug information for code in anonymous namespaces. Given that most uses didn’t
accomplish anything more than putting static in front of functions did, we
decided to stick with that. B
I've been experimenting with watchlists as Dave has been working on
them, and I find them very helpful. For example, if you'd like to be
CCed whenever someone changes a web-facing IDL file, you subscribe to
"WebIDL" changes, as I have:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/c
On Oct 19, 2011, at 3:47 PM, Ryosuke Niwa wrote:
> How about classes that are only used in one cpp file? Should we be wrapping
> those in an anonymous namespace?
I’d suggest not wrapping them in an anonymous namespace. Debugging tools work
better when classes have unique names.
Can anyone name
I'm interested in learning the existing convention, not reasons to prefer
one or another.
- Ryosuke
On Wed, Oct 19, 2011 at 3:50 PM, John Knottenbelt wrote:
> I would recommend wrapping such classes in an anonymous namespace to avoid
> surprising link errors due to unintentional name collision.
I would recommend wrapping such classes in an anonymous namespace to avoid
surprising link errors due to unintentional name collision. Such problems
can also be difficult to spot at first as sometimes the linker "just" works
and then you get a seg fault sometime later.
On Wed, Oct 19, 2011 at 3:47
How about classes that are only used in one cpp file? Should we be wrapping
those in an anonymous namespace?
- Ryosuke
On Wed, Oct 19, 2011 at 3:45 PM, Darin Adler wrote:
> The guideline is not to disallow anonymous namespaces.
>
> It’s to prefer “static” over anonymous namespaces when either o
The guideline is not to disallow anonymous namespaces.
It’s to prefer “static” over anonymous namespaces when either one would work.
Debugging tools on at least some of the platforms work better with functions
that are given internal linkage by using the “static” keyword rather than
functions t
The watchlist is a simple way to watch for new patches that interest you. The
watchlist is automatically applied to patches by a bot (currently the style
bot).
I'm happy to answer questions about it here or in irc (and/or review any
patches you make to the config file, but of course I don't mind o
I definitely agree that our current approach to pixel baselines is
less than ideal. There have been a number of efforts to reduce the
number of pixel tests, for example by converting tests to text tests
or to ref tests, but even after those efforts, we still have thousands
of tests that require di
We finally have correct baseline images checked in for Chromium-Skia on
SnowLeopard (hooray). Now we face the daunting task of rebaselining for
Chromium-Skia on Leopard.
The problem is that chromium-mac-leopard has ~4500 image diffs compared to
chromium-mac. The vast majority of these diffs are
There shouldn't be any performance costs. Instead of returning a
boolean (as the virtual function call does today), it will return a
constant AtomicString which can be compared to another AtomicString in
one instruction.
Adam
On Wed, Oct 19, 2011 at 1:31 PM, Sam Weinig wrote:
> I'd be interest
I'm not an advocate for or against, but it would be nice if we're going to
disallow this, that there be a rationale.
regards,
--Tom
> Hi,
>
> This came up again in one of my reviews :( I hate to add a bunch of new
> rules to style guide but apparently there are 86 instances of anonymous
> namesp
Hi,
This came up again in one of my reviews :( I hate to add a bunch of new
rules to style guide but apparently there are 86 instances of anonymous
namespaces in WebKit already so it's probably a good idea to mention that we
don't normally do this.
Best,
Ryosuke Niwa
Software Engineer
Google Inc
I'd be interested in performance cost to that, especially on a test that
creates a lot of JS wrapped Events.
-Sam
On Oct 18, 2011, at 6:42 PM, Adam Barth wrote:
> My thought on that is to use a single virtual function and return an atomic
> string, like we do for elements.
>
> Adam
> On Oct 1
On 10/17/2011 04:13 PM, Raphael Kubo da Costa wrote:
Anyway, are there any options besides simply svn commit'ting all these
files?
I'm thinking in uploading the text baselines (which are small) first.
When these are in place, we could work together to diminish the amount
of pixel baselines by
Hi
1) When we use spatial navigation, to find the nearest node it traverse DOM
> tree, is that node information can not be retrieved from render tree?
>
>
As per my understanding render tree (after layout) will have the position
> information for each node.
>
Code tranverses the DOM, yes, but it
Hi,
Thanks for Replying...
Still i have some doubts ...can you help me to clear them.
1) When we use spatial navigation, to find the nearest node it traverse DOM
tree, is that node information can not be retrieved from render tree?
As per my understanding render tree (after layout) will have the
On 10/18/2011 06:42 PM, Darin Adler wrote:
I think it’s worth going further — when can we remove this #if altogether?
-- Darin
Sure we can, sounds great. I will do that in the next patch.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
h
30 matches
Mail list logo
