Re: [webkit-dev] Removal of trailing whitespace

[Adrian Perez de Castro via webkit-dev]

Hi,

On Wed, 12 Apr 2023 10:23:06 -0700 Ryosuke Niwa via webkit-dev 
 wrote:

> Yeah, enforcing that new or otherwise modified lines don’t have trailing
> whitespaces would be good.

I very much agree with this. Let's leave existing code as-is, having new and
modified lines without trailing whitespace. It's nice to avoid trailing
whitespace, but better not at the cost of littering diffs with unrelated
changes that only touch whitespace.


Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removal of trailing whitespace

[Adrian Perez de Castro via webkit-dev]

Hi,

On Wed, 12 Apr 2023 20:27:25 -0500 Michael Catanzaro via webkit-dev 
 wrote:
> On Thu, Apr 13 2023 at 08:15:00 AM +0900, Tetsuharu Ohzeki via 
> webkit-dev  wrote:
>
> > To digress a little, why does webkit now use a style checker based on 
> > python script instead of clang-format?
> > In today, I feel it's more reasonable to use such a formetter.
> 
> We've tried clang-format in several GNOME projects with not great 
> results. I'd recommend uncrustify instead.

That may have been the case because the conventions used for code style
in GLib/GObject-adjacent projects is quite peculiar, and uncrustify allows
for a bit more tweaking than clang-format (and even so I have seen some
projects use additional scripts for the API headers, which have their own
set of indentation challenges!). OTOH, clang-format supports the WebKit
C++ coding conventions out of the box (“clang-format --style=WebKit”).

> Still, I'm not sure it's a good idea for WebKit. I'm sure we could make 
> either tool work, but we'd have to be very lax with any configuration 
> we use, or it could get pretty annoying. And the existing style checker 
> works decently enough.

Personally, I do not care that much which particular style checker is
used, as long as there is a sanctioned style and some way of checking it.
The current style checker is fine, and supports more languages than C/C++
so in that regard it's better than clang-format.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Adrian Perez de Castro via webkit-dev]

Hi Laurence,

On Tue, 28 Mar 2023 18:57:48 -0500 Laurence Rowe via webkit-dev 
 wrote:
 
> So build-jsc without the —jsc-only works:
> 
> lrowe@Laurences-MacBook-Air WebKit %
> ./WebKitBuild/Release/JavaScriptCore.framework/Helpers/jsc
> 
> >>> print(1+1)
> 2
> 
> I was hoping to try and wrap the jsc-only build into a rust crate since the
> existing rust wrappers either include gtk dependencies or only wrap the
> lower level api and link against the system libraries. Though it is looking
> like I lack the C++ build experience to pull that off!

In the case of the WebKit GTK port, there is a “libjavascriptcoregtk-X.Y”
(where X.Y is the API level) that you can link to without pulling in the
GTK librariesa. For example on my Linux box this is what pkg-config will
bring in for linking:

  % pkg-config javascriptcoregtk-4.1 --libs
  -ljavascriptcoregtk-4.1 -lgobject-2.0 -lglib-2.0
  %

Note how there is no GUI libraries there at all. If existing Rust wrappers
are linking also the rest of the GTK libraries, probably they are using the
“webkit2gtk-X.Y” pkg-config module instead. That sounds like a bug in how
the Rust crates are being built and linked.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Documentation

[Adrian Perez de Castro via webkit-dev]

Hi all,

On Thu, 09 Mar 2023 10:48:27 -0800 Brandon Stewart via webkit-dev 
 wrote:
 
> Sorry for the delay on the documentation update.
> For getting the documentation system online, we were trying to settle on a 
> subdomain.

Looking forward to have the documentation online ^_^
 
> What would people prefer we use as the official documentation location:
> (1) docs.webkit.org
> (2) developer.webkit.org
> (3) documentation.webkit.org
> (4) Other
> 
> Could you please reply to this e-mail indicating which origin you would 
> prefer?

One vote more for (1) because it's shorter top type, but (3) could do as well.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

Hi list,

On Thu, 08 Sep 2022 02:27:53 + Alexey Proskuryakov via webkit-dev 
 wrote:
> Ross, I didn't mean any disrespect.
 
> I absolutely agree that this issue is not about the project supporting
> multiple platforms.
 
> What I disagree with is the statement that omitting includes necessary for
> non-unified build is a mistake, or that it needs to be made visible. Fixing
> all of these is very time consuming, whether it's done pre- or post-commit.
> In my mind, it is a logical conclusion that this shouldn't be done at all,
> neither pre- nor post-commit. The downside is that patches are more likely
> to break the build, but overall it's less work, because only a small
> percentage of "missing" includes will ever cause problems. So, ignoring
> non-unified build saves work over time, and saves the 6 days per month that
> its maintenance has been costing.
> 
> Perhaps that's incorrect, and the cost situation is the opposite? So that
> ignoring non-unified builds is costlier overall? It is a real cost, in
> particular because it sometimes requires fixing issues in unfamiliar code,
> but that cost hasn't been quantified AFAICT.

My personal experience is that building locally with non-unified builds while
working on making a patch practically does not add any overhead -- most of the
time I always work with non-unified builds.

What takes more time is to fix the non-unified build caused by other people's
patches if the non-unified build has been broken since the last time I pulled
from the repository. More precisely: sometimes it takes a lot of time, and
often it does not take much to fix the build itself; but even for the simple
ones having to write commit logs, waiting for the EWS, and then some more
time while commit-queue does its thing easily adds 30 to 40 minutes before
I can go on with what I initially planned to work on.

> In other words, the choices are:
> 
> With non-unified EWS:
> - many patches get rejected for breaking it;
> - it's easy for the patch author to add the includes.

  - ensures that patches we land are as correct as possible

Patches rejected for breaking it are patches which are technically wrong. I am
sure we all agree that unified builds are a clever, but disgusting workaround
to speed up builds. If went back to 2017 for a moment, when we did not have
unified builds [1], We would be rejecting these patches anyway, because they
do break the build. And nobody would disagree.

> Without non-unified EWS, or anyone fixing non-unified build manually:
> - a smaller number of patches gets rejected for breaking existing EWS 
> builders;
> - it's sometimes harder to fix, because the errors could be in unfamiliar 
> code (although how hard can it be to add an include, on average).

Not fixing the build ever would not work. If we don't land patches which are
technically correct there will be always situations in which the build will
randomly break.

Example: Buildbot (both EWS and post-commit) build with DEVELOPER_MODE=ON and
ENABLE_EXPERIMENTAL_FEATURES=ON, while end user builds disable those. The
changed options can result in shifted sources in the unified build compilation
units. What passes as "yeah, it builds" in the bots could still fail later
when producing releases. This applies to *all* ports.

> Without non-unified EWS, but someone fixes non-unified build manually:
> - an even smaller number of patches gets rejected due to missing includes;
> - it's a huge investment on the part of those who keep fixing the non-unified 
> build.

Cheers,
—Adrián

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



signature.asc
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

Hi Michael,

On Wed, 07 Sep 2022 12:41:00 -0500 Michael Catanzaro via webkit-dev 
 wrote:
> On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro 
>  wrote:
> > I would go even further and consider enabling unified builds only in 
> > DEVELOPER_MODE (for CMake ports). For non-developer builds, 
> > compilation time is much less important than limiting RAM usage to 
> > reasonable levels. Using ninja's default parallelization level, I 
> > recently started hitting OOM failures even on a machine with 64 GB 
> > RAM! We have many people complaining that they cannot build on more 
> > normal machines with 16 GB RAM. If we have an EWS to ensure the 
> > non-unified build actually works, then it should be safe enough to 
> > make it the normal supported path for non-developers, rather than 
> > just a "best effort, let's hope it works today" thing.
> 
> I withdraw this proposal.
> 
> I thought that non-unified builds would significantly reduce peak RAM 
> usage, but I was wrong [...]

The main reason for having working non-unified builds has never been memory
usage. I would expect that with a reasonable linker memory usage is similar
because the amount of code, relocations, symbol resolutions, etc. to handle is
about the same. The main difference is file descriptor usage and that there
will be more debuginfo copies that the linker has to deduplicate in
non-unified mode--some linkers may handle that worse than others.

> [...] In fact, non-unified builds seem to require substantially more RAM at
> link time, perhaps because there are more object files to link together. On
> a desktop with 64 GB of RAM, I'm not able to link a non-unified build
> successfully without running out of RAM, but using a unified build it works
> fine. So my proposal was just totally off base.

My laptop has 20 GiB of memory and a debug build in non-unified mode links
just fine with either LLD or Mold (I haven't used the GNU linker for months).
Something smells fishy with your setup.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

Hi again,

On Fri, 02 Sep 2022 15:02:05 +0300 Adrian Perez de Castro  
wrote:

> I have picked this message from Ryosuke because I want to explicitly address
> a misjudged metric on the effort it takes to address non-unified build issues
> after patches that break them have landed -- but my comments apply to the
> discussion in general.
> 
> On Wed, 01 Jun 2022 16:39:39 -0700 Ryosuke Niwa via webkit-dev 
>  wrote:
> > On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev <
> > webkit-dev@lists.webkit.org> wrote:
> >
> > [...]
> > 
> > One day per month for one beginner sounds like a really low maintenance
> > cost compared to having every WebKit developer fix non-unified builds at
> > all times.
> 
> I have recorded at least 23 patches fixing non-unified builds in the last
> couple of weeks. Not all of them from Sony/Igalia folks. Assuming that each
> patch took around 1h to solve on average, this means we are investing a
> whopping *six days per month* fixing non-unified builds. Let me re-state
> that:
> 
>   We have collectively spent 1 out of every 4 weeks fixing build issues.

I forgot to add the list of patches I gathered. Here it is:

https://github.com/WebKit/WebKit/pull/3241
https://github.com/WebKit/WebKit/pull/3301
https://github.com/WebKit/WebKit/pull/3307
https://github.com/WebKit/WebKit/pull/3335
https://github.com/WebKit/WebKit/pull/3336
https://github.com/WebKit/WebKit/pull/3337
https://github.com/WebKit/WebKit/pull/3338
https://github.com/WebKit/WebKit/pull/3339
https://github.com/WebKit/WebKit/pull/3403
https://github.com/WebKit/WebKit/pull/3495
https://github.com/WebKit/WebKit/pull/3499
https://github.com/WebKit/WebKit/pull/3524
https://github.com/WebKit/WebKit/pull/3642
https://github.com/WebKit/WebKit/pull/3699
https://github.com/WebKit/WebKit/pull/3732
https://github.com/WebKit/WebKit/pull/3753
https://github.com/WebKit/WebKit/pull/3756
https://github.com/WebKit/WebKit/pull/3767
https://github.com/WebKit/WebKit/pull/3785
https://github.com/WebKit/WebKit/pull/3803
https://github.com/WebKit/WebKit/pull/3820
https://github.com/WebKit/WebKit/pull/3905
https://github.com/WebKit/WebKit/pull/3930

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

Hello,

I have picked this message from Ryosuke because I want to explicitly address
a misjudged metric on the effort it takes to address non-unified build issues
after patches that break them have landed -- but my comments apply to the
discussion in general.

On Wed, 01 Jun 2022 16:39:39 -0700 Ryosuke Niwa via webkit-dev 
 wrote:
> On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> 
> > I feel like this has been discussed adequately in the past, but one more
> > time for good measure:
> >
> > Any two platforms which don't build the exact same set of files will
> > undergo unification differently. That means that unification shifts are an
> > inherent part of working on WebKit, embedder or otherwise.
> >
> > The only way to be certain that includes are done correctly in a given
> > patch is to perform a non-unified build. This would be an unreasonable
> > burden for local development, but that's exactly why an EWS builder is
> > desirable.
> >
> > To have this appear like a non-issue is to ignore the work that Sony and
> > Igalia have continually performed through the 5(?) years since unified
> > builds were introduced. From experience, I know that it can take a person
> > about a day per month to clean up includes on behalf of the entire WebKit
> > community.
> 
> One day per month for one beginner sounds like a really low maintenance
> cost compared to having every WebKit developer fix non-unified builds at
> all times.

I have recorded at least 23 patches fixing non-unified builds in the last
couple of weeks. Not all of them from Sony/Igalia folks. Assuming that each
patch took around 1h to solve on average, this means we are investing a
whopping *six days per month* fixing non-unified builds. Let me re-state
that:

  We have collectively spent 1 out of every 4 weeks fixing build issues.

Let that sink in for a moment.

Sure, some patches take less than an hour, but I *know* from working on them
that some take definitely more than one or two hours. One hour average seems
reasonable, knowing that it's not only applying the fix, but also testing
whether it worked, making sure we don't introduce unneeded #includes, writing
commit log entries, and waiting that EWS runs over the fix to be minimally
sure that nothing else got broken.

The above 1h per patch is time from *experienced* developers. Even if we could
offload these patches to beginners, it would take them *even more time* and in
my opinion it would be *extremely unfair* towards them. Not to mention it
would be counter-productive for the WebKit project at large to burn out
newcomers with a responsibility that, as others already pointer, should be
shared among all of us.

> Each patch should be responsible for getting its own includes correct.
> >
> 
> It's unclear that this makes sense given that we can already fix build
> failures caused by different set of translation units getting unified for
> WebKit ports that have their own EWS bots.
> 
> One day per person per month sounds like a totally reasonable cost for us
> to ask of ports that don't yet to have EWS setup in the upstream WebKit
> project.
> 
> Inevitably, such ports already face other more complex build failures
> whenever we refactor WebKit or WebCore platform by, say, introducing new
> client interface or pure virtual member function that has to be overridden
> in each platform / port.

This is a straw man argument. The fact that other changes like refactors
may break other ports is not a justification to push more build failures
(even if simpler) to other ports *unnecessarily*.

We are not only pointing the issues with non-unified builds, but we are also
putting the money^W effort where our mouth is. Not only we had made building
WebKit more robust for everybody with our continued trickle of patches, we
have spent time and hardware resources setting up a post-commit builder, and
now we are offering to commit further hardware to have pre-commit EWS
builders. We want to see the EWS block from merging patches which break
the non-unified builds *that* badly.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit is now on GitHub

[Adrian Perez de Castro via webkit-dev]

Hi Michael,

On Thu, 23 Jun 2022 16:01:11 -0500 Michael Catanzaro via webkit-dev 
 wrote:
> On Thu, Jun 23 2022 at 10:29:55 AM -0700, Jonathan Bedard via 
> webkit-dev  wrote:
> > Let me know if there is any fallout,
> 
> As far as I know, WebKitGTK and WPE WebKit stable branches have not yet 
> been migrated and are now read-only? Let's make sure not to delete SVN 
> until we're certain they have migrated.

Branches *will* be migrated, there has been a thread in Slack about this:

  https://webkit.slack.com/archives/C01C94S4C6M/p1655821161932009

(/me is a bit sad that with more people favoring Slack over mailing
lists important things can go unnoticed and not archived much more
easily)

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

On Thu, 29 Apr 2021 19:04:55 + Ross Kirsling via webkit-dev 
 wrote:

> 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).

This is pretty accurate. I do have a build directory configured manually
as non-unified so I can get its “compile_commands.json” to point tooling
at (mainly clangd, for code completion and linting), but actual builds I
do them with the “build-webkit” script.

