[webkit-dev] Peng Liu is now a WebKit reviewer!

[Daniel Bates via webkit-dev]

I am delighted to announce that Peng Liu is now a WebKit reviewer. Peng has 
done a lot of work in WebKit media. Most recently he has helped enable media 
features in the GPU process.

Please join me in congratulating Peng on his reviewer status!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Code Style: Opinion on returning void

[Daniel Bates]

I just had to change a void function to a non-void function in <
https://bugs.webkit.org/show_bug.cgi?id=195281>. I was very happy that all
of the existing code was written by people that did not return void because
I didn't have to change any call sites returning void into two lines. This
saved me time, kept the patch minimal, avoided dirtying line history, and
avoiding me having to do a double-take whenever I see a return void.

Is there a path forward for this issue? Should I put together an online
survey for people to vote? I don't want this issue to fall into a void ;)

Dan

On Feb 21, 2019, at 10:32 PM, Ryosuke Niwa  wrote:

On Thu, Feb 21, 2019 at 9:31 AM Darin Adler  wrote:

> I tried not to weigh in on this, but my view on the materials we should
> use to build the bike shed must be shared!
>
> Generally it seems neat to be able to make the code slightly more tight
> and terse by merging the function call and the return into a single
> statement.
>
> Other than not being accustomed to it, I have noticed three small things I
> don’t like about using “return” with a call to a void-returning function.
>
> - You can’t use this idiom when you want to ignore the result of a
> function, only if the function actually returns void. Often functions are
> designed with ignorable and often ignored return values. For example, it’s
> common to call something that might fail and have a good reason to ignore
> whether it failed or not. The idiom we are discussing requires treating
> those functions differently from ones that return void. If you refactor so
> that a function now returns an ignorable return value you need to visit all
> the call sites using return and change them into the two line form.
>

Perhaps this is the key distinction we want to make. Maybe if the *intent*
is to ignore the function's return value regardless of what it may return
in the future, then we should have a separate "return". If the *intent* is
to return whatever that other function returns, then we should return void.
But having to think about the intent of code isn't a great thing for coding
style guideline.

- It works for return, but not for break. I’ve seen at least one case where
> someone filled a switch statement with return statements instead of break
> statements so they could use this more-terse form. Now if we want to add
> one line of code after that switch, we need to convert all those cases into
> multi-line statements with break.
>

This is an orthogonal point but I do prefer switch'es that return directly
over one that break's then having a separate return after the switch
statement especially if the switch statement is long.

I've gotta say I'm fascinated to learn that many people are bothered by
returning void. I guess I was never bothered by it because I see a return
statement as a thing that returns the control back to the caller, not a
thing that returns a value.

- R. Niwa

___
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] Code Style: Opinion on returning void

[Daniel Bates]

Thanks for the opinion!

Dan

On Feb 20, 2019, at 7:26 AM, Saam Barati  wrote:

I prefer it as well.

- Saam

On Feb 20, 2019, at 6:58 AM, Chris Dumez  wrote:

I also prefer allowed returning void.

Chris Dumez

On Feb 19, 2019, at 10:35 PM, Daniel Bates  wrote:



On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa  wrote:

On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates  wrote:

> > On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
> >
> > Hi all,
> >
> > Something bothers me about code like:
> >
> > void f();
> > void g()
> > {
> > if (...)
> > return f();
> > return f();
> > }
> >
> > I prefer:
> >
> > void g()
> > {
> > if (...) {
> > f();
> > return
> > }
> > f();
> > }
> >
> Based on the responses it seems there is sufficient leaning to codify
> the latter style.
>

I don't think there is a sufficient consensus as far as I can tell. Geoff


I didn't get this from Geoff's remark. Geoff wrote:

***“return f()” when f returns void is a bit mind bending.***

Don't want to put words in Geoff's mouth. So, Geoff can you please
confirm: for the former style, for the latter style, no strong
opinion.


and Alex both expressed preferences for being able to return void,


I got this from Alex's message

and Saam pointed out that there is a lot of existing code which does this.


I did not get this. He wrote emphasis mine:

I've definitely done this in JSC. ***I don't think it's super
common***, but I've also seen code in JSC not written by me that also
does this.


Zalan also said he does this in his layout code.


I did not get this, quoting, emphasis mine:

I use this idiom too in the layout code. I guess I just prefer a more
compact code.
***(I don't feel too strongly about it though)***


By the way, you even acknowledged that "WebKit ... tend[s] to have a
separate return.". So, I inferred you were okay with it. But from this
email I am no longer sure what your position is. Please state it clearly.

- R. Niwa

___
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] Code Style: Opinion on returning void

[Daniel Bates]

Okay, you’ve changed your mind from your earlier email of not having a
strong opinion. Would have been good to know from the get-go. Better late
than never knowing :/

Dan

On Feb 20, 2019, at 6:58 AM, Chris Dumez  wrote:

I also prefer allowed returning void.

Chris Dumez

On Feb 19, 2019, at 10:35 PM, Daniel Bates  wrote:



On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa  wrote:

On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates  wrote:

> > On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
> >
> > Hi all,
> >
> > Something bothers me about code like:
> >
> > void f();
> > void g()
> > {
> > if (...)
> > return f();
> > return f();
> > }
> >
> > I prefer:
> >
> > void g()
> > {
> > if (...) {
> > f();
> > return
> > }
> > f();
> > }
> >
> Based on the responses it seems there is sufficient leaning to codify
> the latter style.
>

I don't think there is a sufficient consensus as far as I can tell. Geoff


I didn't get this from Geoff's remark. Geoff wrote:

***“return f()” when f returns void is a bit mind bending.***

Don't want to put words in Geoff's mouth. So, Geoff can you please
confirm: for the former style, for the latter style, no strong
opinion.


and Alex both expressed preferences for being able to return void,


I got this from Alex's message

and Saam pointed out that there is a lot of existing code which does this.


I did not get this. He wrote emphasis mine:

I've definitely done this in JSC. ***I don't think it's super
common***, but I've also seen code in JSC not written by me that also
does this.


Zalan also said he does this in his layout code.


I did not get this, quoting, emphasis mine:

I use this idiom too in the layout code. I guess I just prefer a more
compact code.
***(I don't feel too strongly about it though)***


By the way, you even acknowledged that "WebKit ... tend[s] to have a
separate return.". So, I inferred you were okay with it. But from this
email I am no longer sure what your position is. Please state it clearly.

- R. Niwa

___
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] Code Style: Opinion on returning void

[Daniel Bates]

On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa  wrote:

On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates  wrote:

> > On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
> >
> > Hi all,
> >
> > Something bothers me about code like:
> >
> > void f();
> > void g()
> > {
> > if (...)
> > return f();
> > return f();
> > }
> >
> > I prefer:
> >
> > void g()
> > {
> > if (...) {
> > f();
> > return
> > }
> > f();
> > }
> >
> Based on the responses it seems there is sufficient leaning to codify
> the latter style.
>

I don't think there is a sufficient consensus as far as I can tell. Geoff


I didn't get this from Geoff's remark. Geoff wrote:

***“return f()” when f returns void is a bit mind bending.***

Don't want to put words in Geoff's mouth. So, Geoff can you please
confirm: for the former style, for the latter style, no strong
opinion.


and Alex both expressed preferences for being able to return void,


I got this from Alex's message

and Saam pointed out that there is a lot of existing code which does this.


I did not get this. He wrote emphasis mine:

I've definitely done this in JSC. ***I don't think it's super
common***, but I've also seen code in JSC not written by me that also
does this.


Zalan also said he does this in his layout code.


I did not get this, quoting, emphasis mine:

I use this idiom too in the layout code. I guess I just prefer a more
compact code.
***(I don't feel too strongly about it though)***


By the way, you even acknowledged that "WebKit ... tend[s] to have a
separate return.". So, I inferred you were okay with it. But from this
email I am no longer sure what your position is. Please state it clearly.

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

Re: [webkit-dev] Code Style: Opinion on returning void

[Daniel Bates]

> On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
>
> Hi all,
>
> Something bothers me about code like:
>
> void f();
> void g()
> {
> if (...)
> return f();
> return f();
> }
>
> I prefer:
>
> void g()
> {
> if (...) {
> f();
> return
> }
> f();
> }
>
Based on the responses it seems there is sufficient leaning to codify
the latter style.

Patch posted <https://bugs.webkit.org/show_bug.cgi?id=194848> for
review of language and examples.

Summary of this thread is in that bug, too.

Dan


> Does it bother you? For the former? For the latter? Update our style guide?
>
> Opinions, please.
>
> Dan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Code Style: Opinion on returning void

[Daniel Bates]

Hi all,

Something bothers me about code like:

void f();
void g()
{
if (...)
return f();
return f();
}

I prefer:

void g()
{
if (...) {
f();
return
}
f();
}

Does it bother you? For the former? For the latter? Update our style guide?

Opinions, please.

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

[Daniel Bates]

> On Dec 14, 2018, at 3:52 PM, Chris Dumez  > wrote:
> 
> So to be clear, it is often not truly about using the value after it is 
> moved. It is about expecting that the variable / member has been nulled out 
> after moving it.
> If I WTFMove() out a data member m_dataMember, I expect later on `if 
> (m_dataMember)` to be false.
> 

I do not mean to derail the discussion about whether or not we should have our 
own std::optional that disengages on move. I am all for convenience. I think 
expecting a valid “empty” state (*) when moving out a data member is an 
anti-pattern and I propose that we should be using std::exchange() instead (or 
any code analogous to doing std::exchange()) for these cases, including the 
case in your original email and especially with data members as in 
>.

Why do I consider it an anti-pattern? See (*) and because the concept of 
“moving" is not spec'ed to behave like this. Here’s one reference to the 
spec’ed behavior and an example comparable to the one in your first email 
(highlighting is my own for emphasis):

[[
Unless otherwise specified, all standard library objects that have been moved 
from are placed in a valid but unspecified state. That is, only the functions 
without preconditions, such as the assignment operator, can be safely used on 
the object after it was moved from:
std::vector http://en.cppreference.com/w/cpp/string/basic_string>> v;
std::string  str = 
"example";
v.push_back(std::move(str)); // str is now valid but unspecified
str.back(); // undefined behavior if size() == 0: back() has a precondition 
!empty()
str.clear(); // OK, clear() has no preconditions

]]
>

(*) What is the valid “empty” state for a type without a default constructor?

Dan

> --
>  Chris Dumez
> 
> 
> 
> 
>> On Dec 14, 2018, at 3:45 PM, Chris Dumez > > wrote:
>> 
>> 
>>> On Dec 14, 2018, at 3:39 PM, Fujii Hironori >> > wrote:
>>> 
>>> 
>>> On Sat, Dec 15, 2018 at 6:38 AM Chris Dumez >> > wrote:
>>> 
>>> I have now been caught twice by std::optional’s move constructor. 
>>> 
>>>  I don't understand how this could be useful? Do you want to use the value 
>>> after it is moved? I'd like to see these your code. Could you show me these 
>>> two patches?
>> 
>> This is the latest one: https://trac.webkit.org/changeset/239228/webkit 
>> 
>> 
>> 
>> ___
>> 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] Copy WebKit Permalink for Sublime Text

[Daniel Bates]

Hi all,

If you use Sublime Text, now you can generate a trac.webkit.org hyperlink
to a selected code line using the Copy WebKit Permalink plugin (as of <
https://trac.webkit.org/changeset/235981/>). See <
https://trac.webkit.org/browser/webkit/trunk/Tools/CopyPermalink/Sublime%20Text/INSTALL>
for more details.

I tested the plugin on Mac with Sublime Text 3. The plugin should work on
Windows and Linux. Fixes and improvements are welcome :) Happy hacking.

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

Re: [webkit-dev] EWS for security bugs

[Daniel Bates]

Awesome! The Apple Windows EWS bots have also been configured to process
security bug patches. I am eagerly waiting for the GTK and WPE folks to
configure their bots :)

Dan

On Mon, Jul 9, 2018 at 1:10 PM,  wrote:

> WinCairo EWS is processing security bugs now so we’re good to go.
>
>
>
> *From:* webkit-dev  *On Behalf Of *Daniel
> Bates
> *Sent:* Thursday, June 28, 2018 1:53 PM
> *To:* WebKit Development Mailing List 
> *Subject:* [webkit-dev] EWS for security bugs
>
>
>
> Hi all,
>
>
>
> All Mac and iOS EWS bots now process security bug patches. We are working
> to configure the Apple Windows EWS bots and the WinCairo EWS bots should
> follow shortly. I do not know who maintains the GTK and WPE EWS bots. If
> you maintain one of these bots then please email me directly so that we can
> get you setup.
>
>
>
> For now, EWS processing of security patches is limited to the bubble
> status and the results posted to webkit-queues.webkit.org. That is, the
> EWS bots will not post comments to- or upload result archives to- security
> bugs. Also, we do not support using commit-queue for landing security
> patches at the moment.
>
>
>
> Help keep the tree green!
>
>
>
> Dan
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EWS for security bugs

[Daniel Bates]

Hi all,

All Mac and iOS EWS bots now process security bug patches. We are working
to configure the Apple Windows EWS bots and the WinCairo EWS bots should
follow shortly. I do not know who maintains the GTK and WPE EWS bots. If
you maintain one of these bots then please email me directly so that we can
get you setup.

For now, EWS processing of security patches is limited to the bubble status
and the results posted to webkit-queues.webkit.org. That is, the EWS bots
will not post comments to- or upload result archives to- security bugs.
Also, we do not support using commit-queue for landing security patches at
the moment.

Help keep the tree green!

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

[webkit-dev] Design for review: EWS for security bugs

[Daniel Bates]

Hi all,

I am working to support EWS processing of patches on security bugs (see <
https://bugs.webkit.org/show_bug.cgi?id=186291>) and I am writing to this
list to solicit feedback on any show-stopper bugs in the proposed design.
Historically we have not supported this functionality because the EWS was
designed to use Bugzilla as its data store and hence the EWS machines
(considered untrusted) would need a Bugzilla account with access to all
security bugs. Here is my idea to solve this problem without privileging
these machines with full security bug access:


   1. Have webkit-queues.webkit.org host copies of security sensitive
   patches. These patches will be deleted once all EWS queues have processed
   them. Access to these patches will be guarded by an API key(s) to prevent
   anonymous access. Each EWS machine will need one. Otherwise, it will skip
   such patches.
   2. The tool webkit-patch will now upload a copy of each patch attached
   to a security bug to webkit-queues.webkit.org as part of submitting a
   patch to EWS.
   3. Add a Bugzilla extension to CC the EWS feeder queue on a bug if it
   has a patch up for review, including security bugs. (The EWS feeder queue
   is responsible for polling Bugzilla to find unreviewed patches and
   submitting them to webkit-queues.webkit.org).
   4. The EWS feeder queue will now upload a copy of each patch attached to
   a security bug to webkit-queues.webkit.org as part of submitting a patch
   to EWS.


Then EWS machines will be able to process security sensitive patches,
report compile-time errors and the list of failing tests. There are three
known issues with this approach: 1) EWS bots cannot comment on security
bugs 2) EWS bots cannot upload layout test failure tarballs to security
bugs and 3) the "Submit for EWS analysis" button will not work. I plan to
solve these issues in subsequent bugs. One way to solve the first two
issues is to have webkit-queues.webkit.org store comments and tarballs and
teach the EWS feeder queue (or another bot) to submit these comments and
upload these tarballs to Bugzilla on behalf of the EWS bots (since the EWS
feeder queue has access to the security bug by design decision (3)). To
solve the last issue without requiring a person to re-enter their Bugzilla
credentials there are at least three approaches: 1) set an appropriate CORS
policy for webkit-queues.webkit.org to access Bugzilla 2)
webkit-queues.webkit.org asks Bugzilla to POST a form back to it or
3) re-implement and host the "Submit for EWS analysis" button on Bugzilla
so that it can upload the security sensitive patch to EWS when clicked then
redirect to the status-bubbles page on webkit-queues.webkit.org.

I am open to suggestions.

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

Re: [webkit-dev] Running Safari on the simulator

[Daniel Bates]

Please file a bug.

Dan

> On Sep 27, 2017, at 2:21 PM, Frédéric WANG  wrote:
> 
> On 27/09/2017 19:24, Alex Christensen wrote:
>> When I want to use the public iOS SDK for WebKit on iOS, I refer to
>> Dan’s blog post
>> at https://webkit.org/blog/3457/building-webkit-for-ios-simulator/
>> We have bots using this configuration and they’re working successfully
>> at https://build.webkit.org/waterfall?category=iOS
>> Maybe you forgot to run configure-xcode-for-ios-development
>> 
> I did run configure-xcode-for-ios-development indeed (otherwise the
> build fails IIRC).
> Also I forgot to say that I can use run-webkit-tests --ios-simulator
> (which I guess is what is used on bots). My problem is with run-safari
> --ios-simulator, which has stopped working recently.
> 
> Thanks,
> 
> -- 
> Frédéric Wang
> 
> 
> ___
> 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] Code style: Propose using C++11 uniform initializer syntax in member initializer lists

[Daniel Bates]

Posted patch to update Code Style Guidelines at <
https://bugs.webkit.org/show_bug.cgi?id=176058>.

Dan

On Mon, Aug 28, 2017 at 9:24 PM, Daniel Bates  wrote:

> Hi all,
>
> I am writing to propose using C++11 uniform initializer syntax in member
> initializer lists. The following:
>
> class A {
> public:
> A(B&& b, float i, int j)
> : m_b(WTFMove(b))
> , m_i(i)
> , m_j(j)
> {
> }
> ...
> };
>
> Would become:
>
> class A {
> public:
> A(B&& b, float i, int j)
> : m_b { WTFMove(b) }
> , m_i { i }
> , m_j { j }
> {
> }
> ...
> };
>
> Using uniform initializer syntax in member initializer lists would make
> the syntax we use for member initializer lists consistent with the syntax
> we use for non-static data member initializers. It would also cause a
> compile time error if member initialization required a narrowing conversion
> (e.g. implicit float to int conversion). Another benefit of using this
> syntax is that it allows initialization of a struct using aggregate
> initialization.
>
> Dan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Code style: Propose using C++11 uniform initializer syntax in member initializer lists

[Daniel Bates]

Hi all,

I am writing to propose using C++11 uniform initializer syntax in member 
initializer lists. The following:

class A {
public:
A(B&& b, float i, int j)
: m_b(WTFMove(b))
, m_i(i)
, m_j(j)
{
}
...
};

Would become:

class A {
public:
A(B&& b, float i, int j)
: m_b { WTFMove(b) }
, m_i { i }
, m_j { j }
{
}
...
};

Using uniform initializer syntax in member initializer lists would make the 
syntax we use for member initializer lists consistent with the syntax we use 
for non-static data member initializers. It would also cause a compile time 
error if member initialization required a narrowing conversion (e.g. implicit 
float to int conversion). Another benefit of using this syntax is that it 
allows initialization of a struct using aggregate initialization.

Dan
___
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)

[Daniel Bates]

Thank you for looking into speeding up the build.

How does the speed gain with your proposed "unified source" approach compare to 
using CMake + Ninja to build currently (I think builder Apple El Capitan CMake 
Debug does this)?

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?


> On Aug 28, 2017, at 5:37 PM, Keith Miller  wrote:
> 
> 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.

How does this work if you build from Xcode? I am assuming these bundles won't 
interfere with debugging in Xcode. When debugging in Xcode/lldb/gdb will 
Xcode/lldb/gdb resolve line information with respect to individual files or the 
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.

I take it you mean any file-level function or definition with internal linkage. 
That is, this would also affect file-level constants.

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

Re: [webkit-dev] New tool for Xcode (Emacs?) users: Copy WebKit Permalink

[Daniel Bates]

Hi Charlie,

Thanks for the script! File a bugs.webkit.org bug, CC'ing me, and upload a
patch.

We still need Vim and Textmate plugins :D

Dan

On Mon, Aug 14, 2017 at 4:52 PM, Daniel Bates  wrote:

> Hi Charlie,
>
> Thanks for the script! File a bugs.webkit.org bug, CC'ing me, and upload
> a patch.
>
> We still need Vim and Textmate plugins :D
>
> Dan
>
> On Mon, Aug 14, 2017 at 4:33 PM, Charlie Turner 
> wrote:
>
>> Hi,
>>
>> Thanks for sharing that, thought it was useful so made an Emacs version
>> of it. Only works for the Git mirror and requires Magit as well, but
>> maybe of use to someone else with Emacs.
>>
>> ---8<
>> (defun webkit-trac-url ()
>>   (interactive)
>>   (let ((git-svn-id-line
>>  (car (--filter (string-match-p "svn.webkit.org" it)
>> (magit-git-lines "log" "--format=%b" "-n 1"
>> "HEAD")
>> (if (string-match "\\([A-z]+\\)@\\([[:digit:]]+\\)" git-svn-id-line)
>> (let ((branch (match-string 1 git-svn-id-line))
>>   (revision (match-string 2 git-svn-id-line))
>>   (path (magit-file-relative-name)))
>>   (kill-new (concat "https://trac.webkit.org/browser/"; branch
>> "/" path
>> "?" revision
>> (if current-prefix-arg
>> "&annotate=blame" "")
>> "#L" (format-mode-line "%l")))
>>   (message "On your clipboard!")
>> --->8
>>
>> That goes in your init.el.
>>
>> DISCLAIMER: Not an Emacs expert!
>>
>> ~Charlie.
>> ___
>> 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] New tool for Xcode users: Copy WebKit Permalink

[Daniel Bates]

Hi again,

If you use Xcode then I just landed an Automator service in <
https://trac.webkit.org/changeset/220705/> that you can install to copy a
Trac permalink to your clipboard to the source view or blame view of the
focused file at the currently selected line. To install, just double click
"Copy WebKit Permalink.workflow" in Tools/CopyPermalink and click Install
(*). This service works with Xcode 8 or Xcode 9 beta 5 or later. A picture
is worth a thousand words...



Hold down the Option key while running the service to copy a permalink to
the blame view.

Tip: Assign this service a keyboard shortcut in System Preferences >
Keyboard > Shortcuts for convenience.

File bugs and CC me if you run it any issues or have ideas for
improvements. Feel encouraged to hack on it as well :)

(*) This will actually move the Automator service to the installation
directory making your working copy dirty. Either copy the service to a
temporary location before opening it to install or take care to clean up
your checkout if you install from Tools/CopyPermalink.

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

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

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

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

[webkit-dev] Implement Credential Management Level 1

[Daniel Bates]

Hi all,

I wanted to let you know that I plan to implement the Credential Management
Level 1 spec., . This work
will be done behind a runtime flag. You can follow along by tracking the
master bug at .

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

[webkit-dev] Replaced CSSPropertyNames.in with CSSProperties.json

[Daniel Bates]

Hi all,

Following r209001 the file Source/WebCore/css/CSSPropertyNames.in has been 
replaced with a JSON file in the same directory called CSSProperties.json. See 
the top of this file for editing instructions, 
.
 This is the first step towards modernizing our CSS property generation 
machinery to support a CSS feature status dashboard and more code generation of 
boilerplate code. I will incorporate the functionality of files 
Source/WebCore/css/{SVGCSS, CSS}ValueKeywords.in into CSSProperties.json and 
remove these files in a subsequent commit.

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

Re: [webkit-dev] Windows EWS not working?

[Daniel Bates]

> On Nov 7, 2015, at 7:44 PM, Alexey Proskuryakov  wrote:
> 
> (re-sending from the right e-mail address for the list)
> 
>> 7 нояб. 2015 г., в 16:56, Darin Adler  написал(а):
>> 
>> I was looking at the patch in this bug:
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=150967
>> 
>> The patch was posted 20 hours ago. EWS has processed this for all platforms 
>> other than Windows, but it says “win #61”, so it seems like the Windows bot 
>> has 60 other patches to process before getting to this one.
>> 
>> Does this mean the Windows EWS is stuck? Who can get it unstuck?
> 
> Yes, Windows EWS bots fail to start with the below error. I think that this 
> is a regression from <http://trac.webkit.org/changeset/192087>, so Daniel 
> Bates has volunteered to look into this.

Committed fix in <http://trac.webkit.org/changeset/192137> and Alexey 
Proskuryakov restarted the Windows EWS queues. According to 
<http://webkit-queues.webkit.org/queue-status/win-ews> the Windows EWS machines 
are processing patches as of the time of writing.

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

[webkit-dev] Use WTF::move() instead of std::move()

[Daniel Bates]

Hi all,

Following , please use WTF::move()
instead of std::move(). I substituted WTF::move() for std::move() in all
code to date. WTF::move() is a replacement for std::move() that is less
error prone to use.

Depending on std::move() to lead to a move operation has led to bugs in
some contexts, including 
and . In particular, assigning the
result of std::move() that is passed a const value will lead to a copy
operation (*). For comparison, WTF::move() compile asserts that its
argument is a non-const lvalue reference (**). So, passing a const value to
WTF::move() will cause a compile-time error. This behavior prevents
introducing such bugs and catches unnecessary calls to move() with an
rvalue (as such calls are no-ops).

If you encounter issues using WTF::move() or have suggestions for
improvement then please file a bug and CC me.

Have a happy Fourth of July weekend!

Dan

(*) I'm disregarding functions with nonsensical signatures and behavior,
such as a move assignment operator taking a const rvalue reference.

(**) A person must still ensure that using WTF::move() is necessary at each
call site. That is, that the usage of WTF::move() leads to a move operation
as opposed to a copy operation.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Error while applying on EWS bots.

[Daniel Bates]

Hi Pravin,

svn-apply currently doesn't support SVN 1.7 property diffs. See 
 for more details. I hope to 
take a look at implementing support for these diffs this weekend unless someone 
beats me to it.

Dan

On May 10, 2012, at 10:56 PM, Pravin D wrote:

> Hi All,
> 
> I had uploaded a patch for a Bug from Windows cygwin, using " webkit-patch 
> upload" command. 
> All the EWS bots are not able to apply the patch issuing the following error:
> 
> Failed to find the property value for the SVN property "svn:executable": "## 
> -0,0 +1 ##
> ". at /mnt/git/webkit-style-queue/Tools/Scripts/VCSUtils.pm line 1197,  
> line 478.
> 
> 
> can anyone help on this?
> --Pravin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] WebKit QNX Port

[Daniel Bates]

On Oct 15, 2011, at 4:57 PM, Adam Barth wrote:

> Great!  Does the QNX port require a new build system, or does it
> integrate with one of the existing build systems (e.g., cmake or
> Visual Studio)?

No, it doesn't require a new build system. It integrates with the existing 
CMake build system.

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

Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?

[Daniel Bates]

Please commit the updated Xcode project files.

Dan

On Oct 6, 2010, at 5:00 PM, Darin Adler  wrote:

> Hi folks.
> 
> For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? 
> It’s now showing up in Apple’s Software Update for all Xcode users, I believe.
> 
> I ask because this adds a "developmentRegion = English" string to the project 
> file but the older versions of Xcode remove that string. If we all agree to 
> use the newer version, then we can let that string get checked in. If some of 
> us are using the older version it will be frustrating because the string will 
> be removed each time someone edits the project file with an older version and 
> checks it in.
> 
> If no one objects, we’ll start checking in the project files with 
> developmentRegion in there.
> 
>  -- Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 

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