Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
On Jan 6, 2014, at 3:34 PM, Darin Adler wrote:
>
> On Jan 6, 2014, at 1:49 PM, Geoffrey Garen wrote:
>
>> FunctionParameters::FunctionParameters(ParameterNode* firstParameter,
>> unsigned size)
>> : m_size(size)
>> {
>> unsigned i = 0;
>> for (ParameterNode* parameter = firstParameter; parameter; parameter =
>> parameter->nextParam()) {
>> auto pattern = parameter->pattern();
>> pattern->ref();
>> patterns()[i++] = pattern;
>> }
>> }
>>
>> If I had to describe this algorithm in English, I’d say, “Collect and retain
>> all the [auto] from the list of parsed parameters.” I think that explanation
>> would be stronger if “[auto]” were a concrete noun.
>
> The variable and the function are both named pattern and I would use that as
> the noun.
Question for Geoff or anyone who knows: is it contextually useful to know that
it's specifically a "DeconstructionPatternNode*" beyond knowing that it's a
"pattern"?
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple Mac EWS 10.9 upgrade?
Yeah, I think there is a lot of value in keeping some Mountain Lion coverage now that a lot of people have moved onto Mavericks on their own machines. Ideally, we would like to have EWS for both Mavericks and Mountain Lion though. So perhaps we could move either release or debug bots to Mavericks? - R. Niwa On Mon, Jan 6, 2014 at 1:53 PM, Alexey Proskuryakov wrote: > > 06 янв. 2014 г., в 12:51, Lucas Forschler > написал(а): > > > The Apple Mac EWS bots are currently running 10.8.5. > > I would like to see if there is any opposition (or support) for > upgrading them to 10.9 / Mavericks. > > Mavericks bots are substantially less reliable at this point, so this will > degrade EWS performance. E.g. Mavericks WK2 Release was completely > dysfunctional for two days recently for unclear reasons. > > As everyone is supposed to run tests locally before uploading patches - > and most people with Macs hopefully do this on Mavericks - it is helpful > that EWS tests a different version of the OS. > > - WBR, Alexey Proskuryakov > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
On Jan 6, 2014, at 1:49 PM, Geoffrey Garen wrote:
> FunctionParameters::FunctionParameters(ParameterNode* firstParameter,
> unsigned size)
> : m_size(size)
> {
> unsigned i = 0;
> for (ParameterNode* parameter = firstParameter; parameter; parameter =
> parameter->nextParam()) {
> auto pattern = parameter->pattern();
> pattern->ref();
> patterns()[i++] = pattern;
> }
> }
>
> If I had to describe this algorithm in English, I’d say, “Collect and retain
> all the [auto] from the list of parsed parameters.” I think that explanation
> would be stronger if “[auto]” were a concrete noun.
The variable and the function are both named pattern and I would use that as
the noun.
— Darin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
On Jan 6, 2014, at 1:49 PM, Geoffrey Garen wrote:
> auto children = elementChildren(*dummySpanAncestor);
> for (auto child = children.begin(), end = children.end(); child != end;
> ++child) {
> if (isSpanWithoutAttributesOrUnstyledStyleSpan(&*child))
> toRemove.append(&*child);
> }
This should be written with a C++11 loop:
for (auto& child : elementChildren(*dummySpanAncestor)) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(&child))
toRemove.append(&child);
}
Not sure if you would say that helps or hurts readability. I could easily
imagine either Element& or auto&; in cases like this where we don’t have to
name the iterator type we don’t need auto as much as in the non-C++-11-loop
where the iterator type strongly motivates it.
— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
On Jan 6, 2014, at 13:49 , Geoffrey Garen
mailto:gga...@apple.com>> wrote:
Let me try to clarify with two more motivating examples:
(1) Nodes.cpp:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter, unsigned
size)
: m_size(size)
{
unsigned i = 0;
for (ParameterNode* parameter = firstParameter; parameter; parameter =
parameter->nextParam()) {
auto pattern = parameter->pattern();
pattern->ref();
patterns()[i++] = pattern;
}
}
If I had to describe this algorithm in English, I’d say, “Collect and retain
all the [auto] from the list of parsed parameters.” I think that explanation
would be stronger if “[auto]” were a concrete noun.
Does anybody prefer auto in this context? If so, why?
While I wouldn't say that I prefer auto here, it doesn't really bother me in
this example. Personally, I would read that as "Collect and retain all of the
patterns from the list of parsed parameters", and I'd say it the same way if
auto had been an explicit type.
(2) ApplyStyleCommand.cpp:
auto children = elementChildren(*dummySpanAncestor);
for (auto child = children.begin(), end = children.end(); child != end;
++child) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(&*child))
toRemove.append(&*child);
}
I don’t understand why we’re &*’ing here. That’s a surprising idiom I haven’t
seen before, which I would expect to be a no-op. My first question when reading
this is, “What is the type of ‘child’, such that I would need to &* it?”.
Is this "&*child” obvious to everyone else?
It's actually pretty obvious to me, but I've been spending a lot of time with
similar iterators lately. I don't think it's that much clearer without the
auro. I've definitely found this to be confusing in the codebase much before
auto entered the picture. (In this case, I'd argue strongly for using an
accessor method on the iterator or a temporary variable)
- Bem
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Guideline for nullptr
On Mon, Jan 6, 2014 at 1:16 PM, Ryosuke Niwa wrote: > Sounds like a great idea to me. Seconding this. nullptr also has much better compatibility with varargs than 0. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple Mac EWS 10.9 upgrade?
06 янв. 2014 г., в 12:51, Lucas Forschler написал(а): > The Apple Mac EWS bots are currently running 10.8.5. > I would like to see if there is any opposition (or support) for upgrading > them to 10.9 / Mavericks. Mavericks bots are substantially less reliable at this point, so this will degrade EWS performance. E.g. Mavericks WK2 Release was completely dysfunctional for two days recently for unclear reasons. As everyone is supposed to run tests locally before uploading patches - and most people with Macs hopefully do this on Mavericks - it is helpful that EWS tests a different version of the OS. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Importing W3C tests for HTML template elements
Ryosuke and I discussed this a bit over IRC. Ryosuke's main concern was that supporting multiple document roots adds a fair amount of complexity to NRWT. Conceptually, it's probably easier to add support to run the W3C's new server (known as wptserve) and then maybe use it for *all* imported tests from the W3C. If it turns out that wptserve is too slow, and you would prefer to run only some of the directories over http (i.e., the 10k+ CSS tests don't need http), you'll probably need to modify how wptserve is run (and NRWT) as well, anyway, so the patch would be different. Ryosuke, please let me know if I've misstated your thinking at all. -- Dirk On Mon, Jan 6, 2014 at 11:23 AM, Ryosuke Niwa wrote: > I don't think we should do this given that the python server has been > added to W3C testing harness, and they're gonna convert all existing tests > to use that instead: > http://lists.w3.org/Archives/Public/public-test-infra/2014JanMar/.html > > We should simply wait for that effort to take place and add a support for > the python server instead. > > - R. Niwa > > > On Fri, Dec 6, 2013 at 12:25 AM, youenn fablet wrote: > >> As long as the newly imported tests use relative URLs, alias may be used >> as a workaround. I will give it a try. >> Bug entry is at https://bugs.webkit.org/show_bug.cgi?id=125339 >> Any further help appreciated, >> Youenn >> >> >> >> 2013/12/6 Darin Adler >> >>> If that's really ends up being super hard we can always put yet another >>> third-party or imported directory inside the http directory as previously >>> suggested. it's annoying to have three different places for imported tests >>> and code, but not something I want to hold us up for a long time. >>> >>> -- Darin >>> >>> Sent from my iPhone >>> >>> On Dec 5, 2013, at 5:51 PM, Ryosuke Niwa wrote: >>> >>> On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler wrote: >>> On Dec 4, 2013, at 6:48 AM, youenn fablet wrote: I am planning to add some XHR tests from https://github.com/w3c/web-platform-tests. My initial plan was to add them in a subdirectory of LayoutTests/http/tests/w3c. If adding them into LayoutTests/imported/w3c, that would probably require updating the test scripts to start/stop the HTTP test server for that particular sub-folder. Any preference? I’d prefer LayoutTests/imported/w3c. Although I’m not so happy about the different terminology we are using for “imported” vs. “ThirdParty”, which seems like the same concept at the top level of the directory structure. >>> >>> One trickiness to it is that we don't currently run any HTTP test in >>> parallel and the document root of the HTTP server is set to >>> LayoutTests/http/tests so we might need to modify that or restart the HTTP >>> server whenever we're running HTTP tests outside of LayoutTests/http. >>> >>> - R. Niwa >>> >>> >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
Let me try to clarify with two more motivating examples:
(1) Nodes.cpp:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter, unsigned
size)
: m_size(size)
{
unsigned i = 0;
for (ParameterNode* parameter = firstParameter; parameter; parameter =
parameter->nextParam()) {
auto pattern = parameter->pattern();
pattern->ref();
patterns()[i++] = pattern;
}
}
If I had to describe this algorithm in English, I’d say, “Collect and retain
all the [auto] from the list of parsed parameters.” I think that explanation
would be stronger if “[auto]” were a concrete noun.
Does anybody prefer auto in this context? If so, why?
(2) ApplyStyleCommand.cpp:
auto children = elementChildren(*dummySpanAncestor);
for (auto child = children.begin(), end = children.end(); child != end;
++child) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(&*child))
toRemove.append(&*child);
}
I don’t understand why we’re &*’ing here. That’s a surprising idiom I haven’t
seen before, which I would expect to be a no-op. My first question when reading
this is, “What is the type of ‘child’, such that I would need to &* it?”.
Is this "&*child” obvious to everyone else?
Thanks,
Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Guideline for nullptr
Sounds like a great idea to me. - R. Niwa On Mon, Jan 6, 2014 at 12:04 PM, Anders Carlsson wrote: > > On Jan 6, 2014, at 12:01 PM, Dan Bernstein wrote: > > > > > > > Sent from my iPad > > > >> On Jan 6, 2014, at 11:55 AM, Darin Adler wrote: > >> > >> I suggest we use nullptr, rather than of 0 or NULL, for all pointer > nulls in WebKit C++ sources. I don’t see any advantage to using 0 or NULL > over nullptr, and nullptr has multiple advantages. Three obvious ones: > Compile time error if accidentally passed to something expecting an > integer, can be distinguished from an integer in function overloading, can > tell it’s a pointer. > >> > >> Any objections? > > I think this is a great idea and something I’ve been doing ever since > nullptr became available to us. > > >> > >> — Darin > >> > >> PS: Maybe even instead of nil in WebKit Objective-C++ code? > > > > In Objective-C++, nil is nullptr, so I suggest that we stick with the > language convention of writing it as nil. > > I agree. (Also, using Nil for null classes). > > - Anders > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple Mac EWS 10.9 upgrade?
Support here! On Jan 6, 2014, at 12:51 PM, Lucas Forschler wrote: > Happy near year! > > The Apple Mac EWS bots are currently running 10.8.5. > I would like to see if there is any opposition (or support) for upgrading > them to 10.9 / Mavericks. > > Please let me know your thoughts :) > Lucas > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Apple Mac EWS 10.9 upgrade?
Happy near year! The Apple Mac EWS bots are currently running 10.8.5. I would like to see if there is any opposition (or support) for upgrading them to 10.9 / Mavericks. Please let me know your thoughts :) Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Importing W3C tests for HTML template elements
On 06/01/2014 20:23 , Ryosuke Niwa wrote: I don't think we should do this given that the python server has been added to W3C testing harness, and they're gonna convert all existing tests to use that instead: http://lists.w3.org/Archives/Public/public-test-infra/2014JanMar/.html We should simply wait for that effort to take place and add a support for the python server instead. I'm happy to report that the conversion to a python server as well as of all the server-side dynamic content that it needs to run is now complete and has been merged to master as of today. No need to wait! -- Robin Berjon - http://berjon.com/ - @robinberjon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Guideline for nullptr
On Jan 6, 2014, at 12:01 PM, Dan Bernstein wrote: > > > Sent from my iPad > >> On Jan 6, 2014, at 11:55 AM, Darin Adler wrote: >> >> I suggest we use nullptr, rather than of 0 or NULL, for all pointer nulls in >> WebKit C++ sources. I don’t see any advantage to using 0 or NULL over >> nullptr, and nullptr has multiple advantages. Three obvious ones: Compile >> time error if accidentally passed to something expecting an integer, can be >> distinguished from an integer in function overloading, can tell it’s a >> pointer. >> >> Any objections? I think this is a great idea and something I’ve been doing ever since nullptr became available to us. >> >> — Darin >> >> PS: Maybe even instead of nil in WebKit Objective-C++ code? > > In Objective-C++, nil is nullptr, so I suggest that we stick with the > language convention of writing it as nil. I agree. (Also, using Nil for null classes). - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Guideline for nullptr
Sent from my iPad > On Jan 6, 2014, at 11:55 AM, Darin Adler wrote: > > I suggest we use nullptr, rather than of 0 or NULL, for all pointer nulls in > WebKit C++ sources. I don’t see any advantage to using 0 or NULL over > nullptr, and nullptr has multiple advantages. Three obvious ones: Compile > time error if accidentally passed to something expecting an integer, can be > distinguished from an integer in function overloading, can tell it’s a > pointer. > > Any objections? > > — Darin > > PS: Maybe even instead of nil in WebKit Objective-C++ code? In Objective-C++, nil is nullptr, so I suggest that we stick with the language convention of writing it as nil. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Guideline for nullptr
I suggest we use nullptr, rather than of 0 or NULL, for all pointer nulls in WebKit C++ sources. I don’t see any advantage to using 0 or NULL over nullptr, and nullptr has multiple advantages. Three obvious ones: Compile time error if accidentally passed to something expecting an integer, can be distinguished from an integer in function overloading, can tell it’s a pointer. Any objections? — Darin PS: Maybe even instead of nil in WebKit Objective-C++ code? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Importing W3C tests for HTML template elements
I don't think we should do this given that the python server has been added to W3C testing harness, and they're gonna convert all existing tests to use that instead: http://lists.w3.org/Archives/Public/public-test-infra/2014JanMar/.html We should simply wait for that effort to take place and add a support for the python server instead. - R. Niwa On Fri, Dec 6, 2013 at 12:25 AM, youenn fablet wrote: > As long as the newly imported tests use relative URLs, alias may be used > as a workaround. I will give it a try. > Bug entry is at https://bugs.webkit.org/show_bug.cgi?id=125339 > Any further help appreciated, > Youenn > > > > 2013/12/6 Darin Adler > >> If that's really ends up being super hard we can always put yet another >> third-party or imported directory inside the http directory as previously >> suggested. it's annoying to have three different places for imported tests >> and code, but not something I want to hold us up for a long time. >> >> -- Darin >> >> Sent from my iPhone >> >> On Dec 5, 2013, at 5:51 PM, Ryosuke Niwa wrote: >> >> On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler wrote: >> >>> On Dec 4, 2013, at 6:48 AM, youenn fablet wrote: >>> >>> I am planning to add some XHR tests from >>> https://github.com/w3c/web-platform-tests. >>> My initial plan was to add them in a subdirectory of >>> LayoutTests/http/tests/w3c. >>> If adding them into LayoutTests/imported/w3c, that would probably >>> require updating the test scripts to start/stop the HTTP test server >>> for that particular sub-folder. >>> >>> Any preference? >>> >>> >>> I’d prefer LayoutTests/imported/w3c. Although I’m not so happy about the >>> different terminology we are using for “imported” vs. “ThirdParty”, which >>> seems like the same concept at the top level of the directory structure. >>> >> >> One trickiness to it is that we don't currently run any HTTP test in >> parallel and the document root of the HTTP server is set to >> LayoutTests/http/tests so we might need to modify that or restart the HTTP >> server whenever we're running HTTP tests outside of LayoutTests/http. >> >> - R. Niwa >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
On Jan 6, 2014, at 10:03 AM, Alexey Proskuryakov wrote: > As auto facilitates search-replace-don't-read refactoring I was talking about refactoring without changing function names. I don’t understand your example. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)
04 янв. 2014 г., в 9:51, Darin Adler написал(а): > There are so many other things which you can’t see when reading a line of C++ > code, which I think is a good thing — part of what makes C++ a high level > language. To create a straw man, imagine what it would be like if we had to > say “inline” at each call site of an inline function or “virtual” every time > we called a virtual function. Not sure if this is a fair comparison. Type names are useful when trying to understand what the code is doing. You get verified information about what each "thingy" in the code is, and extensive tools support for cross-referencing (be it Cmd-click, or copy/paste and grep). Inline and virtual specifiers might perhaps be useful for performance work, where reading the code shouldn't be the primary source of information anyway. > I’d like to be able to refine the return type of a function without having to > visit every call site, just as I can change a function to be an inline or a > virtual without doing so. To be clear, I'm not arguing to ban auto. Geoff's proposed WebKit style rules addition is one I like. However this example that you gave in support of auto seems to me like a reason to completely ban it, one I didn't think of before. As auto facilitates search-replace-don't-read refactoring, we'll just end up with rotten code like // Obsolete comment. auto preRefactoringVariableName = postRefactoringFunction(); These lines will be visible in the patch, and a super careful reviewer could catch it. Overall, it would strain reviewers more, I think. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove the WinCE bot?
Hi, +1 for removing the WinCE bot, it seems it isn't maintained at all. The latest build on it was on 8th Aug, it is offline since then: http://build.webkit.org/builders/WinCE%20Release%20%28Build%29/builds/36154 Additionally the latest build in the build.webkit.org history was on 6 th Jun and the build was failed since then: http://build.webkit.org/builders/WinCE%20Release%20%28Build%29/builds/35155 I filed a bug report to remove this bot and uploaded the patch: https://bugs.webkit.org/show_bug.cgi?id=126517 Ossy Simon Fraser írta: The WinCE bot has been dead for almost a month: http://build.webkit.org/builders/WinCE%20Release%20%28Build%29 I propose we remove it from the waterfall. WinCairo is also in a pretty bad, non-building state. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
