Re: [webkit-dev] Transformations precision: double - float

[Olmstead, Don]

What CPU executes single precision floating point values at the same speed as 
double precision?

Here's a benchmark from NASA giving a comparison of single vs. double precision 
performance for one of their simulations. 
https://modelingguru.nasa.gov/docs/DOC-1664.

Single precision maps better to GPU backends, and CPU's SIMD computations than 
double. Unless there's something in the spec requiring double precision it 
makes sense to move away from double precision throughout WebKit.

It's fairly trivial to make SIMD types that can have CPU architecture specific 
implementations. As an example of how to do this in the wild there's the Sony 
vectormath library that's present in the Bullet Physics Library. 
http://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/vectormathlibrary/include/vectormath/.

As Kui noted the TransformationMatrix is a hotspot that could be helped by 
SIMD. Making the solution generic enough to target multiple architectures using 
SIMD should help the performance on all the platforms.

Don

-Original Message-
From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Simon Fraser
Sent: Monday, May 21, 2012 10:35 AM
To: Zoltan Herczeg
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Transformations precision: double - float

TransformationMatrix started out as floats, then got changed to doubles in 
http://trac.webkit.org/changeset/40761

This was done because on most hardware there is no penalty for using doubles 
over floats, and provided a better match with our system APIs that used doubles.

I'd prefer to take a forward-looking stance here, and assume that in time 
hardware will catch up.

Simon

On May 21, 2012, at 4:04 AM, Zoltan Herczeg wrote:

 Hi,
 
 is there any reason why the transformations in WebKit use doubles? We 
 could optimize some functions further with ARM SIMD if they would be 
 floats. Is there any objection to make them float if the change would 
 have no other side effects except some rounding because of the lower 
 precision?
 
 Regards,
 Zoltan
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


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

Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

[Olmstead, Don]

Subtraction of two points should not equate to a size. That's would be 
unexpected behavior for anyone used to working in 2D space. Mathematically 
speaking point - point equates to a vector. When writing a vector math library 
there typically isn't a differentiation made between a point and a vector, 
mainly because there's a lot of code overlap between the two. However when they 
do for 3D values a point is x, y, z, 1 while a vector is x, y, z, 0.

On a somewhat unrelated note is there any interest in getting a SIMD 
implementation of these classes?

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ryosuke Niwa
Sent: Friday, January 04, 2013 12:19 AM
To: Steve Block
Cc: WebKit-Dev Development
Subject: Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

On Thu, Jan 3, 2013 at 10:32 PM, Steve Block 
stevebl...@chromium.orgmailto:stevebl...@chromium.org wrote:
 I find point - point = size quite useful in general, and it seems to make 
 logical sense.
I agree that it makes logical sense, but I think that 'point - point =
point' also makes sense, and is perhaps more frequently the right
choice.

 What would you call this type, avoiding confusion with Vector?
I guess 'Offset' is an obvious candidate, but that is probably already
too overloaded. Perhaps RelativePosition or RelativePoint?

I don't think Relative adds any value here.

Also, the word position is used to represent a tree-position in DOM in WebKit 
so please don't use that to represent a point in a screen or a layout 
coordinate system.

I don't like offset either because it's such an overloaded word. e.g. 
offset is often used to mean a child node index in DOM.

- R. Niwa

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

[webkit-dev] WinCairo Maintainers

[Olmstead, Don]

I was wondering who was in charge of WinCairo now. We at Sony have been using 
WinCairo to land anything that isn't specific to our own internal port but we 
don't have any intention to ship anything using it.

We have some outstanding patches for the GitHub requirements repository, 
https://github.com/peavo/WinCairoRequirements, that perarne was running but he 
informed me that he will not be maintaining it going forward. I was thinking 
about making a WinCairo org on GitHub and then pushing the contents of that 
repo to it but I wanted to ask beforehand.

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

Re: [webkit-dev] WinCairo Maintainers

[Olmstead, Don]

@annulen I know you've mentioned conan.io before but I've never personally used 
it so I'm not sure how well it would fit with everything. It's something we can 
take a look at beforehand and see what it would take vs the single repository 
setup.

@alexchristensen I can make a GitHub org  push the repository to it and then 
start using GitHub releases to host the final binary.

Do either of you know of anyone who is shipping a product based on WinCairo 
though?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GPU rendering possibility

[Olmstead, Don]

We actually mentioned fastuidraw while we were at the contributors meeting as a 
potential replacement for our Cairo rendering for PlayStation. When we got to a 
point with our port where we can start evaluating we'd be interested in taking 
a look. The only problem I had with the setup was a reliance on boost, but 
maybe there are ways around it.

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Rogovin, Kevin
Sent: Wednesday, November 2, 2016 9:36 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] WebKit GPU rendering possibility


Hi,



I was directed here by some colleagues as this is the place to post the 
following to get started on the following proposal.



I have been working on an experimental 2D renderer that requires a GPU, the 
project is open sourced on github at https://github.com/01org/fastuidraw. I 
gave a talk at the X Developers Conference this year which can be seen from 
https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ .



I made a benchmark which makes heavy use of rotations and clipping and ported 
to SKIA, Qt's QPainter and Cairo. The benchmark and its ports are in the git 
repo linked above under the branch with_ports_of_painter-cells. It's 
performance advantage of FastUIDraw against the other renderers was quite 
severe (against Cairo and Qt's QPainter over 9 times and against SKIA about 5 
times faster).



I would like to explore the option of using FastUIDraw to implement a 
WebCore::GraphicsContext backend for the purpose of making drawing faster and 
more efficient on Intel devices that are equipped with a GPU. I also think that 
some minor modifications to WebKit's use of GraphicsContext will also give some 
benefits. I have worked on WebKit a few years ago and knew/know my way around 
the rendering code very well (atleast at that time).



Looking forward to collaboration,

-Kevin Rogovin

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

Re: [webkit-dev] WebKit build failed

[Olmstead, Don]

I can confirm that wincairo builds with the following revision 
https://trac.webkit.org/changeset/209809 on 64-bit

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Plamen Dimitrov
Sent: Wednesday, December 14, 2016 6:55 AM
To: youenn fablet 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] WebKit build failed

This is the log.

On Wed, Dec 14, 2016 at 4:40 PM, youenn fablet 
> wrote:
I guess you tried something like "./Tools/Scripts/build-webkit --release 
--wincairo" or "perl ./Tools/Scripts/build-webkit --release --wincairo"?

If so, can you provide the log?


Le mer. 14 déc. 2016 à 13:01, Plamen Dimitrov 
> a écrit :
OK. How to build webkit-wincairo correctly?

On Wed, Dec 14, 2016 at 11:40 AM, Konstantin Tokarev 
> wrote:


14.12.2016, 12:22, "Plamen Dimitrov" 
>:
> Hi all,
>
> if  WinCairo build is OK why I cann't build it?
>
> I've still cannot generated a lot of files.
> It seems that DerivedSources.make has not been invoked.

CMake build does not use DerivedSources.make

> How I can generate the files manually?  perl build-webkit --release 
> --wincairo not works for me the error is error C2672: 'std::invoke': no 
> matching overloaded function found"
> It is very important to build it today.

--
Regards,
Konstantin

___
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] WebCore/platform standalone library

[Olmstead, Don]

I was the one who did the WebCore::PAL namespace so I wanted to chime in on why 
I went that route. We at Sony are newcomers to pushing to trunk so my 
explanation might be entirely too idealistic but here goes.

I had thought of PAL as a library that is internal to WebCore that provides a 
clear porting layer. I would not expect anyone outside of WebCore to be linking 
to it. Because of that it was living inside Source/WebCore, and since it was 
setup that way having an internal namespace of WebCore::PAL made sense 
conceptually. Also in the future if PAL was successful I could see a WebKit2 
equivalent.

Whatever the consensus is we’re looking forward to working on getting the PAL 
layer up and running. We’re working on rebooting our port so we’re in a good 
position to help build it out and do any refactoring to help create a clear 
layering. Having a clear porting layer, especially one with tests, is something 
we’re hoping will be beneficial to all the ports.

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak
Sent: Wednesday, January 11, 2017 2:05 PM
To: Antti Koivisto 
Cc: Webkit Development List ; mrobin...@igalia.com
Subject: Re: [webkit-dev] WebCore/platform standalone library


These both sound right to me.

More generally, I would expect that over time, PAL would likely become a peer 
project to WebCore instead of being inside it, much the same way WTF started 
inside JavaScriptCore and eventually moved outside it in the source tree. In 
the WTF case, it always had a separate top-level namespace.

On Jan 11, 2017, at 12:27 PM, Antti Koivisto 
> wrote:

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
top-level namespace (even if it currently happens to live in the WebCore 
project)?

#include  would be more consistent with existing headers than 
.


  antti

On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield 
> wrote:
After 18 months of no progress, Don Olmstead and I are getting the band back 
together!

We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 which 
incorporates feedback from many different stakeholders (and as such, the 
direction is a little different than where I was going with this in the 
beginning).

First of all, this isn’t a new project; instead, it’s a new target inside the 
WebCore project. The target creates a static library which gets linked into 
WebCore, which means that the enforcement mechanism can’t be done by the 
linker. Instead, the layering will be enforced by a Python script, triggered as 
an extra build step, which checks the symbol names inside the .a file as well 
as #include directives in source code.

We opted for WebCore to include files using “#include ” instead of 
just including Foo.h. Similarly, we are putting symbols inside the PAL 
namespace, which is a child of the WebCore namespace. Therefore, inside 
WebCore, you use PAL things by specifying “PAL::Foo”.

The first thing to move into PAL is the “crypto” subfolder, which is a good 
candidate because it’s small, simple, yet also has platform-dependent 
implementations.

We would love your feedback on this approach to help make the dream a reality!

Thanks,
Myles and Don

On Mar 22, 2015, at 4:40 PM, Gavin Barraclough 
> wrote:

On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak 
> wrote:

Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
sometimes…)

+1


___
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] Buildbot 0.9

