Re: [webkit-dev] Request for position: relative indexing method on JS indexables

2020-11-30 Thread Kirsling, Ross via webkit-dev
Hey Shu,

This is already implemented behind the JSC runtime option `useAtMethod`.
(Latest relevant revision is r270005.)
Looking forward to seeing whether the new name is in fact web-compatible. 爛

Ross


From: Shu-yu Guo via webkit-dev 
Sent: Monday, November 30, 2020 5:04:02 PM
To: webkit-dev@lists.webkit.org 
Subject: [webkit-dev] Request for position: relative indexing method on JS 
indexables

Hi all,

This is a request for the WebKit position on the TC39 relative indexing method 
proposal, which has been at Stage 3 since September 2020. It was initially 
named `.item`, but due to web incompatibility with the YUI library and Flickr, 
it was renamed in November 2020 to `.at`, pending further web incompatibility 
data.

Chrome would like to ship ASAP to gather said incompatibility data.

- Proposal: https://github.com/tc39/proposal-relative-indexing-method
- Specification: https://tc39.es/proposal-relative-indexing-method/
- ChromeStatus: https://chromestatus.com/feature/6123640410079232

Cheers,
Shu-yu Guo, V8
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2020-07-16 Thread Kirsling, Ross
Non-unified build fixes are done to support *all* platforms, because sudden 
unification shifts can happen anywhere. We can't currently perform a full 
non-unified build on Mac since the CMake build only works up through JSC, so 
Sony and Igalia have been performing this maintenance by hand on Windows and 
Linux for years. It is for this reason that one is unlikely to encounter 
unification shift issues via EWS.

Tips for how to make better build fixes are helpful, but these build fixes 
can't go anywhere until we have a bot to identify missing includes and such as 
they arise.

Ross

From: Geoffrey Garen 
Sent: Thursday, July 16, 2020 8:54:00 AM
To: Yusuke Suzuki 
Cc: Fujii, Hironori (SIE) ; Darin Adler 
; WebKit Development Mailing List 
Subject: Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

The original question was, as I understood it, was do we need to support 
non-unified builds as an essential requirement for a given port, and if so, why?

I’d like to finish answering that question, before we wonder off-topic and 
consider whether supporting non-unified builds as an optional way to improve 
our workflow is a good idea.

Thanks,
Geoff

On Jul 15, 2020, at 4:20 PM, Yusuke Suzuki 
mailto:ysuz...@apple.com>> wrote:

And I agree, keeping non-unified build sane is quite useful.
In addition to the benefit described by Alex, this also allows CMake to 
generate sane compile_commands.json, so that my completion in Neovim works 
better in cpp files,
and I think this compile_commands.json is also used in several clang-related 
toolings too.

I think we should have a bot maintaining it.

-Yusuke

On Jul 15, 2020, at 7:33 AM, Alex Christensen 
mailto:achristen...@apple.com>> wrote:

I think it is still quite useful to fix non-unified builds.  Otherwise adding a 
file usually involves many unrelated build fixes.

On Jul 14, 2020, at 5:25 PM, Fujii Hironori 
mailto:fujii.hiron...@gmail.com>> wrote:



On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig 
mailto:wei...@apple.com>> wrote:
While I don’t want to take away from what Darin is saying here about correct 
usage of forward declaration and , I’d like to understand why we 
have two different compilation models supported in WebKit. Is there a reason 
both need to be supported? Can we remove one?


I also want to know that. Does anyone still need non-unified builds?

I introduced other unnecessary header inclusion, and Darin asked me to fix it.
https://bugs.webkit.org/show_bug.cgi?id=214204#c25
Reducing header inclusion can easily cause build breakages for non-unified 
builds.
So, I fixed non-unified build breakage in r264332 and r264333 as the 
preparation for that.
Non-unified builds was more broken than I expected. Does anyone still need it?
Should we maintain non-unified builds until C++20 modules will nullify unified 
builds?

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

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

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

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


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

2020-04-09 Thread Kirsling, Ross
No need for apology—I hugely appreciate the support on this, given the shrouded 
process of getting those ZIP files updated! :D

Ross

From:  on behalf of Brent Fulgham 
Date: Thursday, April 9, 2020 at 3:16 PM
To: Ryosuke Niwa 
Cc: "Kirsling, Ross" , "webkit-dev@lists.webkit.org" 

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

Please note that Per Arne updated the Apple ZIP files to have the correctly 
aligned ICU libraries, so the Windows bots should have what they need.

I apologize for taking so long to complete that.

Thanks,

-Brent