Another situation in which I explicitly opt-in to non-unified builds is
around the time we make a release branch for the GTK and WPE ports; get
to solve the non-unified build issues and then land the patches in the
release branch as well. The goal here is to make sure that what we release
can be built non-unified, which means header includes and whatnot are
correct (at least for these ports) and we can have the confidence that
people doing cross-builds (where the set of files in each unified build
compilation unit can shift) will not have problems with the builds.

Before I did the above we used to have complaints and distributions
sometimes carrying odd patches playing whack-a-mole to get builds done
instead of properly fixing things.

Cheers,
—Adrián

 
> 
> 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


pgpstgQfzBoDJ.pgp
Description: PGP signature
___
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

[Adrian Perez de Castro via webkit-dev]

On Thu, 29 Apr 2021 15:56:31 + Don Olmstead via webkit-dev 
 wrote:

> When the Mac CMake build is in a working state I'd request an EWS that is 
> Non-Unified as well since Mac builds cover more code.

This would be a great addition, I agree. While I don't have a Mac around,
I can try and spare some cycles helping out with CMake Mac to get the build
in shape :)

Cheers,
—Adrian


> -Original Message-
> From: Alex Christensen via webkit-dev  
> Sent: Thursday, April 29, 2021 8:16 AM
> To: dpino 
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] New EWS Non-Unified builder
> 
> I’d be excited to have this.  Those build failures have been bothering me 
> ever since we started using unified builds.  We would have a way to see more 
> problems in our code that are currently hidden.
> 
> > On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
> >  wrote:
> > 
> > Hi everyone,
> > 
> > In Igalia we have been discussing the need of deploying a new builder 
> > which builds WebKit using non-unified sources, and we know that at 
> > least the folks at Sony are also in favor.
> > 
> > One side effect of Unified Source building is that it hides 
> > compilation errors. The kinds of errors that usually get hidden by 
> > unified builds are missing headers inclusions and missing definitions 
> > of functions declared inline; the latter being tricky to debug because 
> > it results in mysterious linker errors. This is caused by unified 
> > builds stashing several .cpp files together for compilation, so the 
> > definitions and header inclusions done in one “leak” into the others. 
> > As for missing header inclusion errors, a source file might include a 
> > header definition as a co-lateral effect of being stashed together 
> > with another file that indeed includes the missing header.
> > 
> > These hidden compilation errors may arise later at some point if 
> > unified source files are stashed together in a different manner.
> > 
> > The current situation is requiring periodical maintenance. You can 
> > check build fixes commits due to unified source compilation with:
> > 
> >$ git log --pretty=short --grep "Non-unified"
> > 
> > Here are some examples:
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222652__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-e_2Uo6c$
> >  
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222755__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-cnURaLI$
> >  
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=22
> > 1701__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_
> > y9h8CnFZ7s60jhM-qQl-arU$
> > 
> > A new builder which builds WebKit with non-unified Source will highly 
> > help to improve this situation. Compilation errors will be detected as 
> > soon as possible and will save a lot of time not only for the 
> > developers who are currently doing this manual maintenance but for 
> > anyone who would like to build WebKit, and may stumble on compilation 
> > errors accidentally introduced due to unified sources.
> > 
> > While correct compilation of the codebase can only be guaranteed with 
> > non-unified source builds, we do not propose switching the current EWS 
> > compilation builders to non-unified because it's slower and the EWS 
> > LayoutTests and API test bots use the products built by the EWS 
> > builders — we do not want to delay getting results from those. That's 
> > why we are proposing a new builder: it will run on parallel, resulting 
> > in no slowdown for the other EWS builders, which will keep using 
> > unified builds.
> > 
> > How this new builder will impact developers? The EWS LayoutTest bots 
> > take at least 1 hour to complete a build. We think that as long as 
> > this new EWS Non-Unified builder is within that time budget, this new 
> > EWS wont' slow down development speed.
> > 
> > Thoughts?
> > 
> > Best regards,
> > 
> > Diego
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/
> > webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjAC
> > a4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


pgp8GrVzObtlu.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mailman web interface missing

[Adrian Perez de Castro via webkit-dev]

On Mon, 26 Apr 2021 13:07:47 -0700 Darin Adler  wrote:
> > On Apr 26, 2021, at 1:03 PM, Adrian Perez de Castro via webkit-dev 
> >  wrote:
> > 
> > - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found”
> > - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden”
> 
> I took a look and it seems that the URLs have simply changed, perhaps as a 
> result of an update:
>
> https://lists.webkit.org/mailman/listinfo/webkit-wpe

Thanks, you're right—this URL works!

> https://lists.webkit.org/mailman/admin/webkit-wpe 
> <https://lists.webkit.org/mailman/admin/webkit-wpe>

…but this one still results in “403 Forbidden” (it won't work even with a
fresh profile to rule out saved cookies).

Regards,
—Adrián


pgphr0Fkgq0k3.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Mailman web interface missing

[Adrian Perez de Castro via webkit-dev]

Hello all,

Mailing lists seem to be working fine, and web pages for their archives are
accessible, for example https://lists.webkit.org/pipermail/webkit-wpe/ works
fine—but on the other hand the Mailman administrative interface seems to have
gone the way of the dodo:

 - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found”
 - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden”

I noticed this a couple of days ago because I got a notification from Mailman
that there are messages pending moderation for the WPE mailing list; but I
cannot do anything about that because the web interface (second link above)
does not seem to work.

Could anyone at Apple please take a look at this?

Thanks in advance!
—Adrián


pgpxQ4tvbEhQL.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be offline for a week

[Adrian Perez de Castro via webkit-dev]

On Tue, 16 Mar 2021 02:18:48 +0200 Adrian Perez de Castro  
wrote:
> On Sat, 06 Mar 2021 16:29:10 +0200 Adrian Perez de Castro via webkit-dev 
>  wrote:
>  
> > I will be moving to a new office in the next week or two, and I need to shut
> > these down today. In all goes as expected, it should be possible to bring 
> > them
> > online in about a week. There are other workers for the GTK and EWS ports, 
> > so
> > the queues will continue running normally--if a tad slower. In the meantime,
> > my apologies for the inconvenience.
> 
> The hardware was moved on Saturday, and I am currently waiting that Internet
> connectivity is sorted out to be able to bring the builders back online in
> the next days.

…aaand they are back online.

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

[webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be offline for a week

[Adrian Perez de Castro via webkit-dev]

Hello,

I will be moving to a new office in the next week or two, and I need to shut
these down today. In all goes as expected, it should be possible to bring them
online in about a week. There are other workers for the GTK and EWS ports, so
the queues will continue running normally--if a tad slower. In the meantime,
my apologies for the inconvenience.

Cheers,
-Adrian


pgpVVeXD1uh4I.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reminder: include everything that you use in implementation files

[Adrian Perez de Castro via webkit-dev]

Hello Peng,

On Wed, 11 Nov 2020 12:05:18 -0800 "Peng (WebKit) Liu via webkit-dev" 
 wrote:
 
> Any way/option to turn off the unified build completely or partially in a
> local build? That would be very helpful for a developer to locally verify
> that header files are included correctly in a patch. Thanks!

You can use “build-webkit --no-unified-builds” to disable them; though I am
unsure if this will work for the Mac/iOS ports… It surely works with the
ports that use CMake (WPE, GTK, JSCOnly), and when using CMake you can also
use “cmake -DENABLE_UNIFIED_BUILDS=OFF” if you would rather configure and
build manually.

I hope this helps.

Cheers,
—Adrián
 
> Best regards
> Peng
> 
> > On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
> >  wrote:
> > 
> > Hello folks,
> > 
> > I'd like to remind everyone to please include what you use in .cpp,  .mm, 
> > and other files. When reviewing patches, please
> > ensure that new mentions of classes, structs, etc. within an implementation 
> > file have a corresponding header include. 
> > All of our headers have #pragma once, so there is no downside to being more 
> > explicit.
> > 
> > I've been noticing an uptick in the number of unified sources-related build 
> > failures. I can't remember the last nontrivial patch
> > I wrote that did *not* include unrelated build fixes. Typically these 
> > failures aren't found until EWS results come back, reducing developer 
> > velocity.
> > And obviosuly it's super annoying to encounter completely unrelated build 
> > failures that must be nonetheless addressed.
> > 
> > Let's all do our part so that hacking on WebKit remains delightful.
> > 
> > Thanks,
> > 
> > Brian Burg (he/they)
> >  WebKit Developer Experience


pgp3EqFjbVP0a.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be rebooted for maintenance

[Adrian Perez de Castro via webkit-dev]

Hi all,

Quick PSA: the two build bot workers I run will be brought down for a short
period of time at 05:30 PST due to a kernel update; the machine where they
are hosted is going to be rebooted. Most likely this will take only a few
minutes =)

Cheers,
—Adrián


pgpLIHd8suLcc.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be rebooted for maintenance

[Adrian Perez de Castro via webkit-dev]

On Fri, 06 Nov 2020 15:05:59 +0200 Adrian Perez de Castro  
wrote:
 
> Quick PSA: the two build bot workers I run will be brought down for a short
> period of time at 05:30 PST due to a kernel update; the machine where they
> are hosted is going to be rebooted. Most likely this will take only a few
> minutes =)

Done! The machine is back, along with the EWS builders.

Cheers,
—Adrián


pgpKfupEJ_rw0.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ACCELERATED_2D_CANVAS

[Adrian Perez de Castro]

Hello,

On Tue, 13 Oct 2020 14:36:11 +0200 z...@falconsigh.net wrote:

> ACCELERATED_2D_CANVAS feature right now is only implemented for ports using
> Cairo. Of those ports, I can only guarantee for the GTK and WPE ports that
> it works to some degree. The implementation relies on a GL-oriented Cairo
> backend that's always been deemed experimental and is not receiving a lot of
> attention anymore. As such, I propose removing the ImageBuffer backend
> implementation, along with the code guarded by the ACCELERATED_2D_CANVAS
> build guard and the relevant configuration options.
> 
> The patch removing the guarded code and build/configuration options is here,
> pending to land: https://bugs.webkit.org/show_bug.cgi?id=217603
> 
> There's also some preference cruft still left in the WebKit layer that's
> going to be removed later.

I am in favor of this removal.

We just fixed the build with the feature enabled with the idea of merging the
fix in the 2.30.x branch because it is expected to work there; but given that
whether the option improves performance or not is hit-and-miss (sometimes it
makes things go slower) and that our longer term plan is to get rid of Cairo,
I think it's good to go ahead with this and remove from trunk this code—it is
not even routinely built and thus prone to bitrot.

Cheers,
—Adrián


pgpP4PPRmrEQ6.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

On Tue, 06 Oct 2020 11:15:05 -0700 Jonathan Bedard  wrote:

> Seems like most large projects are using some sort of bot or action to solve
> this problem: https://github.com/isaacs/github/issues/581
> .

Wow, “there's a bot for that” seems to be the “there's an app for that” of
the GitHub ecosystem 😵

> > On Oct 6, 2020, at 11:07 AM, Michael Catanzaro  wrote:
> > 
> > On Wed, Oct 7, 2020 at 2:22 am, Tetsuharu OHZEKI 
> >  wrote:
> >> If we move to GitHub Issue, compared to bugzilla, that does not have
> >> "component watching".
> >> (I don't know the case of GitLab's Issue)
> >> We only can watch all issues or not for the repository.
> > 
> > Oh dear. I had assumed that you could easily subscribe to particular labels 
> > (as you can in GitLab) but, poking around in GitHub's UI, I indeed don't 
> > see any way to do that. :/
> > 
> > That's no good. E.g. multimedia developers expect to be able to subscribe 
> > only to multimedia bugs, WebKitGTK developers will want to watch only GTK 
> > bugs, etc.
> > 
> > Michael


pgpGPdP1onlz3.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hi there,

There is one more annoyance I am adding below Konstantin's list…

On Tue, 06 Oct 2020 03:13:32 +0300 Konstantin Tokarev 
wrote:
 
> 05.10.2020, 23:41, "Yusuke Suzuki" :
> > I think security component is special in terms of how to handle it already
> > (e.g. not posting a test with the patch etc.) To me, handling non-security
> > issues in GitHub and security issues in Bugzilla is OK.  By nature,
> > security issues are not open. Since one of our motivation of moving to
> > GitHub is openness for feedback collection, security issue in Bugzilla
> > does not matter for this motivation.  Ideally, handling both in GitHub is
> > better. But to me, rather than continuing using Bugzilla, using GitHub for
> > non security issues sounds improvement.
> 
> To me it sounds as a huge step backwards. Asides from situation with
> security issues, it has other significant drawbacks in domain of issue
> triaging and management:
> 
> 1. Sub-par support for linking issues to each other
> 
> 
> Traditional bug tracking systems (like Bugzilla or JIRA) have support of
> "related" or "linked" issues. Most important relations are
> 
> * A depends on B (B blocks A) - blockers and umbrella issues
>
> * B is duplicate of A
>
> * A and B are related in other unspecified way
> 
> All GitHub can offer here now is mentions (and, to some extent, milestones
> for case of "umbrella issues" [1]). Mention is created every time someone
> uses "#" (e.g. "#123") in the text of issue or in the comment, where
> number is a sequential number of issue or pull request [2]. When comment is
> published in issue A which mentions issue B, there is a pseudo-comment added
> to B, and subscribers of B receive email notification.
> 
> At first glance this naive approach seems to work, but
> 
> * There is no easily visible list of relations: if you are not closely
>   following all activity on A, to find all issues related to it you have
>   to browse through all its (pseudo-)comments, which in some cases might
>   be long.
>
> * There is no *stateful* list of relations: if A was believed to have
>   common source with B, but then it was discovered they are not related,
>   you cannot delete relationship between A and B because there is no
>   relationship, just a set of comments.
>
> * "#" is not a safe reference format. Sometimes users' comments
>   may have other data in "#" format with a different
>   meaning than references to GitHub issues. For example, may the force be
>   with you if someone pastes gdb or lldb backtrace into comment without
>   escaping it into markdown raw text block (```). Also, GitHub parses
>   mentions in git commit messages, so care must be taken to avoid any
>   occurrences of "#" with a meaning different from reference to
>   issue number.
> 
> ---
> 
> [1] Milestones are not issues themselves, but they establish true two-way
> stateful relation between issues and their "parent" milestone.  [2] For some
> reason they have shared numbering, which means sometimes you may not know
> what kind of reference is in front of you until you look up its URL or
> navigate
> 
> 
> 2. Sub-par issue categorization and search
> --
> 
> In traditional bug tracking systems every issue has properties like status,
> resolution, component, severity/issue type, priority. When new bug is
> created, user chooses values of these properties, which can be later
> adjusted by the person doing triaging. They also are used in user-friendly
> search dialog like [1].
> 
> All GitHub can offer here are custom labels. While in theory they are
> sufficient to replace pre-defined issue properties, they require disciplined
> use to be efficient, for example issue must not have mutually exclusive
> labels. To avoid chaos, GitHub allows setting issue labels only to
> contributors. However, this puts more work on triagers, and they cannot
> triage only certain kinds of issues which match their interests by going
> through results of search query.
> 
> [1] https://bugs.webkit.org/query.cgi
> 
> 
> 3. Sub-par attachments
> --
> 
> Traditional bug trackers allow attaching files to issue. GitHub goes further
> and allows to attach files to every comment. Enjoy the progress -  now you
> can look for attached test cases and proposed patches through all comment
> feed, instead of having them in one place at the top.
> 
> Also, on test cases. You probably like this feature of Bugzilla when you can
> attach self-contained HTML file to the issue and then simply open it by URL
> in any browser including your build of WebKit to try it out. Forget this -
> GitHub simply forbids HTML or JS attachments (without wrapping them in
> archive):
> 
> "We don’t support that file type. with a GIF, JPEG, JPG, PNG, DOCX, GZ,
> LOG, PDF, PPTX, TXT, XLSX or ZIP."
> 
> And yes, take care not to use tar.xz or tar.bz2 or any other unapprov

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

On Sun, 04 Oct 2020 02:00:02 +0300 Konstantin Tokarev  wrote:
 
> 03.10.2020, 21:49, "Adrien Destugues" :
> > Yes that's why I didn't elaborate much. Whichever tool you pick, there
> > will always be people unhappy about it.
> 
> Right. For example, I have negative bias against GitLab, because this
> company have bought its open source competitor (Gitorious, which was
> quite popular service those days) just to shut it down.

I personally have negative bias against both GitHub *and* GitLab.

In the case of GitHub, apart of the reasons already mentioned by others,
yesterday I started getting a new popup asking consent to being tracked
even more.

In the case of GitLab, it's a bloated kitchen sink which does not inspire
trust in me when its official documentation has pearls [1] like this:

  “GitLab has memory leaks. These memory leaks manifest themselves in
   long-running processes, such as Unicorn workers. (The Unicorn master
   process is not known to leak memory, probably because it does not
   handle user requests.)

   To make these memory leaks manageable, GitLab comes with the
   unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to
   do a memory self-check after every 16 requests. If the memory of the
   Unicorn worker exceeds a pre-set limit then the worker process exits. The
   Unicorn master then automatically replaces the worker process.”

Also GitLab has contracts with ICE (like GitHub), and not only explicitly
decided to continue them, but also attempted to silence their employees
on political matters:

  https://www.theregister.com/2019/10/16/gitlab_employees_gagged/
  https://www.theregister.com/2019/10/17/gitlab_reverse_ferret/

Cheers,
—Adrián

---
[1] 
https://docs.gitlab.com/ee/administration/operations/unicorn.html#unicorn-worker-killer


pgp4KjNmxjOrc.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hello,

On Fri, 02 Oct 2020 13:48:56 -0700 Ken Russell  wrote:

> Excited about this migration! One comment inline.
> 
> On Fri, Oct 2, 2020 at 9:43 AM Jonathan Bedard  wrote:
> 
> > *Patches to Pull Requests*
> > In the coming months, more automation will start using the git version of
> > the repository instead of the Subversion version. Even immediately after we
> > switch, the patch review workflow will remain what it is now (EWS bots
> > mostly already use a git clone as their checkout). We do, however, intend
> > to switch from a system of patch review to a system of pull requests. This
> > process will be incremental and the patch review system will remain alive
> > as long as Bugzilla does.
> >
> > *GitHub Issues*
> > The last part of transitioning away from Subversion is to re-evaluate our
> > bug tracker. Bugzilla has served us well, but seems to be an impediment to
> > engaging with the open source community. We are interested in moving away
> > from Bugzilla and to GitHub Issues, allowing new developers to work with a
> > system they are likely already familiar with and to allow us closer
> > integration with repositories managed by W3C. Although GitHub Issues has
> > had performance problems in the past with projects that have many bugs,
> > these performance problems have been resolved to the satisfaction of a few
> > large projects hosted on GitHub that are of a comparable scale to WebKit.
> > The biggest blocker we are aware of is managing security bugs, since the
> > security advisory system used by GitHub is essentially the opposite of how
> > WebKit security bugs work. Moving to GitHub Issues, if it happens, will be
> > the last part of this transition, and we are interested in soliciting
> > feedback from our contributors on what the WebKit project’s integration
> > with GitHub Issues should look like.
> 
> Github's code review UI has a couple of feature gaps in my opinion. It's
> difficult to look at earlier versions of the pull request, in particular to
> verify that issues found during code review have been fixed. I remember it
> also being difficult to figure out whether all comments on earlier versions
> have been addressed.

There is also one annoyance which has been slowly grinding my gears: the
GitHub diff viewer (including in reviews) hides “big diffs” for some arbitrary
and unknown definition of “big”, forcing a reviewer to manually click in a
“Load diff” link, for each hidden diff, every time. In a few cases I ran into
“very big” diffs or diff hunks which could not even be displayed that way and
had to fetch the branch locally to review the changes. Truth be told: it has
been a good while since I haven't found any diff which could not be loaded
at all, so maybe that issue has been fixed by now.

Now, GitLab's diff viewer has its own set of similar-but-not-quite-same
annoyances. Instead of hiding “big” diff hunks, it hides “random” hunks:
typically big ones, but sometimes small ones as well. A positive point for
GitLab is that at least they can always be loaded using that pesky “Load
diff” link.

Why none of Git{Hub,Lab} would have an option “gimme all the diffs” user
option, or at least remember which reviews I visited before where the “Load
diff” links have been used is something inexplicable. Or they could just
show the diffs ¯\_(ツ)_/¯ 

> Gerrit code review has worked well in my experience. It explicitly manages
> different versions of the same patch set, and prominently shows whether all
> code review comments have been addressed.

One point for Gerrit: I never ran into a diff that it would not show.

Regards,
—Adrián


pgpstt94v6F6n.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hello,

On Sun, 04 Oct 2020 01:57:56 -0700 Yusuke Suzuki  wrote:

> GitHub is planning to have review revisions in 2020/Q4.
> So, when WebKit repository is migrated, we already have that in GitHub 
> builtin review tool :)
> 
> https://github.com/github/roadmap/issues/54 
> 

It's not clear from the description in that issue that using a “rebase and
force-push” strategy to update patch sets to be will be supported and that the
differences between versions will be available. Rebases are not mentioned at
all, so I would not count on this workflow working even with the upcoming
improvements in 2020/Q4.
 
> > On Oct 3, 2020, at 5:18 PM, Michael Catanzaro  wrote:
> > 
> > On Sat, Oct 3, 2020 at 9:52 pm, Konstantin Tokarev  
> > wrote:
> >> If I understand correctly, there is no way in GitHub UI to see a 
> >> difference between
> >> patches submitted at step 1 and step 3. It's still possible to see old 
> >> version of patches
> >> if you navigate to old commit hash, but that's not for long as they can be 
> >> garbage
> >> collected by GitHub because they don't belong to git branch anymore.
> > 
> > If we are really seriously concerned about this... it's not a problem with
> > GitLab. At least, I can still view diffs between different revisions of
> > merge requests from two years ago, and the changes seem to be stored
> > forever. At least I still can view diffs from years ago. E.g.:
> > 
> > https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=27669&start_sha=0c020384b602c9e1f0e8ec9e491d1951e8feadf7
> >
> > Unfortunately it's sometimes less useful than I might have hoped, because
> > rebases bring in a bunch of totally unrelated changes, e.g.:
> >
> > https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=28036&start_sha=043b5fc32f4f9263d393c9de83e1b33123c5

This is the kind of thing that Gerrit is *designed* to solve :]

Cheers,
—Adrián


pgpd479NRitRQ.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hi,

On Tue, 06 Oct 2020 03:42:11 +0300 Konstantin Tokarev  wrote:
 
> 05.10.2020, 13:26, "Frédéric Wang" :
> > One thing to take into account is that WebKit's repository is big and
> > public GitHub/GitLab prevent creating large repository by default. This
> > means it might not be possible for contributors to actually fork
> > WebKit's repository on their account and then create a pull request
> > (which is the standard way IIUC).
> 
> Every repository which is already present on GitHub can be forked by
> anyone without any restrictions.
> 
> There are restrictions for repositories which are not forks, e.g. if you
> create new repo on your account and try to push whole WebKit there,
> you'll get an error.
> 
> > Instead, we would probably end up
> > doing like web-platform-tests and give contributors the permission to
> > create branches to the WebKit account and make Pull Request to the
> > master branch. 
> 
> This is not needed and should be avoided - private development branches
> in main repo will confuse users and will be copied into all forks.
 
While I agree that having private development branches in the main repository
can be confusing for people not used to that, OTOH it is awkward to have to
“fork” [1] the repository to one's user area, then add an extra remote to
one's local clone of the upstream (main) repository, just to be able to submit
a “pull request” [2].

Also with Git{Hub,Lab} it's an annoyance that one has to go through the web
interface to create a “pull request”. Being able to do “webkit-patch upload”
saves a non negligible amount of developer time. It is even better with
Gerrit: do “git push” directly to a remote ref and a changeset will be
automatically created for review [3].

> >Probably, we should forbid people to commit to the master
> > branch directly (I think someone broke WPT's master branch that way last
> > year)...
> 
> I have to admit that ability to make small unreviewed commit for thing like 
> typo fix or change in personal watchlist is rather useful...

I suppose this could be solved by still making a “pull request” and tagging
it with some label to be merged automatically by some bot. It won't be as
fast as directly landing a patch, but on the upside all patches (including
unreviewed ones) would be landed in the same way.

As a side note, Gerrit can be configured to allow direct pushes that bypass
the review process.

Cheers,
—Adrián

---
[1] I put “fork” in between quotes because it's a perversion of the term: what
it does is create a clone of the repository in Git{Hub,Lab}'s own servers
which happens to be accessible remotely with one's credentials.
[2] GitHub's usage of the “pull request” term is yet another perversion: Git
has had a pull requests (produced by a command) long before GitHub even
existed, see https://git-scm.com/docs/git-request-pull
[3] 
https://gerrit-documentation.storage.googleapis.com/Documentation/3.2.3/intro-user.html#upload-change


pgpEp7XcmnUrw.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hello,

On Wed, 07 Oct 2020 04:17:45 +0300 Konstantin Tokarev  wrote:
 
> 06.10.2020, 18:03, "Michael Catanzaro" :
> > On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev 
> > wrote:
> >>  1. Sub-par support for linking issues to each other
> >>  
> >>
> >>  Traditional bug tracking systems (like Bugzilla or JIRA) have support
> >>  of "related" or "linked" issues. Most important relations are
> >>
> >>  * A depends on B (B blocks A) - blockers and umbrella issues
> >>  * B is duplicate of A
> >>  * A and B are related in other unspecified way
> >
> > GitHub does have duplicates btw, but the syntax is completely different
> > from GitLab so I can never remember how it's done. It's not exposed in
> > the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate
> > of issue #245. (You can have cross-repo duplicates too, and I think
> > even cross-*project* duplicates. This is very important for GNOME, but
> > not for WebKit since WebKit is just one huge repo.)
> >
> > I found instructions for GitHub here:
> > https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates
> >
> >>  * There is no easily visible list of relations: if you are not
> >>  closely following all activity on A, to find all issues related to it
> >>  you have to browse through all its (pseudo-)comments, which in some
> >>  cases might be long.
> >>  * There is no *stateful* list of relations: if A was believed to have
> >>  common source with B, but then it was discovered they are not
> >>  related, you cannot delete relationship between A and B because there
> >>  is no relationship, just a set of comments.
> >
> > In my experience, this isn't really a *huge* problem. Umbrella issues
> > work well enough to track relationship between bugs, as do milestones,
> > and you can use whichever you prefer. I admit it is not nearly as nice
> > as Depends/Blocks from Bugzilla, though. But I think it should be good
> > enough for us.
> >
> >>  * "#" is not a safe reference format. Sometimes users'
> >>  comments may have other data in "#" format with a different
> >>  meaning than references to GitHub issues. For example, may the force
> >>  be with you if someone pastes gdb or lldb backtrace into comment
> >>  without escaping it into markdown raw text block (```). Also, GitHub
> >>  parses mentions in git commit messages, so care must be taken to
> >>  avoid any occurrences of "#" with a meaning different from
> >>  reference to issue number.
> >
> > Yeah this is unfortunate and also guaranteed to happen. The first
> > several dozen issues are going to be spammed with references to other
> > bugs all over the place.
> >
> >>  [2] For some reason they have shared numbering, which means sometimes
> >>  you may not know what kind of reference is in front of you until you
> >>  look up its URL or navigate
> >
> > This is silly too (and not a problem on GitLab, which uses # for issues
> > and ! for merge requests). But although I agree it is a defect, is it
> > really a huge problem? Probably not.
> >
> >>  Also, on test cases. You probably like this feature of Bugzilla when
> >>  you can attach self-contained HTML file to the issue and then simply
> >>  open it by URL in any browser including your build of WebKit to try
> >>  it out. Forget this - GitHub simply forbids HTML or JS attachments
> >>  (without wrapping them in archive):
> >>
> >>  "We don’t support that file type. with a GIF, JPEG, JPG, PNG,
> >>  DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP."
> >>
> >>  And yes, take care not to use tar.xz or tar.bz2 or any other
> >>  unapproved archive type.
> >
> > OK, now you've convinced me... this is bad. :P I forgot about this
> > problem because GitLab does not have any such restrictions on
> > attachments. It's very frustrating to have to say "I added a .txt file
> > extension so I could upload this to GitHub. Please remove the file
> > extension after you have downloaded the file before you use it." I
> > would say this is strongest argument I've seen against GitHub. Silly
> > problem to have tbh.
> >
> > I'll just add that GitLab has become *really* popular for Linux-related
> > projects. I have to regularly work with GNOME GitLab, freedesktop
> > GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab
> > too, so soon that will be five different public GitLab instances that I
> > have to switch between regularly, and that's limited to only the public
> > instances. Then there are also many major communities I don't work with
> > that are also using GitLab (KDE, Debian, Purism).
> 
> FWIW, KDE is using Bugzilla for bug reporting, and Debian uses debbugs.

Not that debbugs would be particularly user-friendly… ;-)

> > It's reached the
> > point where unless you only work on Linux kernel itself, you probably
> > spend a lot of time on one GitLab or another. It should be consid

Re: [webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

On Wed, 07 Oct 2020 08:58:58 -0500 Michael Catanzaro  
wrote:
> On Wed, Oct 7, 2020 at 4:17 am, Konstantin Tokarev  
> wrote:
> > BTW, could you estimate how many of users which have provided
> > meaningful bug reports were directed to bugs.webkit.org but never 
> > made it?
> 
> A lot. I'd say maybe about half make it upstream. That's OK. We don't 
> have time to fix everything, after all, and it doesn't make sense to 
> focus on bug reports where we cannot easily interact with the reporter.

I think there is some bias here to say that “a lot have not gone into
Bugzilla” because people who may complain about Bugzilla are of course more
vocal than those who went ahead, made an account (or already had one), and
filed a bug.

Also, the “a lot” above is definitely overestimated, because you do not seem
to be taking into account that among the people who cannot be bothered to file
a bug report in Bugzilla, many would not file it in GitHub either (nor GitLab,
nor anything else).

Good software gets its job done and is mostly invisible and boring: you use
it, but don't think twice about it, nor there is any need to write about it.
Bugzilla is among the kind of software that is good at what it does without
getting in the way, so of course it does not have hype. It's only when one
starts to seriously think about the allegedly “shiny” alternatives that all
the small annoyances start becoming evident (the list shared by Konstantin is
a perfect example).

Cheers,
—Adrián


pgpATre9rjMqT.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS

[Adrian Perez de Castro]

Hello,

On Wed, 22 Jul 2020 14:42:07 +0100, Philippe Normand  wrote:
> On Wed, 2020-07-22 at 08:24 -0500, Michael Catanzaro wrote:
> > On Wed, Jul 22, 2020 at 11:15 am, shriva...@firemail.cc wrote:
> > > DerivedSources/ForwardingHeaders/JavaScriptCore/JSContext.h:40:1: 
> > > error: duplicate interface definition for class 'JSContext'
> > > @interface JSContext : NSObject
> > > ^
> > > ../../Source/JavaScriptCore/API/JSContext.h:40:12: note: previous 
> > > definition is here
> > > @interface JSContext : NSObject
> > >^
> > > 
> > > Your assistance would be much appreciated.
> > 
> > It might be time to simply remove support for building WebKitGTK on 
> > macOS. I imagine it's been many years since anyone has successfully 
> > built it.
> 
> jmercouris on IRC reported yesterday that he got it to build on macOS.
> IIUC he's working on the macports project.

That's right; I have been helping them out and encouraging to send patches
upstream. The Nyxt [1] browser is using WebKitGTK on MacOS and actively
maintained, too.

Cheers,
—Adrián

---
[1] https://github.com/atlas-engineer/nyxt


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Plugin process

[Adrian Perez de Castro]

On Mon, 20 Jul 2020 09:35:24 -0500, Michael Catanzaro  
wrote:
> On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro 
>  wrote:
> > Our tentative plan for sunsetting the NPAPI support is to keep 
> > supporting
> > the GTK3 plugin process in the next stable release series. This means 
> > that
> > we could remove the support from trunk after creating the stable 
> > branch
> > for the 2.30.x releases—that would be around September-October 2020.
> 
> Well branching normally occurs in August... just a few weeks away now. 
> Then we can make the plugin process specific to PLATFORM(COCOA), until 
> Apple figures out if it can be removed, and we can delete the support 
> for all other platforms.

Oh, I was sleepy when I wrote that… of course you are right: branching
for the stable release happens *before* the first release of the series
is done, not after. So yes, we can start removing the plugin process from
trunk around August.

> For now, I'll submit a patch to deprecate these settings without 
> changing behavior yet.
> 
> > I think we would need to make the public API to toggle the support 
> > for plugins
> > a no-op and log a warning to avoid breaking applications.
> 
> Well a warning certainly doesn't hurt. I suspect no applications are 
> using it, though.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Plugin process

[Adrian Perez de Castro]

Hi all,

On Sun, 19 Jul 2020 15:49:37 -0700, Brent Fulgham  wrote:

> We haven’t removed it from Apple builds yet, because we think there are
> still some WebKit clients that use them. I.e., WebKit framework users on the
> platform that are not Safari or one of the other web browsers.

For the GTK port we have already removed the support for NPAPI plugins
that use the GTK2 plugin process in the 2.28.x releases (the current stable
series), but using the GTK3 plugin process is still supported.

Our tentative plan for sunsetting the NPAPI support is to keep supporting
the GTK3 plugin process in the next stable release series. This means that
we could remove the support from trunk after creating the stable branch
for the 2.30.x releases—that would be around September-October 2020.

> We should take another look, because it would be great to get rid of it
> completely.

Indeed!
 
> > On Jul 19, 2020, at 11:12 AM, Michael Catanzaro 
> > wrote:
> > 
> > Hi,
> > 
> > Is anybody still using the plugin process? I understand that Safari does
> > not allow plugins anymore. Epiphany doesn't either, nor does anything
> > packaged in Linux distros  (afaik). If nothing is using it, maybe we can
> > delete a lot of code? Is it exposed in Apple system APIs?
> > 
> > WebKitGTK still has an enable-plugins setting that is not yet deprecated.
> > Probably long past time to at least deprecate it. There's also,
> > incredibly, an enable-java setting, which I presume toggles the old Java
> > browser plugin. I sense there must be some history behind that setting. :)

AFAIU, the idea is to allow things like enabling plugins in general, but not
the Java plugin in particular. Probably the reason has been that the Java
browser plugins have historically been plagued by bugs—but this is just me
doing a wild guess ;-)

I think we would need to make the public API to toggle the support for plugins
a no-op and log a warning to avoid breaking applications.

When building against GTK4 the plugin process is never supported (and has
never been, we decided to avoid it from the very beginning).


Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Adrian Perez de Castro]

On Thu, 16 Jul 2020 15:01:14 -0700, Darin Adler  wrote:
> > On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro  
> > wrote:
> > 
> > It is not feasible to test unified builds for all the possible combinations 
> > of
> > target architectures and set of features enabled at build time (there is a
> > combinatorial explosion of configurations). Keeping non-unified builds in a
> > working state guarantees that regular unified builds will keep working no
> > matter what the build configuration is.
> 
> But it doesn’t.

Yes, because enabling/disabling features changes the set of source files to
build, which results in different source files being #included from each
unifier source compilation unit.

> Non-unified builds don’t make it possible to have arbitrary sets of features
> enabled at build time. We break that all the time and it’s only fixed when
> someone tests that arbitrary set of features. Headers are only a small part
> of that issue.

True, and that is why our message for the GTK and WPE ports is always that
we only support builds with the default build options, but of course anyone
is free to change them their mileage may vary.

In practice, we tend to keep things working in a best-effort basis for the
following few cases:

 - Disabling the Wayland or X11 support in the GTK port.
 - Disabling the WPE renderer in the GTK port.
 - Disabling multimedia support in the WPE port.

> I’d go as far as saying it’s not a project goal to always build with
> arbitrary sets of features enabled.
 
I agree. But even toggling the few features I mentioned above, or the target
architecture to something else than what the bots use, results in build
failures related to unified builds due to different sources being #included
in each unified compilation unit ¯\_(ツ)_/¯ 

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Adrian Perez de Castro]

Hi,

On Fri, 17 Jul 2020 06:52:54 +0900, Fujii Hironori  
wrote:
> I'm glad to hear various opinions. Slack still can't beat mailing lists for
> technical discussions.

Aye, in my experience mailing lists are better because having to write down
thoughts in a slightly more structured way (in a mail message to be read
from start to end in one go) results in people organizing their thoughts
better (as opposed to a more or less random exchange of loosely organized
chat messages).

Not to mention that using a mailing list *also* records discussions and the
decisions, thanks to the messages being archived, which is more “durable” for
future reference. Oh, and everybody can easily grab a copy of the mailing list
archives (from the Mailman web interface as mboxes, or keeping their local
copy) so it's less likely that all copies of mailing list archives would
suddenly disappear; but OTOH, as unlikely as it may seem, Slack could go
bankrupt and/or the chat history vanish from one day to another.

> On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro 
> wrote:
> 
> > Also, some packagers used to carry assorted downstream patches for build
> > issues related to unification build which have not been needed anymore.
> >
> 
> Unified source builds can have performance merit.
> The SQLite Amalgamation makes it 5% and 10% faster.
> https://www.sqlite.org/amalgamation.html

Well, this is what Link-Time Optimization is for, without needing to resort to
ugly preprocessor tricks. I would rather let the compiler and linker do their
job—it's 2020 and any serious toolchain supports it by now ;-)

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Adrian Perez de Castro]

I forgot to mention one tidbit...

On Fri, 17 Jul 2020 00:28:53 +0300, Adrian Perez de Castro  
wrote:
> Hello everybody,
> 
> On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler  wrote:
> > > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross  
> > > wrote:
> > > 
> > > Non-unified build fixes are done to support *all* platforms, because
> > > sudden unification shifts can happen anywhere.
> >
> > I’m not sure that benefit is worth the additional code churn. I understand
> > that it’s frustrating to run into a problem when unification shifts, say
> > when you are adding a source file. I believe we have made changes to
> > unification since the earliest version that reduce how often unification
> > shifts.
>  
> While this is true, shifts still happen easily when changing anything in the
> build configuration that affects the list of source files to build. The cases
> in which I have seen this happening when using the CMake based ports are:
> 
> * The target architecture is not one of the few tested by the bots.
> 
>   - For the GTK and WPE ports this means that a build for anything else
> than x86_64 is susceptible to break easily.
> 
>   - Note that JSCOnly builds on ARM, MIPS, and i386 are actively tested by
> EWS bots, so the JSC build is less likely to.
> 
> * The features enabled at build time are changed from what the EWS bots test.
> 
>   - Happens when the build configuration (via CMake) changes the defaults.
> For example one can build the GTK port with support for Wayland enabled
>   and X11 disabled (the default is both enabled). Or one can build WPE 
> with
>   all media support disabled (which completely avoids needing GStreamer,
>   making the disk footprint considerably smaller: this is sometimes done
>   when targeting embedded devices).

As a matter of fact: lately I have been trying to make sure that non-unified
builds are working *right before* making source tarball releases for the WPE
port, and the reports of build failures due to unification issues has been
zero ever since.

Also, some packagers used to carry assorted downstream patches for build
issues related to unification build which have not been needed anymore. The
case I know better is Buildroot [1]: when I started maintaining its package
for the GTK port in preparation to submit the WPE package one of the tasks
I did was precisely avoid downstream patches, by applying the fixes to WebKit
itself—and *that* was when I learnt that making non-unified builds work was
a good thing.

>   - Bots test with experimental features enabled, but the default setting when
>   building from source tarballs has those disabled at build time. This is
>   less likely to result in a broken build than manually toggling features,
>   it can happen.
> 
> It is not feasible to test unified builds for all the possible combinations of
> target architectures and set of features enabled at build time (there is a
> combinatorial explosion of configurations). Keeping non-unified builds in a
> working state guarantees that regular unified builds will keep working no
> matter what the build configuration is.
> 
> Another side effect of keeping non-unified builds usable is that it is
> possible to build WebKit on machines with less RAM (granted: only release
> builds without any debugging information), which sometimes has enabled people
> who don't have access to beefier machines to get WebKit built and even work
> on patches. While this has not been very common, I think it's a commendable
> goal to allow people without access to beefy computers to contribute to
> WebKit :)
> 
> Best regards,
> —Adrián

---
[1] https://buildroot.org/


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Adrian Perez de Castro]

Hello everybody,

On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler  wrote:
> > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross  wrote:
> > 
> > Non-unified build fixes are done to support *all* platforms, because
> > sudden unification shifts can happen anywhere.
>
> I’m not sure that benefit is worth the additional code churn. I understand
> that it’s frustrating to run into a problem when unification shifts, say
> when you are adding a source file. I believe we have made changes to
> unification since the earliest version that reduce how often unification
> shifts.
 
While this is true, shifts still happen easily when changing anything in the
build configuration that affects the list of source files to build. The cases
in which I have seen this happening when using the CMake based ports are:

* The target architecture is not one of the few tested by the bots.

  - For the GTK and WPE ports this means that a build for anything else
than x86_64 is susceptible to break easily.

  - Note that JSCOnly builds on ARM, MIPS, and i386 are actively tested by
EWS bots, so the JSC build is less likely to.

* The features enabled at build time are changed from what the EWS bots test.

  - Happens when the build configuration (via CMake) changes the defaults.
For example one can build the GTK port with support for Wayland enabled
and X11 disabled (the default is both enabled). Or one can build WPE 
with
all media support disabled (which completely avoids needing GStreamer,
making the disk footprint considerably smaller: this is sometimes done
when targeting embedded devices).

  - Bots test with experimental features enabled, but the default setting when
building from source tarballs has those disabled at build time. This is
less likely to result in a broken build than manually toggling features,
it can happen.

It is not feasible to test unified builds for all the possible combinations of
target architectures and set of features enabled at build time (there is a
combinatorial explosion of configurations). Keeping non-unified builds in a
working state guarantees that regular unified builds will keep working no
matter what the build configuration is.

Another side effect of keeping non-unified builds usable is that it is
possible to build WebKit on machines with less RAM (granted: only release
builds without any debugging information), which sometimes has enabled people
who don't have access to beefier machines to get WebKit built and even work
on patches. While this has not been very common, I think it's a commendable
goal to allow people without access to beefy computers to contribute to
WebKit :)

Best regards,
—Adrián



signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews offline for some days

[Adrian Perez de Castro]

Hi again,

On Sat, 2 May 2020 00:04:37 +0300, Adrian Perez de Castro  
wrote:
 
> Unfortunately, builders “aperez-gtk-ews” and “aperez-wpe-ews” will be offline
> for a few days: it is sitting at the office, where nobody is going these days,
> and I cannot get hold of it remotely. Next time I venture out I plan to stop
> by and bring it back online—but that may take until May 11th.

These two EWS builders are back online, and also they have been migrated away
from JHBuild and are now using Flatpak-based builds.

Regards,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews offline for some days

[Adrian Perez de Castro]

Hello,

Unfortunately, builders “aperez-gtk-ews” and “aperez-wpe-ews” will be offline
for a few days: it is sitting at the office, where nobody is going these days,
and I cannot get hold of it remotely. Next time I venture out I plan to stop
by and bring it back online—but that may take until May 11th.

Meanwhile, the remaining EWS bots for the GTK and EWS bots seem to be handling
the workload just fine, so it does not seem like this will be an inconvenience
for now.

My apologies for this.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adrian Perez de Castro is now a WebKit reviewer

[Adrian Perez de Castro]

Hello WebKittens,

On Mon, 14 Oct 2019 15:17:19 +0200, Carlos Alberto Lopez Perez 
 wrote:
 
> I would like to announce that Adrian Perez de Castro (aperezdc on #webkit)
> is now a WebKit reviewer. 
> 
> Adrian has several years of experience working with the WebKitGTK and WPE
> WebKit ports. He is the release manager of the WPE port and the main developer
> behind the Cog WPE browser.
> 
> Please join me in congratulating Adrian, and send him some patches to review.

Thank you!

I'll be happy to help out with all kinds of reviews. For starters feel free
to ping me for anything related to “GLib ports” (GTK, WPE), the CMake build
machinery, and Linux-related issues [1]. As time goes by I expect to become
more continue getting more confident with other parts of the tree (WebCore,
I am looking at you! :D)

Cheers,
—Adrián


---
[1] On my spare time I have been known to run OpenBSD, so there's that as
well — it's far from being my daily environment though.


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Planned EWS improvements

[Adrian Perez de Castro]

Hello Aakash (and everybody else),

On Thu, 26 Sep 2019 14:27:25 -0400, Aakash Jain  wrote:
 
> I have been making number of improvements to EWS. I also have various
> planned improvements to EWS […]

Thanks once again for your continued work on improving the EWS, it is
much appreciated =)

> Here is the list of improvements (in no particular order):
> 
> […]
>
> 3) Add a way to retry a patch in EWS. This would allow engineers to confirm
> that the failures indicated by EWS aren't flaky/incorrect. Maybe a good
> place to add the 'retry' button would be the status-bubble's tool-tip
> (visible only if the bubble is red) https://webkit.org/b/196599
> 

Being able to retry a patch without having to re-upload it, and more
importantly without having to ping another person, would be neat. I
don't have a strong opinion about which tasks to prioritize first, tho.

> […]
> 
> 6) Add more test-suites to EWS (e.g.: LLDB tests, resultsdbpy tests)
> https://webkit.org/b/189206 ,
> https://webkit.org/b/201928 

In this line of adding more things that the EWS could test, among the
developers of the GTK/WPE ports we think it would be manageable for us
to have bots run API tests. There is some work we need to do, and the
intention is to start with GTK first, see how it goes, and then add WPE
afterwards. Carlos opened a bug for this, I took the liberty of CC'ing
you assuming that you might want to at least keep tabs on it (feel free
to unsubscribe):

  https://bugs.webkit.org/show_bug.cgi?id=202361

Best regards,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Recent EWS improvements

[Adrian Perez de Castro]

Hello Aakash, WebKittens,

On Thu, 29 Aug 2019 18:01:56 -0400, Aakash Jain  wrote:
 
> I want to update everyone with the further improvements I have made to new
> EWS. As always, please feel free to provide any feedback (either by filing
> bugs or contacting me directly). 
> 
> New Features:
> 
> [...]

Thanks a ton for all the improvements in the EWS! Since we moved the GTK/EWS
builders to the new queues they have been faster and more reliable. After
solving a couple of minor hiccups right after the switch, the builders have
not needed any manual intervention since (with the old system we would need
to clean stray files from old builds now and then, but not anymore!)

\o/

> Only remaining queues on old EWS are windows, jsc and commit-queue, which I
> will be working on next.

Today Xan López and I talked a bit about the JSCOnly queue. We have a many
builders targeting different architectures, which we would like to have
moved to the new system.

In the case of the JSC port, instead of grouping all of the builders under a
single “jsc” status bubble it would be better to have a bubble for each target
architecture e.g. “jsc-armv7”, “jsc-arm64”, and so on.

The motivation is that we think it makes sense to that the system considers
that a patch cannot be landed if it breaks any of the supported JSC
architectures. With a single status bubble grouping them, we can have
situations where a builder for one architecture passes the build+checks
but the patch may still break *some other* architecture (e.g. a patch
that touches ARM code generation gets picked by a MIPS builder).

Is the above something that can supported? Let us know if you need more
information and/or some support from our side for this.

Best regards,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews down for the weekend

[Adrian Perez de Castro]

Hello again,

On Mon, 19 Aug 2019 17:33:07 +0300, Adrian Perez de Castro  
wrote:

> […]
>
> P.S: I have just noticed that “igalia3-gtk-wk2-ews” is down, so I'll take a
> look into that one in a moment.

This one is up again, too.

Regards,
-Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews down for the weekend

[Adrian Perez de Castro]

Hello,

On Fri, 16 Aug 2019 18:38:03 +0300, Adrian Perez de Castro  
wrote:
 
> A firmware update has left my build machine unusable, but it looks
> recoverable. I will try to get it back running next Monday when I am
> back at the office (I will need physical access).

After some fiddling, the machine is back online and so are the two EWS bots.

Once again, sorry for the inconvenience, though it seems the queues ran fine
with the rest of the builders during the weekend :-)

Regards,
—Adrián


P.S: I have just noticed that “igalia3-gtk-wk2-ews” is down, so I'll take a
look into that one in a moment.



signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews down for the weekend

[Adrian Perez de Castro]

Hi all,

A firmware update has left my build machine unusable, but it looks
recoverable. I will try to get it back running next Monday when I am
back at the office (I will need physical access).

Sorry about the inconvenience.

Cheers,
-Adrián


pgpQVIVTNIVVB.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Python 3

[Adrian Perez de Castro]

Hello,

On Fri, 12 Jul 2019 12:37:43 -0700, Tim Horton  wrote:

> > On Jul 12, 2019, at 12:18 PM, Jonathan Bedard  wrote:
> > 
> > Hello WebKit developers,
> > 
> > Now that the Catalina developer seeds are available, it is official that
> > the new Mac developer tools come with Python 3. As a result, we need to
> > continue the ongoing discussion about migrating our Python 2.7 scripts to
> > Python 3.

Given that GNU/Linux distributions have started already a while ago switching
it is great that MacOS is now following suit as well \o/

We have a bug already for this: https://bugs.webkit.org/show_bug.cgi?id=184986

If one has to make code compatible with both Python 2.7 and 3.x, my advice
would be to use the Six module, which provides ready-made helpers which
behave consistently across both versions: https://six.readthedocs.io/
 
> > I propose that, over the next 9 months, we do the following:
> > 
> > 1. Make any no-cost Python 3 compatibility changes, in particular
> > - print foo -> print(foo)
> > - import .foo -> import webkitpy.foo
> > 2. Convert any scripts not used in automation to Python 3 ASAP (scripts 
> > like bisect-builds, block-spammers, compare-results)
> > 3. Make most Python 3 compatibility changes which sacrifice efficiency, 
> > subject to a case-by-case audit. These would be things like:
> > - dict.iteritems() -> dict.items()
> > - dict.items() -> list(dict.items())
> > 4. Install Python 3 on macOS Sierra and Mojave bots
> > 5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts like 
> > clean-webkit, merge-results-json, webkit-patch)
> > 6. Convert testing scripts and webkitpy to Python 3 in a single change
> > 
> > The trouble I foresee us encountering with any scheme which attempts a 
> > conversion which retains both Python 2.7 and Python 3 compatibility is code 
> > like this:
> > 
> > for expectation_string, expectation_enum in 
> > test_expectations.TestExpectations.EXPECTATIONS.iteritems():
> > ...
> > 
> > In this code, the EXPECTATIONS dictionary is thousands of elements long. In 
> > Python 2.7, iteritems() gives us an iterator instead of creating a new 
> > list, like items() would. In Python 3, iteritems() doesn’t exist, but 
> > items() does, and now gives us an iterator instead of creating a new list. 
> > The trouble here is that, in this case, creating a new list will be very 
> > expensive, expensive enough that we might manage to impact the testing run. 
> > There isn’t really an elegant way around this problem if we want to support 
> > both Python 2.7 and Python 3, other than defining different code paths for 
> > each language.
> 
> The official Python 3 transition documentation has a fairly elegant solution 
> to this, actually??
> 
> https://legacy.python.org/dev/peps/pep-0469/
> 
> See "Migrating to the common subset of Python 2 and 3” — you define different 
> iteritems() helpers in the two cases. Seems pretty reasonable to me.

Instead of rolling our own, I would rather use Six (mentioned above). It
covers all the differences with the different “.iter*()” methods:

  https://six.readthedocs.io/#six.iterkeys
  https://six.readthedocs.io/#six.itervalues
  https://six.readthedocs.io/#six.iteritems
  https://six.readthedocs.io/#six.iterlists
  ...

> > There are other small gotchas as well. For example, ‘%’ is no longer a
> > protected character, which can actually change the behavior of regexes.
> > That’s why I think it’s better to just try and directly convert things
> > instead of attempting to be compatible with both Python 2.7 and Python 3.