[Olmstead, Don]

There was a commit, https://trac.webkit.org/changeset/220139/webkit , 
referencing a Buildbot 0.9 dashboard. I'm wondering if we need to upgrade our 
setup to 0.9 and if so what the timeframe is for the upgrade.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Buildbot 0.9

[Olmstead, Don]

We’re running https://build.webkit.org/buildslaves/wincairo-2 . Its all in a 
docker container so its pretty painless to upgrade to 0.9 I’m just not sure 
when we should plan to do the work. So we could update our build slave to 0.9 
right now?

From: aakash_j...@apple.com [mailto:aakash_j...@apple.com]
Sent: Wednesday, August 2, 2017 12:26 PM
To: Olmstead, Don <don.olmst...@sony.com>
Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org) 
<webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] Buildbot 0.9

Hi Olmstead,

The commit adding buildbot 0.9 support is 
https://trac.webkit.org/changeset/220120. This is for bot watcher's dashboard 
http://build.webkit.org/dashboard/. The code now have support for both buildbot 
0.8 and 0.9. However, we might drop the support for buildbot 0.8 in near future 
(after we fix https://bugs.webkit.org/show_bug.cgi?id=175056).

I would be able to answer your question better if I know what kind of buildbot 
setup you are using. Is your setup using code from 
https://svn.webkit.org/repository/webkit/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/
 ?

Thanks
Aakash


On Aug 2, 2017, at 11:27 AM, Olmstead, Don 
<don.olmst...@sony.com<mailto:don.olmst...@sony.com>> wrote:

There was a commit, https://trac.webkit.org/changeset/220139/webkit , 
referencing a Buildbot 0.9 dashboard. I’m wondering if we need to upgrade our 
setup to 0.9 and if so what the timeframe is for the upgrade.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto: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] !!Tests for equality comparison

[Olmstead, Don]

I was looking at clang-tidy and include-what-you-need support in CMake. Clang 
currently won’t compile WebKit on Windows but I was going to look into that as 
well so those tools could end up running.

Happy to provide some patches if it bears fruit.

From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Maciej Stachowiak
Sent: Friday, April 28, 2017 1:11 PM
To: JF Bastien 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] !!Tests for equality comparison



Sent from my iPhone

On Apr 28, 2017, at 1:00 PM, JF Bastien 
> wrote:

On Apr 28, 2017, at 12:12, Maciej Stachowiak 
> wrote:


Here's some comments in the other direction:

- If there are times we recommend x != 0 instead of !x, it should maybe be 
based on whether the condition is better expressed as "not zero" or "false". In 
the numTestsForEqualityComparison, that's clearly a "not zero" check given the 
naming of the variable. This could be addressed by removing zero/non-zero from 
the list with true/false and null/non-null instead of making a carve-out based 
on type.

- Allowing both forms for zero/non-zero comparisons would be unfortunate. We 
have style guidelines to avoid tiny inconsistencies like this. So if the 
guideline changes, it should be to *require* == 0 or != 0 for numeric 
comparisons to 0, not merely allow it. Proliferating both styles would be sad.

- If we adopted the new rule, it would be slightly sad that a bunch of old code 
doesn't follow it. Changing it all at once would be needless churn, but we'll 
end up with a lot of code in both styles, partly defeating the consistency 
benefits of having a style guideline at all. This is sort of a general issue 
with any change to the coding style guidelines. If we change the guideline for 
a frequently used construct, the benefit has to be really high to account for 
the fact that we'll have many years of inconsistency. Note that the guidelines 
are mainly for the benefit of people reading the code, not writing, and 
inconsistent style may be worse than consistently using a slightly worse form.

- The style checker wouldn't be able to check the rule since it's not smart 
enough to tell if you are doing a null check, a false check or a zero check. (I 
am not sure if it enforces the current rule.)

That’s kind of a sad reason though. If we think it’s really worth it, we can 
move to a clang-based approach. It’ll definitely be way more powerful than 
regular expressions. I really liked how That Other Browser did 
this (hook 
into clang for extra diagnostics, and you also get rewriting tools for Free™).

I listed that reason last intentionally. I don't think it's the most important. 
That said, I like the idea of a smarter style checker based on clang.





I don't actually have a strong opinion on the substance of the rule, either 
version seems fine to me if we were starting from a blank slate. I'm not 
entirely sure why the rule ended up that way in the first place. But I wanted 
to note these as things to think about.

Regards,
Maciej


On Apr 28, 2017, at 1:00 AM, Keith Miller 
> wrote:

Is there any opposition to relaxing this rule? Speak now or forever hold your 
piece! (not really but I would be curious to hear opposition).

Cheers,
Keith

On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos 
> wrote:

El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:

Hello C++ fans!

The C++ style check currently say:
Tests for true/false, null/non-null, and zero/non-zero should all be
done without equality comparisons

I totally agree for booleans and pointers… but not for integers. I
know it’s pretty much the same thing, but I it takes me slightly
longer to process code like this:

int numTestsForEqualityComparison = 0:
// Count ‘em!
// …
if (!numTestsForEqualityComparison)
  printf(“Good job!”);