On Apr 3, 2020, at 4:57 PM, Ryosuke Niwa 
mailto:rn...@webkit.org>> wrote:


On Fri, Apr 3, 2020 at 4:25 PM Kirsling, Ross 
mailto:ross.kirsl...@sony.com>> wrote:
Hi everybody,

Just sending out an email blast for visibility regarding 
https://bugs.webkit.org/show_bug.cgi?id=209694.

This patch:

  *   Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
matching Mojave
  *   Introduces a minimum ICU version of 60.2 throughout the codebase, as 
required by GTK for Ubuntu 18.04 LTS

As written in the ChangeLog, the immediate motivations are:

  1.  To properly establish a minimum ICU version for WebKit as a whole
(responding to a pain point identified in 
https://bugs.webkit.org/show_bug.cgi?id=209579)
  2.  To support the development of ECMA-402 Intl API features, which JSC is 
quite behind on
(and which often boil down to exposing ICU functionality to JavaScript)

The only remaining concern of which I am aware is that AppleWin’s ICU headers, 
stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 49 to 62 (to 
match the lib files stored in WebKitSupportLibrary.zip). We do have a potential 
workaround for this (i.e. having CMake copy the Mac headers to 
WebKitLibraries/win) but it is feared that this may break Apple-internal builds 
and we would certainly like to avoid a revert if possible. Any help on this 
front would be greatly appreciated.

FWIW, I've been told that Brent / Per might be able to help you there but might 
need some more time due to other more urgent commitments.

- R. Niwa

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

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


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

2020-04-03 Thread Kirsling, Ross
Hi everybody,

Just sending out an email blast for visibility regarding 
https://bugs.webkit.org/show_bug.cgi?id=209694.

This patch:

  *   Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
matching Mojave
  *   Introduces a minimum ICU version of 60.2 throughout the codebase, as 
required by GTK for Ubuntu 18.04 LTS

As written in the ChangeLog, the immediate motivations are:

  1.  To properly establish a minimum ICU version for WebKit as a whole
(responding to a pain point identified in 
https://bugs.webkit.org/show_bug.cgi?id=209579)
  2.  To support the development of ECMA-402 Intl API features, which JSC is 
quite behind on
(and which often boil down to exposing ICU functionality to JavaScript)

The only remaining concern of which I am aware is that AppleWin’s ICU headers, 
stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 49 to 62 (to 
match the lib files stored in WebKitSupportLibrary.zip). We do have a potential 
workaround for this (i.e. having CMake copy the Mac headers to 
WebKitLibraries/win) but it is feared that this may break Apple-internal builds 
and we would certainly like to avoid a revert if possible. Any help on this 
front would be greatly appreciated.

Thanks,
Ross
___
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'?

2020-03-06 Thread 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.

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


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

2020-03-06 Thread Kirsling, Ross
Greetings WebKittens,

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

In terms of metaphors: The typical meaning of ‘roll out’ is synonymous with 
‘roll forward’, hence the opposite being ‘roll back’. The way that I came to 
explain to myself and others what WebKit means by ‘roll out’ is that it’s 
movement along the other axis. There is a tree (SVN trunk) which is built up 
from disc-shaped slices (revisions), and these slices are rolled sideways in 
and out of the tree. Needless to say, this is not obvious to a newcomer, and 
it’s not even accurate to how SVN works—rollouts don’t remove an old revision, 
they add a new revision to perform the revert!

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). Having heard complaints about this from people in both of these groups 
within the last few weeks, I hereby propose that we start using ‘roll back’ 
instead. Given the string similarity between the two, I hope that this will be 
a relatively easy change to enact, if folks are onboard with it.

Thanks for your consideration!

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


[webkit-dev] Question regarding per-file BSD license text

2017-08-22 Thread Kirsling, Ross
Hi all,

I have a simple question about the license text included in each source file.

My understanding is that if a non-Apple contributor adds a new file, their 
affiliation should only be reflected in the copyright line and NOT in the BSD 
license text itself (which reads "APPLE INC."), because the latter is a 
"per-file copy of a project-wide license". Could someone confirm whether or not 
this is correct?

I believe this is what's implied by "preferred license text" at 
https://webkit.org/contributing-code/#develop-your-changes, but it's not 100% 
spelled out.
I do see a handful of exceptions in the codebase, where "THE COPYRIGHT HOLDER" 
or "GOOGLE INC." or "UNIVERSITY OF SZEGED" is used instead, but the vast 
majority of files are in alignment.

(Incidentally, it looks like we also need to update the paragraph I linked to 
reflect the WebKitLegacy move.)

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