In my experience some of the major troubles making a codebase compatible
with both Pythons are the string types:

  - In Python 2, “str” is also usable for binary data (basically it's backed
by a char[], while “unicode” is actual text which may contain any code
point.
  - In Python 3, “string” is kind of the old “unicode” (textual data),
and “bytes” is kind of “string” but only holds binary data and in
general cannot be used where a string would have been used.

The Six module helps a bit with the text types (see “six.text_type” and
“six.binary_type”.

Regards,
—Adrián


pgpuX1RTgiWOr.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

[Adrian Perez de Castro]

Hello,

On Thu, 27 Jun 2019 08:36:22 +0200, Xan  wrote:

> Sorry about that. We'll take care of it ASAP.
> 
> Cheers,
> Xan
> 
> On Thu, Jun 27, 2019, 06:23 Fujii Hironori  wrote:
> 
> > jsc-i368 EWS is still failing.
> > Who is igalia-jsc-i386-ews bot maintainer?

Done, this EWS has now CMake 3.13 as well (from the Debian Stretch backports
repository). I managed to miss this bot yesterday — sorry.

Please do let me know if you find any other issues with our bots :)

Cheers,
—Adrián

> > On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
> > wrote:
> >
> >> Hi,
> >>
> >> I'm going to bump cmake_minimum_required version to 3.10 for
> >> shining new features.
> >>
> >> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> >> https://bugs.webkit.org/show_bug.cgi?id=199181
> >>
> >>
> >> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> >> update your CMake on your bots?
> >>
> >> If you are using CMake Visual Studio generator, you need CMake
> >> 3.12 or newer to avoid an unnecessary recompilation issue.
> >>
> >> AppleWin port seems still using old Visual Studio 2017. If it
> >> will switch to Visual Studio 2019 for better C++17 support,
> >> Visual Studio 2019 needs CMake 3.14 or newer.
> >> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
> >>
> >> Happy WebKit 18th
> >> birthday
> >> 🎂
> >>
> >> -- Fujii
> >>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
Non-text part: text/html
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


pgpcWObglL2YY.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows 32-bit support?

[Adrian Perez de Castro]

I was mistaken about one thing (sorry!), please read below...

On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro  
wrote:
> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro  
> wrote:
> > It's great that you find our stable branches helpful, but keep in mind 
> > those branches do not include Windows-specific fixes.
> > 
> > On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar 
> >  wrote:
> > > Right. Actually the problem is in 32-bit Windows platform. I see that 
> > > the JIT support has been dropped some time ago, and CLOOP based 
> > > backend seems to be unstable on 32-bit Windows. Any thoughts on that?
> > 
> > So I'm not an expert here, but I understand there are three ways you 
> > can build JSC:
> > 
> > (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
> > (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
> > (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
> > 
> > (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
> > 
> > I believe that nowadays the only 32-bit platforms supported by JIT are 
> > Linux, and there only for ARM and MIPS, not x86. So you're almost 
> > certainly going to need to use -DENABLE_JIT=OFF. That eliminates option 
> > (1).
> 
> JIT works on x86 as long as your CPU has support for SSE2 instructions.

Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.

(The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
made to work on 32-bit x86, support for SSE2 will be needed.)
 
> > You say the cloop seems unstable for you, which is option (3). So 
> > perhaps you should try option (2) if you haven't already. I'm not 
> > actually sure if that works, because I'm not an expert, which is why I 
> > added that (?) to it. But at least it couldn't hurt to try.
> 
> Option (2) would be using the LLint bytecode interpreter, without JIT.
> 
> In principle CLoop is expected to work “everywhere” because the interpreter
> is generated C/C++ code, which gets then built by the same compiler used to
> build all the rest of WebKit.
> 
> > Maybe the Windows port maintainers know more about the status of 32-bit 
> > Windows support?
> 
> Cheers,
> —Adrián


pgp2iggwRcXVA.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows 32-bit support?

[Adrian Perez de Castro]

On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro  
wrote:
> It's great that you find our stable branches helpful, but keep in mind 
> those branches do not include Windows-specific fixes.
> 
> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar 
>  wrote:
> > Right. Actually the problem is in 32-bit Windows platform. I see that 
> > the JIT support has been dropped some time ago, and CLOOP based 
> > backend seems to be unstable on 32-bit Windows. Any thoughts on that?
> 
> So I'm not an expert here, but I understand there are three ways you 
> can build JSC:
> 
> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
> 
> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
> 
> I believe that nowadays the only 32-bit platforms supported by JIT are 
> Linux, and there only for ARM and MIPS, not x86. So you're almost 
> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option 
> (1).

JIT works on x86 as long as your CPU has support for SSE2 instructions.

> You say the cloop seems unstable for you, which is option (3). So 
> perhaps you should try option (2) if you haven't already. I'm not 
> actually sure if that works, because I'm not an expert, which is why I 
> added that (?) to it. But at least it couldn't hurt to try.

Option (2) would be using the LLint bytecode interpreter, without JIT.

In principle CLoop is expected to work “everywhere” because the interpreter
is generated C/C++ code, which gets then built by the same compiler used to
build all the rest of WebKit.

> Maybe the Windows port maintainers know more about the status of 32-bit 
> Windows support?

Cheers,
—Adrián


pgpd174IOnvF7.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Tadeu and Robin are now WebKit reviewers

[Adrian Perez de Castro]

On Mon, 10 Jun 2019 15:49:23 -0700, Saam Barati  wrote:
 
> Tadeu and Robin are both now WebKit reviewers. Join me in congratulating
> them. Please ask them to review your code! They both have a focus in JSC.

Wooho, congrats! \o/


—Adrián


pgpNWgUjWt_AR.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Jonathan Bedard is now a WebKit Reviewer!

[Adrian Perez de Castro]

On Wed, 08 May 2019 15:30:21 -0700, Lucas Forschler  
wrote:
 
> I would like to announce that Jonathan Bedard is now a WebKit Reviewer.
> Jonathan goes by ‘jbedard’ on #webkit.  His expertise is tools,
> infrastructure, and webkitpy.

\o/

> Please join me in congratulation him, and feel free to send patches his way!
> 
> 🎉 Congratulations Jonathan! 🎉

Congrats Jonathan!


—Adrián


pgpXO4AA3cNkU.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EWS bots aperez-{wpe, gtk}-gcc6-ews will be offline for some days

[Adrian Perez de Castro]

Hi WebKittens,

These two EWS bots which I run on my build machine will be offline for some
days due to an office relocation. The machine will be taken on Monday to its
new location, but it may take a few days more for the bots to come online
depending on how quick the ISP will be in setting up our Internet connection
there.

Luckily, we have EWS bots in other locations, so only two will be down in the
meantime — hopefully the patch queue won't lag too much.  If the queue grows
long, an option is asking someone else from Igalia to spin up a couple of EWS
bots.

Sorry for the inconvenience,

—Adrián


pgp98TXVNIH6V.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkitgtk 2.22.6 tarball inaccessible

[Adrian Perez de Castro]

Hello,

On Fri, 22 Mar 2019 11:59:46 -0700, "niveditha@oracle.com" 
 wrote:
 
> I am trying to download the webkitgtk 2.22.6 tarball from 
> https://webkitgtk.org/releases/webkitgtk-2.22.6.tar.xz
> 
> and get "You don't have permission to access 
> /releases/webkitgtk-2.22.6.tar.xz on this server"
> 
> I realize this is an older tarball and not the latest one of the 2.22.x 
> branch, but was wondering if there is a reason its blocked from being 
> downloadable (are distros not supposed to be using 2.22.6?)

It was an issue with the file permissions and the web server was not able
to read that particular file. It should be fixed now, so please do try
downloading the file.

Sorry for the inconvenience, and thank you for letting us know.

Regards,
-Adrián


pgpaMAIYyIfXt.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Licensing terms for content from developer.apple.com

[Adrian Perez de Castro]

Hi again,

On Tue, 19 Feb 2019 18:54:43 +0200, Adrian Perez de Castro  
wrote:
 
> Lately we have been working on enabling the content extensions feature
> in the GTK and WPE WebKit ports [1], and we would like to include in the
> generated API documentation a reference of the JSON source format which
> WebKit consumes.
> 
> There is one page [2] at “developer.apple.com” which already includes
> a description, and I was wondering if it would be possible to copy some
> part from it. What is the licensing situation for the contents in that
> page? Would it be acceptable to copy the tables with the possible values
> for the different objects, and some of the paragraphs, in our documentation?

Is there anyone who can comment on this? In a few weeks I'll take silence
as a sign that it would be better that we write our documentation for the
content extension JSON format from scratch =)

Cheers,

-Adrián

> ---
> [1] https://bugs.webkit.org/show_bug.cgi?id=167941
> [2] 
> https://developer.apple.com/documentation/safariservices/creating_a_content_blocker?language=objc


pgpo7pNl4HrSv.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Queries regarding few Components in webkit

[Adrian Perez de Castro]

On Sun, 17 Mar 2019 21:03:33 +0530, Rajagopalan Gangadharan 
 wrote:
> This is great, thank you so much!

You're welcome!

Quick addition: after sending my previous e-mail I kept browsing around
the Haiku website, and it looks like one of the ideas for this year's
Google Summer of Code is precisely migrating to WebKit2. You can see the
full list of GSoC ideas here:

  https://www.haiku-os.org/community/gsoc/2019/ideas

Maybe you will want to apply, but at least you can see there that there
is one contact person (IRC: PulkoMandy) who would be mentoring the porting
effort, so I suppose it would be good to contact them to coordinate :)

Cheers,


-Adrián

> On Sun, Mar 17, 2019 at 8:59 PM Adrian Perez de Castro 
> wrote:
> 
> > Hello,
> >
> > On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro <
> > mcatanz...@igalia.com> wrote:
> >
> > > It might be more realistic to try making an existing WebKit port work
> > > on Haiku (either WebKitGTK or WPE WebKit) rather than try to create an
> > > entirely new port.
> >
> > You are forgetting that there is an existing, well-maintained WebKit1
> > port for Haiku. *That* should be the basis for a port to WebKit2. The
> > repository is available at:
> >
> >   https://github.com/haiku/webkit
> >
> > As a matter of fact, according to the README in that repository, there
> > is already some ongoing effort to support WebKit2 in the Haiku port. You
> > should look into that instead of potentially wasting time redoing work
> > that has already been done by others.
> >
> > > Previously you indicated that you were planning to create a new network
> > > backend for Haiku; that alone would be enough to occupy a developer
> > > full-time for a long while and doesn't seem very realistic. But that's
> > > just one small portion of developing and maintaining an entire WebKit
> > > port. Taking an existing port and making it run on Haiku would be much
> > > easier.
> >
> > Haiku has its own “libnetapi” system library, so IMO the goal should be
> > making WebKit use it (if it doesn't already — note that I am not familiar
> > with the insides of the Haiku WebKit port). You can see it in the upstream
> > repository here:
> >
> >   https://git.haiku-os.org/haiku/tree/src/kits/network/libnetapi
> >
> > Its API documentation is available here:
> >
> >   https://www.haiku-os.org/docs/api/group__network.html
> >
> > If using this is impossible, hard, or would need a lot of work in Haiku's
> > network library, then I would suggest using WebKit's libcurl network
> > backend
> > to have something working at first (because the code it's already in the
> > WebKit repository and is known to work), and *then* once you have the rest
> > of the WebKit2 port running, look into switching from libcurl to Haiku's
> > built-in network library.
> >
> > > On Sun, Mar 17, 2019 at 7:38 AM, Rajagopalan Gangadharan
> > >  wrote:
> > > > What is a WKRetainPtr ? where can I use it?
> > >
> > > It's a smart pointer for holding ownership of C API types, which you
> > > shouldn't be using. The C API is not stable and is slowly being
> > > retired. If you really don't want to use WebKitGTK or WPE WebKit, then
> > > you should create your own separate public API based on WebKit
> > > internals, not based on the C API. If you use the C API, your port will
> > > be difficult to maintain in the long run.
> >
> > Agreed. Your public API should use Haiku types and existing conventions.
> > A good first step would be to check the exiting API for Haiku's WebKit1
> > port (see above, I linked the repository), keep the parts that still make
> > sense in a WebKit2 world, and add and modify others as necessary.
> >
> > You can get more inspiration for API design from:
> >
> >  - The Haiku documentation itself: https://www.haiku-os.org/docs/api/
> >  - The public APIs for existing WebKit2 ports:
> > * The GTK/WPE ports (both have a rather similar GLib-based API):
> >   https://webkitgtk.org/reference/webkit2gtk/stable/index.html
> > * The Qt port (the code for it is also in its own repo):
> >   https://github.com/annulen/webkit
> > * The Cocoa ports (which has both Objective-C and Swift APIs):
> >   https://developer.apple.com/documentation/webkit
> >
> > > > What is WKContext and WKView (I think Webview is different from
> > > > WKView) -> as far my understanding is Context like t

Re: [webkit-dev] Queries regarding few Components in webkit

[Adrian Perez de Castro]

Hello,

On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro  
wrote:
 
> It might be more realistic to try making an existing WebKit port work 
> on Haiku (either WebKitGTK or WPE WebKit) rather than try to create an 
> entirely new port.

You are forgetting that there is an existing, well-maintained WebKit1
port for Haiku. *That* should be the basis for a port to WebKit2. The
repository is available at:

  https://github.com/haiku/webkit

As a matter of fact, according to the README in that repository, there
is already some ongoing effort to support WebKit2 in the Haiku port. You
should look into that instead of potentially wasting time redoing work
that has already been done by others.

> Previously you indicated that you were planning to create a new network 
> backend for Haiku; that alone would be enough to occupy a developer 
> full-time for a long while and doesn't seem very realistic. But that's 
> just one small portion of developing and maintaining an entire WebKit 
> port. Taking an existing port and making it run on Haiku would be much 
> easier.

Haiku has its own “libnetapi” system library, so IMO the goal should be
making WebKit use it (if it doesn't already — note that I am not familiar
with the insides of the Haiku WebKit port). You can see it in the upstream
repository here:

  https://git.haiku-os.org/haiku/tree/src/kits/network/libnetapi

Its API documentation is available here:

  https://www.haiku-os.org/docs/api/group__network.html

If using this is impossible, hard, or would need a lot of work in Haiku's
network library, then I would suggest using WebKit's libcurl network backend
to have something working at first (because the code it's already in the
WebKit repository and is known to work), and *then* once you have the rest
of the WebKit2 port running, look into switching from libcurl to Haiku's
built-in network library.
 
> On Sun, Mar 17, 2019 at 7:38 AM, Rajagopalan Gangadharan 
>  wrote:
> > What is a WKRetainPtr ? where can I use it?
> 
> It's a smart pointer for holding ownership of C API types, which you 
> shouldn't be using. The C API is not stable and is slowly being 
> retired. If you really don't want to use WebKitGTK or WPE WebKit, then 
> you should create your own separate public API based on WebKit 
> internals, not based on the C API. If you use the C API, your port will 
> be difficult to maintain in the long run.

Agreed. Your public API should use Haiku types and existing conventions.
A good first step would be to check the exiting API for Haiku's WebKit1
port (see above, I linked the repository), keep the parts that still make
sense in a WebKit2 world, and add and modify others as necessary.

You can get more inspiration for API design from:

 - The Haiku documentation itself: https://www.haiku-os.org/docs/api/
 - The public APIs for existing WebKit2 ports:
* The GTK/WPE ports (both have a rather similar GLib-based API):
  https://webkitgtk.org/reference/webkit2gtk/stable/index.html
* The Qt port (the code for it is also in its own repo):
  https://github.com/annulen/webkit
* The Cocoa ports (which has both Objective-C and Swift APIs):
  https://developer.apple.com/documentation/webkit

> > What is WKContext and WKView (I think Webview is different from 
> > WKView) -> as far my understanding is Context like the context menu 
> > an os offers (ie right clicking provides copy,paste etc.)
> 
> No, it's a library context object (corresponding to WebProcessPool). If 
> you have two web contexts, you effectively have two separate instances 
> of WebKit (e.g. separate NetworkProcess, separate data storage 
> directories, separate everything) to avoid shared global state.
> 
> > and View is where rendering takes place?
> 
> This is correct.
> 
> Good luck,

I also wish you a fun time hacking on WebKit, but *please* do make sure to
contact the Haiku developers and coordinate with them to avoid duplicating
efforts. Making a new WebKit port is a big task, and you will certainly have
much better chances of succeeding by making the most of existing work and
having the support of developers with knowledge of the target platform.

Regards,


-Adrián

P.S: I am a bit of a BeOS fan myself, unfortunately I haven't used daily for a
long time, and never developed anything for the platform. I would love to see
Haiku have a working WebKit2 port for the platform!


pgpVMZvgfbZ_K.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reminder regarding formatting uint64_t

[Adrian Perez de Castro]

Hello,

On a related note...

On Wed, 27 Feb 2019 16:35:39 -0600, Michael Catanzaro  
wrote:
 
> For the past several years, I've been regularly fixing -Wformat 
> warnings that look like this:
> 
> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning: 
> format ‘%llu’ expects argument of type ‘long long unsigned 
> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned 
> int’} [-Wformat=]
>  RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage 
> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when 
> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
>   
> ^~
>  this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
>
> 
> Problem is that uint64_t is long long unsigned int on Mac, but only 
> long unsigned int on Linux. It can't be printed with %llu, so please 
> use PRIu64 instead. E.g.:
> 
> LOG("%llu", pageID); // wrong
> LOG("%" PRIu64, pageID); // correct
>
> This is good to keep in mind for any sized integer types, but uint64_t 
> in particular since this is what causes problems for us in practice.

Related tip: if you want to print a “size_t” or “ssize_t”, use the
corresponding format specifiers “%zu” and “%zs” — do not cast the value
to some “big enough” integral type. Examples:

  size_t byteSize = /* ... */;
  LOG("size: %llu bytes", static_cast(byteSize)); // meh
  LOG("size: %zu bytes", byteSize); // better!

This is not as much of an issue as the issue with “uint64_t” mentioned by
Michael, but still nice to keep in mind as well.

Cheers,


-Adrián


pgpq5ut2IWFsf.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Git

[Adrian Perez de Castro]

On Wed, 20 Feb 2019 22:30:22 +0300, Konstantin Tokarev  
wrote:
 
> 20.02.2019, 22:27, "Bug Tracker" :
>
> > Sorry, for the anonymous email. I opted for it because the list archives 
> > are public and concluded that it's not that useful to reveal my identity 
> > for the purposes of this question.
> >
> > In short, however, I am a graduate student interested in using WebKit for 
> > an academic project and thought that I should ask first about the progress 
> > on Git migration, since it would be far easier for me to work with WebKit 
> > then.
> 
> You can use public Git mirror:
> 
> https://github.com/WebKit/webkit

You can even do upstream WebKit development using exclusively Git, even
without needing to use the GitHub mirror, see:

  https://trac.webkit.org/wiki/UsingGitWithWebKit#Checkout

Even for things which would normally require Subversion, “git svn” can be
used 99.9% of the time. For the usual “pull latest code from master, make
a branch, prepare a patch, upload patch to Bugzilla for landing” Subversion
is not needed at all. Just make sure you have 20 to 30 GiB of space for the
Git checkout and building WebKit.

For other more specialized workflows, like checking out release branches and
version tags you will need some “git svn” usage; but IMO that is still nicer
than having to use Subversion.

I hope this helps!


-Adrián


pgpE6Sz_YtHI3.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Licensing terms for content from developer.apple.com

[Adrian Perez de Castro]

Hello WebKittens,

Lately we have been working on enabling the content extensions feature
in the GTK and WPE WebKit ports [1], and we would like to include in the
generated API documentation a reference of the JSON source format which
WebKit consumes.

There is one page [2] at “developer.apple.com” which already includes
a description, and I was wondering if it would be possible to copy some
part from it. What is the licensing situation for the contents in that
page? Would it be acceptable to copy the tables with the possible values
for the different objects, and some of the paragraphs, in our documentation?

Best regards,


-Adrián

---
[1] https://bugs.webkit.org/show_bug.cgi?id=167941
[2] 
https://developer.apple.com/documentation/safariservices/creating_a_content_blocker?language=objc


pgpLPIIk2tm4S.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename AtomicString to AtomString

[Adrian Perez de Castro]

Hi,

On Wed, 30 Jan 2019 08:31:49 -0800, Darin Adler  wrote:

> So, did we reach consensus that we should rename AtomicString to AtomString?

Let's go with it 👍

Cheers,

-Adrián


pgpCXmm7f6QX0.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

[Adrian Perez de Castro]

Hello all,

On Fri, 14 Dec 2018 06:46:20 +0900, Fujii Hironori  
wrote:

> I would like to announce that Don Olmstead (dolmstead on #webkit) and
> Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked
> on WinCairo port and PlayStation port, and Ross worked on Web
> Inspector Layers Tab, too.
> 
> Please join me in congratulating Don and Ross, and send them patches
> to review.

Congrats, Don and Ross! It's great to have more reviewers around who can
give insight about Windows for patches that touch cross-platform code :)

-Adrián


pgpZJSleDJZzn.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Adrian Perez de Castro]

Hello,

On Fri, 14 Dec 2018 14:02:39 -0800, Saam Barati  wrote:
 
> > On Dec 14, 2018, at 1:59 PM, Chris Dumez  wrote:
> > 
> >> On Dec 14, 2018, at 1:56 PM, Saam Barati  >> > wrote:
> >> 
> >>> On Dec 14, 2018, at 1:54 PM, Saam Barati  >>> > wrote:
> >>> 
>  On Dec 14, 2018, at 1:37 PM, Chris Dumez   > wrote:
>  
>  Hi,
>  
>  I have now been caught twice by std::optional’s move constructor. It 
>  turns out that it leaves the std::optional being moved-out *engaged*, it 
>  merely moves its value.
>  
>  For example, testOptional.cpp:
>  #include 
>  #include 
>  
>  int main()
>  {
>  std::optional a = 1;
>  std::optional b = std::move(a);
>  std::cout << "a is engaged? " << !!a << std::endl;
>  std::cout << "b is engaged? " << !!b << std::endl;
>  return 0;
>  }
>  
>  $ clang++ testOptional.cpp -o testOptional -std=c++17
>  $ ./testOptional
>  a is engaged? 1
>  b is engaged? 1
>  
>  I would have expected:
>  a is engaged? 0
>  b is engaged? 1
> >>> I would have expected this too.

This is also what I would have expected.

>  This impacts the standard std::optional implementation on my machine as 
>  well as the local copy in WebKit’s wtf/Optional.h.
>  
>  As far as I know, our convention in WebKit so far for our types has been 
>  that types getting moved-out are left in a valid “empty” state.
> >>> I believe it's UB to use an object after it has been moved.
> >> I'm wrong here.
> >> Apparently objects are left in a "valid but unspecified state".
> >> 
> >> https://stackoverflow.com/questions/32346143/undefined-behavior-with-stdmove
> >>  
> >> 
> > I believe in WebKit, however, we’ve made sure our types are left in a valid 
> > “empty” state, thus my proposal for our own optional type that would be 
> > less error-prone / more convenient to use.
> I think your proposal is reasonable. I agree it's less error prone.
> 
> I think if we make this change, we should pull optional out of std and put it 
> in WTF, since we're now implementing behavior we will rely on being specified.

I am also in favor of having an implementation in WTF that empties the
optional after moving the value out from it.

Cheers,


-Adrián


pgpE_fxSDMoUF.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

[Adrian Perez de Castro]

Hi,

On Sat, 14 Jul 2018 12:28:40 -0500, Michael Catanzaro  
wrote:
 
> Fujii Hironori is now a WebKit reviewer. He has expertise in Windows 
> support, WebKitGTK+, and WebCore bugs. Please congratulate him and send 
> him patches to review!

Congratulations, Fujii! \o/

-Adrián


pgpJAuMBHiQ4B.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EWS for security bugs

[Adrian Perez de Castro]

Hello everybody,

On Mon, 9 Jul 2018 20:10:54 +,  wrote:

> WinCairo EWS is processing security bugs now so we're good to go.

Nice!

> From: webkit-dev  On Behalf Of Daniel 
> Bates
> Sent: Thursday, June 28, 2018 1:53 PM
> To: WebKit Development Mailing List 
> Subject: [webkit-dev] EWS for security bugs
> 
> Hi all,
> 
> All Mac and iOS EWS bots now process security bug patches. We are working to
> configure the Apple Windows EWS bots and the WinCairo EWS bots should follow
> shortly. I do not know who maintains the GTK and WPE EWS bots. If you
> maintain one of these bots then please email me directly so that we can get
> you setup.
>
> [...]

I have just finished reconfiguring the EWS bots for the GTK+ and WPE
ports, which will be going through security patches as well from now on.

\o/

Best regards,


-Adrián


pgpmXo_z7O5VS.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] GTK+ EWS bot sick?

