Re: [webkit-dev] Request for Position on URLPattern

[Ben Kelly via webkit-dev]

FYI, there is now an intent-to-ship [0] for this feature in chromium.

[0]:
https://groups.google.com/a/chromium.org/g/blink-dev/c/-T5pJtBO8h4/m/cAkpQec1AwAJ

On Fri, Aug 13, 2021 at 4:19 PM Ben Kelly  wrote:

> Hello,
>
> I would like to request an official WebKit position on URLPattern [0].
> This is a web API for matching against URLs which is often done in
> javascript routing systems.  We also intend to use this same matching
> primitive in future changes to service worker scopes.  This larger set of
> use cases is described in the explainer. [1]  This particular request,
> however, is just for the URLPattern API and does not yet touch service
> workers.
>
> URLPattern was discussed in a couple of past TPAC meetings:
>
> * TPAC 2019 [2]
> * TPAC 2020 Video Call [3]
>
> In case it's helpful, we also have a summary of web developer feedback
> we've received so far. [4]
>
> Thank you.
>
> Ben
>
> [0]: https://wicg.github.io/urlpattern
> [1]: https://github.com/WICG/urlpattern/blob/main/explainer.md
> [2]:
> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.d6e4ecicreet
> [3]: https://github.com/w3c/ServiceWorker/issues/1535
> [4]: https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for Position on URLPattern

[Ben Kelly via webkit-dev]

Hello,

I would like to request an official WebKit position on URLPattern [0].
This is a web API for matching against URLs which is often done in
javascript routing systems.  We also intend to use this same matching
primitive in future changes to service worker scopes.  This larger set of
use cases is described in the explainer. [1]  This particular request,
however, is just for the URLPattern API and does not yet touch service
workers.

URLPattern was discussed in a couple of past TPAC meetings:

* TPAC 2019 [2]
* TPAC 2020 Video Call [3]

In case it's helpful, we also have a summary of web developer feedback
we've received so far. [4]

Thank you.

Ben

[0]: https://wicg.github.io/urlpattern
[1]: https://github.com/WICG/urlpattern/blob/main/explainer.md
[2]:
https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.d6e4ecicreet
[3]: https://github.com/w3c/ServiceWorker/issues/1535
[4]: https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md
___
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)

[Ben Kelly]

On Tue, Aug 29, 2017 at 12:10 PM, Chris Dumez  wrote:

> I worry about adopting unity build because while it makes clean builds
> faster, it also slows down incremental builds. As a developer, I rarely do
> clean builds, I mostly do incremental builds so this would likely make my
> experience worse?
> Unity builds also require a lot of code churn to resolve naming conflicts
> and the resulting code does not look as nice.
>

Just to add a data point, the full build time is currently a bit of a
barrier to contributing to the project casually.  If I decided to try to
work on webkit one night I often ended up updating my tree and building,
but not having time for much else.  Even for simple patches this became a
problem for me.  If unified builds cut the full build time by 75% that
could be quite helpful for casual contributors.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Ben Kelly]

On Sat, May 13, 2017 at 8:55 PM, Michael[tm] Smith  wrote:

> Anne van Kesteren , 2017-05-13 06:20 +0200:
> >
> > On Fri, May 12, 2017 at 11:49 PM, Maciej Stachowiak 
> wrote:
> > > It seems like there's two unusual things about WPT:
> > > - At least according to Alexey, WPT tests are somewhat prone to
> flakiness in Safari.
> >
> > Although they haven't always been working perfectly, changes to
> > web-platform-tests run through some kind of stability check in both
> > Chrome and Firefox (run the new tests 10 times and fail if the results
> > are inconsistent). Ideally Safari is added to that mix, though I think
> > the last time folks looked into that it wasn't possible for some
> > reason. That might be something to put some resources on.
>
> I think we already have that now un-blocked and we will by the end of this
> week
> (May 19) start having Travis running the stability checker for Safari too
> (and
> Edge too) and providing the results as comments to PRs (just as we now do
> for Chrome and Firefox).
>

FWIW safari results are now showing up:

https://github.com/w3c/web-platform-tests/pull/5921#issuecomment-301517865
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Ben Kelly]

On Fri, May 12, 2017 at 2:26 PM, Rick Byers  wrote:

> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov 
> wrote:
>
>> Since imported WPT tests are very flaky, and are not necessarily written
>> to defend against important regressions, investigating issues with them is
>> relatively lower priority than investigating issues observed with WebKit
>> tests. So I would recommend not mixing tests for WebKit regressions with
>> WPT tests - if your test eventually ends up in LayoutTests/imported, it
>> will become a lot less effective.
>>
>
> FWIW this is absolutely NOT how we're treating this in chromium.  If this
> is how things end up in practice then we will have failed massively in this
> effort.
>
> We figure if we want the web to behave consistently, we really have no
> choice but to treat web-platform-tests as first class with all the
> discipline we give to our own tests.  As such we are actively moving
>  many of our LayoutTests to
> web-platform-tests and depending entirely on the regression prevention they
> provide us from there.  Obviously there will be hiccups, but because our
> product quality will depend on web-platform-tests being an effective and
> non-flaky testsuite (and because we're starting to require most new
> features have web-platform-tests before they ship), I'm confident that
> we've got the incentives in place to lead to constant ratcheting up the
> engineering discipline and quality of the test suite.
>

FWIW, mozilla also treats WPT as first class tests.  We're not actively
moving old tests to WPT like google, but all new tests (at least in DOM)
are being written in WPT.  Of course, we do have exceptions for some tests
that require gecko-specific features (forcing GC, etc).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ccache on mac

[Ben Kelly]

On Mon, May 8, 2017 at 10:25 AM, Alex Christensen 
wrote:

> It would be nice if we could just get the CMake built WebKit working with
> run-safari and run-webkit-tests.  That’s something I’ve been meaning to do
> for a while but haven’t gotten around to it.  Something is wrong with the
> xpc service locations and plists, but I think everything else should be ok
> since run-minibrowser works fine with WebKit1.  Let me know if you want to
> help out with this approach and I’ll give you more details
>

Ah, ok.  It wasn't obvious to me what was fully or partially supported.
Unfortunately I don't think I'll have time to work on the build system.  I
want to try to focus on web facing stuff if I can.

For the time being I worked around the issue with a few scripts using the
xcode build:

A clang wrapper like this:

#!/bin/bash
export CCACHE_CPP2=true
_xcode_path=`/usr/bin/xcode-select -p`
_xcode_clang="${_xcode_path}/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
exec /usr/local/bin/ccache "$_xcode_clang" "$@"

And then a build-webkit wrapper to pass them on the command line:

#!/bin/bash
build-webkit CC="/srv/bin/ccache-clang" CXX="/srv/bin/ccache-clang++" "$@"

Seems to be working.  I didn't realize before I could just pass CC/CXX on
the command line like this.

I guess I'll have to make this smarter or have separate scripts if I want
to build for ios or the simulator.

Anyway, just thought I would post that in case anyone else ran into the
same problem.

Thanks.

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

Re: [webkit-dev] ccache on mac

[Ben Kelly]

On Mon, May 8, 2017 at 12:32 AM, youenn fablet <youe...@gmail.com> wrote:

> I had this setup working a year or so ago. I was using the regular Mac
> "make" build.
>
> Le dim. 7 mai 2017 à 19:28, Ben Kelly <b...@wanderview.com> a écrit :
>
>> Hi all,
>>
>> Does anyone have ccache (or an equivalent) working with local webkit
>> builds on mac?  I've spent the last couple of days trying to figure out,
>> but have not had much luck.
>>
>> I've installed ccache via homebrew and its in my path.
>>
>
> Did the same. I had to ensure clang used by Xcode was the ccache proxy.
> Don't remember whether just setting CC/CXX in the command line works.
> When running make, you can see which clang is used.
> Maybe setting CC/CXX in Source/WebCore/Configurations/Base.xcconfig would
> do the trick (for WebCore).
>

I guess I'm hesitant to fiddle with Base.xcconfig because I don't want to
accidentally include those changes in patches, etc.

What is the syntax for overriding CC/CXX on the command line with
build-webkit?  (Or for the make build, although its unclear how to
configure that.)

I guess I was also hoping there was some way to specify a
'user-override.xcconfig' that the webkit build would try to pull-in
automatically where this stuff could be set.

Thanks.

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

[webkit-dev] ccache on mac

[Ben Kelly]

Hi all,

Does anyone have ccache (or an equivalent) working with local webkit builds
on mac?  I've spent the last couple of days trying to figure out, but have
not had much luck.

I've installed ccache via homebrew and its in my path.

I *do* see ccache being used if I do a `webkit-build --cmake`, but I can't
use run-safari or run-webkit-tests with a cmake build.  I get an error like:

  Can't find built framework at
"/srv/WebKit/WebKitBuild/dev/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore".

If I do a non-cmake build I can successfully use run-safari and
run-webkit-tests, but it appears ccache is not used.  It looks like its
going through the xcode CLI tools.  I've searched for how to configure
xcode to use ccache, but everything suggests I need to hand modify the
project xcconfig.

Can anyone recommend a good way to get local builds that work with
run-safari/run-webkit-tests and that use ccache?

(FWIW, the main reason I want ccache is that touching any idl file appears
to trigger a rebuild of most of WebCore.)

Thanks!

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