[webkit-dev] Can we jettison Sputnik?

[Ross . Kirsling]

Hi everybody,

I’d like to verify whether there’s any specific reason that the 
LayoutTests/sputnik directory continues to exist.

According to Wikipedia, “All current Sputnik tests have been incorporated into 
ECMA's Test262 test suite.” (Here “current” evidently means June 2011.) And 
indeed, when making fixes to address Test262 failures in JSC, it’s quite 
awkward to have to update the Sputnik expectations to reflect any new 
“failures”—particularly given that it’s not sufficient to simply build JSC in 
order to run them.

Would anyone object to a patch deleting this directory outright? The only 
concern that occurs to me is that Test262 is not currently integrated into EWS.

Thanks!
Ross
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

[Ross . Kirsling]

In that case, I'll point out that C++ Core Guidelines has a rule "Virtual 
functions should specify exactly one of virtual, override, or final".
(http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)

Their tl;dr:
"
• virtual means exactly and only “this is a new virtual function.”
• override means exactly and only “this is a non-final overrider.”
• final means exactly and only “this is a final overrider.”
"

FWIW, they also have a rule "Use final sparingly" with the note that "Claims of 
performance improvements from final should be substantiated."
(http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)

Ross

On 12/19/18, 1:54 PM, "webkit-dev on behalf of Darin Adler" 
 wrote:

Let’s be clear about what we are discussing.

The choice is not be between “final” and “override”.

The choice is between “final override”, “override final”, and “final” for 
functions which are both overrides and final.

— Darin

Sent from my iPhone

> On Dec 19, 2018, at 12:27 PM, Michael Catanzaro  
wrote:
> 
>> On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev  
wrote:
>> Adding override to method which already has final specifier doesn't 
affect anything,
>> because both final and override may ony be used on virtual methods
> 
> FWIW I prefer override because it's much more clear what that keyword is 
used for.
> 
> Michael
___
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] Lots of spam on Bugzilla

[Ross . Kirsling]

On 12/5/18, 8:28 AM, "webkit-dev on behalf of Michael Catanzaro" 
 wrote:


On Tue, Dec 4, 2018 at 7:47 PM, Alexey Proskuryakov  
wrote:
> Anyone can tag comments to make them invisible

How?

You can click Tag and enter "spam". (There's also the "obsolete" tag for 
hiding, say, outdated feedback from the EWS bots. Unfortunately tagging is 
purely by manual entry right now, but it works.)

___
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] Tools/TestWebKitAPI

[Ross . Kirsling]

APITests/ would seem like an improvement to me...although given that this would 
be the seventh *Tests/ directly, it also makes me wonder if those should all be 
moved under a top-level Tests/ directory? __

(Either way, I'd be happy to help with Xcode rearranging if needed, at least to 
the point of pleasing the external builds.)

Ross

On 2/5/19, 12:13 PM, "webkit-dev on behalf of Michael Catanzaro" 
 wrote:

Hi,

I started writing this mail to propose creating a separate ChangeLog 
for Tools/TestWebKitAPI, to make the Tools/ ChangeLog more focused on, 
you know, actual tools. So many of my changes under Tools/ are to the 
API tests.

But this reminded me that TestWebKitAPI is the only testsuite we have 
under Tools/. All the rest are toplevel directories:

JSTests/
LayoutTests/
ManualTests/
PerformanceTests/
WebDriverTests/
WebPlatformTests/

So it almost doesn't fit under Tools/ at all, right? Would there be any 
objections to moving it to a toplevel WebKitAPITests/ or just APITests/ 
directory? That would nicely parallel all our other tests.

(The practical objection is that moving anything is difficult for 
someone without familiarity with both XCode and CMake. I'd only be able 
to help with the CMake portion of the move. And then Apple internal 
build will inevitably break too, so someone would need to volunteer to 
care for that.)

If we don't want to move it, I guess a new ChangeLog file would be 
fine? :)

Michael

___
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] Tools/TestWebKitAPI

[Ross . Kirsling]

That said, I would expect specifically the Tools/TestWebKitAPI/Tests 
subdirectory to be the thing moved to APITests/, since the code that actually 
runs the tests is as much a “tool” as DRT, WKTR, or various other test-running 
scripts under Tools/Scripts are.

Ross

From: Ryosuke Niwa 
Date: Tuesday, February 5, 2019 at 1:44 PM
To: "Kirsling, Ross" 
Cc: Michael Catanzaro , WebKit Development 

Subject: Re: [webkit-dev] Tools/TestWebKitAPI

Moving it to top-level APITests directory sounds good to me although I'm not 
volunteering to fix any Xcode or Apple internal build related issues.

- R. Niwa

On Tue, Feb 5, 2019 at 1:07 PM 
mailto:ross.kirsl...@sony.com>> wrote:
APITests/ would seem like an improvement to me...although given that this would 
be the seventh *Tests/ directly, it also makes me wonder if those should all be 
moved under a top-level Tests/ directory? __

(Either way, I'd be happy to help with Xcode rearranging if needed, at least to 
the point of pleasing the external builds.)

Ross

On 2/5/19, 12:13 PM, "webkit-dev on behalf of Michael Catanzaro" 
mailto:webkit-dev-boun...@lists.webkit.org>
 on behalf of mcatanz...@igalia.com> wrote:

Hi,

I started writing this mail to propose creating a separate ChangeLog
for Tools/TestWebKitAPI, to make the Tools/ ChangeLog more focused on,
you know, actual tools. So many of my changes under Tools/ are to the
API tests.

But this reminded me that TestWebKitAPI is the only testsuite we have
under Tools/. All the rest are toplevel directories:

JSTests/
LayoutTests/
ManualTests/
PerformanceTests/
WebDriverTests/
WebPlatformTests/

So it almost doesn't fit under Tools/ at all, right? Would there be any
objections to moving it to a toplevel WebKitAPITests/ or just APITests/
directory? That would nicely parallel all our other tests.

(The practical objection is that moving anything is difficult for
someone without familiarity with both XCode and CMake. I'd only be able
to help with the CMake portion of the move. And then Apple internal
build will inevitably break too, so someone would need to volunteer to
care for that.)

If we don't want to move it, I guess a new ChangeLog file would be
fine? :)

Michael

___
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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Ross Kirsling via webkit-dev]

Yeah, I think it's important to clarify that nobody is "using 
non-Unified-Source building for their development", at least to my knowledge. 
Being broken by the shifting sands of unified sources is an everybody problem 
(or at the very least an "everybody that builds via CMake problem", which is 
ultimately an everybody problem).

Ross

From: Alex Christensen via webkit-dev 
Sent: Thursday, April 29, 2021 11:03 AM
To: Darin Adler 
Cc: webkit-dev@lists.webkit.org 
Subject: Re: [webkit-dev] New EWS Non-Unified builder

I don’t see the goal as “keep non-Unified-Source building” but rather “prevent 
unrelated build fixes when we add another file later”.  Right now when we add a 
new file we often have to sprinkle includes, declarations, and other build 
fixes in files unrelated to the current change.  If we had a bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
>
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
>
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
>
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
>
> — Darin
> ___
> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev