Re: [webkit-dev] Remove the WinCE bot?

2014-01-06 Thread Osztrogonác Csaba

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


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-06 Thread Alexey Proskuryakov

04 янв. 2014 г., в 9:51, Darin Adler da...@apple.com написал(а):

 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] When to use auto? (I usually consider it harmful)

2014-01-06 Thread Darin Adler

On Jan 6, 2014, at 10:03 AM, Alexey Proskuryakov a...@webkit.org 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] Importing W3C tests for HTML template elements

2014-01-06 Thread Ryosuke Niwa
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 youe...@gmail.com 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 da...@apple.com

 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 rn...@webkit.org wrote:

 On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler da...@apple.com wrote:

 On Dec 4, 2013, at 6:48 AM, youenn fablet youe...@gmail.com 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] Guideline for nullptr

2014-01-06 Thread Darin Adler
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] Guideline for nullptr

2014-01-06 Thread Dan Bernstein


Sent from my iPad

 On Jan 6, 2014, at 11:55 AM, Darin Adler da...@apple.com 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


Re: [webkit-dev] Guideline for nullptr

2014-01-06 Thread Anders Carlsson

On Jan 6, 2014, at 12:01 PM, Dan Bernstein m...@apple.com wrote:

 
 
 Sent from my iPad
 
 On Jan 6, 2014, at 11:55 AM, Darin Adler da...@apple.com 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] Importing W3C tests for HTML template elements

2014-01-06 Thread Robin Berjon

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


[webkit-dev] Apple Mac EWS 10.9 upgrade?

2014-01-06 Thread Lucas Forschler
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] Apple Mac EWS 10.9 upgrade?

2014-01-06 Thread Myles C. Maxfield
Support here!
On Jan 6, 2014, at 12:51 PM, Lucas Forschler lforsch...@apple.com 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


Re: [webkit-dev] Guideline for nullptr

2014-01-06 Thread Ryosuke Niwa
Sounds like a great idea to me.

- R. Niwa


On Mon, Jan 6, 2014 at 12:04 PM, Anders Carlsson ander...@apple.com wrote:


 On Jan 6, 2014, at 12:01 PM, Dan Bernstein m...@apple.com wrote:

 
 
  Sent from my iPad
 
  On Jan 6, 2014, at 11:55 AM, Darin Adler da...@apple.com 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] When to use auto? (I usually consider it harmful)

2014-01-06 Thread Geoffrey Garen
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] Importing W3C tests for HTML template elements

2014-01-06 Thread Dirk Pranke
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 rn...@webkit.org 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 youe...@gmail.com 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 da...@apple.com

 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 rn...@webkit.org wrote:

 On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler da...@apple.com wrote:

 On Dec 4, 2013, at 6:48 AM, youenn fablet youe...@gmail.com 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] Apple Mac EWS 10.9 upgrade?

2014-01-06 Thread Alexey Proskuryakov

06 янв. 2014 г., в 12:51, Lucas Forschler lforsch...@apple.com написал(а):

 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] Guideline for nullptr

2014-01-06 Thread Martin Robinson
On Mon, Jan 6, 2014 at 1:16 PM, Ryosuke Niwa rn...@webkit.org 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] When to use auto? (I usually consider it harmful)

2014-01-06 Thread Bem Jones-Bey

On Jan 6, 2014, at 13:49 , Geoffrey Garen 
gga...@apple.commailto: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] When to use auto? (I usually consider it harmful)

2014-01-06 Thread Darin Adler

On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com 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)

2014-01-06 Thread Darin Adler

On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com 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] Apple Mac EWS 10.9 upgrade?

2014-01-06 Thread Ryosuke Niwa
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 a...@webkit.org wrote:


 06 янв. 2014 г., в 12:51, Lucas Forschler lforsch...@apple.com
 написал(а):

  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)

2014-01-06 Thread Maciej Stachowiak

On Jan 6, 2014, at 3:34 PM, Darin Adler da...@apple.com wrote:

 
 On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com 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