Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Saam Barati
Why are we insisting on doing something on the bots that takes ~10x longer to 
run than necessary? I’d rather have that time spent running more tests.

Overall, how we’re doing things now feels like a bad allocation of bot 
resources. The differences I see between O3 with no-inlining vs O0 is:
- Some race conditions will behave differently. Race conditions are already non 
predictable. I don’t think we’re losing anything here.
- O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in O0, 
and vice versa. In general, we probably care more about O3 compiler bugs than 
O0, since we don’t ship O0, but ship a lot of O3.

(And if we’re going to insist on “I want it to run what I build at my desk”: I 
run debug with O3 at my desk, and I can run debug tests in a reasonable amount 
of time now.)

In evaluating what’s the better setup, I think it’s helpful to think about this 
from the other side. Let’s imagine we had Debug+O3 as our current setup. And 
someone proposed to move it to O0 and make our tests take ~10x longer. I think 
that’d be a non-starter.

- Saam

> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what I 
> build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam  wrote:
>> 
>> Hi folks,
>> 
>> We're planning to switch the JSC EWS bot and build.webkit.org Debug build 
>> and test bots to building with the following set first:
>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>> 
>> This means the Debug builds will be built with optimization level forced to 
>> O3.
>> 
>> Why are we doing this?
>> 1. So that the JSC EWS will start catching ASSERT failures.
>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>> all.  Hopefully, this change will fix this issue.
>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>> 
>> The downside: crash stack traces will be like Release build stack traces.  
>> But I don’t think we should let this deter us.  It’s not like there’s no 
>> stack information.  And just as we do with debugging Release build test 
>> failures, we can always do a Debug build locally to do our debugging.
>> 
>> We would like to apply this change to all Debug build and test bots, not 
>> just the JSC ones.  Does anyone strongly object to this change?
>> 
>> Thanks.
>> 
>> Cheers,
>> Mark
>> 
>> ___
>> 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


[webkit-dev] Can we remove ENABLE_STREAMS_API compile flag?

2020-06-18 Thread Tetsuharu OHZEKI
Hi WebKitten,

As I see the following codes and grep,  I seem today's all (?) ports of WebKit
have enabled ENABLE_STREAMS_API flag by default.

- 
https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h?rev=263222#L466
- 
https://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake?rev=263222#L104
- 
https://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake?rev=263222#L58
- 
https://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake?rev=263222#L87
- 
https://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake?rev=263222#L210
- 
https://trac.webkit.org/browser/trunk/Source/cmake/tools/vsprops/FeatureDefines.props?rev=263222#L276

If my assumption is right, I'd like to propose to remove this
`ENABLE_STREAMS_API` flag.

What do you think about this?
If I missed some ports, please tell me about them.

--
Tetsuharu OHZEKI
tetsuharu.ohz...@gmail.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Geoffrey Garen
Better JSC debugging in exchange for worse debugging in non-JSC code that calls 
through to WTF is not a great tradeoff.

Is there a way to localize this change to only JSC?

Do we know for sure that this change would get stress tests running, or are we 
just guessing? Can we find out? It’s easier to weight a tradeoff between known 
quantities than it is to weigh a tradeoff between hoped-for quantities.

Thanks,
Geoff

> On Jun 18, 2020, at 9:55 AM, Ryan Haddad  wrote:
> 
>> 
>> On Jun 18, 2020, at 9:44 AM, Alex Christensen > > wrote:
>> 
>> It sounds to me like Mark’s suggestion does not lose anything.  It’s just 
>> for JSC “Debug”
> 
> The post-commit JSC bots use the same build products as the other debug 
> testers, so with our current setup it would have to apply to other queues as 
> well.
> 
> Ryan
> 
>> which currently is not running because it’s too slow.  If he called it 
>> “ReleaseWithAssert” it would make it more clear what is going on and we 
>> would all appreciate the additional information those bots provide.
>> 
>>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >> > wrote:
>>> 
>>> I also object to losing good stack traces for crashes on Debug bots.
>>> 
>>> Also, I don't think Debug bots should build something different from what I 
>>> build at my desk.
>>> 
>>> Simon
>>> 
 On Jun 17, 2020, at 1:36 PM, Mark Lam >>> > wrote:
 
 Hi folks,
 
 We're planning to switch the JSC EWS bot and build.webkit.org 
  Debug build and test bots to building with the 
 following set first:
 ./Tools/Scripts/set-webkit-configuration --force-opt=O3
 
 This means the Debug builds will be built with optimization level forced 
 to O3.
 
 Why are we doing this?
 1. So that the JSC EWS will start catching ASSERT failures.
 2. JSC stress test Debug bots have been timing out and not running tests 
 at all.  Hopefully, this change will fix this issue.
 3. Tests will run to completion faster and we’ll catch regressions sooner.
 
 The downside: crash stack traces will be like Release build stack traces.  
 But I don’t think we should let this deter us.  It’s not like there’s no 
 stack information.  And just as we do with debugging Release build test 
 failures, we can always do a Debug build locally to do our debugging.
 
 We would like to apply this change to all Debug build and test bots, not 
 just the JSC ones.  Does anyone strongly object to this change?
 
 Thanks.
 
 Cheers,
 Mark
 
 ___
 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