I read it as “if not number of tests for equality comparison”. That's
weird. It takes me every slightly longer to think about, and I’ve
gotten it wrong a bunch of times already. I’m not trying to check for
“notness", I’m trying to say “if there were zero tests for equality
comparison”, a.k.a.:

if (numTestsForEqualityComparison == 0)
  printf(“Good job!”);

So how about the C++ style let me just say that? I’m not suggesting
we advise using that style for integers everywhere, I’m just saying
it should be acceptable to check zero/non-zero using equality
comparison.

I agree, it's also quite confusing when using strcmp, because !strcmp
means the strings are equal. It's not only more difficult to read, I've
seen patches with wrong strcmp checks because of that.

I also think this could be solved by #defining a success a C call positive 
result that is 0 (e.g. CCallSuccess), regardless of the 

[webkit-dev] Intent to implement WebKit for Windows ports

[Olmstead, Don]

Hi WebKittens,

We over at Sony have been committing more resources to WebKit, from 
revitalizing the WinCairo port, rebooting the cURL network backend, and 
continued work on the PAL layer. We've had some developers looking at the 
possibility to move WinCairo from WebKitLegacy over to WebKit and they've made 
good progress so we'd like to begin contribution of a Windows implementation of 
WebKit. If landed we would enable this path for WinCairo and continue its 
development.

We wanted to start the discussion of adding back a Windows implementation 
before going any further with the work. We have a tracking bug for the work at 
https://bugs.webkit.org/show_bug.cgi?id=174003
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Olmstead, Don]

Web Audio is on the radar for WinCairo. I wasn't going to start working on it 
until after platform/audio ended up in PAL.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Konstantin Tokarev
Sent: Wednesday, August 2, 2017 2:44 AM
To: Ryosuke Niwa ; Adrien Destugues 
Cc: WebKit-Dev 
Subject: Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the 
flag?



02.08.2017, 09:19, "Ryosuke Niwa" :
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know 
>> we
>>  are not an upstream port anymore and have little chance of being 
>> again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and 
>> I
>>  do plan to implement some of these at some point. However, being 
>> able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then 
>> support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION, 
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they 
> all more or less require some external dependency (e.g. sqlite) and 
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge 
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you 
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia 
player" library, while ENABLE_WEB_AUDIO requires more advanced audio processing 
features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to 
real website which is not WebAudio demo but makes use of this API somehow?

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

--
Regards,
Konstantin
___
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] Python

[Olmstead, Don]

There are automated tools that will update to Python 3 while keeping 
compatibility with Python 2.

There is future, http://python-future.org/automatic_conversion.html,  and 
modernizer, https://python-modernize.readthedocs.io/en/latest 

This came up in https://bugs.webkit.org/show_bug.cgi?id=170439 and it seemed 
like 2/3 compatibility would be the ideal solution.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Michael Catanzaro
Sent: Monday, August 7, 2017 8:13 AM
To: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Python

On Mon, Aug 7, 2017 at 8:47 AM, Michael Catanzaro  wrote:
>  This has not really been a problem until now because none of Igalia's 
> developers use Arch, and occasional contributions rarely need to use 
> the Python scripts.

I stand corrected: we have one developer who has been using an elaborate local 
hack [1] to get WebKit's python scripts to work. Wow

[1]
https://wiki.archlinux.org/index.php/python#Dealing_with_version_problem_in_build_scripts

___
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] CSS Typed OM

[Olmstead, Don]

Hi,

I'd like to begin an implementation of CSS Typed OM (CSSOM) and wanted to gauge 
interest for supporting the feature.

CSSOM provides typed style access to improve performance by removing the need 
to do lots of string parsing. Its also the basis of other Houdini 
specifications so working through it will enable those specifications to be 
implemented.

If there's interest I can begin implementation after finishing up some 
outstanding patches. Any particular pointers on good places to begin are 
greatly appreciated as this is the first feature we here at Sony have attempted.

Thanks
Don

Spec:
https://drafts.css-houdini.org/css-typed-om/

WebKit Bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=175733
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Clang tidy

[Olmstead, Don]

I took some time today to see how clang-tidy can be run on WebKit code and 
opened https://bugs.webkit.org/show_bug.cgi?id=171632 with some examples on how 
to run things. I also attached some output from the modernizer fixes that can 
be applied.

I was thinking of running any code we move from WebCore/platform through 
clang-tidy during the process of moving it to PAL. Documentation for the checks 
can be found at http://clang.llvm.org/extra/clang-tidy/checks/list.html if 
anyone wants to take a look at what should potentially be run.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Olmstead, Don]

Same for our WinCairo bots which embed it into a Docker image, 
https://hub.docker.com/r/webkitdev/buildbot/.

The same images should be fine for AppleWin but it's not something I've tested.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Alex 
Christensen
Sent: Friday, June 23, 2017 1:56 PM
To: Michael Catanzaro 
Cc: webkit-...@lists.webkit.org; WebKit-Dev 
Subject: Re: [webkit-dev] update GCC version?

I’ve been using MSVC 2017 on my WinCairo bot for a while now and it builds 
fine.  It would take a bit to update our internal Windows infrastructure, but 
we should do that soon.


___
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] PAL Strategy

[Olmstead, Don]

Hey all,

As we mentioned during the contributors meeting we want to work towards 
fleshing out the PAL library. We have the cycles to really start rolling on it 
but are hitting some issues we wanted to run by the community.

Currently the obvious stuff to move over into PAL, network, graphics and text, 
has dependencies on some non-obvious stuff, such as FileSystem. We've also hit 
a couple cases, UUID and CPUTime, where they ended up moving into WTF while we 
were moving things into PAL.

We wanted to get the opinion of the community about a strategy going forward so 
we can get rolling on everything and land some patches. It would be good to 
identify any sort of general criteria for what goes in WTF and what goes into 
PAL.

At the moment I'm debating whether FileSystem and its related classes should go 
into WTF or PAL and am leaning more towards WTF at the moment so maybe that's 
something worth discussing.

Thanks for any feedback!
Don
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Olmstead, Don]

Did you happen to look at any sort of distributed build system? We use 
distributed builds here for WebKit and a full rebuild is pretty reasonable. 
That would negate the need to change how everything is done to get a unity 
build going.

From: webkit-dev 
[mailto:webkit-dev-bounces+don.olmstead=am.sony@lists.webkit.org] On Behalf 
Of Keith Miller
Sent: Monday, August 28, 2017 5:37 PM
To: WebKit Development Mailing List 
Subject: [webkit-dev] Growing tired of long build times? Check out this awesome 
new way to speed up your build... soon (HINT: It's not buying a new computer)

Hello fellow Webkittens,

Are you growing tired of long cat naps while waiting 45 minutes for WebKit to 
build? (I’ve definitely never done this 蘿!)
Do you want WebKit to build up to 3-4x faster on a clean build?*
Does seeing your incremental build… stay the same sound good?

You’ll be purring with excitement after you switch to unified source builds!**

* Building JSC with CMake, including CMake configuration time, went from ~8m15s 
to ~2m30s on my MBP using unified sources only on cpp files in JavaScriptCore. 
Final results on WebKit may vary. Using unified sources may cause sudden 
feelings of euphoria and productivity (or grumpiness from lack of naps…). Not 
responsible for any bugs in extra patches produced by using unified source 
builds (excluding build system related bugs) except where required by law 
(pi...@apple.com).

** Soon. Unified source builds haven’t been landed yet.

How are things going to change? Great question! Let’s find out!

When you fire off the build script it will automagically paw your source files 
into bundles. The size of each bundle is speculatively going to be 8 .cpp files 
but that’s up for experimentation. From my testing so far, the compile time for 
a bundle is at most 20% (~6s vs ~7s for the Air directory) longer than the 
longest file it includes. Given that most of the build time in incremental 
builds is scanning dependencies, this change is probably only barely noticeable.

Bundling happens as part of the CMake configuration process, in the CMake 
build. In the Xcode build it’s more complicated since we cannot dynamically 
choose the files we are going to compile. The only solution I know of is to 
pre-list a bunch of files for the build to dump files into. Occasionally, we’ll 
need to add more files to the build list.

When you add or remove a file in the project, the cost is higher. The current 
plan to bundle source files is by directory. This means that when a .cpp file 
is added or removed you will rebalance the bundles in its directory, and you 
will have to rebuild up to the full directory that file is in.

My goal is to make all of this invisible to developers as much as possible. I 
believe, for the most part, things should operate mostly as they have before. 
As the details on unified source builds get finalized, I’m sending out a 
separate email documenting any workflow changes. I’ll also do my best to answer 
any questions or concerns.

“But Keith, am I going to have to make major changes to the way I develop 
WebKit?” Yes and, hopefully, no. There is one major common workflow change that 
comes with unified sources, the naming of static variables and functions. Since 
C++ does not have a way to only declare a static function or variable in some 
restricted top level scope we are going to need to create some work around. The 
choice I’m thinking we’ll go with is to have an auto-generated macro value 
FILENAME, which is similar to __FILE__ except that it doesn’t have file 
extension (We can’t use FILE since that’s actually a type in C ). This macro 
would be redefined in the unified source directly above the file that is about 
to be included. Then in each cpp file that has static functions/variables 
developers would have:

namespace FILENAME {
static int myVariable { 0 };
static int myFunction() { return myVariable; }
}

The advantage of using a macro over textually writing the filename is that it 
makes code more portable between files. Also, once people get used to the 
concept of FILENAME in the code base it will, hopefully become obvious what it 
means. The main downside to this is using FILENAME in a header would give you 
whatever cpp file first included you (if only we got the compiler magic of 
__FILE__...). We would probably need to prohibit using FILENAME in .h files. 
Unfortunately, you cannot "using FILENAME;” because it will export all the 
values in each subsequent namespace. e.g.

namespace JSC {
namespace Foo {
static int myVar { 0 };
}
using Foo;
}

namespace JSC {
namespace Bar {
static int myVar { 0 };
}
using Bar;
}

does not compile.

Does anyone have other name recommendations for the macro name other than 
FILENAME? I went with file name since it describes what the substituted value 
will be the best, which is helpful for 

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Olmstead, Don]

Sure but in a corporate environment it can be a really big win. All of our 
developers have their machines hooked up to the distributed build system and we 
also have servers hanging out that can be used in the build. This sort of thing 
doesn't require anyone to change how they write their code which is something a 
unity build ends up requiring.

In terms of WebKit development the only places it falls apart are in the source 
code generation and the link.

Really I was just curious if anything like that was discussed because all of 
this requires pretty big changes to source code. Additionally there's other fun 
things that can happen around includes when doing a unity build where a file 
will stop being able to be built in isolation. The same thing has happened with 
WebCorePrefix where a number of files can't be built without it.

-Original Message-
From: Konstantin Tokarev [mailto:annu...@yandex.ru] 
Sent: Tuesday, August 29, 2017 11:22 AM
To: Olmstead, Don <don.olmst...@sony.com>; Keith Miller 
<keith_mil...@apple.com>; WebKit Development Mailing List 
<webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] Growing tired of long build times? Check out this 
awesome new way to speed up your build... soon (HINT: It's not buying a new 
computer)



29.08.2017, 21:19, "Olmstead, Don" <don.olmst...@sony.com>:
> Did you happen to look at any sort of distributed build system? We use 
> distributed builds here for WebKit and a full rebuild is pretty reasonable. 
> That would negate the need to change how everything is done to get a unity 
> build going.

This isn't helpful for contributors who have only one machine at their disposal

>
> From: webkit-dev 
> [mailto:webkit-dev-bounces+don.olmstead=am.sony@lists.webkit.org] On 
> Behalf Of Keith Miller
> Sent: Monday, August 28, 2017 5:37 PM
> To: WebKit Development Mailing List <webkit-dev@lists.webkit.org>
> Subject: [webkit-dev] Growing tired of long build times? Check out this 
> awesome new way to speed up your build... soon (HINT: It's not buying a new 
> computer)
>
> Hello fellow Webkittens,
>
> Are you growing tired of long cat naps while waiting 45 minutes for WebKit to 
> build? (I’ve definitely never done this 蘿!)
>
> Do you want WebKit to build up to 3-4x faster on a clean build?*
>
> Does seeing your incremental build… stay the same sound good?
>
> You’ll be purring with excitement after you switch to unified source builds!**
>
> * Building JSC with CMake, including CMake configuration time, went from 
> ~8m15s to ~2m30s on my MBP using unified sources only on cpp files in 
> JavaScriptCore. Final results on WebKit may vary. Using unified sources may 
> cause sudden feelings of euphoria and productivity (or grumpiness from lack 
> of naps…). Not responsible for any bugs in extra patches produced by using 
> unified source builds (excluding build system related bugs) except where 
> required by law (pi...@apple.com).
>
> ** Soon. Unified source builds haven’t been landed yet.
>
> How are things going to change? Great question! Let’s find out!
>
> When you fire off the build script it will automagically paw your source 
> files into bundles. The size of each bundle is speculatively going to be 8 
> .cpp files but that’s up for experimentation. From my testing so far, the 
> compile time for a bundle is at most 20% (~6s vs ~7s for the Air directory) 
> longer than the longest file it includes. Given that most of the build time 
> in incremental builds is scanning dependencies, this change is probably only 
> barely noticeable.
>
> Bundling happens as part of the CMake configuration process, in the CMake 
> build. In the Xcode build it’s more complicated since we cannot dynamically 
> choose the files we are going to compile. The only solution I know of is to 
> pre-list a bunch of files for the build to dump files into. Occasionally, 
> we’ll need to add more files to the build list.
>
> When you add or remove a file in the project, the cost is higher. The current 
> plan to bundle source files is by directory. This means that when a .cpp file 
> is added or removed you will rebalance the bundles in its directory, and you 
> will have to rebuild up to the full directory that file is in.
>
> My goal is to make all of this invisible to developers as much as possible. I 
> believe, for the most part, things should operate mostly as they have before. 
> As the details on unified source builds get finalized, I’m sending out a 
> separate email documenting any workflow changes. I’ll also do my best to 
> answer any questions or concerns.
>
> “But Keith, am I going to have to make major changes to the way I develop 
> WebKit?” Yes and, hopefully, no. There is one major common workflow change 
> that comes 

[webkit-dev] WinCairo Update

[Olmstead, Don]

Hello WebKittens,

I wanted to give an update on the status of WinCairo to the group as we've hit 
a few good milestones.

WebKitForWindows Github organization

We went ahead and created a WebKitForWindows organization on Github at 
https://github.com/WebKitForWindows where we will be working out of. This has 
the WinCairoRequirements and tooling around building WinCairo. The hope is this 
makes things easier for third-parties building WinCairo.

We'll also be using it to experiment with a way to update ANGLE on a more 
regular cadence.

WinCairoRequirements is up to date

The previous incarnation of WinCairoRequirements run by Per Arne hadn't been 
updated in over a year and a half. Now all the requirements are up to date 
except for ICU. The thing holding us back from updating ICU to 60 is the 
dependency on CFLite. This is something we want to get rid of completely but 
have not exorcised the CF code from WebKitLegacy. After that we'll be doing the 
work to get ICU 60+ working on Windows.

WinCairoRequirements also got a few additions. We've added nghttp2 and have 
been compiling cURL with it to get support for HTTP2. The work to enable it 
will be ongoing. We've also added WebP and will be enabling that shortly.

Windows Docker images for development

Internally we've been big proponents of using Docker for our CI/CD workflows. 
With Windows gaining support for that we took a stab at creating Docker images 
for WebKit development.

We have images that contain all the tools for WebKit, Perl, Python, etc, and 
also Visual Studio 2017 build tools. You can build WinCairo completely in a 
Docker container for your own development using these images. It should also be 
able to build AppleWin.

Additionally we have images for Buildbots and EWS.

EWS is live!

As Aakash mentioned in a previous message WinCairo now has an EWS for release 
builds. Currently we have 5 bots running which seems to be successful thus far. 
Our bots are doing builds within Windows Docker containers so we can easily 
scale out further as needed.

We ask that you respect the EWS as much as possible when landing your patches. 
We made it a point to prioritize the work because there were a number of times 
when we would have to fix the build after our buildbots determined there was an 
error.

WebKit(2) development

Windows on WebKit(2) is still ongoing. We still have a lot of patches to land 
there. After we can build it we'll introduce a Buildbot and EWS for it to make 
sure things stay working.

Visual Studio 2017

All our bots and all our developers are using VS2017 so we are all for 
deprecating VS2015 whenever Apple's build structure is ready.

That's about it for now. If you have any questions or comments let us know.

Thank you for all the assistance in getting this far!

Sony's WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WinCairo Build and EWS down

[Olmstead, Don]

EWS and Buildbots are back up for WinCairo and are successfully building. If 
there are any problems let me know! Apologies for the downtime.

From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Olmstead, Don
Sent: Friday, December 1, 2017 5:32 PM
To: WebKit-Dev Development (webkit-dev@lists.webkit.org) 
<webkit-dev@lists.webkit.org>
Subject: [webkit-dev] WinCairo Build and EWS down

Hi WebKittens,

We're having an issue with the Buildbot and EWS after the ANGLE update. Our 
image does not contain the DirectX 11 SDK that is now wanted by ANGLE. I spent 
my day trying to get the required SDK into the image and have been having 
issues with it so I was not able to spin up the infrastructure again.

I'll get it back as soon as I can but for the moment feel free to ignore any 
WinCairo EWS issues. I'll hopefully have things fixed early next week and let 
the group know.

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

Re: [webkit-dev] Proposal: Do not support Windows fibers

[Olmstead, Don]

We’re fine with removing it.

From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Geoffrey Garen
Sent: Tuesday, December 5, 2017 2:35 PM
To: Michael Saboff 
Cc: John N. Lehner ; WebKit-Dev 
Subject: Re: [webkit-dev] Proposal: Do not support Windows fibers

If our Windows clients are cool with it, I think we should remove support for 
fibers.

I don’t think our current implementation works super well with fibers. It is 
best not to include half-working code in the tree.

Geoff


On Dec 5, 2017, at 11:19 AM, Michael Saboff 
> wrote:

Here is the reply from iTunes for the WebKit-Dev list

- Michael

——

From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
API support.

iTunes still uses some cooperative threading, but implements its own mechanism 
on top of regular preemptive Windows threads. And we believe we've fixed all 
occurrences of calling WebKit/JSC from our non-main cooperative threads.

- John


On Dec 5, 2017, at 10:26 AM, Michael Saboff 
> wrote:

[Bringing John Lehner from the iTunes team into the discussion]

Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
into WebKit/JSC only has one fiber, other parts of the app use multiple fibers 
on one thread but don’t have JS objects active in those threads / fibers.

John, have things changed for iTunes on Windows such that we can eliminate 
support for fibers?

- Michael


On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa 
> wrote:

Yeah, I don't think there is much need to support fibers. With features like 
web workers, supporting fibers doesn't make much sense.

- R. Niwa

On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI 
> wrote:
Hi, Webkittens,

I would like to make sure OR declare that WebKit does not support Windows 
fibers.
While fiber related functions are used in WTF, I believe that it is because 
fiber local storage (FLS) can have destructors. And it is not intended to 
support fibers explicitly.

Actually, I believe the current WebKit does not work well with Windows fibers 
right now.
For example, our JSC GC is conservative for stack and registers. It means that 
GC needs to scan stack and registers to gather conservative roots. But if your 
fiber is not executed at that time, JSC GC will miss to scan the stack and 
registers of those inactive fibers. As a result, managed objects will be 
collected if it is only referenced from the roots in the inactive fibers.

And I think we can potentially improve performance of our TLS by using 
thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
causes some problems[1]. I'm not sure the performance characteristics and 
implementation details of thread_local in VC++, but it's worth checking.

So, I think we should not support Windows fibers. I would like to hear opinions 
about it.

[1]: https://bugs.webkit.org/show_bug.cgi?id=146448

Best regards,
Yusuke Suzuki

___
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

[webkit-dev] WinCairo Build and EWS down

[Olmstead, Don]

Hi WebKittens,

We're having an issue with the Buildbot and EWS after the ANGLE update. Our 
image does not contain the DirectX 11 SDK that is now wanted by ANGLE. I spent 
my day trying to get the required SDK into the image and have been having 
issues with it so I was not able to spin up the infrastructure again.

I'll get it back as soon as I can but for the moment feel free to ignore any 
WinCairo EWS issues. I'll hopefully have things fixed early next week and let 
the group know.

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

Re: [webkit-dev] Introducing a minimum ICU version for WebKit

[Olmstead, Don]

Hi Michael,

There are a couple problems with checking in a version of ICU.

* Other libraries used by WebKit have dependencies on ICU. For our ports 
harfbuzz, libxml2, libxslt, libpsl and CFlite all require ICU.
* ICU doesn't come with a CMake build system and its non-trivial to make one. 
We've largely used this https://github.com/LibCMaker/ICU_CMake_Files to handle 
building ICU but its use is also why ICU is the library we aren't able to 
update on a regular cadence.
* We aren't terribly good with updating things in ThirdParty. Sometimes this is 
because there aren't releases, see gtest. Others because they don't actually 
have releases, see ANGLE. On top of that there might be local modifications to 
make things work within WebKit.

Could you possibly give some overview of how WebKit is packaged by Linux 
distributions? I would have thought they would use flatpack/jhbuild to get the 
dependencies that the WPE/GTK ports are using especially if those dependencies 
have their own set of bug and security fixes. My experience with Linux is 
minimal so some context here would be appreciated.

For our ports we use vcpkg to build and manage dependencies. We host it at 
https://github.com/WebKitForWindows/WebKitRequirements and have an internal 
fork for PlayStation. I'm guessing it's probably similar to flatpack/jhbuild in 
terms of functionality but in our case we just use GitHub releases to have 
binaries ready.

Perhaps there are better ways for us to approach the requirements that would be 
beneficial to all ports?

-Original Message-
From: webkit-dev  On Behalf Of Michael 
Catanzaro
Sent: Thursday, April 9, 2020 10:32 AM
To: Kirsling, Ross 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Introducing a minimum ICU version for WebKit


Any objections to uploading a bundled ICU 60 under Source/ThirdParty?

Seems easier than forcing downstreams to work out bundling themselves. 
Most major distros will just stop providing WebKit security updates if we don't 
bundle it for them. E.g. this is sure to kill Ubuntu's current long streak of 
providing our updates to Ubuntu 16.04.


___
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] Deployment of new EWS Non-Unified builder

[Olmstead, Don via webkit-dev]

I agree with everything Mark said in his reply I just wanted to add another 
benefit of having a non-unified build specifically to support build time 
optimization.

> > 2) In my contributions, I don’t just want to add missing includes, I want 
> > to remove unnecessary ones taking full advantage of forward declarations 
> > and moving code out of headers. Too many includes and too much dependency 
> > has a dramatic bad effect on the project, making colossal project build 
> > times even worse.

> I too try to do this when writing my patches.  I would argue that a 
> non-unified EWS gives me greater confidence that a forward declaration is 
> sufficient, and that I’m not just mistakenly thinking that it is only because 
> some other file in the same unified unit also happen to include the header.  
> So, again, a non-unified EWS is helping here.
 
If we wanted to try any tooling around identifying when an include or forward 
declaration should be used we need a functioning non-unified build. We could 
try IWYU on the codebase, 
https://github.com/include-what-you-use/include-what-you-use , and see what 
happens.

There's also tools for analyzing where the build is spending its time. For 
Clang users the ClangBuildAnalyzer could be used, 
https://github.com/aras-p/ClangBuildAnalyzer . For Visual Studio a project that 
looks interesting is CompileScore, https://github.com/Viladoman/CompileScore .
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Olmstead, Don via webkit-dev]

If it isn’t it should be considering how many times I’ve had a cq- come from an 
AppleWin build that is in no way affected by my patch.

From: Geoffrey Garen via webkit-dev 
Sent: Monday, June 6, 2022 10:40 AM
To: Mark Lam 
Cc: Darin Adler ; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder

As such, I also think that the non-unified EWS being green should not be a 
blocker to landing a patch. But I think having it there for information will 
help the situation. At minimum, even if every engineer simply ignores the 
non-unified EWS, it also makes it easier for someone trying to fix a trim 
missing include build issue to scan through PRs to look for this EWS failure in 
order to narrow down on which patches (and therefore possible includes) to 
focus on.

Is this the proposal on the table — to have an EWS bot, but also not block 
patches on it?

That’s surprising to me, and not how EWS bots usually work. If we just want an 
optional record of where a particular build configuration started failing, 
Isn’t that just… a not-EWS bot?

Thanks,
Geoff

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