[Adrian Perez de Castro]

Hi,

On Tue, 3 Jul 2018 19:23:31 -0700, Ryosuke Niwa  wrote:
> https://webkit-queues.webkit.org/patch/344243/gtk-wk2-ews
> 
> e.g. https://webkit-queues.webkit.org/results/8431213
> ICECC[28449] 18:15:59: flush_writebuf() failed Resource temporarily
> unavailable
> ICECC[28449] 18:16:01: write of source chunk to host 192.168.10.42
> ICECC[28449] 18:16:01: failed  Resource temporarily unavailable
> ICECC[28449] 18:16:01: got exception Error 15 - write to host failed
> (192.168.10.42)
> [4359/5075] Building CXX object
> Source/WebKit/CMakeFiles/WebKit.dir/WebProcess/InjectedBundle/InjectedBundleNavigationAction.cpp.o
> ICECC[28521] 18:17:11: flush_writebuf() failed Resource temporarily
> unavailable
> ICECC[28521] 18:17:13: write of source chunk to host 192.168.10.42
> ICECC[28521] 18:17:13: failed  Resource temporarily unavailable
> ICECC[28521] 18:17:13: got exception Error 15 - write to host failed
> (192.168.10.42)
> [4360/5075] Building CXX object
> Source/WebKit/CMakeFiles/WebKit.dir/WebProcess/InjectedBundle/InjectedBundlePageContextMenuClient.cpp.o
> ICECC[28528] 18:17:18: flush_writebuf() failed Resource temporarily
> unavailable
> ICECC[28528] 18:17:20: write of source chunk to host 192.168.10.42
> ICECC[28528] 18:17:20: failed  Resource temporarily unavailable
> ICECC[28528] 18:17:20: got exception Error 15 - write to host failed
> (192.168.10.42)
> ninja: build stopped: subcommand failed.

I did take a look at this, should be working better now, in particular
after landing a patch to avoid running too many linker processes at the
same time and going into an OOM situation.

If anyone hits this again, please let me know. There are still a couple
of things we can do to avoid poking the OOM killer [2].

Cheers,

---
[1] https://bugs.webkit.org/show_bug.cgi?id=187254
[2] Probably not in the list of “The 10 best Linux features” ¯\_(ツ)_/¯


pgpZhRZNJD4Kw.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JavaScriptCore on Fuchsia

[Adrian Perez de Castro]

Hello,

(Just a quick note, below.)

On Wed, 27 Jun 2018 21:35:40 -0700, Adam Barth  wrote:
> On Wed, Jun 27, 2018 at 8:05 PM Adam Barth  wrote:
> >
> > Hi Yusuke,
> >
> > For some reason, your original email missed my inbox.
> >
> > On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro  
> > wrote:
> > > On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI 
> > > wrote:
> > > > My suggestion is introducing Fushcia port, adding both
> > > > PLATFORM(FUSHCIA) and OS(FUSHCIA) ifdefs.
> > > > Use OS(FUSHCIA) when the change is b/c of Fushcia's APIs. And use
> > > > PLATFORM(FUSHCIA) to change
> > > > the policy of the released build (e.g. enabling / disabling FTL JIT
> > > > etc.).
> >
> > So far, I seem to be able to control those features on a build level
> > through CMake.
> >
> > > > By doing so, JSCOnly port also becomes available in Fushcia. And it
> > > > means that Fushcia port can benefit
> > > > from JSCOnly port's work for making WTF and JSC portable.
> >
> > Fuchsia appears to need to be a port in the sense of having an
> > OptionsFuchsia.cmake in order to set the target triple to
> > x86_64-unknown-fuchsia.  I didn't find any other uses of
> > CMAKE_CXX_COMPILER_TARGET in WebKit.  Is there some other mechanism
> > folks use to set the target triple (or maybe other folks aren't
> > crosscompiling using clang)?
> 
> I discovered CMAKE_TOOLCHAIN_FILE and figured out how to make this work:
> 
> https://bugs.webkit.org/show_bug.cgi?id=187133

Using CMAKE_TOOLCHAIN_FILE definitely should work, and if it ever breaks
we will want to fix things. This is what many cross-compilation systems
(example: Buildroot) are using for building the GTK+ and WPE ports, which
means we'll notice if any issue is introduced [1].

> > > I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would
> > > suffice? Then instead of a separate Fushcia port, we would just have
> > > the existing JSCOnly port running on Fuschia.
> >
> > That sounds like a good approach to start with.  If we run into
> > trouble, we might need to adjust.

As long as having only OS(FUCHSIA) satisfies your needs, I also think it
is simpler to avoid PLATFORM(FUCHSIA) and reusing the JSCOnly port for now.

Cheers,

 Adrián

---
[1] I'm subscribed to Buildroot's autobuilder (http://autobuild.buildroot.net)
for the “webkitgtk” package, which has been handy to fix quite some build
issues in the past :-)


pgpW67bSXk5wv.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Question about ARMv7 JIT maintenance by Apple

[Adrian Perez de Castro]

On Sat, 05 May 2018 02:45:02 +, Yusuke SUZUKI  wrote:
> On Sat, May 5, 2018 at 11:27 AM Filip Pizlo  wrote:
> 
> > We aren’t maintaining armv7.
> 
> OK, thanks. I'll replace ARMv7 disassembler with capstone based one once
> capstone is adopted :)

We are maintaining ARMv7 support at Igalia; but I think it is a good idea
to use Capstone for this architecture as well: we have a bit more time for
other things, while still having a good dissembler around 😉

Cheers,


--
 Adrián 🎩

> > -Filip
> >
> > > On May 4, 2018, at 7:01 PM, Yusuke SUZUKI  wrote:
> > >
> > > Hi WebKittens,
> > >
> > > JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures.
> > > While X86, X86_64, and ARM64 is maintained by build bots configured by
> > Apple,
> > > the other architectures are maintained by the community.
> > >
> > > Recently, I'm about to adopting capstone disassembler for MIPS and ARM.
> > > And I'm also wondering if ARMv7 can use it instead of our own
> > disassembler.
> > >
> > > So my question is, is ARMv7 JIT maintained by Apple right now? Or is it
> > maintained by the community?
> > > If Apple does not maintain it right now, I would like to drop ARMv7
> > disassembler and use capstone instead.
> > >
> > > Best regards,
> > > Yusuke Suzuki
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
Non-text part: text/html
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


pgpNna4tCE29R.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using compile_command.json in sources that go into Unified Sources

[Adrian Perez de Castro]

On Mon, 26 Mar 2018 07:54:38 -0500, Michael Catanzaro  
wrote:
> On Sat, Mar 24, 2018 at 6:03 PM, Cadu Bentzen  
> wrote:
> > I included calling this script at the end of the build-webkit (under 
> > a command line option) script. So far it has work for me, but I 
> > wonder if this is the right approach or if you already solved that in 
> > another way. 
> 
> Is compile_commands.json intended only for use by IDEs? If it's not 
> going to break anything, then this seems reasonable to me. I would go 
> ahead and submit a patch for review on bugs.webkit.org, and leave a 
> link to it in this thread.

At least I know also that the “scan-build” implementation in Python [1] uses
the compilation database (in my experience it is easier to get running than
Clang's, and is what I have used in the past to run the Clang analyzer on the
WebKit code).

I *think* that many tools like scan-build should work equally well regardless
of whether the compilation database contains the unifies or the individual
sources. But of course it's difficult to predict what every other tool will
do, so it's impossible to be sure :-\

Didn't we have a CMake flag that disabled unified sources completely? Maybe
people who want to use “compile_commands.json” with IDEs can just use that…

Cheers,


--
 Adrián 🎩


pgpxehPRGlYiz.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WTFCrash()

[Adrian Perez de Castro]

On Fri, 09 Mar 2018 12:59:01 -0600, Michael Catanzaro  
wrote:
> On Fri, Mar 9, 2018 at 5:34 AM, Adrian Perez de Castro 
>  wrote:
> > I would enable printing backtraces to -DENABLE_DEVELOPER_MODE=ON 
> > instead,
> > because they can be useful in release (well, or RelWithDebInfo) 
> > builds.
> 
> OK, let's do this, then. I don't want to make it impossible to solve 
> bugs on small embedded systems.

Great, thanks!

> I would really hate to work in an environment where you can't get a 
> proper backtrace... that sounds awful. :(

It is painful, yep ;-)

--
 Adrián 🎩


pgp9alhhTCP7C.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WTFCrash()

[Adrian Perez de Castro]

Hello,

Just a quick note below about the backtraces...

On Tue, 06 Mar 2018 23:09:18 -0600, Michael Catanzaro  
wrote:
 
> After [1], WTFCrash() is used only in debug builds on Darwin. For 
> Darwin release builds, inline assembly is used to trigger a SIGTRAP. I 
> experimented with this today and found it works quite badly on Linux, 
> somehow confusing gdb and clobbering the top frames of the stacktrace, 
> so I think we should leave that unchanged and keep it Darwin-only. So 
> this mail applies only to debug builds on Darwin, and to non-Darwin 
> ports.
> 
> Now, currently, WTFCrash() does three things:
> 
>  (1) Calls a user-configurable crash hook
>  (2) Print a low-quality backtrace to stderr
>  (3) Crash somehow:
>- If ASAN is used, with __builtin_trap() (that's SIGILL on Linux 
> x86_64)
>- Then with *(int *)(uintptr_t)0xbbadbeef = 0, which might fail to 
> crash if 0xbadbeef is a valid address, and is SIGSEGV otherwise
>- Then with __builtin_trap() if COMPILER(GCC_OR_CLANG)
>- Then with ((void(*)())0)() otherwise (presumably SIGSEGV or 
> SIGBUS, dunno)
> 
> This is all rather more complicated than it needs to be.
> 
> First off, the crash hook is (almost) unused and should simply be 
> removed, see [2].
> 
> Next, the low-quality backtrace. Does anyone think this is useful? [...]

In some cases I have worked with embedded devices where it was extremely
difficult to even run “gdbserver”, mainly due to memory constraints, and
having the limited backtrace from WTFCrash() can save the day in those
cases.

I think it's perfectly fine to skim over and ignore the backtraces
printed by WTFCrash() if one has a better way of debugging.

> [...] It's mainly annoying to me, [...]

This is not a good reason to remove them. Just don't use them and skip
reading them and you are done ;-)

> [...] because it's not anywhere near as good as a proper backtrace that
> shows stack members, [...]

True, but sometimes it's all we can have (see above), which is always
better than nothing.

> [...] it's mangled so function names are unnecessarily-difficult to read,

Pipe the output to “c++filt” and you will get back demangled names.
Nifty little tool :D

> [...] and it takes all of five seconds to get a much nicer one with
> modern Linux developer tools.

That is, *IF* one has access to modern developers tools.

> [...] If other developers like it, perhaps we could keep it for debug builds
> only, and skip right to the crashing in release builds? I suppose we could
> keep printing it always if there is desire to do this, because it has never
> caused any problems with Linux crash telemetry and doesn't seem to be
> harming anything, but otherwise my instinct is to simplify.

I would enable printing backtraces to -DENABLE_DEVELOPER_MODE=ON instead,
because they can be useful in release (well, or RelWithDebInfo) builds.

Cheers,


--
 Adrián 🎩


pgpYrFm0MJcLF.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Disabling the 32-bit JITs by default.

[Adrian Perez de Castro]

Hello everybody,

On Mon, 19 Feb 2018 13:43:38 -0600, Guillaume Emont  
wrote:
> Quoting Filip Pizlo (2018-02-19 13:05:27)
> > 
> > > On Feb 19, 2018, at 10:53 AM, Guillaume Emont  
> > > wrote:
> > > 
> > > Hi Keith,
> > > 
> > > We at Igalia have been trying to provide a better story for 32-bit
> > > platforms, in particular for Armv7 and MIPS. These platforms are very
> > > important to us, and disabling JIT renders many use cases impossible.
> > 
> > What use cases?
> 
> I'm not sure of how much I can elaborate here, but in this particular
> case that was for a set-top-box UI.
> 
> > I realize that having a JIT is good for marketing, but it’s better to have
> > a stable and well-maintained interpreter than a decrepit JIT. Right now
> > the 32-bit JIT is basically unmaintained.

*Was* basically unmaintained a few months ago.

I agree that in many cases the JIT may be a marketing point, that not every
application benefits from it, and that some applications may be better off
using more CPU and saving memory instead by not having the JIT. Yet many
applications *do* work better with a JIT — otherwise we would not be having
this discussion, and the proposal would be to completely remove the JIT
support, for all platforms ;-)

> Indeed these platforms used to be practically abandoned in WebKit. I
> don't think that is true any more though. We've been working on fixing
> this and getting mips32 and armv7+thumb2 to pass all the tests. We have
> achieved that for mips32[1] and we are almost there for armv7[2]. I
> would appreciate it if you could acknowledge that effort.
> 
> [1] https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release
> [2] 
> https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release

When we took the decision at Igalia of stepping up and work on keeping the
32-bit JIT support alive, we had only one person available to work full-time
with the needed knowledge.

It was lucky that Guillaume could start right away when this topic was last
discussed, but finding more developers to work on JSC is not trivial. Some of
us have been even chipping in now and then to review patches — sometimes in
our free time, like my informal reviews of patches for MIPS. Now we have a
second person who can devote time to JSC, so I would expect things to get even
better.