> 
> ___
> 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] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Ryan Haddad

> On Jun 18, 2020, at 9:44 AM, Alex Christensen  wrote:
> 
> It sounds to me like Mark’s suggestion does not lose anything.  It’s just for 
> JSC “Debug”

The post-commit JSC bots use the same build products as the other debug 
testers, so with our current setup it would have to apply to other queues as 
well.

Ryan

> which currently is not running because it’s too slow.  If he called it 
> “ReleaseWithAssert” it would make it more clear what is going on and we would 
> all appreciate the additional information those bots provide.
> 
>> On Jun 17, 2020, at 9:48 PM, Simon Fraser > > wrote:
>> 
>> I also object to losing good stack traces for crashes on Debug bots.
>> 
>> Also, I don't think Debug bots should build something different from what I 
>> build at my desk.
>> 
>> Simon
>> 
>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >> > wrote:
>>> 
>>> Hi folks,
>>> 
>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>  Debug build and test bots to building with the 
>>> following set first:
>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>> 
>>> This means the Debug builds will be built with optimization level forced to 
>>> O3.
>>> 
>>> Why are we doing this?
>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>>> all.  Hopefully, this change will fix this issue.
>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>> 
>>> The downside: crash stack traces will be like Release build stack traces.  
>>> But I don’t think we should let this deter us.  It’s not like there’s no 
>>> stack information.  And just as we do with debugging Release build test 
>>> failures, we can always do a Debug build locally to do our debugging.
>>> 
>>> We would like to apply this change to all Debug build and test bots, not 
>>> just the JSC ones.  Does anyone strongly object to this change?
>>> 
>>> Thanks.
>>> 
>>> Cheers,
>>> Mark
>>> 
>>> ___
>>> 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

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


Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Alex Christensen
It sounds to me like Mark’s suggestion does not lose anything.  It’s just for 
JSC “Debug” which currently is not running because it’s too slow.  If he called 
it “ReleaseWithAssert” it would make it more clear what is going on and we 
would all appreciate the additional information those bots provide.

> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what I 
> build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam > > wrote:
>> 
>> Hi folks,
>> 
>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>  Debug build and test bots to building with the 
>> following set first:
>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>> 
>> This means the Debug builds will be built with optimization level forced to 
>> O3.
>> 
>> Why are we doing this?
>> 1. So that the JSC EWS will start catching ASSERT failures.
>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>> all.  Hopefully, this change will fix this issue.
>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>> 
>> The downside: crash stack traces will be like Release build stack traces.  
>> But I don’t think we should let this deter us.  It’s not like there’s no 
>> stack information.  And just as we do with debugging Release build test 
>> failures, we can always do a Debug build locally to do our debugging.
>> 
>> We would like to apply this change to all Debug build and test bots, not 
>> just the JSC ones.  Does anyone strongly object to this change?
>> 
>> Thanks.
>> 
>> Cheers,
>> Mark
>> 
>> ___
>> 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] Request for position on Media Feeds

2020-06-18 Thread Becca Hughes
   1. There is a longer discussion about why we didn't use RSS here
   . The short
   version is that RSS does not provide enough detail for our use case, so we
   went with schema.org which is already a pretty established standard
   which primarily uses JSON for data feeds
   2. Yes this is correct
   3. At the moment our focus is on videos but if we plan to support more
   features such as audio it will likely be beyond podcasts e.g. music and
   will therefore require much more detailed data than what podcast feeds can
   provide today (such as detailed, artist, album and playlist info). One
   thing we are also thinking about it is adding support for Actions
    which would allow a user agent to show a
   like/dislike button in the UI and make a post in the background when they
   are clicked. This is easily achievable with schema.org but not with RSS.


On Wed, Jun 17, 2020 at 4:09 PM Maciej Stachowiak  wrote:

>
> Without having read the spec in detail, the first thing I wonder is why
> not use RSS for this purpose? That seems to be the de facto standard for
> audio feeds (i.e. podcasts). This is dismissed in a cursory way in the
> explainer. There’s some more detailed discussion in the issue filed by the
> TAG: , which I
> found eventually. It seems like some of that should go in the Explainer.
>
> Second, it’s not clear to me if this spec has anything that would need to
> be implemented in the browser engine. Rather, it provides a format for
> metadata linked from the page, which can optionally be used by the UA in
> some manner unrelated to processing of web content. Is that correct?
> (Asking in part to know the right people to ask for an opinion.)
>
> Third, and this is a minor thing, it seems strange that the spec (and
> parts of its syntax) are called Media Feeds instead of Video Feeds, since
> audio is explicitly out of scope. Perhaps audio is intended to be added
> later. If so, that increases the value of aligning with how podcasts are
> done today.
>
>
> On Jun 17, 2020, at 2:48 PM, Becca Hughes 
> wrote:
>
> Hi webkit-dev,
>
> I would like to request an official position on Media Feeds.
>
> Explainer: https://github.com/WICG/media-feeds/blob/master/explainer.md
> Chrome Status: https://chromestatus.com/feature/5695114963845120
> TAG review: https://github.com/w3ctag/design-reviews/issues/477
>
> Thanks,
> Becca
> ___
> 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