Re: [webkit-dev] Obtaining backtraces

[Konstantin Tokarev via webkit-dev]

В Sat, 07 Sep 2024 15:49:09 -0400
Michael Orlitzky via webkit-dev  пишет:

> On Sat, 2024-09-07 at 07:39 -0500, Michael Catanzaro wrote:
> > 
> > You've simply got no sandbox. You'll be fine unless the website
> > you're debugging is malicious.
> >   
> 
> I tested it today and it does work for obtaining core dumps in the
> absence of systemd. Problem solved, thank you.
> 
> A final note: I actually have three processes crashing in a row, and
> in that case it's necessary to e.g. sysctl
> "kernel.core_pattern=core.%P" to get them all.

I suggest you also include %e (or even %E if you have several
installations of same program in different places) into core_pattern to
see easily which executable crashed.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Documentation

[Konstantin Tokarev via webkit-dev]

> Why not double-down on the GitHub wiki? It's very easy to learn to use,
> and there are edit buttons everywhere so there is no "distance" between
> the docs and the ability to edit them. The easier it is to edit docs,
> the better we'll do at keeping them up to date.
> 
> I like Markdown, and am OK with editing Markdown files wherever they
> live, but it's not very likely that I would install Swift and figure
> out how to build a new project to to see what the result looks like.
> With GitHub, we can easily preview results live to ensure we're not
> messing anything up.

Also, Markdown is not the only format supported by GitHub. It's also possible to
use AsciiDoc, POD, reStructuredText, or any other format listed in [1] in any
file of main repository or in wiki, and it will be rendered to HTML when 
browsing
online.

[1] https://github.com/github/markup/blob/master/README.md#markups

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

Re: [webkit-dev] Shrinking Git clone size (WebKit Transition to Git)

[Konstantin Tokarev]

19.10.2020, 07:38, "Ryosuke Niwa" :
> Hi all,
>
> While we're making the transition to Git, I think we should try to
> shrink the Git clone size. Right now, it's 10GB and I suspect we can
> cut it down quite a bit without sacrificing much. For example, we can
> exclude any history for LayoutTests/platform/chromium* and
> LayoutTests/platforn/*qt*. I bet that would reduce the clone size
> considerably.

Note that you can use partial clone, for example this command

git clone --filter=blob:none g...@github.com:WebKit/webkit.git

will download only data which is required for files present in trunk,
resulting of repository + working directory size of 5.3GB. If you access
old parts of history or files which were removed in the past, missing
git data will be automatically fetched from network.

You can also set up custom sparse checkout pattern and completely
exclude any subdirectories you don't need, in this case you can
reduce size of working directory and .git even further.

(Note that it's recommended to install latest git release for best experience)

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

14.10.2020, 16:52, "Tetsuharu OHZEKI" :
> I feel from this discussion that everybody has their own best way and
> we’re tackling to resolve them at once in this migration process.
> I also feel it’s a bit difficult to conclude something.
>
> FWIW, I would like to write some my problems about the current
> workflow to help figure out
> what is a problem in the current workflow and what we should be
> resolved in this or other future process.
>
> This would not propose an actual solution, but I believe this would
> help to find a final solution and other people will also say your
> problems to help.
>
> 1. Code review tools
> WebKit Bugzilla’s code review tool is not a beautiful solution for today.
> I would like to get a preview for markdown file or syntax highlights.
>
> 2. Bug Tracking System
> I don’t feel a problem to use WebKit Bugzilla, and I doubt that using
> Bugzilla is really a problem to collect a feedback from the webdev
> community as other people said in this thread.
> However, I have some complaints…
>
> * I’d like to write markdown as a comment for bugs.

Why would you want to do that?

I think rich text in comments is evil, for the same reasons as HTML e-mail.

Yes, with markdown you won't often see unreadably colored text (what happens
with HTML e-mail), but still there is pretty much room for abuse of formatting
(to attract attention or just because they can), or accidental formatting when
non-markdown text is interpreted as markdown resulting in a total mess
(which inexperienced users cannot fix and leave as is).

BTW, GitHub recently added rich text UI controls to code review comments, so
even those who don't know markdown can start abusing formatting there now...

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

14.10.2020, 02:01, "Ryosuke Niwa" :
> On Tue, Oct 13, 2020 at 3:53 PM Konstantin Tokarev  wrote:
>>  14.10.2020, 01:45, "Ryosuke Niwa" :
>>  > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev  
>> wrote:
>>  >> 14.10.2020, 01:30, "Ryosuke Niwa" :
>>  >> > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev  
>> wrote:
>>  >> >> 13.10.2020, 22:33, "Maciej Stachowiak" :
>>  >> >> >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro 
>>  wrote:
>>  >> >> >>
>>  >> >> >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand 
>>  wrote:
>>  >> >> >>> Would you also consider preventing merge commits in order to keep 
>> a
>>  >> >> >>> clean mainline branch?
>>  >> >> >>
>>  >> >> >> Big +1 to blocking merge commits. Merge commits in a huge project 
>> like WebKit would make commit archaeology very frustrating. (I assume this 
>> is implied by the monotonic commit identifiers proposal, but it doesn't 
>> exactly say that.)
>>  >> >> >
>>  >> >> > I’m assuming your objection is to regular merges, but how do you 
>> feel about squash merges? Or do you think all PRs should be landed by 
>> rebasing?
>>  >> >>
>>  >> >> I'm not Michael but will add my 2 dollars anyway :)
>>  >> >>
>>  >> >> In these two approaches commits inside PR have different meaning, and 
>> workflow is different.
>>  >> >>
>>  >> >> Below I use a term "atomic change" to describe minimal code change 
>> which is a self-contained work unit with following properties:
>>  >> >> * It implements well-defined task which can be summarized as a short 
>> English sentence (typical soft limit is 60 characters)
>>  >> >> * It doesn't introduce defects (e.g. bugs, compilation breakages, 
>> style errors, typos) which were discovered during review process
>>  >> >> * It doesn't include any code changes unrelated to main topic. This 
>> separation is sometimes subjective, but it's usually recommended to split 
>> refactoring and implementation of feature based on that, bug fix and new 
>> feature, big style change and fix or feature.
>>  >> >>
>>  >> >> AFAIU our current review process has similar requirements to patches 
>> submitted to Bugzilla, though sometimes patches include unrelated changes. 
>> This can be justified by weakness of webkit-patch/Bugzilla tooling which has 
>> no support for patch series, and by fact that SVN doesn't support keeping 
>> local patch series at all.
>>  >> >>
>>  >> >> 1. Workflow 1 - "Squash merge" policy
>>  >> >>
>>  >> >> * Whole PR is considered to be a single atomic change of WebKit 
>> source tree. If work is supposed to be landed as a series of changes which 
>> depend on each other (e.g. refactoring and feature based on it, or 
>> individual separate features touching same parts of code), each change needs 
>> a separate PR, and, as a consequence, only one of them can be efficiently 
>> reviewed at the moment of time
>>  >> >> * Commits in PR represent review iterations or intermediate 
>> implementation progress
>>  >> >> * Reviewers' comments are addressed by pushing new commits without 
>> rewriting history, which works around GitHub's lack of "commit revisions". 
>> Also this workflow has lower entry barrier for people who haven't mastered 
>> git yet, as it requires only "git commit" and "git push" without rebases.
>>  >> >>
>>  >> >> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
>>  >> >>
>>  >> >> * PR is considered to be a series of atomic changes. If work consists 
>> of several atomic changes, each commit represent an atomic change
>>  >> >> * Review iterations are done by fixing commits in place and 
>> reuploading entire series using force push (of course if review discovers 
>> that substantial part of work is missing it can be added as a new atomic 
>> commit to the series)
>>  >> >> * It's possible to review each commit in the series separately
>>  >> >> * Workflow requires developers to have more discipline and exper

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

14.10.2020, 01:45, "Ryosuke Niwa" :
> On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev  wrote:
>>  14.10.2020, 01:30, "Ryosuke Niwa" :
>>  > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev  
>> wrote:
>>  >> 13.10.2020, 22:33, "Maciej Stachowiak" :
>>  >> >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  
>> wrote:
>>  >> >>
>>  >> >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
>> wrote:
>>  >> >>> Would you also consider preventing merge commits in order to keep a
>>  >> >>> clean mainline branch?
>>  >> >>
>>  >> >> Big +1 to blocking merge commits. Merge commits in a huge project 
>> like WebKit would make commit archaeology very frustrating. (I assume this 
>> is implied by the monotonic commit identifiers proposal, but it doesn't 
>> exactly say that.)
>>  >> >
>>  >> > I’m assuming your objection is to regular merges, but how do you feel 
>> about squash merges? Or do you think all PRs should be landed by rebasing?
>>  >>
>>  >> I'm not Michael but will add my 2 dollars anyway :)
>>  >>
>>  >> In these two approaches commits inside PR have different meaning, and 
>> workflow is different.
>>  >>
>>  >> Below I use a term "atomic change" to describe minimal code change which 
>> is a self-contained work unit with following properties:
>>  >> * It implements well-defined task which can be summarized as a short 
>> English sentence (typical soft limit is 60 characters)
>>  >> * It doesn't introduce defects (e.g. bugs, compilation breakages, style 
>> errors, typos) which were discovered during review process
>>  >> * It doesn't include any code changes unrelated to main topic. This 
>> separation is sometimes subjective, but it's usually recommended to split 
>> refactoring and implementation of feature based on that, bug fix and new 
>> feature, big style change and fix or feature.
>>  >>
>>  >> AFAIU our current review process has similar requirements to patches 
>> submitted to Bugzilla, though sometimes patches include unrelated changes. 
>> This can be justified by weakness of webkit-patch/Bugzilla tooling which has 
>> no support for patch series, and by fact that SVN doesn't support keeping 
>> local patch series at all.
>>  >>
>>  >> 1. Workflow 1 - "Squash merge" policy
>>  >>
>>  >> * Whole PR is considered to be a single atomic change of WebKit source 
>> tree. If work is supposed to be landed as a series of changes which depend 
>> on each other (e.g. refactoring and feature based on it, or individual 
>> separate features touching same parts of code), each change needs a separate 
>> PR, and, as a consequence, only one of them can be efficiently reviewed at 
>> the moment of time
>>  >> * Commits in PR represent review iterations or intermediate 
>> implementation progress
>>  >> * Reviewers' comments are addressed by pushing new commits without 
>> rewriting history, which works around GitHub's lack of "commit revisions". 
>> Also this workflow has lower entry barrier for people who haven't mastered 
>> git yet, as it requires only "git commit" and "git push" without rebases.
>>  >>
>>  >> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
>>  >>
>>  >> * PR is considered to be a series of atomic changes. If work consists of 
>> several atomic changes, each commit represent an atomic change
>>  >> * Review iterations are done by fixing commits in place and reuploading 
>> entire series using force push (of course if review discovers that 
>> substantial part of work is missing it can be added as a new atomic commit 
>> to the series)
>>  >> * It's possible to review each commit in the series separately
>>  >> * Workflow requires developers to have more discipline and experience 
>> with using git rebase for history rewriting. Entry barrier can be lowered by 
>> providing step by step instructions like e.g. [1].
>>  >
>>  > I really dislike this workflow due to its inherent complexity. Having
>>  > to use Git is enough of a burden already. I don't want to deal with an
>>  > extra layer of complexity to deal with.
>>
>>  There is simplified version of workflow 2 when you have only one com

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

14.10.2020, 01:30, "Ryosuke Niwa" :
> On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev  wrote:
>>  13.10.2020, 22:33, "Maciej Stachowiak" :
>>  >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  
>> wrote:
>>  >>
>>  >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
>> wrote:
>>  >>> Would you also consider preventing merge commits in order to keep a
>>  >>> clean mainline branch?
>>  >>
>>  >> Big +1 to blocking merge commits. Merge commits in a huge project like 
>> WebKit would make commit archaeology very frustrating. (I assume this is 
>> implied by the monotonic commit identifiers proposal, but it doesn't exactly 
>> say that.)
>>  >
>>  > I’m assuming your objection is to regular merges, but how do you feel 
>> about squash merges? Or do you think all PRs should be landed by rebasing?
>>
>>  I'm not Michael but will add my 2 dollars anyway :)
>>
>>  In these two approaches commits inside PR have different meaning, and 
>> workflow is different.
>>
>>  Below I use a term "atomic change" to describe minimal code change which is 
>> a self-contained work unit with following properties:
>>  * It implements well-defined task which can be summarized as a short 
>> English sentence (typical soft limit is 60 characters)
>>  * It doesn't introduce defects (e.g. bugs, compilation breakages, style 
>> errors, typos) which were discovered during review process
>>  * It doesn't include any code changes unrelated to main topic. This 
>> separation is sometimes subjective, but it's usually recommended to split 
>> refactoring and implementation of feature based on that, bug fix and new 
>> feature, big style change and fix or feature.
>>
>>  AFAIU our current review process has similar requirements to patches 
>> submitted to Bugzilla, though sometimes patches include unrelated changes. 
>> This can be justified by weakness of webkit-patch/Bugzilla tooling which has 
>> no support for patch series, and by fact that SVN doesn't support keeping 
>> local patch series at all.
>>
>>  1. Workflow 1 - "Squash merge" policy
>>
>>  * Whole PR is considered to be a single atomic change of WebKit source 
>> tree. If work is supposed to be landed as a series of changes which depend 
>> on each other (e.g. refactoring and feature based on it, or individual 
>> separate features touching same parts of code), each change needs a separate 
>> PR, and, as a consequence, only one of them can be efficiently reviewed at 
>> the moment of time
>>  * Commits in PR represent review iterations or intermediate implementation 
>> progress
>>  * Reviewers' comments are addressed by pushing new commits without 
>> rewriting history, which works around GitHub's lack of "commit revisions". 
>> Also this workflow has lower entry barrier for people who haven't mastered 
>> git yet, as it requires only "git commit" and "git push" without rebases.
>>
>>  2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
>>
>>  * PR is considered to be a series of atomic changes. If work consists of 
>> several atomic changes, each commit represent an atomic change
>>  * Review iterations are done by fixing commits in place and reuploading 
>> entire series using force push (of course if review discovers that 
>> substantial part of work is missing it can be added as a new atomic commit 
>> to the series)
>>  * It's possible to review each commit in the series separately
>>  * Workflow requires developers to have more discipline and experience with 
>> using git rebase for history rewriting. Entry barrier can be lowered by 
>> providing step by step instructions like e.g. [1].
>
> I really dislike this workflow due to its inherent complexity. Having
> to use Git is enough of a burden already. I don't want to deal with an
> extra layer of complexity to deal with.

There is simplified version of workflow 2 when you have only one commit in PR. 
In this case you can easily edit this single commit with gic commit --amend or 
GUI tools to address review comments. At the same time those who are more 
comfortable with git can use longer patch series.


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

13.10.2020, 22:33, "Maciej Stachowiak" :
>>  On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  wrote:
>>
>>  On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  wrote:
>>>  Would you also consider preventing merge commits in order to keep a
>>>  clean mainline branch?
>>
>>  Big +1 to blocking merge commits. Merge commits in a huge project like 
>> WebKit would make commit archaeology very frustrating. (I assume this is 
>> implied by the monotonic commit identifiers proposal, but it doesn't exactly 
>> say that.)
>
> I’m assuming your objection is to regular merges, but how do you feel about 
> squash merges? Or do you think all PRs should be landed by rebasing?

I'm not Michael but will add my 2 dollars anyway :)

In these two approaches commits inside PR have different meaning, and workflow 
is different.

Below I use a term "atomic change" to describe minimal code change which is a 
self-contained work unit with following properties:
* It implements well-defined task which can be summarized as a short English 
sentence (typical soft limit is 60 characters)
* It doesn't introduce defects (e.g. bugs, compilation breakages, style errors, 
typos) which were discovered during review process
* It doesn't include any code changes unrelated to main topic. This separation 
is sometimes subjective, but it's usually recommended to split refactoring and 
implementation of feature based on that, bug fix and new feature, big style 
change and fix or feature.

AFAIU our current review process has similar requirements to patches submitted 
to Bugzilla, though sometimes patches include unrelated changes. This can be 
justified by weakness of webkit-patch/Bugzilla tooling which has no support for 
patch series, and by fact that SVN doesn't support keeping local patch series 
at all.

1. Workflow 1 - "Squash merge" policy

* Whole PR is considered to be a single atomic change of WebKit source tree. If 
work is supposed to be landed as a series of changes which depend on each other 
(e.g. refactoring and feature based on it, or individual separate features 
touching same parts of code), each change needs a separate PR, and, as a 
consequence, only one of them can be efficiently reviewed at the moment of time
* Commits in PR represent review iterations or intermediate implementation 
progress
* Reviewers' comments are addressed by pushing new commits without rewriting 
history, which works around GitHub's lack of "commit revisions". Also this 
workflow has lower entry barrier for people who haven't mastered git yet, as it 
requires only "git commit" and "git push" without rebases.

2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy

* PR is considered to be a series of atomic changes. If work consists of 
several atomic changes, each commit represent an atomic change
* Review iterations are done by fixing commits in place and reuploading entire 
series using force push (of course if review discovers that substantial part of 
work is missing it can be added as a new atomic commit to the series)
* It's possible to review each commit in the series separately
* Workflow requires developers to have more discipline and experience with 
using git rebase for history rewriting. Entry barrier can be lowered by 
providing step by step instructions like e.g. [1]. 


Workflow 1 is more like what we have now with Bugzilla.

Workflow 2 is used by many projects which use git for a long time and value 
high-quality commit history. It's used e.g. by Linux kernel, or projects which 
use Gerrit as a review tool (Chromium, Android, Qt, etc). It advantages for 
developers (who can submit more work to review at the same time without risk of 
mixing up unrelated changes together), reviewers (it's easier to review atomic 
changes than those with too high or too low granularity), maintainers of stable 
branches (they can pick bug reports and avoid at least some unneeded 
refactorings, features and style improvements).

Workflow 1 is the most obvious way to use GitHub, because it doesn't make any 
hints about existence of workflow 2. However, many projects which use GitHub 
for code review and value high-quality history are using workflow 2. For 
example, see Ryosuke's example with whatwg/html repo.

Workflow 2 is facilitated by Gerrit, which doesn't require using force pushes 
and makes it immediately obvious for new user if they start adding new fixup 
commits instead of editing those being reviewed.

Workflow 2 can use both rebase and merge strategies, and merge isn't so evil in 
this case. However, using merge moves responsibility for solving conflicts from 
contributor to repository maintainers, which doesn't scale well. Projects which 
accept patches via mailing lists, like Linux kernel, imply that reviewed patch 
series must apply to the tip of the tree, so while there is no explicit 
"rebase" it is implied.

In conclusion, I recommend using 2 with "rebase" policy, but YMMV.

[1] https://wiki.qt.io/Gerrit_Introduction#Updating_a_Contri

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

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 bu

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

06.10.2020, 20:32, "Yusuke Suzuki" :
>>  On Oct 5, 2020, at 5:13 PM, 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 t

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

06.10.2020, 12:40, "Konstantin Tokarev" :
> 06.10.2020, 11:42, "Ryosuke Niwa" :
>>  On Mon, Oct 5, 2020 at 5:13 PM 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
>>>
>>>   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.
>>
>>  Yeah, this is a pretty significant functional regression to me. I use
>>  bug dependencies all the time (e.g.
>>  https://bugs.webkit.org/showdependencytree.cgi?id=148695&hide_resolved=1)
>>  and not having this capability will significantly hinder my ability to
>>  track & triage some bugs.
>
> As I've mentioned above, for this particular case you could create a 
> milestone "Implement v1 shadow DOM API" and add all subtasks to it. Then you 
> have a list of dependencies in one place, with ability to see only unresolved 
> once, and with a nice progress bar. But you may find this approach a bit 
> lame, because milestone itself is not a proper task, it has nothing else but 
> title, description, and due date. Also, it's probably wrong to call this 
> entity a milestone.

Also it doesn't allow to create dependency tree with depth > 1, as children of 
milestone cannot be milestones themselves.


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

06.10.2020, 11:42, "Ryosuke Niwa" :
> On Mon, Oct 5, 2020 at 5:13 PM 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.
>
> Yeah, this is a pretty significant functional regression to me. I use
> bug dependencies all the time (e.g.
> https://bugs.webkit.org/showdependencytree.cgi?id=148695&hide_resolved=1)
> and not having this capability will significantly hinder my ability to
> track & triage some bugs.

As I've mentioned above, for this particular case you could create a milestone 
"Implement v1 shadow DOM API" and add all subtasks to it. Then you have a list 
of dependencies in one place, with ability to see only unresolved once, and 
with a nice progress bar. But you may find this approach a bit lame, because 
milestone itself is not a proper task, it has nothing else but title, 
description, and due date. Also, it's probably wrong to call this entity a 
milestone.

>
>>  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."
>&g

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

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.


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

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

05.10.2020, 17:19, "Robert Ma" :
> On Mon, Oct 5, 2020 at 6:22 AM Frédéric Wang  wrote:
>> 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). 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. Probably, we should forbid people to commit to the master
>> branch directly (I think someone broke WPT's master branch that way last
>> year)...
>
> Note that this is not exactly the reason we give people write access in WPT. 
> The WPT repo is not too big to impede forking. Rather, this was to work 
> around some CI setup constraints (e.g. some secrets not accessible from 
> forks), most of which have been resolved so the write access is largely for 
> convenience for active developers (e.g. avoid having to sync the fork).

There is no need to sync the fork for any development activity. You can have 
WPT repo as an upstream for master branch, and push your topic branches to your 
own fork added as another remote. When you pull master it will be updated from 
WPT repo, or you can do git fetch and rebase your topic branch to origin/master.

The only possible downside is that master branch of your fork may become 
outdated, but since you don't need it for anything and use local master which 
is always in sync, it's just cosmetic issue.

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

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 unapproved archive 
type.

But you can attach funny cat picture to your comment and it will be displayed 
inline :)


Conclusion
--

You can say this is all small issues which are not really significant. With 
current state of things when Bugzilla is mostly used as a code review tool, and 
very few of issues reported by p

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

02.10.2020, 19:46, "Jonathan Bedard" :
> Monotonic Commit Identifiers
> Of great interest to Apple’s engineers has been retaining some kind of 
> ordered tag we can use to refer to commits to make defending CI and bisection 
> easier. We’ve developed a scheme for this that assigns commits an ordered 
> identifier per-branch, outlined in 
> https://trac.webkit.org/wiki/commit-identifiers, designed to be used 
> alongside git hashes. These identifiers can be used in our current Subversion 
> repository, and we would like to start using them before the project has 
> transitions to git.

AFAIU, this is very close to what `git describe` does: you give it git hash, it 
gives you new identifier consisting of 3 parts:

--

Note that resulting identifier can be used in all git operations which require 
git reference (like `git log` or `git show`).
So, if you push git tags to main repository (maybe lightweight tags, if you are 
planning to have lots of them), there is no need to invent any other 
identifiers.

As for bisection, git bisect works just fine when given two commit hashes.


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

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.

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

02.10.2020, 23:17, "Jonathan Bedard" :
>>  On Oct 2, 2020, at 11:47 AM, Tetsuharu OHZEKI  
>> wrote:
>>
>>  Hi Jonathan,
>>
>>  As a contributor, I hear this change positively and I'm looking
>>  forward to transition to a new process.
>>
>>  I have some questions and feelings:
>>
>>  1. Will we continue to use https://trac.webkit.org/wiki after moving
>>  to something to host the Git repository?
>>
>>  This is just my curiosity.
>
> We don’t have plans to migrate the wiki in the immediate future, although I 
> suspect that as development workflows switch to GitHub, we will eventually 
> want to move the wiki to GitHub as well.

If you are considering this, please take into account that GitHub doesn't allow
to configure separate access lists for repository and wiki. There are only two
options:

1) wiki can be edited by any GitHub user
2) wiki can be edited by people who have write access to repo (i.e. right to 
make
unreviewed push to any branch, as there are no "partial access" settings)

It's not possible to have a separate list of "contributors" without push right 
as
we do now.

Of course, this can be worked around via setting up wiki in a different 
repository
with different access list.


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

03.10.2020, 05:18, "Ryosuke Niwa" :
> On Fri, Oct 2, 2020 at 5:06 PM Michael Catanzaro  wrote:
>>  On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
>>  > 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.
>>
>>  I'm not familiar with reviews on GitHub. I just want to add that GitLab
>>  reviews are great and have none of these problems. It's very easy to
>>  view older versions of merge requests and compare the differences
>>  between arbitrary revisions of the merge request. (That's often
>>  important when reviewing small changes to a large merge request.) Every
>>  discussion thread is clearly marked as either resolved (green!) or
>>  unresolved, and you can (and should) configure GitLab to block merges
>>  until all discussions are resolved. (I would be disappointed if GitHub
>>  doesn't have the same convenience features, as this helps prevent
>>  mistakes from being forgotten.)
>
> GitHub totally offers this. See, for example:
> https://github.com/whatwg/html/pull/5912

Let's consider this example in depth.

1. mfreed7 have pushed a patch series 
2. You and others have added comments on what should be changed in patches
3. mfreed7 did all the changes in patches and force-pushed result

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.

In contrast, with Gerrit you can see all revisions of each patch and compare
arbitrary revisions side by side to see how your comments were addressed and
what else was changed.

>
>>  > I realize that Gerrit might not integrate at all with hosting the
>>  > repo on Github, but has any thought been given to this aspect of the
>>  > transition?
>>
>>  That sounds like it would be a significant barrier to contribution, and
>>  frankly defeat the point of switching. If we have serious concerns with
>>  GitHub's code review functionality (which, again, I'm not familiar
>>  with), then we should just use GitLab and have everything in one place.
>>  (GitLab accepts GitHub logins via OAuth, both on gitlab.com and
>>  self-hosted instances, so the barrier to contributing remains low
>>  either way.)
>
> Indeed. Gerrit's UI is also quite dense and hard to use for someone
> new to it too:
> https://gerrit-review.googlesource.com/c/plugins/replication/+/282176
>
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

03.10.2020, 20:40, "Michael Catanzaro" :
> On Sat, Oct 3, 2020 at 3:16 am, Ryosuke Niwa  wrote:
>>  I've gotta say I'm very much concerned about getting rid of change
>>  logs when we move to Git. We put a lot of useful information about
>>  what was causing the bug, how we fixed it, and why we fixed the way we
>>  did in a change log. I've seen a few projects which transitioned to
>>  Git and somehow lost the rigor in maintaining an equally high quality
>>  commit message, partly because most code review tools don't let you
>>  add inline comments to commit messages.
>
> You may not be able to add inline comments on commit messages, but I've
> never been particularly concerned about that. You can still start a new
> discussion thread mentioning the problem with the commit message that
> you'd like to see resolved, blocking merge until the discussion thread
> is resolved. Although in GNOME we don't often have problems with
> low-quality commit messages, we do sometimes, and during review we
> treat that as we would any problem with the code. Having a set of
> guidelines for writing commit messages, like [1], might help. But yes,
> we do lose the ability to do inline comments during code review.

FWIW, Gerrit allows to do inline comments on commit messages,
or to add comment for the whole file.

>
> (Anyway, this is only a tangent, since of course we can switch to
> GitHub but still keep ChangeLog files if we decided to do that.)
>
> [1] https://wiki.gnome.org/Git/CommitMessages
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

03.10.2020, 19:34, "Alexey Proskuryakov" :
>>  3 окт. 2020 г., в 2:24 AM, Adrien Destugues  
>> написал(а):
>>
>>  On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
  I realize that Gerrit might not integrate at all with hosting the repo
  on Github, but has any thought been given to this aspect of the
  transition?
>>>
>>>  That sounds like it would be a significant barrier to contribution, and
>>>  frankly defeat the point of switching. If we have serious concerns with
>>>  GitHub's code review functionality (which, again, I'm not familiar with),
>>>  then we should just use GitLab and have everything in one place. (GitLab
>>>  accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
>>>  instances, so the barrier to contributing remains low either way.)
>>
>>  Gerrit accepts GitHub and other OAuth providers as well, so that's not a
>>  problem. We have been using this for Haiku code reviews for a few years
>>  now, and interestingly we got some complaints from people who don't want
>>  to have a Github account (for various reasons) and won't use our code
>>  review tool because of that.
>
> What are the reasons why people don't want to have a GitHub account? I wonder 
> if that's somehow a different kind of barrier to entry to be concerned about.

Maybe because it's owned by Microsoft, which is an enemy of all living things 
and
basically are an embassy of Devil on Earth (no).

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

Re: [webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

03.10.2020, 19:46, "Tetsuharu OHZEKI" :
>>>  I think having to create an account on a website isn't the main thing
>>>  preventing people to contribute anyway? It's more about having to use
>>>  project-specific tools to prepare the patch for submission (in the case
>>>  of WebKit, having to write the commit message in the Changelog file, for
>>>  example).
>>
>>  It's about all those things. We've definitely heard of people
>>  complaining or refusing to create a Bugzilla account to report bugs.
>>  I've gotta say I'm very much concerned about getting rid of change
>>  logs when we move to Git. We put a lot of useful information about
>>  what was causing the bug, how we fixed it, and why we fixed the way we
>>  did in a change log. I've seen a few projects which transitioned to
>>  Git and somehow lost the rigor in maintaining an equally high quality
>>  commit message, partly because most code review tools don't let you
>>  add inline comments to commit messages.
>
> I'd like to tell my feelings about a ChangeLog file other than
> perspective for code review.
>
> As a newbie patch contributor, it's true that ChangeLog file is a
> *bit* tired when I update a patch.
> I felt repeatedly that it should be replaced by VCS' commit log to
> make it easier.
>
> On the other hand, ChangeLog file also helps me many times when I dig
> into the history of WebKit
> because ChangeLog file contains what functions are removed in which
> commit with Bugzilla id
> and sometimes includes detailed reason for changeset.

FWIW, right now our ChangeLog entries are our commit messages too.
If we migrate to git is no additional value in keeping them separately,
because git log is local (no requests to server) and fast (you can search
in it with ~ same speed as in changelog files)

>
> Perhaps it may be just that I don't know the way, VCS (I think here is
> Git) has a powerful feature to trace when we added codes
> but it's hard to trace when we removed codes, and it force a tough
> work to me when I investigate why we introduced this line to fix a
> bug.

If you know piece of code or function name which was removed, you
can use git log -S to find commit where it was deleted.

> By contrast, WebKit's ChangeLog file is helpful to make it easier to
> trace both of adding ones and removing codes.
>
> --
> Tetsuharu OHZEKI
> tetsuharu.ohz...@gmail.com
>
> On Sat, Oct 3, 2020 at 7:17 PM Ryosuke Niwa  wrote:
>>  On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues
>>   wrote:
>>  >
>>  > On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
>>  > > > I realize that Gerrit might not integrate at all with hosting the repo
>>  > > > on Github, but has any thought been given to this aspect of the
>>  > > > transition?
>>  > >
>>  > > That sounds like it would be a significant barrier to contribution, and
>>  > > frankly defeat the point of switching. If we have serious concerns with
>>  > > GitHub's code review functionality (which, again, I'm not familiar 
>> with),
>>  > > then we should just use GitLab and have everything in one place. (GitLab
>>  > > accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
>>  > > instances, so the barrier to contributing remains low either way.)
>>  >
>>  > Gerrit accepts GitHub and other OAuth providers as well, so that's not a
>>  > problem. We have been using this for Haiku code reviews for a few years
>>  > now, and interestingly we got some complaints from people who don't want
>>  > to have a Github account (for various reasons) and won't use our code
>>  > review tool because of that.
>>  >
>>  > I think the integration referred to was rather in terms of having
>>  > reviews synchronized between Gerrit and Github pull requests, which is
>>  > also possible, but I think if the point is to use Github, it doesn't
>>  > work this way: if your workflow is too different from the standard way
>>  > to use Github, people will still be confused by it and it will still be
>>  > a barrier to contribution.
>>
>>  But using Gerrit would make that situation any better either.
>>
>>  > I think having to create an account on a website isn't the main thing
>>  > preventing people to contribute anyway? It's more about having to use
>>  > project-specific tools to prepare the patch for submission (in the case
>>  > of WebKit, having to write the commit message in the Changelog file, for
>>  > example).
>>
>>  It's about all those things. We've definitely heard of people
>>  complaining or refusing to create a Bugzilla account to report bugs.
>>  I've gotta say I'm very much concerned about getting rid of change
>>  logs when we move to Git. We put a lot of useful information about
>>  what was causing the bug, how we fixed it, and why we fixed the way we
>>  did in a change log. I've seen a few projects which transitioned to
>>  Git and somehow lost the rigor in maintaining an equally high quality
>>  commit message, partly because most code review tools don't let you
>>  add inline comments

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Konstantin Tokarev]

17.09.2020, 09:35, "Ryosuke Niwa" :
> Hi all,
>
> I’ve been working with Geoff (ggaren) and Jan Korous from Apple's compiler 
> team to create a static analyzer which detects dangerous use of ref counted 
> objects, and we’re looking for folks who are interested in trying out this 
> tool and helping us refine the tool. Please let me know if you’re interested 
> in using this tool & try applying code changes to WebKit. Our goal is to 
> eventually integrate this tool into buildbot and EWS so that we can catch 
> dangerous code before they get committed.
>
> What is Dangerous?
>
> So what is a dangerous use of ref counted objects you may ask? It’s any use 
> of which we can’t trivially conclude that it doesn’t lead to a use-after-free.
>
> For now, we don’t detect dangerous use of non-ref counted objects including 
> ones that can vend WeakPtr. It’s on us, humans, to decide which objects need 
> to be ref counted or need to be CanMakeWeakPtr.
>
> Consider the following example. This code most certainly will lead to a 
> use-after-free of “parent” in the third line because the code doesn’t keep 
> the parent alive. Because isContentEditable updates style in some cases, it 
> could lead to arbitrary script execution which could remove the parent from 
> the document.
>
> Node* parent = element->parentElement();
> if (parent->isContentEditable())
>     parent->scrollIntoView();
>
> In general, relying on a complex data structure such as DOM tree to keep 
> RefCounted objects alive while we call a non-trivial function is not safe. 
> All it takes for the code to have a use-after-free is for someone to start 
> updating style, layout, etc… inside the function either directly or 
> indirectly. And we don’t want to make WebKit development really hard by 
> forcing anyone who modifies a function to check every caller of the function 
> and their callers, etc… to make sure it’s safe to do so.
>
> For this reason, it’s dangerous to store a raw pointer or a reference to a 
> ref counted object as a local variable and use it after calling a non-trivial 
> function. We did a similar analysis of a number of other patterns and usage 
> of ref counted objects in WebKit and came up with the following basic rules 
> for using ref counted objects in a safe manner. We’re hoping that these rules 
> would be eventually incorporated into our coding style guideline: 
> https://webkit.org/code-style-guidelines/
>
> Rules for Using Ref Counted Objects
>
> * Every data member to a ref counted object must use either Ref, RefPtr, or 
> WeakPtr. webkit.NoUncountedMemberChecker
> * Every ref counted base class, if it has a derived class, must define a 
> virtual destructor. webkit.RefCntblBaseVirtualDtor
> * Every ref counted object passed to a non-trivial function as an argument 
> (including "this" pointer) should be stored as a Ref or RefPtr in the 
> caller’s local scope unless it's an argument to the caller itself by 
> transitive property [1]. alpha.webkit.UncountedCallArgsChecker
> * Every ref counted object must be captured using Ref or RefPtr for lambda. 
> webkit.UncountedLambdaCapturesChecker
> * Local variables - we’re still working on this 
> (https://reviews.llvm.org/D83259)
>
> Below, I've dissected each one of these rules with the real warning emitted 
> by the analysis tool in development. Please let me know if you have any 
> comments / concerns.
>
> 
> (1) is pretty trivial. Every ref counted data member should be stored using 
> Ref, RefPtr, or WeakPtr since it would be not trivially obvious that life 
> cycles of two or more objects are correctly tied or managed together.
>
> 
> (2) is also pretty easy to understand. In the following example, if someone 
> destroys an instance of B using Ref, then it would result in an undefined 
> behavior.
>
> struct A : public RefCounted {
>         Vector someData;
> };
>
> struct B : public A {
>         Vector otherData;
> };
>
> 
> For (3), passing a ref counted object as a raw pointer or reference to a 
> function as an argument, the tool may generate a warning like this:
>
> Source/WebCore/html/FormAssociatedElement.cpp:181:13: warning: [WebKit] call 
> argument is a raw pointers to a ref-countable type 
> [-Wfunction-arg-ptr-to-refcntbl]
>     setForm(findAssociatedForm(&asHTMLElement(), originalForm.get()));
>             ^
>
> This warns that void setForm(HTMLFormElement*) is called with the result of 
> findAssociatedForm, which returns HTMLFormElement* without storing it 
> anywhere. If setForm can somehow cause HTMLFormElement to be deleted, then 
> this can result in the use-after-free in setForm.
>
> void FormAssociatedElement::resetFormOwner()
> {
>     RefPtr originalForm = m_form.get();
>     setForm(findAssociatedForm(&asHTMLElement(), originalForm.get()));
>     HTMLElement& element = asHTMLElement();
>     auto* newForm = m_form.get();
>    

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

[Konstantin Tokarev]

20.07.2020, 13:13, "shriva...@firemail.cc" :
> Hi webkit-dev,
>
> I'm trying to study the structure of web browsers in general and WebKit
> specifically for academic purposes. I found that using language servers
> that index compile_commands.json (clangd, ccls etc.) is a very good
> solution to navigate source code of extremely large projects, such as
> WebKit.
>
> Unfortunately, I was only able to get compile_commands.json generated
> when I compiled with --jsc-only where the build is executed using cmake
> and not the perl script. Trying to pass --cmake as a build argument to
> build-webkit causes the build to fail pretty early for missing files
> (that I believe aren't open source).

No, these files were just removed from tree or renamed recently, and Mac/cmake
doesn't have EWS bot so such breakages happen regularly. However, it should
be possible to fix such error just by looking at git log for missing file paths 
and
figuring out what happened to respective files, i.e. should the be removed from
cmake or replaced with a different file path. Feel free to contribute patches 
if you
happen to fix anything.

>
> To wrap it up, I wonder if there's a way to compile WebKit as a browser
> (and not just JavaScriptCore) and have compile_commands.json generated?
>
> platform: osx
> arch: x86_64
> commit: 521d40b
>
> Thanks,
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

[Konstantin Tokarev]

07.03.2020, 05:41, "Kirsling, Ross" :
> I'd be thrilled for us to use 'revert'.
> Somehow I'd convinced myself that it'd be easier to ask for this if we kept 
> the 'roll' part, but I'm not really sure why I thought so.

On the negative side, it won't be possible anymore to say that someone is on a 
roll when they revert several patches in a row :)

>
> Of course, it's fine for folks to continue to _say_ 'roll out' due to habit; 
> I just think it would be great if our automated 'rollouts' turned into 
> automated 'reverts' instead.
>
> Ross
>
> On 3/6/20, 6:31 PM, "Ryosuke Niwa"  wrote:
>
> On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  
> wrote:
> >
> > Late on Friday seems like a good time for a terminological debate (), 
> so I’d like to propose we revisit one of the strangest items of 
> WebKit-specific terminology: the phrase ‘roll out’.
> >
> > In our industry, the typical meaning of the phrase ‘roll out’ is, of 
> course, ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of 
> ‘roll out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ 
> to mean the exact opposite, ‘revert’ or ‘roll back’.
>
> I think the ship has sailed on this one. People who have been working
> on the WebKit project for long enough are so used to the phrase
> "rollout a patch" that it's gonna be tricky to change the terminology.
> Having said that, I'd much prefer the term "revert" over "rollout" or
> "rollback". It's also the term git uses.
>
> > This term is confusing enough for native English speakers outside our 
> community, let alone non-natives (since phrasal verbs are notoriously tricky 
> as it is).
>
> As a non-native speaker myself, I never find this term confusing
> because I have no mental model of what "rollout" or "rollback" means.
> However, I find those two terms infinitely more confusing than the
> very direct "revert".
>
> - R. Niwa
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Naming convention for static member variables

[Konstantin Tokarev]

19.02.2020, 22:31, "Simon Fraser" :
> class Foo {
>   static bool thing.
> };
>
> What's the naming convention for static member variables like this? I've seen 
> m_foo, which seems positively harmful. I've seen s_foo, which I like.
>
> There are 165 instances of s_ that I can find in the project. There are 17 
> instances of static m_.

According to [1], convention is "s_". Apparently, it just lacks an enforcement 
in style checker.

[1] https://webkit.org/code-style-guidelines/#names-data-members

-- 
Regards,
Konstantin

___
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

[Konstantin Tokarev]

14.10.2019, 16:20, "Carlos Alberto Lopez Perez" :
> Hi everyone,
>
> 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.
>
> Adrian, congratulations.
>
> Cheers!

Congratulations!

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

[Konstantin Tokarev]

10.10.2019, 23:10, "Ryosuke Niwa" :
> People often associate the term "WebKit" with Apple's WebKit port in 
> practice. The risk here is really about people not understanding the nuance 
> of port specific bugs & set of features. 

However, Safari has its own column in the table, and its logo is very different.


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

Re: [webkit-dev] Planned EWS improvements

[Konstantin Tokarev]

27.09.2019, 08:15, "Simon Fraser" :
>> On Sep 27, 2019, at 3:27 AM, Aakash Jain  wrote:
>>
>> Hi Everyone,
>>
>> I have been making number of improvements to EWS. I also have various 
>> planned improvements to EWS. I wanted to reach out to you guys to see if 
>> anyone
>
> Not everyone on this list is a guy.

FWIW, plural form of "guy" is often used as gender-neutral vocative, see e.g. 
[1,2]

[1] https://www.merriam-webster.com/dictionary/guy
[2] https://dictionary.cambridge.org/us/dictionary/english/guy


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

Re: [webkit-dev] Questions about JSC EWS queues

[Konstantin Tokarev]

18.09.2019, 20:24, "Aakash Jain" :
> Hi All,
>
> I am working on moving JSC EWS queues from old EWS to new EWS. I am trying to 
> clearly understand various JSC EWS queues. I have few questions:
>
> 1) What does 'jsc-only' port represent?

It is a port which aims to provide just JSC with minimum dependencies. 

> From 
> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/common/config/ews.json#L45
>  it seems like Apple JSC EWS uses 'mac' port, while linux jsc EWSes use 
> 'jsc-only' port. Is jsc-only port specific to linux? Is there a corresponding 
> jsc port for mac?

Yes. JSCOnly is supposed to work on all platforms including macOS and Windows. 
On macOS it's quite close to Mac port, but does not include Objective-C API.

>
> 2) Is there any difference between the three linux JSC EWSes (JSC i386, JSC 
> MIPS32el, JSC Armv7) apart from the architecture and few queues 
> running/skipping tests?
>
> 3) Where is the architecture for various linux JSC EWS queues configured in 
> the old EWS code (e.g.: I don't see the architecture being added in 
> https://trac.webkit.org/changeset/237001/webkit)? Is the queue configuration 
> for various JSC EWS queues same, and the device connected to the queue 
> actually decides the architecture?
>
> Thanks
> Aakash
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Moving to Python 3

[Konstantin Tokarev]

16.07.2019, 14:33, "Guillaume Emont" :
> Quoting Fujii Hironori (2019-07-16 08:04:09)
>>  On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa  wrote:
>>
>>  I don’t think anyone is arguing that we’d eventually need to move to
>>  Python3. I’m arguing that it’s not okay to require random WebKit
>>  contributor to know some obscure python insanity to install Python 3, or
>>  have a script that installs Python 3 and breaks all other python 
>> scripts in
>>  the system.
>>
>>   Just out of curiosity. As far as I know, installing Python 3 breaks 
>> nothing.
>>  What and why are they got broken?
>
> I suspect Ryosuke is talking about a case where python 3 has already
> been installed on the OS (but is not part of the original OS), and we
> install python 3 also, and the scripts that were using the first python
> 3 installed end up using WebKit's python 3 instead, which could lack a
> python module required by these scripts, hence breaking them.

But we have autoinstaller which handles this situation.

>
> I think this situation should be easy to avoid with a virtualenv though.
>
> Best regards,
>
> Guillaume
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

27.06.2019, 20:19, "Michael Catanzaro" :
> On Thu, Jun 27, 2019 at 11:20 AM, Brent Fulgham 
> wrote:
>>  Apple is in the process of bringing up VS2019 now. I would be in
>>  favor of moving the minimum to 3.14 so we can safely support VS2019
>>  compiles.
>
> The 3.14 target is too aggressive for WPE/GTK, unfortunately. You could
> use a different cmake_minimum_required for Windows only, of course.

Note that you don't have to raise cmake_minimum_required to use newer CMake
in your builds.

-- 
Regards,
Konstantin

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

Re: [webkit-dev] What is the status of Network Error Logging and Reporting API?

[Konstantin Tokarev]

04.06.2019, 02:41, "Ryosuke Niwa" :
> I assume you want to use this feature. What are your use cases?

Actually, I was just rambling through web-platform-tests and discovered thing I 
wasn't aware of,
which seemed to be on standards track but missing in feature status.

However, I think this feature could be useful as a lightweight inspector 
replacement for embedded
systems which are deployed to clients, when it may not be easy to make a direct 
connection.

>
> On Sun, Jun 2, 2019 at 6:16 PM Konstantin Tokarev  wrote:
>> They are missing from features.json
>>
>> https://w3c.github.io/network-error-logging/
>> https://www.w3.org/TR/reporting/
>>
>> --
>> Regards,
>> Konstantin
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

[webkit-dev] What is the status of Network Error Logging and Reporting API?

[Konstantin Tokarev]

They are missing from features.json

https://w3c.github.io/network-error-logging/
https://www.w3.org/TR/reporting/

-- 
Regards,
Konstantin

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

Re: [webkit-dev] C++17 is here. Should we use it?

[Konstantin Tokarev]

11.05.2019, 02:47, "Yusuke Suzuki" :
> Cool! So,
>
> 1. We can use GCC 7
> 2. We can use libstdc++7
>
> Is my understanding correct? Basically, this means that we can use cool C++17 
> features super aggressively :)

Not so aggressively with library features, a few of them require libstdc++ 8 or 
even 9[1]. However, there is portable
implementation of std::filesystem [2] which we could use as a "polyfill" if 
needed.

[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017
[2] https://github.com/gulrak/filesystem
-- 
Regards,
Konstantin

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

Re: [webkit-dev] C++17 is here. Should we use it?

[Konstantin Tokarev]

07.05.2019, 16:53, "Michael Catanzaro" :
> Since there were no objections, I've updated the policy on the wiki:
>
> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Note that since we have to support libstdc++ 6.x, most of C++17 standard
library features () should be disallowed. Those include std::filesystem, 
std::string_view, etc. Core language features should be fine.
-- 
Regards,
Konstantin

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

Re: [webkit-dev] C++17 is here. Should we use it?

[Konstantin Tokarev]

20.04.2019, 01:16, "Alex Christensen" :
> It’s always fun to reply to two year old emails.
>
> I would like to have a plan to start using and requiring C++17 in WebKit. 
> Based on my minimal research, I believe that DebianBuster is frozen but not 
> yet released. Is there something we are still waiting for, or could we begin 
> making the switch?

[1] says: "we support each major Debian version until one year after the 
release of the next major version"

Given that Buster is not released yet, bumping GCC requirement to 7 seems to be 
premature.

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, which might be 
sufficient for now.

[1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
[3] https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Spam and indexing

[Konstantin Tokarev]

22.04.2019, 18:58, "Michael Catanzaro" :
> Not indexing bugs.webkit.org will be sad for people who won't be able
> to find bugs they may be interested in via search engines... but those
> people are probably not WebKit developers working with WebKit on a
> daily basis. For us, it's just annoying to deal with the spam. I would
> turn off the indexing if we think it could make a difference.

Another possible way is to disable self-registration for new users, similarly
to what LLVM project did [1].

[1] https://bugs.llvm.org/

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Concurrent JS and 32bit platforms

[Konstantin Tokarev]

11.04.2019, 17:03, "Xan" :
> Hi all,
>
> as part of our work on improving 32bit support in JSC we at Igalia are 
> planning to have a look at enabling concurrent js for these platforms. Before 
> we dive in, though, we thought it would be better to ask some preliminary 
> questions:
>
> - Was this feature only implemented for 64bit because that was the focus of 
> the implementors moving forward? Or is there any fundamental difficulty in 
> the current architecture? In particular we have seen some comments about 
> atomic updates of JSValues that suggest it could be hard (or impossible) to 
> get this done on 32bit with the current approach.
>
> - Assuming this is doable right now, we'll get on with it. Assuming it's not: 
> would you be open to making the necessary changes to JSC to make concurrent 
> js an option on 32bits?

This feature would be very much appreciated, there are lots of multicore 
embedded Linux systems which have to use 32-bit userspace


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

Re: [webkit-dev] Spam and indexing

[Konstantin Tokarev]

29.03.2019, 19:30, "Michael Catanzaro" :
> On Thu, Mar 28, 2019 at 3:57 PM, Alexey Proskuryakov 
> wrote:
>>  2. Block indexing completely.
>>
>>  Seems like no one was bothered by lack of indexing on new bugs so far.
>
> Spam problem seems worse than not being indexed.
>
> If you want to search for WebKit bugs, you can do that on WebKit
> Bugzilla, right?

1. If some issue is referenced from external Web sites (such as, e.g., 
StackOverflow),
it's placed higher in search engine results, so for issues affecting many people
using search engine may allow finding right issue faster

2. Search engines allow searching answer in all web, which may be useful if one 
is not
sure if bug is in WebKit or not.

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Spam and indexing

[Konstantin Tokarev]

29.03.2019, 19:16, "Alexey Proskuryakov" :
>> 28 марта 2019 г., в 14:10, Konstantin Tokarev  написал(а):
>>
>> 28.03.2019, 23:58, "Alexey Proskuryakov" :
>>> Hello,
>>>
>>> The robots.txt file that we have on bugs.webkit.org currently allows search 
>>> engines access to individual bug pages, but not to any bug lists. As a 
>>> result, search engines and the Internet Archive only index bugs that were 
>>> filed before robots.txt changes a few years ago, and bugs that are directly 
>>> linked from webpages elsewhere. These bugs are where most spam content 
>>> naturally ends up on.
>>>
>>> This is quite wrong, as indexing just a subset of bugs is not beneficial to 
>>> anyone other than spammers. So we can go in either direction:
>>>
>>> 1. Allow indexers to enumerate bugs, thus indexing all of them.
>>>
>>> Seems reasonable that people should be able to find bugs using search 
>>> engines.
>>
>> Yes, and it may give better result even than searching bugzilla directly
>>
>>> On the other hand, we'll need to do something to ensure that indexers don't 
>>> destroy Bugzilla performance,
>>
>> This can be solved by caching
>
> Is this something that other Bugzilla instances do? I'm actually not sure how 
> caching can be meaningfully applied to Bugzilla. One wants to always see the 
> latest updates, and our automation in particular won't be OK with stale data.

I'm not sure if HTTP-level caching may be used here, but quick search brings 
this:
https://www.bugzilla.org/releases/5.0.4/release-notes.html#feat_caching_performance

If we can update Bugzilla it should be possible at least to reduce number of 
database hits when pages
are rendered.

> - Alexey
>
>>> and of course spammers will love having more flexibility.
>>
>> rel="nofollow" on all links in comments should be enough to make spamming 
>> useless
>>
>>> 2. Block indexing completely.
>>>
>>> Seems like no one was bothered by lack of indexing on new bugs so far.
>>
>> That's survival bias - if nobody can find relevant bugs, nobody will ever 
>> complain
>>
>>> Thoughts?
>>>
>>> For reference, here is the current robots.txt content:
>>>
>>> $ curl https://bugs.webkit.org/robots.txt
>>> User-agent: *
>>> Allow: /index.cgi
>>> Allow: /show_bug.cgi
>>> Disallow: /
>>> Crawl-delay: 20
>>>
>>> - Alexey
>>> - Alexey
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>> --
>> Regards,
>> Konstantin


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

Re: [webkit-dev] Spam and indexing

[Konstantin Tokarev]

28.03.2019, 23:58, "Alexey Proskuryakov" :
> Hello,
>
> The robots.txt file that we have on bugs.webkit.org currently allows search 
> engines access to individual bug pages, but not to any bug lists. As a 
> result, search engines and the Internet Archive only index bugs that were 
> filed before robots.txt changes a few years ago, and bugs that are directly 
> linked from webpages elsewhere. These bugs are where most spam content 
> naturally ends up on.
>
> This is quite wrong, as indexing just a subset of bugs is not beneficial to 
> anyone other than spammers. So we can go in either direction:
>
> 1. Allow indexers to enumerate bugs, thus indexing all of them.
>
> Seems reasonable that people should be able to find bugs using search engines.

Yes, and it may give better result even than searching bugzilla directly

>On the other hand, we'll need to do something to ensure that indexers don't 
>destroy Bugzilla performance,

This can be solved by caching

>and of course spammers will love having more flexibility.

rel="nofollow" on all links in comments should be enough to make spamming 
useless

>
> 2. Block indexing completely.
>
> Seems like no one was bothered by lack of indexing on new bugs so far.

That's survival bias - if nobody can find relevant bugs, nobody will ever 
complain

>
> Thoughts?
>
> For reference, here is the current robots.txt content:
>
> $ curl https://bugs.webkit.org/robots.txt
> User-agent: *
> Allow: /index.cgi
> Allow: /show_bug.cgi
> Disallow: /
> Crawl-delay: 20
>
> - Alexey
> - Alexey
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Regarding problem in building webkit2

[Konstantin Tokarev]

25.02.2019, 14:06, "Rajagopalan Gangadharan" :
> Hello,
>
> I am trying to build webkit for haiku and I stumbled upon an error
>
> The error is in “Source\WebKit\UIProcess\WebsiteData\WebsiteDataStore.cpp” 
> line 2080 says about missing platformSetNetworkParameters function and I saw 
> it was defined for CURL and SOUP only. Should I use the function defined 
> under them or should I write it to be haiku specific(platform specific) if so 
> what should be the contents of it. Thank you!

It depends on how your network stack works. In order to reduce maintainance cost
you should consider using network stack supported by upstream, i.e. soup or curl

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

Re: [webkit-dev] Moving to Git

[Konstantin Tokarev]

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

>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, February 20, 2019 8:34 PM, Simon Fraser 
>  wrote:
>
>> Are you a WebKit developer? I can't tell from your email.
>>
>> Simon
>>
>>> On Feb 20, 2019, at 8:27 AM, Bug Tracker 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> I was curious about the status of the proposal for migrating from SVN to 
>>> Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
>>>
>>> The relevant page on the Trac wiki hasn't been updated for over 5 years and 
>>> since then Git has become much more popular (the de facto standard for new 
>>> projects, more or less), while:
>>>
>>> * SVN support is diminishing (e.g. in Xcode).
>>> * Git support on Windows is much better than 5 years ago.
>>> * It's difficult to find free robust SVN clients / UIs, unlike the plethora 
>>> of options available for Git.
>>> * Most young and relatively new developers (with less than 10 years of 
>>> experience, like myself) are much more comfortable with Git and maybe have 
>>> not even used SVN before, so moving to Git could encourage more users and 
>>> contributors.
>>>
>>> Is there any progress in this direction?
>>>
>>> Thank you, in advance!
>>> ___
>>> 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


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

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

[Konstantin Tokarev]

20.12.2018, 09:17, "Fujii Hironori" :
> Thank you very much for the feedbacks.
>
> On Thu, Dec 20, 2018 at 4:52 AM Konstantin Tokarev  wrote:
>> 19.12.2018, 12:53, "Fujii Hironori" :
>>> I'd like to change this because 'final' doesn't necessarily imply
>>> 'override'. See the following stackoverflow:
>>> https://stackoverflow.com/questions/29412412/does-final-imply-override
>>
>> It does imply override, unless it is used in a declaration of new virtual 
>> method
>> (which has no practical meaning fwiw)
>
> You are right. C++ allows using 'final' with 'virtual' without overriding.
> Even though I don't know practical use-cases for it, C++ allows it because 
> 'final' doesn't mean overriding.
> And, this is the only reason 'final' doesn't necessarily imply override.
> This is a kind of chicken egg problem. I don't know which is true:
>
> 1. C++ allows it because 'final' doesn't mean overriding.
> 2. 'final' doesn't necessarily imply override because C++ allows it

I see no problem here, because our code style checker forbids using 'final' and 
'virtual' in the
same declaration, so it's only allowed in overriding context.

>
> On Thu, Dec 20, 2018 at 6:28 AM Konstantin Tokarev  wrote:
>> 19.12.2018, 23:27, "Michael Catanzaro" :
>>> On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev 
>>> wrote:
>>>>  Adding override to method which already has final specifier doesn't
>>>>  affect anything,
>>>>  because both final and override may ony be used on virtual methods
>>>
>>> FWIW I prefer override because it's much more clear what that keyword
>>> is used for.
>>
>> If class itself has "final" specifier, "override" on methods works in the 
>> same way
>> as "final", and I agree that it conveys intention more clear.
>
> I think so, especially after I will update the code style guidelines in Bug 
> 192844.
>
>> Bug 192844 – Update code style guidelines for using 'final' specifier for 
>> all classes which has no derived classes
>> https://bugs.webkit.org/show_bug.cgi?id=192844
>
>> However, Darin in [1]
>> suggested that we use "final" aggressively to avoid accidentally losing 
>> compiler
>> optimization (i.e. devirtualization of call)
>>
>> [1] https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html
>
> I think this won't be a problem after all classes which has no derived 
> classes are capped with 'final'.

However, it might be a problem when leaf class with 'final' becomes non-final.

>
> On Thu, Dec 20, 2018 at 7:42 AM  wrote:
>> In that case, I'll point out that C++ Core Guidelines has a rule "Virtual 
>> functions should specify exactly one of virtual, override, or final".
>> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
>>
>> Their tl;dr:
>> "
>>         • virtual means exactly and only “this is a new virtual function.”
>>         • override means exactly and only “this is a non-final overrider.”
>>         • final means exactly and only “this is a final overrider.”
>> "
>>
>> FWIW, they also have a rule "Use final sparingly" with the note that "Claims 
>> of performance improvements from final should be substantiated."
>> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
>
> C.128 is a same rule with the current WebKit coding style guidelines.
> But, I think C.128 makes sense with C.139.
> C.139 is against to Bug 192844.
> After Bug 192844 update, we will have a lot of 'final' classes, not sparignly.

Do you have an idea how to automate this? Otherwise we'll never reach the
state where all leaf classes are final, because doing it manually will take 
lots of
time, and I see no way to enforce the rule in new code

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


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

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

[Konstantin Tokarev]

19.12.2018, 23:27, "Michael Catanzaro" :
> On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev 
> wrote:
>>  Adding override to method which already has final specifier doesn't
>>  affect anything,
>>  because both final and override may ony be used on virtual methods
>
> FWIW I prefer override because it's much more clear what that keyword
> is used for.

If class itself has "final" specifier, "override" on methods works in the same 
way
as "final", and I agree that it conveys intention more clear. However, Darin in 
[1]
suggested that we use "final" aggressively to avoid accidentally losing compiler
optimization (i.e. devirtualization of call)

[1] https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html

>
> Michael

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

19.12.2018, 21:02, "Darin Adler" :
>>  On Dec 19, 2018, at 1:52 AM, Fujii Hironori  
>> wrote:
>>
>>  I'd like to change this because 'final' doesn't necessarily imply
>>  'override'. See the following stackoverflow:
>>  https://stackoverflow.com/questions/29412412/does-final-imply-override
>
> I’d be happy to require both final and override if there was any benefit to 
> doing so.
>
> I read it fairly carefully, and I don’t think it says anything meaningful for 
> us. Maybe we can find a real example in WebKit code where there’s a “final” 
> and if we added “override”, it would have caught a mistake that “final” won’t 
> catch?

Adding override to method which already has final specifier doesn't affect 
anything,
because both final and override may ony be used on virtual methods

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

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

19.12.2018, 12:53, "Fujii Hironori" :
> I'd like to change this because 'final' doesn't necessarily imply
> 'override'. See the following stackoverflow:
> https://stackoverflow.com/questions/29412412/does-final-imply-override

It does imply override, unless it is used in a declaration of new virtual method
(which has no practical meaning fwiw)

>
> IIUC, 'final' method specifier can be useful for such like the following case:
>
>> class B {
>> public:
>>   virtual foo();
>>   virtual bar();
>> };
>> class B1 : public B {
>>   foo() final;
>> };
>> class D final : B1 {
>>   bar() override;
>> };
>
> The 'final' method specifier indicates D can't override the method foo.
> Thus, using 'final' method specifier implies other virtual functions
> can be overridden. I'm not sure my understanding right. Please correct me.

final method specifier on foo doesn't affect other methods anyhow, it just 
forbids
overriding of foo

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


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

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

[Konstantin Tokarev]

18.12.2018, 22:35, "Michael Catanzaro" :
> I know I'm getting a bit far afield here, but:
>
> On Mon, Dec 17, 2018 at 9:26 PM, Ryosuke Niwa  wrote:
>>  But then our behavior of HashMap which doesn't accept the POD
>>  integral value of 0 as a key
>
> This behavior is really unexpected and dangerous [1], and we should
> seriously consider changing it. No doubt lots of bugs caused by this
> are just waiting to be uncovered. I've been working on WebKit since
> 2014 and didn't know about this until last month.
>
> Another oddity: I recently learned that AtomicStrings are actually
> interned strings. WTF. Why not call them that? I had thought for years
> that they were strings safe to be shared across threads, like other
> atomics. Not at all. Maybe this was dumb of me, but it could have been
> avoided by better naming.

I agree that "atomic" part of AtomicString is kinda misleading, however wiki
explains it all

https://trac.webkit.org/wiki/EfficientStrings#AtomicStringVSString

BTW, /me personally didn't know what "interned string" is until today :)

>
> Michael
>
> [1] https://trac.webkit.org/changeset/238407/webkit
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Lots of spam on Bugzilla

[Konstantin Tokarev]

05.12.2018, 20:31, "Michael Catanzaro" :
> On Wed, Dec 5, 2018 at 10:44 AM, ross.kirsl...@sony.com wrote:
>>  You can click Tag and enter "spam". (There's also the "obsolete" tag
>>  for hiding, say, outdated feedback from the EWS bots. Unfortunately
>>  tagging is purely by manual entry right now, but it works.)
>
> Wow, I never noticed this. I thought Apple folks were using superpowers
> to obsolete comments!
>
> If we add rel="nofollow" then I think we should also respond with
> comments warning the spammers that we are using rel="nofollow" and
> their spam will not boost their SEO. Maybe that will convince
> individual spammers to give us a break.

Also it might make sense to block comments in issues that attract unhealthy 
attention,
like this one, if bugzilla allows that

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

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

[Konstantin Tokarev]

31.10.2018, 05:18, "Fujii Hironori" :
> wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like to 
> rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h.
> Any suggestion?

What about Unicode.h or UnicodeHelpers.h? UTF8.h deals with UTF16 as well

>
> Here is ICU's #include "unicode/utf8.h" which happens to include 
> wtf/unicode/UTF8.h
> https://github.com/unicode-org/icu/blob/master/icu4c/source/common/unicode/utf.h#L217
>
> Here is MSVC quoted form #include behavior documented.
> https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx
>
> Bug 189693 – [Win][Clang] warning: #include resolved using non-portable 
> Microsoft search rules as: ..\..\Source\WTF\wtf/unicode/utf8.h
> https://bugs.webkit.org/show_bug.cgi?id=189693
>
> -- Fujii
>
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Is gperf really needed when building the JSCOnly with CMake?

[Konstantin Tokarev]

Or, better, if (ENABLE_WEBCORE) 30.09.2018, 18:58, "Michael Catanzaro" :Yeah, I'd just put it in an if (NOT ${PORT} STREQUAL "JSCOnly")(writing that off the top of my head, probably somehow wrong)___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev-- Regards,Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Freenode spam counter-measure

[Konstantin Tokarev]

06.08.2018, 18:25, "Philippe Normand" :
> Also the WKR and webkitbot bots will need to be registered with NickServ, 
> otherwise their notifications in the channel won’t be delivered :)

You'll be surprised but webkitbot is registered (while WKR isn't)

/msg NickServ ACC webkitbot
ACC 3

However, not all developers on the channel are registered

So it might be more convenient to use bot like [1] to kick off spammers instead 
of requiring registration

[1] http://paste.the-compiler.org/view/170e0019

>
> Philippe
>
>> On 6 Aug 2018, at 16:18, Philippe Normand  wrote:
>>
>>> On 6 Aug 2018, at 16:12, Darin Adler  wrote:
>>>
>>>> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev  wrote:
>>>>
>>>>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>>>>>
>>>>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>>>>> reducing spam. Only messages from registered nicks would come through.
>>>>>
>>>>> I tried this by typing this:
>>>>>
>>>>>   /msg ChanServ set #webkit restricted on
>>>>
>>>> This command works differently from +r: it forbids join for people who are 
>>>> not in access list, instead of simply forbidding unregistered users.
>>>
>>> What’s the ChanServ function for setting +r?
>>
>> I think it is:
>>
>> /msg chanserv set #webkit mlock +r
>>
>> Philippe
>>
>> ___
>> 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


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

Re: [webkit-dev] Freenode spam counter-measure

[Konstantin Tokarev]

06.08.2018, 01:21, "Darin Adler" :
>>  On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>
>>  Can one of the #webkit admin please set the +r mode on? This would help 
>> reducing spam. Only messages from registered nicks would come through.
>
> I tried this by typing this:
>
> /msg ChanServ set #webkit restricted on

This command works differently from +r: it forbids join for people who are not 
in access list, instead of simply forbidding unregistered users.

>
> But ChanServ replied:
>
> ChanServ: You are not authorized to perform this command.
>
> I wonder who is authorized!?

Only channel op can do this. If you have appropriate rights in access list, you 
can do

/msg ChanServ op #webkit

and then use operator's commands

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

-- 
Regards,
Konstantin

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

Re: [webkit-dev] why the "WebKitStorageProcess” process missing when midori running?

[Konstantin Tokarev]

26.05.2018, 12:28, "tugouxp" <13824125...@163.com>:
> Hi folks:
>
>    i porting the webkit to my boards, and also the browser midori and 
> minibrowser can be running normally, but from the pstree ,
>
> i know that the process "WebKitStorageProcess“　are not running, so can you 
> tell me why?

Does loaded page use IndexedDB or ServiceWorker?

>
> so you can see only WebKitNetWork, WebKitWebProcess and midori process here, 
> where is the storage process?
>
> init-+-WebKitNetworkPr-+-2*[{ReceiveQueue}]
>      |                 |-{Storage}
>      |                 |-{WebKitNetworkPr}
>      |                 |-{background}
>      |                 |-{erialBackground}
>      |                 |-{gmain}
>      |                 `-{pool}
>      |-WebKitWebProces-+-{EventDispatcher}
>      |                 |-2*[{ReceiveQueue}]
>      |                 |-{WebKitWebProces}
>      |                 |-{gmain}
>      |                 |-{nnectionManager}
>      |                 `-{rruptDispatcher}
>      |-adbd-+-adb_shell---sh---pstree
>      |      `-4*[{adbd}]
>      |-ash-+-midori-+-{PressureMonitor}
>      |     |        |-2*[{ReceiveQueue}]
>      |     |        |-{StorageManager}
>      |     |        |-{e: IconDatabase}
>      |     |        |-{ebsiteDataStore}
>      |     |        |-{gmain}
>      |     |        |-{midori}
>      |     |        `-{pool}
>      |     `-weston-+-weston-desktop-
>      |              `-3*[{weston}]
>      |-ntpd
>      |-udevd
>      |-udhcpc
>      `-wpa_supplicant
>
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Switch to std::variant?

[Konstantin Tokarev]

23.05.2018, 18:40, "Michael Catanzaro" :
> On Wed, May 23, 2018 at 6:14 AM, z...@falconsigh.net wrote:
>>  Some GCC-and-libstdc++ configurations would still require a fallback
>>  implementation
>
> After the std::optional fiasco, I'm pretty nervous about the state of
> using new C++ 17 features.

What do you mean under "std::optional fiasco"?

>
> We've wound up in a situation where we're OK with increasing the
> compiler requirement to recent versions... as long as WebKit continues
> to build with ancient libstdc++. So increasing use of more C++ 17
> standard library features seems difficult, and of really limited
> benefit if we're going to need to keep a fallback WTF implementation
> around, which will receive limited testing from us, but which will be
> used by most of our users in practice (at least for GTK).
>
> This is a hard problem. I don't have any answers. But I don't think our
> status quo is very good. https://bugs.webkit.org/show_bug.cgi?id=185198
> is still unresolved and I'm out of ideas
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

Re: [webkit-dev] [jsc-dev] Proposal: Removing ENABLE(INTL)

[Konstantin Tokarev]

21.05.2018, 17:45, "Michael Catanzaro" :
> On Mon, May 21, 2018 at 8:55 AM, Konstantin Tokarev 
> wrote:
>>  For the record, having !ENABLE(INTL) option allowed to build WebKit
>>  against old ICU versions, e.g. version that is shipped with RHEL 7.
>
> For WebKitGTK+, we do not support building without ENABLE(INTL), and we
> don't need to worry about RHEL 7 since RHEL is shipping an unsupported
> version of WebKit with bundled ICU.
>
> But we do need to support Ubuntu 16.04 (with ICU 55). If ENABLE(INTL)
> is going to require newer ICU than that, then we would need to expose
> ENABLE(INTL) and ensure that disabling it works. We do have a buildbot
> to check this, and it's green right now, so trunk must be fine. But I'm
> curious if anyone knows what the ICU requirement is for ENABLE(INTL)?

AFAIK ICU 54 is enough

>
> Michael

-- 
Regards,
Konstantin

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

Re: [webkit-dev] [jsc-dev] Proposal: Removing ENABLE(INTL)

[Konstantin Tokarev]

19.05.2018, 14:12, "Yusuke SUZUKI" :
> Hi WebKittens,
>
> I would like to remove ENABLE(INTL) compile time flag and always enable INTL.
> This is ECMAScript Intl (i18n) feature. This feature depends on ICU.
> But right now, even JSC (and WTF) always require ICU. Even if we disable 
> ENABLE(INTL), we still require ICU.

For the record, having !ENABLE(INTL) option allowed to build WebKit against old 
ICU versions, e.g. version that is shipped with RHEL 7.

>
> New INTL features are gurded separately with the compile flags (since some 
> new features require new ICU). So, removing ENABLE(INTL) just enables Intl 
> basic features, which are shipped more than 1 year ago and it is quite mature.
>
> Best regards,
> Yusuke Suzuki
> --
> Regards,
> Yusuke Suzuki
> ,
>
> ___
> jsc-dev mailing list
> jsc-...@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev


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

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

[Konstantin Tokarev]

26.04.2018, 20:09, "Colin Bendell | +1.613.914.3387" :
> On 26 April 2018 at 12:23, Konstantin Tokarev  wrote:
>>  Not to mention those evil people who reject page loading for user agents
>>  they don't (want to) support
>
> How does locking the UA solve the misbehaving parsers in the wild?

There will be less information in UA and therefore less reasons for developers
to do this, instead of using direct feature testing

> They will still misbehave and break the user experience. However,
> those of us that are trying to optimize the user experience by working
> around bugs for specific versions are now handicapped and punished.

While parsing UA string handicaps and punishes users of alternative user agents.

-- 
Regards,
Konstantin

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

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

[Konstantin Tokarev]

26.04.2018, 19:16, "Michael Catanzaro" :
> On Thu, Apr 26, 2018 at 11:13 AM, Michael Catanzaro
>  wrote:
>>  By fixing the WebKit bug, of course. And in the meantime you can work
>>  around it on the server side by not using , right?
>
> Consider the other perspective on this problem. If other servers look
> at the WebKit version in the UA to determine if WebKit supports img
> src=mp4, other WebKit ports that don't support this are going to be out
> of luck and get broken pages. I know that's not what you're doing --
> you're looking at iOS version instead, and only doing it to work around
> a specific bug, which is much better -- but the problem of websites
> sending bad content based on bad user agent parsing is so severe that
> we don't have many good options, here. :/

Not to mention those evil people who reject page loading for user agents
they don't (want to) support

-- 
Regards,
Konstantin

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

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

[Konstantin Tokarev]

26.04.2018, 15:15, "Ricky Young" :
> Actually it does, a lot!
>
> I guess that soon it won't be possible to determine iOS version distribution 
> using User-Agent sniffing. Right? Is there an alternative for the browser to 
> tell the iOS version?

Why do you want to access this information?

>
> Sent: Thursday, April 26, 2018 at 1:54 PM
> From: "Anne van Kesteren" 
> To: "Ricky Young" 
> Cc: "Konstantin Tokarev" , "webkit-dev@lists.webkit.org" 
> 
> Subject: Re: [webkit-dev] New iOS versions sending bogus User-Agent build data
> On Thu, Apr 26, 2018 at 12:30 PM, Ricky Young  wrote:
>>  I read the report and still find it hard to understand, if "User Agent 
>> sniffing is a terrible way to determine whether a browser supports certain 
>> features", what is the correct way of doing it?
>
> https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection
>
> Hope that helps,
>
> --
> https://annevankesteren.nl/[https://annevankesteren.nl/]

-- 
Regards,
Konstantin

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

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

[Konstantin Tokarev]

26.04.2018, 13:08, "Ricky Young" :
> Until iOS 11.3, User-Agent build data contained the build that corresponds to 
> the device (e.g. Mobile/15D100 if the requesting device was running iOS 
> 11.2.6).
>
> Since iOS 11.3 was released I noticed that the User-Agent that is reported to 
> the brower is reporting a bogus build, i.e Mobile/15E148, regardless to the 
> iOS version that the requesting device is running. I would expect that a 
> device that runs 11.3 will reprot a different User-Agent than a device that 
> runs 11.3.1 and certianly than a device that runs 11.4 (Beta 1 & 2).
>
> I just wonder if my observation is an expected behavior, and if so, what is 
> the intention behind it. If this behavior is not intended and expected, I 
> would love to research it and propose a patch (would be my first Open Source 
> contribution).

Hi,

User-Agent string is frozen since https://bugs.webkit.org/show_bug.cgi?id=180365

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

Re: [webkit-dev] Compiling Webkit --wincairo

[Konstantin Tokarev]

19.04.2018, 17:24, "Barone Ashura" :
> Hello,
>
> I would like to understand how can I control the build process for building 
> Webkit-cairo on windows.
>
> As of now I managed to successfully compile/integrate/link/execute a source 
> tree downloaded from git using the instructions listed at: 
> https://webkit.org/webkit-on-windows/#installing-developer-tools
>
> It was not a straightforward experience, but in the end the process completed 
> for 64bit architectures, using Visual Studio 2017.
>
> I ran the process using the following command line: perl build-webkit --debug 
> --verbose --wincairo --only-webkit, and it worked even with the --release 
> option.
>
> As far as I understand this build contains waaay too many things than I 
> actually need (sqlite, webGL, 3d-rendering, gamepad, just to name a few); I 
> would like to run a minimal build, and according to the e help of the 
> build-webkit script it appears that there there is a ton of options to 
> exclude parts of the build.
>
> I ran the following command:
> 
> D:\WebKit\webkit\Tools\Scripts>perl build-webkit --release --verbose 
> --wincairo --only-webkit --no-3d-rendering --no-accelerated-2d-canvas 
> --no-attachment-element --no-channel-messaging --no-css-box-decoration-break 
> --no-css-compositing --no-css-device-adaptation --no-css-image-orientation 
> --no-css-image-resolution --no-css-image-set --no-css-shapes --no-css3-text 
> --no-custom-elements --no-custom-scheme-handler --no-data-transfer-items 
> --no-datalist-element --no-device-orientation --no-dom4-events-constructor 
> --no-download-attribute --no-encrypted-media --no-fetch-api 
> --no-font-load-events --no-ftl-jit --no-ftpdir --no-fullscreen-api 
> --no-gamepad --no-geolocation --no-gstreamer-gl --no-high-dpi-canvas 
> --no-icon-database --no-indexed-database --no-input-speech 
> --no-input-type-color --no-input-type-date --no-input-type-datetime 
> --no-input-type-datetimelocal --no-input-type-month --no-input-type-time 
> --no-input-type-week --no-intl --no-jit --no-legacy-encrypted-media 
> --no-legacy-web-audio --no-link-prefetch --no-mathml --no-media-capture 
> --no-media-source --no-media-statistics --no-media-stream --no-meter-element 
> --no-mhtml --no-mouse-cursor-scale --no-navigator-content-utils 
> --no-navigator-hardware-concurrency --no-netscape-plugin-api 
> --no-notifications --no-orientation-events --no-performance-timeline 
> --no-proximity-events --no-quota --no-readableStreamAPI 
> --no-readableByteStreamAPI --no-resolution-media-query --no-scripted-speech 
> --no-service-worker --no-subtle-crypto --no-svg-fonts --no-system-malloc 
> --no-touch-events --no-touch-slider --no-video --no-video-track 
> --no-web-animations --no-web-audio --no-web-authn --no-web-rtc 
> --no-webassembly --no-webgl --no-webgl2 --no-writableStreamAPI --no-xslt
> 
>
> but the output of CMake seems to be inconsistent with the command line 
> options:
>
> 
> +  cmake -DPORT="WinCairo" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
> -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 15 2017 Win64" 
> -DCMAKE_GENERATOR_TOOLSET="host=x64" -DSHOW_BINDINGS_GENERATION_PROGRESS=1 
> "D:/WebKit/webkit"

Looks like build-webkit ignores feature flags for WinCairo and AppleWin ports

Please try this patch:

diff --git a/Tools/Scripts/build-webkit b/Tools/Scripts/build-webkit
index 3bfed1ee289..dbfd8f64aaa 100755
--- a/Tools/Scripts/build-webkit
+++ b/Tools/Scripts/build-webkit
@@ -290,7 +290,7 @@ if (isAppleWinWebKit() || isWinCairo()) {
 removeCMakeCache(@featureArgs);
 
 chdirWebKit();
-if (exitStatus(generateBuildSystemFromCMakeProject($prefixPath, 
@cmakeArgs))) {
+if (exitStatus(generateBuildSystemFromCMakeProject($prefixPath, 
@featureArgs, @cmakeArgs))) {
 die "Run Visual Studio 2017 installation vcvars.bat before 
build-webkit when using ninja";
 }
 


> Re-run cmake no build system arguments
> -- The C compiler identification is MSVC 19.12.25830.2
> -- The CXX compiler identification is MSVC 19.12.25830.2
> -- Check for working C compiler: 
> D:/VisualStudio2017/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe
> -- Check for working C compiler: 
> D:/VisualStudio2017/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: 
> D:/VisualStudio2017/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe
> -- Check for working CXX compiler: 
> D:/VisualStudio2017/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- The CMake build type is: Release
> -- Found Gperf: D:/WebKit/GnuWin32/bin/gperf.exe (Required is at least 
> version "3.0.1")
> -- Found Perl: D:/WebKit/Perl64/bin/perl.e

Re: [webkit-dev] python2

[Konstantin Tokarev]

10.04.2018, 23:38, "Michael Catanzaro" :
> Hi,
>
> python2 end of life is January 1, 2020. But even before then, we'll need to 
> make WebKit work in environments without python2 available, because it's not 
> going to be present in the next Red Hat Enterprise Linux or SUSE Linux 
> Enterprise, and its fate in community distros like Fedora (where it is being 
> orphaned by the maintainers, and at risk of removal) is looking questionable 
> at best.
>
> So we have basically two options:
>
>  * Require python3 and port our python scripts from python2 to python3
>  * Make our scripts support both major versions of python simultaneously
>
> The later would be quite a pain, because developers using python2 are sure to 
> break developers using python3, and vice-versia.

Adding pylint --py3k to style checker could prevent such breaks

> But my understanding is that python3 is not readily-available on Macs, so 
> that might be what we need to do if Apple wants to stick with python2.
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

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

[Konstantin Tokarev]

26.03.2018, 16:31, "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).

A lot of other clang-based tools use this file, most notably clang-tidy.

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

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Meltdown and Spectre attacks

[Konstantin Tokarev]

05.01.2018, 20:28, "Michael Catanzaro" :
> On Fri, Jan 5, 2018 at 10:31 AM, Konstantin Tokarev 
> wrote:
>>  Seems like both mitigations are already present in trunk
>
> Are there recent commits you can link to? I must have missed them fly
> by.

https://bugs.webkit.org/show_bug.cgi?id=181266
https://bugs.webkit.org/show_bug.cgi?id=165503 (prophecy?)

>
> Michael

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

Re: [webkit-dev] Meltdown and Spectre attacks

[Konstantin Tokarev]

> Hi,
> 
> Here's a collection of blog posts from other major browser vendors
> regarding the Meltdown and Spectre attacks:
> 
> https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
> 
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
> 
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
> 
> Notably, Edge and Firefox are reducing the resolution of
> performance.now(), and all three are disabling SharedArrayBuffer.
> 
> This is just a heads-up.

Seems like both mitigations are already present in trunk

> 
> Michael
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting WPT tests

[Konstantin Tokarev]

21.12.2017, 04:29, "youenn fablet" :
> Hi all,
>
> Just to let you know that a new script landed in WebKit: 
> Tools/Scripts/export-w3c-test-changes.
> Please have a look if you are interested in and ping me if you have any 
> question or suggestion.
> This script can:
> - Push your LayoutTests/imported/w3c/web-platform-tests changes made within a 
> WebKit repository to your own GitHub WPT clone
> - Create a PR on W3C WPT repo and add a comment on the related WebKit 
> bugzilla (-c option)
>
> There is some information that is needed the first time: your GitHub 
> username, a GitHub token to allow the script to create a PR on your behalf.

It might be useful to add GitHub usernames to contributors.json

> Script documentation might help.
>
> One potential workflow could be something like:
> 1. Author a webkit patch
> 2. Upload patch to bugzilla
> 3. At the time patch is set to "r?" on bugzilla, use the script to create a 
> W3C WPT PR.
> When the patch is "r+", merge the W3C WPT PR and land the WebKit patch.
>
> Merry Christmas,
>    y
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Buildbot upgrade on build.webkit.org

[Konstantin Tokarev]

11.12.2017, 02:49, "Carlos Alberto Lopez Perez" :
> On 07/12/17 21:47, Aakash Jain wrote:
>>  For people using build.webkit.org , I would
>>  like to know what pages you use most of the time (e.g.: builder page,
>>  console view etc.) and what are your primary use-cases (purpose to
>>  visit build.webkit.org ). Also if you have
>>  any feedback/concern about new Buildbot please let me know.
>
> I use 99% of the time the waterfall view, and I think the new waterfall
> view of buildbot 9 is a step back in terms of usefulness.
>
> More details on about why I think this here:
> https://bugs.webkit.org/show_bug.cgi?id=175056#c1

I also use waterfall 99% of time, and new waterfall totally sucks.

I wonder if it's possible to get rid of stupid sidebar, if not it's a complete
disaster.

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

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

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

[Konstantin Tokarev]

  08.12.2017, 20:18, "JF Bastien" :Also, as we discussed on the github bug the JSC binary is available as part of the WebAssembly waterfall that Google maintains at wasm-stat.us The build is pretty straightforward:https://github.com/WebAssembly/waterfall/blob/7cda260b8ea5264900624a4cdc45df2c9e2de010/src/build.py#L943FWIW, it's easy to extend this script to work for Windows and Linux too by replacing -DPORT=Mac with -DPORT=JSCOnly   I understand that you've got a policy of only taking "official" binaries. The GTK team would be the official maintainer of the Linux port? There's an official jsc binary is available on MacOS :-)  On Fri, Dec 8, 2017 at 9:07 AM, Lucas Forschler  wrote:Hi Mathias, The Linux archives could be exposed on the build-archives page. In fact, we already store the output of the builders in S3. However, the igalia team only uploads a small file with a pointer to their internal builds. If I recall, they have limited bandwidth, and prefer to store their builds behind their firewall to save on external traffic to buildbot/s3. If you look here you will see a ‘transfer-to-s3’ build step.The archive the builder creates is uploaded, here is a sample. Opening that up shows the location where the archive is stored:Built product is available here:http://webkitgtk-release.igalia.com/built-products/release_r225678_b7832.zip I cannot reach that link, so I would assume it’s behind the igalia firewall. 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) Lucas   On Dec 8, 2017, at 12:44 AM, Mathias Bynens  wrote: Dear WebKit friends, Please consider hosting precompiled `jsc` binaries for Linux somewhere official. Perhaps https://webkit.org/build-archives/? The build bots already generate those binaries anyway — all that’s missing is an additional build step that archives and uploads them. Doing so would make it easier for developers to test JSC directly, or to include JSC when running benchmarks such as the Web Tooling Benchmark (ref. https://github.com/v8/web-tooling-benchmark/pull/29#discussion_r155587697). I recently built a tool that automates the process of installing precompiled binaries for various JS engines: https://github.com/GoogleChromeLabs/jsvu It’d be great to be able to support _javascript_Core on linux32 and linux64 as well! Prior discussion: https://bugs.webkit.org/show_bug.cgi?id=179945#c11 Regards,Mathias___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev ,___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev  -- Regards,Konstantin ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Konstantin Tokarev]

17.11.2017, 18:19, "Maciej Stachowiak" :
>>  On Nov 17, 2017, at 7:15 AM, Konstantin Tokarev  wrote:
>>
>>  16.11.2017, 20:10, "Alexey Proskuryakov" :
>>>  Migrating WebKit tests seems undesirable to me, as that would make us lose 
>>> all their modification history. As mentioned before, WPT tests are 
>>> inherently getting less attention in CI support, largely because of unclear 
>>> benefit when there isn't any history for why the particular test was added.
>>
>>  Possible workaround would be to keep original file path as a comment inside 
>> new file. In this case history of ex-WebKit tests can be easily retraced 
>> from WebKit repository.
>
> From Apple’s point of view, we are ok with leaving duplicate tests rather 
> than removing them, especially when they were created as regression tests for 
> specific bugs rather than as broad standards compliance tests.
>
>>>  Regression tests are taking an excessive amount of time to run for us 
>>> (more than 1.5 hours in a debug build), a very large proportion of which is 
>>> WPT. I do not think that the strategy of adopting WPT tests is working well 
>>> for WebKit.
>>
>>  If existing tests are converted to WPT, do they take more time to run? If 
>> yes, it's quite unfortunate and needs to be fixed in WPT infrastructure.
>
> I talked to Alexey bout this and he says there is indeed a higher per-test 
> time cost, and that it’s a likely fixable problem with the WPT server. If 
> anyone fixed this, EWS and buildbot turnaround time would improve 
> significantly.

Is it possible to run tests that don't require server directly, like it's done 
now for regression tests?

>
>>>  - Alexey
>>>
>>>>  15 нояб. 2017 г., в 2:02, Philip Jägenstedt  
>>>> написал(а):
>>>>
>>>>  Hello webkit-dev! (ecosystem-infra in Bcc)
>>>>
>>>>  TPAC was last week, and there was much talk about web-platform-tests. 
>>>> Some notes are at 
>>>> https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html
>>>>  and in particular https://www.w3.org/2017/11/07-testing-minutes.html.
>>>>
>>>>  In Blink, we're thinking seriously about what it'd take to upstream large 
>>>> parts of LayoutTests into web-platform-tests, and we've realized that 
>>>> there are some risks here, beyond just making sure the tests are good and 
>>>> per spec. Specifically, one bad outcome would be if Blink successfully 
>>>> upstreamed thousands of tests that are also in WebKit, which then begin to 
>>>> diverge in small and large ways. That'd leave WebKit with more duplication 
>>>> between its own tests and web-platform-tests than any other engine, and a 
>>>> headache that grows over time.
>>>>
>>>>  So, I think this would require close cooperation with the WebKit project. 
>>>> Some different ways this might happen:
>>>>
>>>>  * A Blink developer and WebKit developer work together at the same time 
>>>> to move their common tests in some area into web-platform-tests, each 
>>>> removing identical tests that were upstreamed by the other and 
>>>> consolidating what remains.
>>>>  * A Blink developer works to first upstream tests from WebKit (using 
>>>> WebKit's coming export mechanism), waits for it to be imported into Blink, 
>>>> and then removes the tests from Blink.
>>>>  * The reverse situation.
>>>>
>>>>  Are there already some areas where the first approach might be doable, 
>>>> where the Blink and WebKit folks already know each other and are eager to 
>>>> do this? Is LayoutTests/css3/flexbox/ by any chance such a case?
>>>>
>>>>  I realize it's hard to judge these approaches in the abstract, but am 
>>>> curious to hear any enthusiasm or concerns about it.
>>>>
>>>>  Thanks!
>>>>  ___
>>>>  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
>>
>>  --
>>  Regards,
>>  Konstantin
>>  ___
>>  webkit-dev mailing list
>>  webkit-dev@lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Konstantin Tokarev]

16.11.2017, 20:10, "Alexey Proskuryakov" :
> Migrating WebKit tests seems undesirable to me, as that would make us lose 
> all their modification history. As mentioned before, WPT tests are inherently 
> getting less attention in CI support, largely because of unclear benefit when 
> there isn't any history for why the particular test was added.

Possible workaround would be to keep original file path as a comment inside new 
file. In this case history of ex-WebKit tests can be easily retraced from 
WebKit repository.

>
> Regression tests are taking an excessive amount of time to run for us (more 
> than 1.5 hours in a debug build), a very large proportion of which is WPT. I 
> do not think that the strategy of adopting WPT tests is working well for 
> WebKit.

If existing tests are converted to WPT, do they take more time to run? If yes, 
it's quite unfortunate and needs to be fixed in WPT infrastructure.

>
> - Alexey
>
>> 15 нояб. 2017 г., в 2:02, Philip Jägenstedt  написал(а):
>>
>> Hello webkit-dev! (ecosystem-infra in Bcc)
>>
>> TPAC was last week, and there was much talk about web-platform-tests. Some 
>> notes are at 
>> https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html
>>  and in particular https://www.w3.org/2017/11/07-testing-minutes.html.
>>
>> In Blink, we're thinking seriously about what it'd take to upstream large 
>> parts of LayoutTests into web-platform-tests, and we've realized that there 
>> are some risks here, beyond just making sure the tests are good and per 
>> spec. Specifically, one bad outcome would be if Blink successfully 
>> upstreamed thousands of tests that are also in WebKit, which then begin to 
>> diverge in small and large ways. That'd leave WebKit with more duplication 
>> between its own tests and web-platform-tests than any other engine, and a 
>> headache that grows over time.
>>
>> So, I think this would require close cooperation with the WebKit project. 
>> Some different ways this might happen:
>>
>> * A Blink developer and WebKit developer work together at the same time to 
>> move their common tests in some area into web-platform-tests, each removing 
>> identical tests that were upstreamed by the other and consolidating what 
>> remains.
>> * A Blink developer works to first upstream tests from WebKit (using 
>> WebKit's coming export mechanism), waits for it to be imported into Blink, 
>> and then removes the tests from Blink.
>> * The reverse situation.
>>
>> Are there already some areas where the first approach might be doable, where 
>> the Blink and WebKit folks already know each other and are eager to do this? 
>> Is LayoutTests/css3/flexbox/ by any chance such a case?
>>
>> I realize it's hard to judge these approaches in the abstract, but am 
>> curious to hear any enthusiasm or concerns about it.
>>
>> Thanks!
>> ___
>> 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


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

Re: [webkit-dev] unified sources build + forwarding headers that are copies

[Konstantin Tokarev]

14.11.2017, 14:54, "Salisbury, Mark" :
> Hello,
>
> I’m building on Windows (WPE platform, perhaps I’m the first to try this!) 
> and I’m seeing some compile errors that I believe are arising from previously 
> untested combinations of source files.
>
> If I understand unified sources build correctly, it uses a large list of 
> files and then arranges them into groups, 8 files at a time.  If I have a 
> slightly different set of files than is standard, or if someone adds a new 
> source file, the combinations of files can change.  If the same header file 
> is included twice (and forwarding header file is a copy of the original), 
> this causes duplicate definitions / compile errors.

Huh, this seems to be a consequence of our conversion to #pragma once

>
> My question is – is there a right / ideal way to fix these conflicts?
>
> d:\git\webkit-org\source\javascriptcore\runtime\ArrayBufferSharingMode.h is 
> included twice, the first time, via the real path, the second time, via a 
> JavaScriptCore forwarding header.  Note that this forwarding header is a copy 
> of the header file, not a pointer/alias to the real header path.
>
> The code that creates the forwarding header version comes from 
> D:\git\webkit-org\Source\JavaScriptCore\PlatformWin.cmake (see xcopy around 
> line 40).
>
> Do non-windows ports use a more intelligent method (a pointer, not a file 
> copy) for creating forwarding headers for JavaScriptCore includes?
>
> Is the windows build the only one to use unified sources currently?
>
> Source/WebKit/Scripts/generate-forwarding-headers.pl scans .c|.cpp files for 
> forwarding headers that need to be created and creates a header ‘pointer’ to 
> the real path, so both paths could be included (forwarding header vs. real) 
> and there would be no conflict, because ultimately, only the real header is 
> included.
>
> So I guess I’m suggesting to use a forwarding header ‘pointer’ instead of 
> header file xcopy, which would mean running a script that recurses 
> directories in javascriptcore and creates forwarding headers.  That would 
> mean no duplicate header file name would be allowed in JavaScriptCore – I 
> don’t think that’s a problem though.  (I don’t really like the idea of 
> grep’ing all webcore to create forwarding headers where needed, grep’ing 
> webcore gets expensive) .  Just wondering if there are other suggestions.
>
> Thanks,
>
> Mark
>
> (Personally I don’t like forwarding headers but that’s another topic…  not 
> sure if the benefits outweigh associated problems)
>
> D:\git\webkit-org\WebKitBuild\Debug\DerivedSources\WebCore\unified-sources\UnifiedSource180.cpp
>
> Turned on ‘show includes’, you can see the two ways I get to the same header 
> file:
>
> First source file including ArrayBufferSharingMode.h:
>
> 1>Note: including file: D:\git\webkit-org\Source\WebCore\css/DOMMatrix.cpp
>
> 1>Note: including file:  D:\git\webkit-org\Source\WebCore\config.h
>
> 1>Note: including file:  d:\git\webkit-org\source\webcore\css\DOMMatrix.h
>
> 1>Note: including file:   
> d:\git\webkit-org\source\webcore\css\DOMMatrixReadOnly.h
>
> 1>Note: including file:    
> d:\git\webkit-org\source\webcore\css\DOMMatrixInit.h
>
> 1>Note: including file: 
> d:\git\webkit-org\source\webcore\css\DOMMatrix2DInit.h
>
> 1>Note: including file:    
> D:\git\webkit-org\Source\WebCore\bindings\js\ScriptWrappable.h
>
> 1>Note: including file: 
> D:\git\webkit-org\Source\JavaScriptCore\heap/Weak.h
>
> 1>Note: including file:    
> D:\git\webkit-org\Source\WebCore\platform\graphics\transforms\TransformationMatrix.h
>
> 1>Note: including file: 
> D:\git\webkit-org\Source\WebCore\platform\graphics\FloatPoint.h
>
> 1>Note: including file:  
> d:\git\webkit-org\source\webcore\platform\graphics\FloatSize.h
>
> 1>Note: including file:   
> d:\git\webkit-org\source\webcore\platform\graphics\IntPoint.h
>
> 1>Note: including file:    
> d:\git\webkit-org\source\webcore\platform\graphics\IntSize.h
>
> 1>Note: including file: 
> D:\git\webkit-org\Source\WebCore\platform\graphics\FloatPoint3D.h
>
> 1>Note: including file:    
> D:\git\webkit-org\Source\JavaScriptCore\runtime/Float32Array.h
>
> 1>Note: including file: 
> d:\git\webkit-org\source\javascriptcore\runtime\TypedArrays.h
>
> 1>Note: including file:  
> d:\git\webkit-org\source\javascriptcore\runtime\GenericTypedArrayView.h
>
> 1>Note: including file:   
> d:\git\webkit-org\source\javascriptcore\runtime\ArrayBuffer.h
>
> 1>Note: including file:    
> d:\git\webkit-org\source\javascriptcore\runtime\ArrayBufferSharingMode.h
>
> Second source file including ArrayBufferSharingMode.h:
>
> 1>Note: including file: 
> D:\git\webkit-org\Source\WebCore\css/DOMMatrixReadOnly.cpp
>
> 1>Note: including file:  D:\git\webkit-org\Source\WebCore\config.h
>
> 1>Note: including file:  
> d:\git\webkit-org\source\webcore\css\CSSToLengthConversionData.h
>
> 1>Note: including file:  D:\git\webkit-org\Source\WebCore\dom\DOMPoint.h
>
> 1>Not

Re: [webkit-dev] unified sources build + forwarding headers that are copies

[Konstantin Tokarev]

14.11.2017, 19:10, "Michael Catanzaro" :
> On Tue, Nov 14, 2017 at 5:54 AM, Salisbury, Mark
>  wrote:
>>  Hello,
>>
>>  I’m building on Windows (WPE platform, perhaps I’m the first to
>>  try this!)
>
> Wow!
>
>>  and I’m seeing some compile errors that I believe are arising from
>>  previously untested combinations of source files.
>>
>>  If I understand unified sources build correctly, it uses a large list
>>  of files and then arranges them into groups, 8 files at a time. If I
>>  have a slightly different set of files than is standard, or if
>>  someone adds a new source file, the combinations of files can change.
>
> Well, of course the combination of files can change if someone adds a
> new file. But the cross-platform files that get combined together
> should always be the same for all ports, because the bundles defined in
> Sources.txt are deterministic. Only files from the same directory get
> bundled together (they're separated by a blank line in Sources.txt) and
> if multiple bundles are used for the same directory, they should always
> be the same on all ports.
>
> (Of course, you can also have port-specific Sources.txt files.)
>
>>  Do non-windows ports use a more intelligent method (a pointer, not a
>>  file copy) for creating forwarding headers for JavaScriptCore
>>  includes?
>
> Yes, non-Windows ports #include the original file instead of copying
> the original. E.g. in
> DerivedSources/ForwardingHeaders/JavaScriptCore/ArrayBufferSharingMode.h,
> I have the following one-liner:
>
> #include "JavaScriptCore/runtime/ArrayBufferSharingMode.h"
>
> I'm not sure why Windows is different! See the
> WEBKIT_CREATE_FORWARDING_HEADERS macro in
> Source/cmake/WebKitMacros.cmake.

AFAIK Windows uses different approach because AppleWin needs to support
separate building of WTF, WebCore, and WebKit.

FWIW Qt port uses same handling of forwarding headers on all platforms.

>
>>  Is the windows build the only one to use unified sources currently?
>
> No, all ports are using it.
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] where should tests reside? tests/preload v. tests/loading

[Konstantin Tokarev]

08.11.2017, 17:54, "Colin Bendell | +1.613.914.3387" :
> I'm chasing down racy logging with one of my tests and I've noticed
> some duplication for preloader tests. Specifically:
> 1) when should you organize preload tests in
> LayoutTests/http/tests/preload v.
> LayoutTests/http/tests/loading/preload*? I'm assuming that the real
> reason is the debug level?
>
> 2) how is the debug level enabled for http/tests/loading? Is there a
> way to control this threshold programatically in the test?
>
> (an example debug line in question:"main frame -
> didStartProvisionalLoadForFrame")

This is printed by InjectedBundle used in testing
(see Tools/WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp)

>
> thanks,
> /colin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Konstantin Tokarev]

23.10.2017, 19:11, "Frédéric WANG" :
> On 23/10/2017 18:04, Konstantin Tokarev wrote:
>>  There is a big difference between SVG and MathML: the first one is entirely 
>> self-
>>  contained, while (AFAIU) MathML requires presence of math fonts on the 
>> target
>>  system for correct rendering (i.e. native MathML will look much worse than 
>> image
>>  fallback that is usually available).
>>
>>  Imagine embedded system (e.g. of set-top box kind) which has no math fonts 
>> on
>>  the board. Will always-on MathML be progression or regression there?
>
> SVG also requires fonts for the  tag.

Yes, but only general-purpose fonts, not math-specific.
Also, if text is rendered with a different font face (because system lacks 
requested font)
it's remains readable.

> And Web fonts exist to work around the lack of system fonts.

Yes, but what if web developer is not careful enough and assumes that if mathml 
is present,
then math font is available?

> As a Web Platform developer, I believe browser sniffing is bad practice, so I 
> hope people
> use other techniques to provide alternate content.

What do you mean under "browser sniffing"? UA string sniffing is a shame, 
certainly.
But feature testing (e.g. by checking size of ) is a valid appoach.

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

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

[Konstantin Tokarev]

23.10.2017, 18:43, "Frédéric WANG" :
> Hi,
>
> 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.
>
> I'm wondering if other people use the --no-mathml build option and
> believe they really need it? If not, I'm propose to remove this
> compile-time flag.
>
> As a comparison, the flag for SVG was removed in
> https://bugs.webkit.org/show_bug.cgi?id=127991 ; Mozilla also removed
> compile time option for MathML and SVG a long time ago (
> https://hg.mozilla.org/mozilla-central/rev/b8664f450508 for the former).

There is a big difference between SVG and MathML: the first one is entirely 
self-
contained, while (AFAIU) MathML requires presence of math fonts on the target
system for correct rendering (i.e. native MathML will look much worse than image
fallback that is usually available).

Imagine embedded system (e.g. of set-top box kind) which has no math fonts on
the board. Will always-on MathML be progression or regression there?

>
> --
> Frédéric Wang - frederic-wang.fr
>
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] RFC: Removing feature flag defaults in build-webkit

[Konstantin Tokarev]

21.09.2017, 22:01, "Tim Horton" :
>>  On Sep 21, 2017, at 11:57, Konstantin Tokarev  wrote:
>>
>>  21.09.2017, 21:54, "Tim Horton" :
>>>  Hi, all!
>>>
>>>  Would anybody mind if build-webkit stopped being a source of default 
>>> values of feature flags?
>>>
>>>  We have defaults for feature flags in FeatureDefines.xcconfig for Xcode, 
>>> WebKitFeatures.cmake (and Options*.cmake for platform overrides) for CMake, 
>>> and FeatureDefines.h for everyone. This is already a mess. But it gets 
>>> worse!
>>>
>>>  Right now, for both the Xcode and CMake builds, build-webkit overrides 
>>> those with its own set of defaults (in FeatureList.pm). There is also 
>>> currently an argument to fall back to the CMake defaults 
>>> (--default-cmake-features) and ignore build-webkit’s defaults.
>>>
>>>  It doesn’t make sense that build-webkit enables a different set of 
>>> features than a plain ol’ ‘xcodebuild’ or ‘cmake’ in the root directory. It 
>>> seems like we’ve mostly tried to keep them in sync, but that’s silly 
>>> busywork for seemingly little benefit.
>>>
>>>  If we do this, the effective changes would be as follows:
>>>
>>>>  1) The default values of feature flags would be specified in all of the 
>>>> usual places except FeatureList.pm
>>>>  2) build-webkit --help will no longer list the default value of feature 
>>>> flags
>>>>  3) It will be easier (but still not easy, yet) to reason about the 
>>>> default value of feature flags, and keep them in sync between different 
>>>> ways people build
>>>>  4) --default-cmake-features will go away, because it will always be true
>>>
>>>  And things that wouldn’t change:
>>>
>>>>  1) You will still be able to use --FEATURE, --no-FEATURE, and --minimal 
>>>> arguments to build-webkit
>>>
>>>  Any objections or things I’ve overlooked?
>>
>>  I think it would be more useful to have a single file (e.g. JSON) with 
>> options and their default values, and generate all other lists from it.
>
> I agree, but it is a much, much bigger project to get us to 1 list than to 
> reduce us by 1 list.

In the past at least Qt port was generating its feature list from 
FeatureList.pm with a really simple script

https://trac.webkit.org/browser/webkit/trunk/Tools/qmake/dump-features.pl?rev=156692

>
>>>  —Tim
>>>  ,
>>>
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>  --
>>  Regards,
>>  Konstantin

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

Re: [webkit-dev] RFC: Removing feature flag defaults in build-webkit

[Konstantin Tokarev]

21.09.2017, 21:54, "Tim Horton" :
> Hi, all!
>
> Would anybody mind if build-webkit stopped being a source of default values 
> of feature flags?
>
> We have defaults for feature flags in FeatureDefines.xcconfig for Xcode, 
> WebKitFeatures.cmake (and Options*.cmake for platform overrides) for CMake, 
> and FeatureDefines.h for everyone. This is already a mess. But it gets worse!
>
> Right now, for both the Xcode and CMake builds, build-webkit overrides those 
> with its own set of defaults (in FeatureList.pm). There is also currently an 
> argument to fall back to the CMake defaults (--default-cmake-features) and 
> ignore build-webkit’s defaults.
>
> It doesn’t make sense that build-webkit enables a different set of features 
> than a plain ol’ ‘xcodebuild’ or ‘cmake’ in the root directory. It seems like 
> we’ve mostly tried to keep them in sync, but that’s silly busywork for 
> seemingly little benefit.
>
> If we do this, the effective changes would be as follows:
>
>> 1) The default values of feature flags would be specified in all of the 
>> usual places except FeatureList.pm
>> 2) build-webkit --help will no longer list the default value of feature flags
>> 3) It will be easier (but still not easy, yet) to reason about the default 
>> value of feature flags, and keep them in sync between different ways people 
>> build
>> 4) --default-cmake-features will go away, because it will always be true
>
> And things that wouldn’t change:
>
>> 1) You will still be able to use --FEATURE, --no-FEATURE, and --minimal 
>> arguments to build-webkit
>
> Any objections or things I’ve overlooked?

I think it would be more useful to have a single file (e.g. JSON) with options 
and their default values, and  generate all other lists from it.

>
> —Tim
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Generation of documentation describing HTML5 support

[Konstantin Tokarev]

07.09.2017, 13:03, "Romain Bellessort" :
> Hi all,
>
> Safari has some documentation describing support for HTML/CSS/JS (see e.g. 
> [1]). Creating and maintaining such documentation likely requires a 
> significant amount of work.
>
> I don't know to what extent Apple folks may be able to share information 
> about this, but how much of this process is automated? (e.g. are there tools 
> that analyze parts of WebKit code to detect supported tags / attributes / 
> etc.?)
> More generally, has some work been done in this field? (for WebKitGTK for 
> instance)

https://webkit.org/status/ is automatically generated from features.json files. 
It has references to respective W3C standards/drafts.

>
> Thanks,
> Romain.
>
> [1] 
> https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Introduction.html
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

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

[Konstantin Tokarev]

30.08.2017, 21:05, "Alex Christensen" :
>>  On Aug 29, 2017, at 5:54 PM, Sam Weinig  wrote:
>>  In a completely other direction, what does this mean for use of Xcode? Can 
>> we still build from Xcode? Debug?
>
> CMake can generate Xcode files, so you can still develop and debug in Xcode.

This annihilates speed up possibility, as xcodebuild will be used instead of 
ninja

>
>>  On Aug 29, 2017, at 5:37 PM, Carlos Alberto Lopez Perez  
>> wrote:
>>  Does this means that Apple ports are going to switch to CMake?
>
> We have not decided anything officially yet, and if we were to decide to do 
> this then it would take quite a while to make the official switch.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Konstantin Tokarev]

30.08.2017, 03:01, "Michael Catanzaro" :
> On Tue, Aug 29, 2017 at 6:20 PM, Alicia Boya García 
> wrote:
>>  As long as the sets are generated consistently that approach should be
>>  equally fine and indeed it would reduce the burden for contributors.
>>  You
>>  may need at least a file to write exceptions (files not to be included
>>  in any bundle) though.
>>
>>  -- Alicia.
>
> I agree, with the style checker to check for naming conflicts within
> the same directory, and with some help from EWS, automatic generation
> of bundles should work out fine.

Note that EWS and webkit-patch run check-webkit-style over *diff* only,
so it won't be possible to detect such naming conflcts outside of patch
boundaries with check-webkit-style

>
> I'm glad we've discarded the original namespace proposal.
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Konstantin Tokarev]

29.08.2017, 14:44, "Alicia Boya García" :
> On 08/29/2017 06:20 AM, Daniel Bates wrote:
>
>>  Do we know what is the cause(es) for the slow clean builds? I am assuming 
>> that much of the speed up from the "unified source" comes from clang being 
>> able to use an in-memory #include cache to avoid disk I/O and re-parsing of 
>> a seen header. Have we exhausted all efforts (or have we given up?) removing 
>> extraneous #includes? Do we think this pursuing this effort would be more 
>> time consuming or have results that pale in comparison to the "unified 
>> source" approach?
>
> Whilst having an in-process-memory #include cache is not a bad thing,
> it's not the greatest gain as the operating systems should already cache
> file reads just fine.

From my experience, Windows OS is particularly bad at this, even when given
quite enough memory for caching.

>
> The greatest gain comes from reducing the amount of times C++ headers
> are parsed. If you are building a certain .cpp file and include a .h
> file, the compiler has to parse it, which can take quite a bit because
> C++ is really complex monster, especially when templates are used. Doing
> this more than necessary raises build times really quickly.
>
> Header files almost always are include-guarded (either with #pragma once
> or traditional #ifndef guards), so including the same header twice
> within the same .cpp file (or any of its included files) has no cost. On
> the other hand, if you then start building a different .cpp file that
> also includes the same header, you have to parse it again because so far
> C++ is concerned, every inclusion could add different symbols to the AST
> the compiler is building, so their output can't be reused*. In turn we
> end up parsing most headers many more times than actually needed (i.e.
> for every .cpp file that includes Node.h the compiler has to parse
> Node.h and all its dependencies from source, that's a lot of wasted
> effort!).
>
> *Note that including twice the same .h within the same .cpp file is not
> fast because the output is cached in anyway, but because the entire .h
> file is skipped, adding no additional nodes to the AST.
>
> The goal of C++ modules is to fix this problem from its root cause:
> instead of literally including text header files, .cpp files declare
> dependencies on module files that can be compiled, stored, loaded and
> referenced from .cpp files in any order, so you would only parse the
> Node module source code once for the entire project, whilst the compiler
> could load directly the AST every other time from a cached module object
> file.
>
> Note the great advantage of modules comes from the fact that they can be
> imported in different contexts and their content is still semantically
> equivalent, whereas with plain C/C++ includes every header file may act
> differently depending on the preprocessor variables defined by the
> includer and other previous inclusions. In the worst case, when they are
> not include-guarded (luckily this is not too common, but it still
> happens), even including the same file in the same .cpp twice could add
> different symbols each time!
>
> Unfortunately C++ modules are a work in progress... There are two
> different competing proposals with implementations, one from Clang and
> another one from Microsoft, and the C++ technical specification is in a
> very early stage too:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4681.pdf
>
> We know for sure modules are very important for the future of C++, but
> maybe it's still a bit too early to bet a big project like WebKit on them.
>
> So how else can we avoid parsing the same header files so many times and
> speed up our builds? Enter unified builds.
>
> A requirement for unified builds to work correctly is that header files
> are coded in such a way they work as independent units, much like C++
> modules, i.e. including headers should work no matter in what order you
> place them, and in each case they must define the same symbols. On July
> 31 I wrote about some issues we currently have because of not doing
> exactly this in WebKit (particularly, our #include "config.h" lines are
> ambiguous). They can be worked around so they will not become blockers
> for unified builds, but I still think we should fix them at some point.
>
> Once you have a set of .cpp files whose includes all (1) are guarded
> (e.g. by #pragma once) and (2) are independent units according to the
> above rule, you can take advantage of unified builds:
>
> Instead of invoking once the compiler for each .cpp file, you create a
> new artificial "unified" or "bundle" .cpp file that concatenates (or
> #include's) a number of different .cpp files. This way, headers included
> within the bundle are parsed only once, even if they are used by
> different individual .cpp files, as long as they are within the same
> bundle. This can often result in a massive build speed gain.
>
> Unfortunately, there are some pitfalls, as the

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

[Konstantin Tokarev]

29.08.2017, 23:54, "Alicia Boya García" :
> I'm all for stable bundle .cpp files. Automatic generation can be nice
> for the first time... and once in while we can try to modify the bundles
> to try to make the build even faster, but really most of the time bundle
> contents should not change unless new files are added and everybody
> should get the same bundles.
>
> If we're going to end up with some name collisions, we'd rather do so
> that every build of the same source tree gets collisions or no build
> gets them.
>
> The description of these .cpp bundles should become a project artifact,
> shared and versioned in the repository and treated carefully as such.

This is already the case for *AllInOne.cpp files of WebCore, which are enabled
by -DENABLE_ALLINONE_BUILD=ON option (--allinone-build in build-webkit).

>
> Also, in my earlier message about unified builds I explained how the
> distribution of the files within the bundles also affects the number of
> bundles that are rebuilt in response to changes in the source code. I
> also proposed that grouping together files implementing the same
> features could be a good start point to minimize the impact of this issue.
>
> On other note, I don't think namespacing static functions and variables
> as originally proposed is the way to go.
>
> The refactor would be ridiculously huge. Running `rg -w '^static' -tcpp
> --no-filename --no-heading |wc -l` in my local repository yields 16797
> instances of static functions and variables, only taking into account
> those where the word static is at the beginning of the line without any
> spaces before, which is a common case but not a requirement in C++. Note
> though that this regex excludes static class members as long as code is
> properly formatted (they would be indented); these are not included as
> they would not need any changes.
>
> static functions and variables in WebKit are used for hidden
> implementation details, which tend to very very specific and therefore
> receive long specific names with relatively little risk of collisions.
>
> Furthermore, collisions won't go unnoticed as in every case they will
> trigger a compilation error of the likes of 'redefinition of ‘int a’'.
> In this case the compiler will also show the inclusion stack mentioning
> the bundle file and the conflicting definition. The programmer will
> notice that both are static members in .cpp files, so the only way that
> error can arise is because they had a name collision due to unified
> source builds.
>
> We'd probably be better off handling the few collisions on a one by one
> basis, renaming the symbols or excluding the worst offenders from
> unified builds rather than plain out forbidding static declarations.
>
> -- Alicia
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Konstantin Tokarev]

29.08.2017, 22:48, "Geoffrey Garen" :
>>> We have some preliminary data that says incremental builds will be OK, but 
>>> not a full benchmark.
>>>
>>> Here’s a full benchmark I propose to test incremental builds:
>>>
>>> Start 7 days ago in SVN history. Do a clean build.
>>>
>>> SVN update forward by 24 hours. Do an incremental build. Time this build.
>>>
>>> Repeat 7 times. Average the results.
>>
>> How did you arrive at a day’s worth of changes being representative of a 
>> WebKit contributor’s incremental build?
>
> I asked some people how often they svn up and they said every day.

Pulling changes from whole day often means (almost) full rebuild

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


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

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

[Konstantin Tokarev]

  29.08.2017, 21:32, "Maciej Stachowiak" :  On Aug 29, 2017, at 9:10 AM, Chris Dumez  wrote: I worry about adopting unity build because while it makes clean builds faster, it also slows down incremental builds. As a developer, I rarely do clean builds, I mostly do incremental builds so this would likely make my experience worse?Unity builds also require a lot of code churn to resolve naming conflicts and the resulting code does not look as nice. Given the stats presented, if you're rebuilding at least two files in the same slice, you get a speedup.But these 2 modified files are likely to be compiled in parallel For rebuilding only exactly a single file, you get a small slowdown. Your worst case is rebuilding many files but all from a separate slice. Not sure how likely this is. For Apple folks, the penalty would be more than reversed by switching to CMake+Ninja as the main building system for engineering builds (which I think is the plan?)  - Maciej  Finally, the statement that the slow down of incremental build is acceptable because we spend most of our time resolving dependencies seems to assume we keep using make. Using Ninja would speed up incremental builds a lot by notre-resolving dependencies so much. -- Chris Dumez  On Aug 29, 2017, at 9:05 AM, Darin Adler  wrote: On Aug 28, 2017, at 8:34 PM, Ryosuke Niwa  wrote: Wherever possible, we are going to want to convert file-static functionsinto private C++ class member functions.I don't think we should make this change. It would mean that wheneverthe function signature changes, we'd have to modify the header file,which in turn triggers rebuild of every cpp file which includes thatheader file. That was my first thought as well. In fact, I typically ask people to do the opposite: Whenever a function does not require access to private members, convert from a member function that has to be in the header file to a function that is private to the source file. More recently I have started doing something different for the many functions that only have to be used on one place; I use lambdas to create nested functions. This has a couple nice properties: The lambda shares access to private members and anything else that the surrounding function has access to. We have the option of capturing rather than passing arguments, which can be clearer in some cases. It’s not quite as good as a separate function for visual separation; the lambda is often mashed together with the rest of the surrounding function.— Darin___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev,___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev  -- Regards,Konstantin ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Konstantin Tokarev]

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

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

>
> From: webkit-dev 
> [mailto:webkit-dev-bounces+don.olmstead=am.sony@lists.webkit.org] On 
> Behalf Of Keith Miller
> Sent: Monday, August 28, 2017 5:37 PM
> To: WebKit Development Mailing List 
> Subject: [webkit-dev] Growing tired of long build times? Check out this 
> awesome new way to speed up your build... soon (HINT: It's not buying a new 
> computer)
>
> Hello fellow Webkittens,
>
> Are you growing tired of long cat naps while waiting 45 minutes for WebKit to 
> build? (I’ve definitely never done this 🤐!)
>
> Do you want WebKit to build up to 3-4x faster on a clean build?*
>
> Does seeing your incremental build… stay the same sound good?
>
> You’ll be purring with excitement after you switch to unified source builds!**
>
> * Building JSC with CMake, including CMake configuration time, went from 
> ~8m15s to ~2m30s on my MBP using unified sources only on cpp files in 
> JavaScriptCore. Final results on WebKit may vary. Using unified sources may 
> cause sudden feelings of euphoria and productivity (or grumpiness from lack 
> of naps…). Not responsible for any bugs in extra patches produced by using 
> unified source builds (excluding build system related bugs) except where 
> required by law (pi...@apple.com).
>
> ** Soon. Unified source builds haven’t been landed yet.
>
> How are things going to change? Great question! Let’s find out!
>
> When you fire off the build script it will automagically paw your source 
> files into bundles. The size of each bundle is speculatively going to be 8 
> .cpp files but that’s up for experimentation. From my testing so far, the 
> compile time for a bundle is at most 20% (~6s vs ~7s for the Air directory) 
> longer than the longest file it includes. Given that most of the build time 
> in incremental builds is scanning dependencies, this change is probably only 
> barely noticeable.
>
> Bundling happens as part of the CMake configuration process, in the CMake 
> build. In the Xcode build it’s more complicated since we cannot dynamically 
> choose the files we are going to compile. The only solution I know of is to 
> pre-list a bunch of files for the build to dump files into. Occasionally, 
> we’ll need to add more files to the build list.
>
> When you add or remove a file in the project, the cost is higher. The current 
> plan to bundle source files is by directory. This means that when a .cpp file 
> is added or removed you will rebalance the bundles in its directory, and you 
> will have to rebuild up to the full directory that file is in.
>
> My goal is to make all of this invisible to developers as much as possible. I 
> believe, for the most part, things should operate mostly as they have before. 
> As the details on unified source builds get finalized, I’m sending out a 
> separate email documenting any workflow changes. I’ll also do my best to 
> answer any questions or concerns.
>
> “But Keith, am I going to have to make major changes to the way I develop 
> WebKit?” Yes and, hopefully, no. There is one major common workflow change 
> that comes with unified sources, the naming of static variables and 
> functions. Since C++ does not have a way to only declare a static function or 
> variable in some restricted top level scope we are going to need to create 
> some work around. The choice I’m thinking we’ll go with is to have an 
> auto-generated macro value FILENAME, which is similar to __FILE__ except that 
> it doesn’t have file extension (We can’t use FILE since that’s actually a 
> type in C 🙁). This macro would be redefined in the unified source directly 
> above the file that is about to be included. Then in each cpp file that has 
> static functions/variables developers would have:
>
> namespace FILENAME {
>
>     static int myVariable { 0 };
>
>     static int myFunction() { return myVariable; }
>
> }
>
> The advantage of using a macro over textually writing the filename is that it 
> makes code more portable between files. Also, once people get used to the 
> concept of FILENAME in the code base it will, hopefully become obvious what 
> it means. The main downside to this is using FILENAME in a header would give 
> you whatever cpp file first included you (if only we got the compiler magic 
> of __FILE__...). We would probably need to prohibit using FILENAME in .h 
> files. Unfortunately, you cannot "using FILENAME;” because it will export all 
> the values in each subsequent namespace. e.g.
>
> namespace JSC {
>
>     namespace Foo {
>
>     static int myVar { 0 };
>
>     }
>
>     using Foo;
>
> }
>
> namespace JSC {
>
>     namespace Bar {
>
>    

Re: [webkit-dev] How we enable template functions

[Konstantin Tokarev]

23.08.2017, 21:15, "Keith Miller" :
> You can totally have the enable_if in the template list:
>
> #define ENABLE_TEMPLATE_IF(condition) typename = typename 
> std::enable_if::type
>
> template::value))>
> int foo() { return 0; }
>
> template::value))>
> double foo() { return 0; }
>
> int myFunction()
> {
> return foo();
> }
>
> Compiles fine for me.
>
> There is another downside to the macros though. Since they will probably have 
> a comma in them C++ thinks that comma is meant to distinguish arguments to 
> the macro... The only work around I know of is to wrap the argument in parens 
> as I did above.

Actually, you need no parens:

 #define ENABLE_TEMPLATE_IF(...) typename = typename 
std::enable_if<__VA_ARGS__>::type

 template::value)>
 int foo() { return 0; }

 template::value)>
 double foo() { return 0; }

 int myFunction()
 {
 return foo();
 }


>
> I think mark’s case doesn’t work with my proposal so that’s convinced me that 
> the template argument is the way to go. Although, I still think we should use 
> the macro.
>
> Any objections?
>
> Cheers,
> Keith
>
>>  On Aug 23, 2017, at 7:28 AM, Mark Lam  wrote:
>>
>>  One application of enable_if I’ve needed in the past is where I want 
>> specialization of a template function with the same argument signatures, but 
>> returning a different type. The only way I know to make that happen is to 
>> use enable_if in the return type, e.g.
>>
>>  std::enable_if, T>::type doStuff() { }
>>  std::enable_if, T>::type doStuff() { }
>>
>>  This works around the problem of “duplicate function definitions” which 
>> arises if the enable_if is not in the function signature itself. So, I’m not 
>> sure your ENABLE_TEMPLATE_IF macro will give me a solution for this.
>>
>>  Mark
>>
>>>  On Aug 22, 2017, at 11:14 PM, Keith Miller  wrote:
>>>
  On Aug 22, 2017, at 9:17 PM, JF Bastien  wrote:

  I'd suggest considering what it'll look like when we're migrating to 
 concepts in C++20.

  Here's an example for our bitwise_cast:
  https://github.com/jfbastien/bit_cast/blob/master/bit_cast.h#L10

  Notice the 3 ways to enable. There's also the option of using enable_if 
 on the return value, or as a defaulted function parameter, but I'm not a 
 huge fan of either.
>>>
>>>  I think the concepts approach is the cleanest. I’d avoid the macro if we 
>>> go that way.
>>>
>>>  But C++20 is a long way away and I only expect this problem to get worse 
>>> over time. So I’d rather find a nearer term solution.
>>>
  On Aug 22, 2017, at 9:13 PM, Chris Dumez  wrote:

  I personally prefer std::enable_if<>. For e.g.

  template>>> int>::value>
  Class Foo { }
>>>
>>>  I just find this much harder to parse since I now have to:
>>>
>>>  1) recognize that the last class is not a actually polymorphic parameter
>>>  2) figure out exactly what the condition is given that it’s hidden inside 
>>> an enable_if*
>>>
>>>  The plus side of using a static_assert based approach is that it doesn’t 
>>> impact the readability of function/class signature at a high level since 
>>> it’s nested inside the body. It’s also not hidden particularly hidden since 
>>> I would expect it to be the first line of the body
>>>
>>>  Another downside of enable_if as a default template parameter is that 
>>> someone could make a mistake and pass an extra template value, e.g. 
>>> Foo, and it might pick the wrong template parameter. This isn’t 
>>> super likely but it’s still a hazard.
>>>
>>>  Admittedly, we could make a macro like (totes not stolen from JF’s GitHub):
>>>
>>>  #define ENABLE_TEMPLATE_IF(condition) typename = typename 
>>> std::enable_if::type
>>>
>>>  and implement Foo as:
>>>
>>>  template::value)>
>>>  class Foo { };
>>>
>>>  I think this approach is pretty good, although, I think I care about the 
>>> enable_if condition rarely enough that I’d rather not see it in the 
>>> signature. Most of the time the code will look like:
>>>
>>>  template::value)>
>>>  class Foo {...};
>>>
>>>  template::value)>
>>>  class Foo {...};
>>>
>>>  template::value)>
>>>  class Foo {...};
>>>
>>>  So when I know I want to use a Foo but I forgot the signature I now need 
>>> to look mentally skip the enable_if macro, which I’d rather avoid.
>>>
  I don’t like that something inside the body of a class / function would 
 cause a template to be enabled or not.
>>>
>>>  I believe there are cases where this already basically already happens 
>>> e.g. bitwise_cast. Although, I think those cases could be fixed with a more 
>>> standard approach.
>>>
>>>  Cheers,
>>>  Keith
>>>
  --
   Chris Dumez

>  On Aug 22, 2017, at 8:34 PM, Keith Miller  wrote:
>
>  Hello fellow WebKittens,
>
>  I’ve noticed over time that we don’t have standard way that we enable 
> versions of template functions/classes (flasses?). For the most part it 
> seems that people use std::enable_if, although, it seems like it 

Re: [webkit-dev] "webkit-patch upload --no-review" submits to EWS by default

[Konstantin Tokarev]

15.08.2017, 00:16, "Daniel Bates" :
> Hi all,
>
> Just a heads up. Following r220715, "webkit-patch upload --no-review" and 
> "webkit-patch post-commits --no-review" now submits a patch(es) for EWS 
> analysis by default. You no longer need to open the Bugzilla bug and click 
> the Submit for EWS button to do this on your --no-review patch(es). Pass 
> --no-ews if you want to opt into the old behavior of posting a patch(es) 
> without review and without submitting them to EWS.

Nice, thanks!

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


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

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

[Konstantin Tokarev]

07.08.2017, 23:15, "Michael Catanzaro" :
> On Tue, Aug 1, 2017 at 8:57 AM, Dean Jackson  wrote:
>>  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.
>>
>>  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
>>
>>  Dean
>
> I think nobody is using ENABLE_GAMEPAD_DEPRECATED, right? Can we remove
> that (and all the code)?

I thought there was no implementation on non-deprecated Gamepad for Linux

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

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

Re: [webkit-dev] Python

[Konstantin Tokarev]

07.08.2017, 16:47, "Michael Catanzaro" :
> Hi,
>
> As you're probably already aware, in Arch Linux /usr/bin/python has
> been a symlink to /usr/bin/python3 for a long time now. In practice
> this means that Arch users are not going to be able to use basically
> any of our Python scripts, since our scripts use the shebang
> #!/usr/bin/env python but expect it to be python2. This has not really
> been a problem until now because none of Igalia's developers use Arch,
> and occasional contributions rarely need to use the Python scripts. But
> our scripts have been broken this whole time, since the Python
> maintainers have decided the only reasonable way to avoid this problem
> is for scripts to explicitly specify either python2 or python3, and we
> have not been doing that. To be clear: the problem is that
> #!/usr/bin/env python is *python3* on some systems, but *python2* on
> others. WebKit scripts incorrectly assume it is always python2. I say
> "incorrectly" because the Python folks have ratified some bizarre
> standard for how to handle this, PEP 394 [1], which states: "in
> preparation for an eventual change in the default version of Python,
> Python 2 only scripts should either be updated to be source compatible
> with Python 3 or else to use python2 in the shebang line." Lovely.
>
> Now Fedora is planning to switch /usr/bin/python to link to
> /usr/bin/python3 instead of /usr/bin/python2 [2]. Not for another three
> years, but many of us (hi! :) use Fedora, so we're going to have to fix
> our scripts by then. This could be really easy, or it could be really
> hard.
>
> The really easy solution is to just replace #!/usr/bin/env python with
> #!/usr/bin/env python2 everywhere. This will work on all Linux distros
> newer than Red Hat Enterprise Linux 6 or thereabouts, which we
> definitely do not care about anymore. It doesn't work in very old
> distros because they did not provide /usr/bin/python2, only
> /usr/bin/python and very specific links like /usr/bin/python2.6. That
> doesn't matter because we don't care about those old systems anymore,
> but the problem is that last I checked, macOS did not provide a python2
> binary either. I am hoping that has changed in the past few years. Has
> it? If so, I can upload a patch to do this simple find/replace and we
> can all move on. If this is the case, yay! Stop reading now! Let me
> know. We should do that!
>
> But if not, we need to decide what to do among bad options:
>
>  * We could replace all our Python scripts that have shebangs with .in
> files, and perform configure replacements at CMake/XCode configure time
> to generate the scripts with the right python executable path. This
> would mean the scripts would be generated into the WebKit build
> directory instead of the source directory, so it will break those of us
> who have added Tools/Scripts to our PATH. It's not clear how they would
> find the right resource paths in the source directory, especially if
> using a build directory other than WebKit/WebKitBuild. I'm not even
> sure if XCode can do configure replacements. This would be a mess.
>  * We could require Mac developers to install a python2 symlink
> somewhere in PATH. Not really desirable, but possibly tolerable?
>  * We could port all our Python scripts to python3 and use
> #!/usr/bin/env python3, which will surely be unambiguous. But my
> understanding is that macOS does not have python3, so it will need to
> be installed locally. I guess that would be tolerable? Anyway, the main
> disadvantage here is we'd have to make all our scripts work with
> python3. If WebKit was a Linux-only project, we should definitely do
> that anyway, since major Linux distros no longer ship python2 by
> default: it's something we install extra now. But if macOS is sticking
> with python2, it would probably be undesirable to port our scripts to
> python3.
>  * We could make all our Python scripts compatible with both python2
> and python3, and maintain them this way forever. I really hope we can
> avoid this option, since we'd be breaking these scripts all the time as
> we would all surely not test one configuration or the other.

I think the latter option is quite feasible. The most widespread reason of
incompatibility with python3 is use of print operator instead of print()
function. I have a local patch that fixes these things, and it can be enforced 
by
style checker to keep new code compatible.

There are other issues, which are affecting just a few scripts (unfortunately 
they
are used in a build process). Those can be fixed once, and then we can rely on
python3 users to report incompatibilities. Anyway, these issues affect only code
that is already "legacy" in terms of python 2.7

>
> Any other ideas?
>
> Michael
>
> [1] https://www.python.org/dev/peps/pep-0394/
> [2] https://lwn.net/SubscriberLink/729366/1d3cd2dbaea7070b/
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webk

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Konstantin Tokarev]

04.08.2017, 21:20, "Carlos Alberto Lopez Perez" :
> On 02/08/17 12:14, Konstantin Tokarev wrote:
>>  FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt
>>  port and don't have any "terrible" development experience. Even when I
>>  need to make a change in file that is not port-specific, usually just
>>  one of AllInOne files needs to be recompiled
>
> Do you happen to have some numbers of how much less time it takes to
> build with this?

You can find old numbers here:

https://bugs.webkit.org/show_bug.cgi?id=102647#c11

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

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

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Konstantin Tokarev]

03.08.2017, 01:07, "Michael Catanzaro" :
> On Wed, Aug 2, 2017 at 11:14 AM, Konstantin Tokarev  wrote:
>> FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt port 
>> and don't have any "terrible" development experience. Even when I need to 
>> make a change in file that is not port-specific, usually just one of 
>> AllInOne files needs to be recompiled
>
> What... what does that mean? How is it all in one if there are multiple files?

There are large groups of files from WebCore which are compiled as one file for 
each group. Look for *AllInOne.cpp files in WebCore

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

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Konstantin Tokarev]

02.08.2017, 01:49, "Michael Catanzaro" :
> On Tue, Aug 1, 2017 at 11:33 PM, Keith Miller  wrote:
>> P.S. There is also a reasonable chance that we will do some form of unified 
>> sources (compiling multiple cpp files at the same time). In that case we 
>> don’t need to change our config.h rules.
>
> Do you have experience with unified source builds on macOS? We basically 
> never do these on Linux, but it's of course possible. These builds are 
> typically great for production but terrible for development, since everything 
> needs to be recompiled when any file is changed. Also, using static to mark 
> functions as file-private no longer works. This is sure to cause headache. 
> But the benefits may be worthwhile.

FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt port and 
don't have any "terrible" development experience. Even when I need to make a 
change in file that is not port-specific, usually just one of AllInOne files 
needs to be recompiled

Of course this may not be good for people actively developing Web-facing code

>
> Some good description:
>
> http://mesonbuild.com/Unity-builds.html
>
> Michael
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

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

[Konstantin Tokarev]

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

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

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

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

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

Re: [webkit-dev] OpenGl version to be used

[Konstantin Tokarev]

02.08.2017, 10:36, "gaurav.arad...@wipro.com" :
> Hi,
>
> We are trying to port Webkit on an embedded platform from version 74xxx to 
> 184849 (from Webkit turnk version in 2010 to  version in 2015). Currently we 
> have custom implementation of OpenGl 1.x running on the hardware. I have few 
> questions regarding the OpenGl version to use for our platform:
>
> * We want to continue using our custom OpenGl implementation 1.x for the 
> targeted WebKit revision 184849 (approximate). In the code I see conditional 
> compilation flag OPENGL_ES_2 (uses gl2.h) and in the else part we are using 
> gl.h (which seems to be OpenGl 1.x header). So can we continue using our 
> custom OpenGl 1.x implementation (fixed function pipeline)? Ofcourse there 
> could be few additional tweaks/functions / extensions to be supported by the 
> custom OpenGl implementation.

I think this question was answered multiple times on the list already.

> * What versions of OpenGl can HTML5 Canvas Implementation use? I suppose one 
> option is OpengGl 2.0 ES, what are the others? Also please specify if its ES 
> or desktop version.

Canvas (2D) is *raster* graphics API. It works as long as GraphicsContext 
methods are implemented, no matter how.

There is ENABLE(ACCELERATED_2D_CANVAS) flag, but AFAIU it's port-independent 
part still doesn't depend on how you implement it for your platform.

However, 3D canvas (WebGL) requires OpenGL ES 2

>
> Thanks a lot in advance!
>
> Best Regards
> Gaurav
>
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. WARNING: Computer viruses can be transmitted via 
> email. The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage caused 
> by any virus transmitted by this email. www.wipro.com
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

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

[Konstantin Tokarev]

02.08.2017, 01:12, "Maciej Stachowiak" :
>>  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 
>>>>> <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>>
>>>>   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.
>>>>
>>>>   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. 

That's not true for Windows, where each application is shipping its own 
libraries, and is also not true for macOS in case port other than Mac is used. 
And such "small" applications surely benefit from reduced size and reduced 
dependencies. 

>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.
>
> The port argument is potentially more compelling. It would carry more weight 
> if there are platforms that can't supply the required back end at all, or 
> where support is not expected any time soon. It's ok for new ports to be 
> initially incomplete, using stubs or extra ifdefs that we wouldn't want 
> upstream.
>
> Regards,
> Maciej
>
>>>  - Sam
>>>
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>  --
>>  Regards,
>>  Konstantin
>>  ___
>>  webkit-dev mailing list
>>  webkit-dev@lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Konstantin Tokarev]

01.08.2017, 16:58, "Dean Jackson" :
>>  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.
>
> Some others I see:
>
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE

IndexedDB makes no sense on devices without writable storage, so I think it 
would be better to keep this flag.

> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS
>
> Dean
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Konstantin Tokarev]

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

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

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

Re: [webkit-dev] WebKit opengl

[Konstantin Tokarev]

01.08.2017, 23:14, "Nagendra K" :
> Hi Dean,
>
> Thanks for the reply.
> I actually have a embedded device with opengl es 1.1 and WebKit which is 7 
> years old, now requirement is to update the WebKit using the same opengles1.1 
> i.e. no option to update opengles1.1.

I bet your old WebKit was built without use of any OpenGL-dependent code

> So as you said we need opengles2 or opengl4 to upgrade WebKit as WebKit has 
> dependencies with opengl for some features. Is this correct?
> Do I any other option to do this.
>
> Thanks and Regards,
> Nagendra
>
> On 1 Aug 2017 19:12, "Dean Jackson"  wrote:
>>> On 19 Jul 2017, at 12:21, Nagendra K  wrote:
>>>
>>> Current build of WebKit using opengl and with custom port, all apps will 
>>> directly use the opengl calls to draw, making the opengl independent of 
>>> WebKit.
>>> So if I upgrade the WebKit, will the latest WebKit require opengl for any 
>>> of the new features or can we use opengl delinking WebKit.
>>
>> I don't understand what you are asking, sorry.
>>
>> It's possible to make a port of WebKit that doesn't rely on OpenGL. I think 
>> the Windows port is one example. Technically Apple's iOS/macOS ports only 
>> directly require OpenGL for WebGL support.
>>
>> Dean
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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