> > > We want to continue this effort to support these platforms. We have been
> > > short on resources for that effort, which is why we did not realize
> > > early enough that more mitigation was needed for 32-bit platforms. We
> > > now have grown our team dedicated to this and we are hopeful that we
> > > will avoid that kind of issue in the future.
> >
> > I feel like I’ve heard this exact story before.  Every time we say that
> > there isn’t any effort going into 32-bit, y’all say that you’ll put more
> > effort into it Real Soon Now.  And then nothing happens, and we have the
> > same conversation in 6 months.
>
> I'm sorry it took us time to grow our team for this purpose, but that is
> now a reality since the beginning of this month. And beside that, I
> think you can agree that there has been significant progress on that
> aspect, we were very far from having a green tree on mips32 about a year
> ago, when we still had hundreds of test failures.

Also, we have been playing catch-up to get the 32-bit platforms in shape,
without working on something more visible. This is the kind of churn that
often goes unnoticed.

> > > We are working on a plan to mitigate Spectre on 32-bit platforms. We
> > > would welcome community feedback on that, as well as what kinds of
> > > mitigations would be considered sufficient.

Now that you mention plans: It would be extremely useful for us to have an
idea of what's the JSC roadmap for the next few months. Being on the same page
in this regard would allow us all to coordinate better, and better plan the
focus of work on our side.

> > > Regarding your patch, I think you should note that some specific 32-bit
> > > CPUs are immune to Spectre (at least the Raspberry Pi[1] and some
> > > MIPS[2] devices), I think the deactivation should be done at run-time
> > > for CPUs not on a white list.
> >
> > Keith’s main point is that the presence of 32-bit makes it harder to
> > implement mitigations for 64-bit. I don’t think it’s justifiable to hold
> > back development of 64-bit Spectre mitigations because of a hardly-used
> > and mostly-broken 32-bit JIT port that will be maintained by someone Real
> > Soon Now.

Could you provide a concrete example of a mitigation for 64-bit platforms that
would not be possible unless the code for 32-bit JIT support is removed?
 
Best regards,


--
 Adrián 🎩


pgpDv1NhM4H8W.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

[Adrian Perez de Castro]

Hello, everybody.

On Tue, 12 Dec 2017 01:29:42 +0100, Carlos Alberto Lopez Perez 
 wrote:
> On 08/12/17 18:07, Lucas Forschler wrote:
> > If the GTK team wanted to support making these accessible,
> > they have everything they need. They could either choose to open up
> > their firewall so external folks could access them. Or, they could put
> > full archives on build.webkit.org  (which would
> > be transferred to s3/webkit build archives).
> > 
> > Maybe someone over there would be willing to take on this work if it is
> > in their budget. (Both time and bandwidth)
> >
> 
> 
> Hi Lucas, Mathias, et all.
> 
> This is bit more complex that it seems. I will try to explain.
> 
> The built products the WebKitGTK+ bots currently generate are being
> uploaded to a local server that was only reachable from the Igalia
> intranet [1]. I have just changed that, and the build products should
> be now accesible for everybody at:
> 
> http://webkitgtk-release.igalia.com/built-products/
> (also available via https if you prefer)
> 
> Keep in mind that currently we delete the built products after 10 hours,
> so don't expect to find there more than the very last few builds.
> That is just enough time for the test bots to download and test them.
> 
> We are happy on configuring a less aggressive purging of this files to
> keep them available for much longer. We can as well make this resource
> available from a more official domain (like webkit.org or webkitgtk.org)
>  
> But before doing that I will like to know if this files will be useful
> for you in the end (or not). See below.
> 
> If you download one of those build products and try to run it on your dev
> machine you are likely to have some problems with the shared libraries.
> 
> The main issue is that this binaries are linked against a bunch of libraries
> that we build in a internal JHBuild, and will likely differ from the ones
> shipped by your distro.
> 
> To test it, you can download one of this zip files and try running:
> 
> for JSC:
> LD_LIBRARY_PATH=$(pwd)/lib bin/jsc
> 
> for WebKit:
> LD_LIBRARY_PATH=$(pwd)/lib WEBKIT_EXEC_PATH=$(pwd)/bin 
> WEBKIT_INJECTED_BUNDLE_PATH=$(pwd)/lib bin/MiniBrowser
> 
> 
> Perhaps the JSC binary works because it has few dependencies (libicu and
> glib mainly), but I doubt the WebKit one will do. Your mileage may vary.

JSC binaries should indeed be easy to move from one system to another.
 
The public API in GLib has been stable for a long time, so I would not
expect it to be an issue when linking dynamically. In the case of ICU, the
public API changes now and then, and with different GNU/Linux distros
providing different versions I would expect it to be a problem.

As for WebKitGTK+ (MiniBrowsert, libwebkit2gtk, etc.) I would expect moving
the built binaries to other systems quite problematic. The only really safe
way I see is including *all* the dependency libraries from the JHBuild in the
downloadable archives.
 
> And this will be only for the 64-bit builds. Our current 32-bit buildbots
> are test&build ones, which means they don't currently generate and upload
> a built-product. They just test it after building it and then discard it.
> There maybe the possibility of adding an extra step to add the upload in
> case you find this built products useful.
> 
> Trying to look forward for a more elegant solution I tried to generate a
> static build of JSC with the JSCOnly port, but I failed when trying to
> link statically with libicu. I have reported that on the bug below:
> https://bugs.webkit.org/show_bug.cgi?id=180678

Statically linking the “jsc” binary would work well here, I think. Like I
mentioned above, probably dynamically linking GLib would be fine, and only ICU
needs to be statically linked for good. Then again, once we start linking
statically... what's 1 MiB more in the text section? :-)

> Let me know your thoughts.
> 
> Regards
> ---
> 
> [1]
> We do that because the server that generates the built product as well as the
> others that donwload it for testing are on the same LAN. So it makes little
> sense for us to daily upload and download gigabytes worth of data to 
> Internet, 
> when we can just serve the resources locally.
> 
> Doing that will make every build slower because then the build-only bot
> will have to wait for an upload to Internet rather than to a local server,
> as well the test-only bot will have to wait for a download from Internet. 
> Our bandwith to Internet is much less than a gigabit LAN.


pgpLTBDGExdlX.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

[Adrian Perez de Castro]

Hi Fred,

On Mon, 23 Oct 2017 17:42:29 +0200, Frédéric WANG  wrote:
 
> There have been some discussions recently on
> https://bugs.webkit.org/show_bug.cgi?id=177744 regarding the relevance
> of the compile-time flag for MathML. Discussing with Olivier during the
> Web Engines Hackfest, it seems he only had disabled MathML in his
> project because he thought it would reduce binary size. However, he was
> not really sure this actually had a significant impact. AFAIK, the only
> dependencies needed for MathML are the font libraries but they are
> already used for text layout. The implementation is only a few
> element/rendering files plus some changes here and there.

From your description it sounds that what takes more disk space in MathML are
the needed math fonts, and that the amount of code added to WebKit when built
is in the order of hundreds of kilobytes, at most (BTW, do you have figures of
MathML enabld vs. disabled to confirm?). That being the case, it seems fine to
me that MathML support is always enabled.

Usually my main concern with removing compilation guards is forcing additional
usage of megabytes of disk and/or memory in embedded platforms (which is, for
example, the case for ENABLE_VIDEO: for the GTK+ and WPE ports it completely
avoids the GStreamer dependency, which saves tens of megabytes!). But keeping
the guards to save just a few hundreds of kilobytes is certainly not worth it,
and in this case embedders can choose to not ship the math fonts.

TL;DR: Fine by me, as it seems the compile flag only saves a few kilobytes in
the built binaries, and the math fonts can't be skipped anyway by embedders.

Best regards,


--
 Adrián 🎩



pgp7R6bRrzRM0.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Adrian Perez de Castro]

On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba  
wrote:

> [...]
>
> Maybe it will be hard to say good bye to 32-bit architecutres
> for many people, but please, it's 2017 now, the first ARMv8 SoC
> is out 4 years ago, the first AMD64 CPU is out 14 years ago.

While it's true that amd64/x86_64 has been around long enough to not have to
care (much) about its 32-bit counterpart; the same cannot be said about ARM.
It would be great to be able to say that 32-bit ARM is well dead, but we are
not there yet.

If we take x86_64 as an example, it has been “only” 10 years since the last
new 32-bit CPU was announced and until 3-4 years ago it wasn't uncommon to
see plently of people running 32-bit userlands. If things unroll in a similar
way in the ARM arena, I would expect good 32-bit ARM support being relevant
at least for another 3-4 years before the need starts to fade away.

If something, I think it may make more sense to remove 32-bit x86 support,
and have the 32-bit ARM support around for some more time.

Cheers,


--
 Adrián 🎩



pgpfmZnBhMI9l.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Adrian Perez de Castro]

Hi all,

What I have been doing is having a Python 2.7 virtualenv [1], which gets
automatically enabled (or disabled) when changing directory under (or out of)
the WebKit source tree by means of zsh-autoenv [2]. This way the “python”
binary is the one for Python 2.7 inside the virtualenv, and I do not need to
remember about doing any setup manually when navigating directories in the
shell.

On Mon, 7 Aug 2017 17:56:51 +0200, Carlos Alberto Lopez Perez 
 wrote:
> On 07/08/17 17:44, Andy Estes wrote:
> >>> last I checked, macOS did not provide a python2 binary either. I am 
> >>> hoping that has changed in the past few years. Has it?
> >> Nope.
> > macOS does have /usr/bin/python2.7, though.
>
> That's a good thing.

This would work for people using a virtualenv as well:

  WebKit % which python2.7
  /home/aperez/.virtualenvs/webkit/bin/python2.7
  WebKit %

> I believe all Linux distros we support have this, right?
> And all the scripts actually assume python2.7 (AFAIK).

Arch Linux has a “python2.7” binary system-wide, too. The default installation
done when building Python always creates:

  ${prefix}/bin/python2.7
  ${prefix}/bin/python2 -> python2.7
  ${prefix}/bin/python -> python2.7

So I would expect most systems which ship Python to have a “python2.7” binary.

Cheers,


---
[1] https://virtualenv.pypa.io/en/stable/
[2] https://github.com/Tarrasch/zsh-autoenv


pgp415GiH1LYh.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Adrian Perez de Castro]

On Tue, 01 Aug 2017 22:50:35 +0100, Michael Catanzaro  
wrote:

> I will just add that there are some WebKitGTK+ users who would love for
> WebKitGTK+ to be supported on Windows once again. Evolution and GnuCash
> come to mind. Having a working WinCairo port of modern WebKit would be
> a huge step towards that. Although Igalia does not intend to maintain
> Windows code, we would certainly welcome this change in direction for
> the WinCairo port.

Indeed! Having a Windows port that uses WebKit2^H would indeed be a big help
in bringing modern WebKitGTK+ versions to Windows.

Apart from the applications that Michael mentions, I can also think about the
help browser in The GIMP, Pidgin [1], and also any C# application which uses
GTK+/WebKit-Sharp or Mono.WebBrowser.

Cheers,

---
[1] https://developer.pidgin.im/ticket/17184


pgpmqlYDW2ipO.pgp
Description: PGP signature
___
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?

[Adrian Perez de Castro]

Hello,

On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak  wrote:

> > On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
> >
> > 02.08.2017, 00:49, "Sam Weinig" :
> >>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
> >>> 
>   On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>  
>   Hi WebKittens,
>  
>   In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>  Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>  feature flag.
>  
>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>  systems by default, and we have not experienced any fallout from 
>  shipping these features in Safari Technology Preview. I think it’s time 
>  to remove the feature flag. Are there any objections? Is there a port 
>  in-tree that’s compiling without this feature?
>  
>   If I don’t hear anything, the flag’s removal will be tracked in 
>  .
> >>> 
> >>>  In general I think we should be more enthusiastic about removing feature 
> >>> flags that are guarding core parts of the Web platform. Web Timing is a 
> >>> great example.

In general I agree that build-time feature flags should go away once all ports
can have the feature enabled by default.

> >>>  Some others I see:
> >>> 
> >>>  ENABLE_CANVAS_PATH
> >>>  ENABLE_CSS_COMPOSITING
> >>>  ENABLE_CSS_SELECTORS_LEVEL4
> >>>  ENABLE_FETCH_API
> >>>  ENABLE_GEOLOCATION
> >>>  ENABLE_INDEXED_DATABASE
> >>>  ENABLE_STREAMS_API
> >>>  ENABLE_CSS_SCROLL_SNAP
> >>>  ENABLE_WEBGL
> >>>  ENABLE_WEB_AUDIO
> >>>  ENABLE_WEB_SOCKETS
> >> 
> >> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
> >> need to keep that one.
> >> 
> >> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
> >> platform, and how many other features depend on it.
> > 
> > I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
> > lots of non-browser applications that need HTML renderer (document viewers, 
> > mail clients, instant messengers, RSS readers, etc.) which don't need 
> > video, but also because it greatly raises the bar for implementing new 
> > ports (e.g. recently announced Android port didn't implement video at that 
> > time)
> 
> I think all of the clients you mentioned actually do need video (or at least 
> benefit from it). In any case, most clients like that don't usually bundle 
> their own WebKit. They use a shared copy. Usually a copy that is also used by 
> a web browser. So if they really want to disable video, they need a runtime 
> flag, not a compile-time flag.

Many embedded applications (embedded == not a browser, and the device does
not have a general-purpose one) ship their own build of WebKit, almost always
tailored to fit.

A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
are signage panels (typically some kind of info screens in a public space),
which most of the time show imagery and textual content, but no video or audio
at all, running on small embedded computers where on-disk size and memory
usage matter. For this kind of application it also makes sense to support
ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
nor any other kind of sound output.

Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
does not need GStreamer at all, which further reduces disk and memory usage.
For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

Cheers,

--
 Adrián 🎩

---
[1] https://git.busybox.net/buildroot/tree/package/webkitgtk/webkitgtk.mk#n37




pgpLrd2mi2v3F.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Build dependencies

[Adrian Perez de Castro]

On Thu, 22 Jun 2017 15:41:26 +0530, Nagendra K  wrote:

> To build WebKit alone for a cross platform embedded device, want to know
> the list of dependencies/packages  required to build on host(Ubuntu) and
> dependencies to run on host other than toolchain. Request some to help
> where to find this information.

For the GTK+ and WPE ports you can get an idea from the JHBuild module sets:

   https://trac.webkit.org/browser/webkit/trunk/Tools/gtk/jhbuild.modules
   https://trac.webkit.org/browser/webkit/trunk/Tools/wpe/jhbuild.modules

The above are neeed *at run-time*, and for building you will need a bunch of
additional tools. The “install-dependencies” scripts can give you an idea:

  https://trac.webkit.org/browser/webkit/trunk/Tools/gtk/install-dependencies
  https://trac.webkit.org/browser/webkit/trunk/Tools/wpe/install-dependencies

I hope this helps.

Cheers,


--
 Adrián 🎩


pgpeu9tC5kUBy.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Jiewen Tan is now a WebKit reviewer

[Adrian Perez de Castro]

Hi,

On Wed, 31 May 2017 14:18:56 -0700, Mark Lam  wrote:

> I would like to announce that Jiewen Tan (jiewen on #webkit) is now a WebKit
> reviewer.  Jiewen usually works on the WebCrypto API.
>
> Please join me in congratulating Jiewen, and send him some patches to
> review.

Congratulation, Jiewen \o/


--
 Adrián 🎩


pgpGJez5VxTZJ.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev