Re: [webkit-dev] Deployment of new EWS Non-Unified builder

2022-06-06 Thread Darin Adler via webkit-dev
> On Jun 6, 2022, at 1:09 PM, Olmstead, Don  wrote:
> 
> If it isn’t it should be considering how many times I’ve had a cq- come from 
> an AppleWin build that is in no way affected by my patch.

Yes, we have a problem with that AppleWin bot, and it’s one that bothers me 
quite a bit, but I don’t want to design our policy around that problem.

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


Re: [webkit-dev] Deployment of new EWS Non-Unified builder

2022-06-04 Thread Darin Adler via webkit-dev
Yes, I don’t oppose adding another EWS bot, and I was not trying to argue 
against that proposal. I did intend to express my disagreement with many points 
made in follow-up replies that seem quite wrong to me.

Three other thoughts:

1) Even though I don’t object to adding a new bot, I will say that the idea 
that a single “non-unified” bot will add a lot of value at very little cost to 
the WebKit project doesn’t sound right to me. These arguments about how long 
things will take don’t seem correct. My experience is that it’s quite difficult 
to find, understand, and resolve errors seen in bot builds, far more difficult 
than resolving errors I can see locally as I make code changes. In my view 
every EWS bot we add helps weigh down the project, making each change more 
difficult.

2) In my contributions, I don’t just want to add missing includes, I want to 
remove unnecessary ones taking full advantage of forward declarations and 
moving code out of headers. Too many includes and too much dependency has a 
dramatic bad effect on the project, making colossal project build times even 
worse.

3) We had many, many problems with platform-specific include differences before 
we had unified builds, with frustrated contributors if they worked with any 
configuration that lacked an EWS bot. It may seem that the 
unified-build-specific problems are something fundamentally different, but this 
is not how I see it.

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


Re: [webkit-dev] Deployment of new EWS Non-Unified builder

2022-06-03 Thread Darin Adler via webkit-dev
Here’s my view:

Long ago we agreed that we’ll ask WebKit contributors to keep builds working 
that have EWS bots, and not other configurations. As far as I can tell, nothing 
has changed that invalidates that strategy and we should stick with it.

I do not agree that the statement that “all projects must build under all 
supported configurations” applies to WebKit. We don’t even have a concept of 
“supported configurations” to build that policy on. This has not been a project 
goal in the past and I suggest we do not add this project goal.

We should continue to use the Early Warning System to define which 
configurations must be kept working by all contributors, with anything beyond 
being treated as a stretch goal.

And we should continue to accept patches to fix various configurations that 
people want to keep working that are not checked by EWS. But we absolutely 
should not ask contributors to keep all possible combinations working.

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


Re: [webkit-dev] WebKit Style: Whitespace for Objective-C protocols

2022-02-24 Thread Darin Adler via webkit-dev
I personally prefer id, and would be happy to standardize on 
that. I don’t really care that much about statistics about usage in our 
existing code.

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


Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

2022-02-16 Thread Darin Adler via webkit-dev
I think of it as following the same naming pattern as downcast<> or 
static_cast<>, but you don’t have to specify a template argument since it 
infers it for you.

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


Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

2022-02-16 Thread Darin Adler via webkit-dev
Just economy. There is no need for two different names. I personally like it 
this way, and have found it appealing when I used it. I think you should give 
it a try. We can certainly change the name later if this turns out to 
significantly improve things.

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


Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

2022-02-15 Thread Darin Adler via webkit-dev
Oh, forgot to say, it’s in this header:

 #include 

Using functions like this one will help us get over the “bridge” to ARC on this 
project eventually.

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


[webkit-dev] Great function for Cocoa platform, bridge_cast

2022-02-15 Thread Darin Adler via webkit-dev
Hi folks.

For those of you doing work with Objective-C on Cocoa platforms, I want to draw 
your attention to a great new idiom. Back in October, David Kilzer added 
bridge_cast, a type-safe set of functions that convert an Objective-C pointer 
to a Core Foundation pointer or vice versa, preserving types across the 
toll-free bridging boundary. It’s better than traditional non-WTF idioms where 
you use casts that look like “(__bridge id)” because you don’t have to write 
the type, and the correct corresponding type is chosen for you.

When you have a CFStringRef and need to use it as an NSString key and value in 
an Objective-C dictionary, for example, the idiom would be:

bridge_cast(constantKey): bridge_cast(constantValue),

Rather than the old:

(__bridge id)constantKey: (__bridge id)constantValue,

It converts to NSString *, not id, which is better for many contexts, and good 
here, too. Since the function works in both directions, it will also turn an 
NSDictionary into a CFDictionaryRef. And it works on both raw pointers and on 
RetainPtr. I find it’s even more welcome to have something that can convert a 
RetainPtr into RetainPtr without danger of 
getting the reference counting wrong, doing the right thing in both ARC and 
non-ARC source files, and optimizing the move cases appropriately.

Please consider this instead of writing things like (CFStringRef)keyNS.get() 
because it’s easier to see it’s correct.

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


Re: [webkit-dev] OK to flatten WTF's header directory?

2022-02-03 Thread Darin Adler via webkit-dev
> On Feb 3, 2022, at 5:16 PM, Elliott Williams  wrote:
> 
> If what you’ve experienced is unique to WTF, I’d be suspicious of the 
> non-standard approach we’ve taken to copying WTF’s headers I mentioned above.

Great news. I hope this plan works out.

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


Re: [webkit-dev] OK to flatten WTF's header directory?

2022-02-03 Thread Darin Adler via webkit-dev
Long ago, I originally created the forwarding headers to bridge the gap between 
framework-style includes that those of us at Apple wanted to do, where headers 
are flattened and you write #include , and 
Unix-style installed libraries, where things are not flattened. I wanted us to 
be able to write include statements in WebKit in the traditional 
non-Apple-framework style so they would work on those other platforms, and the 
forwarding headers were originally just for the Apple platforms, making those 
includes work with the framework structure provided automatically by the Apple 
framework build system.

Those original forwarding headers were not copies of the headers, they were 
simply files “in the right place” with include statements in them. I’m not sure 
at what point along the way we started making copies of headers, and we may be 
solving other problems with that.

This proposal, to flatten the WTF headers, seems to be a step in of the 
opposite direction, making the non-Apple platforms do something akin to 
framework-style including. Not sure I understand the pros and cons are of that.

I am currently suffering when working on WebKit development because of the 
copies of headers made by the build system. I can’t count the number of times 
I’ve edited a WTF header and then later realized I had edited the copy, not the 
original. I would very much like a solution that resolved that problem. I use 
Xcode features, and it seems the copies are what Xcode thinks are the “real” 
headers.

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


Re: [webkit-dev] Proposal to change nested namespace indentation rule to match the existing code

2021-10-22 Thread Darin Adler via webkit-dev
> On Oct 22, 2021, at 12:33 AM, Kimmo Kinnunen via webkit-dev 
>  wrote:
> 
> 1) Match what seems to already be de-facto used in code.

Yes, does seem to be what we’re already doing. I like it. The rest of your 
arguments also seem good.

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


Re: [webkit-dev] Moving from WTF::Optional to std::optional

2021-06-02 Thread Darin Adler via webkit-dev
Thanks for pointing that out, Chris.

This advice goes beyond std::optional, by the way. For anything that we move 
from, there are two operations at are intended to be safe, from a C++ language 
and library design point of view: destroying the object and overwriting it by 
assigning a new value. If our code relies on doing anything else after the 
object is moved from, like examining the value after the old value is moved 
out, please use std::exchange to set the new value while moving the old value 
out. This even applies to large-seeming objects like HashMap, which I will note 
is not large: in release builds a HashMap is implemented as a single pointer to 
a structure on the heap and a new empty HashMap is a null pointer.

— Darin

Sent from my iPad

> On Jun 1, 2021, at 10:01 PM, Chris Dumez  wrote:
> 
> Hi,
> 
> Another thing Darin didn’t mention but I think people should be careful about:
> The move constructor for std::optional does not clear the is-set flag (while 
> the one for WTF::Optional did).
> 
> As a result, you will be having a very bad time if you do a use-after-move of 
> a std::optional. Please make sure to use std::exchange() instead of WTFMove() 
> if you want to leave to std::optional in a clean state for reuse later.
> 
> Chris Dumez
> 
>>> On Jun 1, 2021, at 8:54 PM, Darin Adler via webkit-dev 
>>>  wrote:
>>> 
>> Hi folks.
>> 
>> We’re getting rid of the WTF::Optional class template, because, hooray, 
>> std::optional is supported quite well by all the C++17 compilers we use, and 
>> we don’t have to keep using our own special version. Generally we don’t want 
>> to reimplement the C++ standard library when there is not a significant 
>> benefit, and this is one of those times.
>> 
>> Here are a few considerations:
>> 
>> 1) Since https://commits.webkit.org/238290@main, if you use Optional<> by 
>> mistake instead of std::optional<>, your code won’t compile. (Unless you are 
>> writing code for ANGLE, which has its own separate Optional<>.)
>> 
>> 2) If you want to use std::optional, include the C++ standard header, 
>> , or something that includes it. In a lot of cases, adding an 
>> include will not be required since it’s included by widely-used headers like 
>> WTFString.h and Vector.h, so if you include one of those are covered. 
>> Another way to think about this is that if your base class already uses 
>> std::optional, then you don’t need to include it.
>> 
>> 3) Once the patch in https://bugs.webkit.org/show_bug.cgi?id=226437 lands, 
>> includes of  won’t forward declare optional, and includes of 
>>  won’t do anything at all.
>> 
>> — Darin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Moving from WTF::Optional to std::optional

2021-06-01 Thread Darin Adler via webkit-dev
Hi folks.

We’re getting rid of the WTF::Optional class template, because, hooray, 
std::optional is supported quite well by all the C++17 compilers we use, and we 
don’t have to keep using our own special version. Generally we don’t want to 
reimplement the C++ standard library when there is not a significant benefit, 
and this is one of those times.

Here are a few considerations:

1) Since https://commits.webkit.org/238290@main, if you use Optional<> by 
mistake instead of std::optional<>, your code won’t compile. (Unless you are 
writing code for ANGLE, which has its own separate Optional<>.)

2) If you want to use std::optional, include the C++ standard header, 
, or something that includes it. In a lot of cases, adding an include 
will not be required since it’s included by widely-used headers like 
WTFString.h and Vector.h, so if you include one of those are covered. Another 
way to think about this is that if your base class already uses std::optional, 
then you don’t need to include it.

3) Once the patch in https://bugs.webkit.org/show_bug.cgi?id=226437 lands, 
includes of  won’t forward declare optional, and includes of 
 won’t do anything at all.

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


Re: [webkit-dev] Let's use -Werror on EWS?

2021-05-24 Thread Darin Adler via webkit-dev
Sorry, I should clarify.

Apple’s ports of WebKit already use -Werror and always have, everywhere, not 
just on EWS. Since day one.

I do not know why we do not already use -Werror on GTK and WPE and I support 
using it there after fixing all the warnings.

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


Re: [webkit-dev] Let's use -Werror on EWS?

2021-05-24 Thread Darin Adler via webkit-dev
I’m a big fan of -Werror. Back when WebKit started, it was controversial to use 
it at Apple.

But we can’t just turn on -Werror until after we fix all the warnings! Who will 
do that project.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-30 Thread Darin Adler via webkit-dev
OK. I acknowledge my view on this is different from the others commenting here, 
perhaps because of different ideas about what is hard and requires expertise. I 
won’t stand in the way of changes you want to make. You know my view now.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev 
>  wrote:
> 
> it is definitely highly annoying

It’s possible that where my thinking differs from others on this is that I 
don’t think shifting annoying work from one set of commits (the ones adding a 
new file) to a different set (the ones unknowingly adding need for a new 
include for non-unified builds) is a significant improvement. Adding more EWS 
bubbles has a cost.

Keep in mind that I am just as passionate as the next person about getting 
includes “right”. I’m just not sure that this would be a step in the right 
direction.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 9:01 PM, Tim Horton  wrote:
> 
> This is a huge problem for people on the Apple platforms using the Xcode 
> projects. Nearly every time someone adds a file they have to add random 
> headers to unrelated code.

OK, sorry, I must be out of touch with the rest of you about how difficult this 
is. I’ve done that many times, and it was always easy for me.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev 
>  wrote:
> 
> Yeah, I think it's important to clarify that nobody is "using 
> non-Unified-Source building for their development", at least to my knowledge. 
> Being broken by the shifting sands of unified sources is an everybody problem 
> (or at the very least an "everybody that builds via CMake problem", which is 
> ultimately an everybody problem).

How is this a bigger problem in CMake than for people on the Apple platforms 
who are using Xcode projects? Can we create greater parity between the two?

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
Given the issue is that there are people that are using non-Unified-Source 
building for their development, the best fix is to add post-commit and EWS 
builders for one of those platforms. I do not support the idea of adding an 
additional builder just to “keep non-Unified-Source building” if no 
actively-supported platform is not choosing that build style.

Specifically, if Sony people are most affected by this, I suggest we find a way 
to add Sony PlayStation post-commit and EWS builders.

I am not convinced that we should add some kind of abstract “correct 
compilation” that is a separate builder.

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


Re: [webkit-dev] Mailman web interface missing

2021-04-26 Thread Darin Adler via webkit-dev
> On Apr 26, 2021, at 1:03 PM, Adrian Perez de Castro via webkit-dev 
>  wrote:
> 
> - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found”
> - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden”

I took a look and it seems that the URLs have simply changed, perhaps as a 
result of an update:

https://lists.webkit.org/mailman/listinfo/webkit-wpe
https://lists.webkit.org/mailman/admin/webkit-wpe 


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


Re: [webkit-dev] GitHub Account and Commit Attribution

2020-12-17 Thread Darin Adler via webkit-dev
> On Dec 17, 2020, at 8:47 AM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> Something we’ve just learned about commit attribution and GitHub is that 
> adding an email to your GitHub account may not attribute commits that were 
> pushed to a repository before you added the email. There were a few issues 
> with history as it stands now, and I will be pushing up the final version of 
> history in the next few days.
> 
> What this means for you now is that it is time to set-up your GitHub account 
> if you have not already and add any emails you used to commit to WebKit to 
> your account (GitHub allows multiple emails to be associated with a single 
> account).

Do GitHub’s privacy settings matter? My GitHub account now has da...@apple.com 
associated with it, but I have "Keep my email addresses private” checked in 
GitHub settings. Does that matter?

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


Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

2020-12-09 Thread Darin Adler via webkit-dev
> On Dec 9, 2020, at 1:02 PM, Geoff Garen via webkit-dev 
>  wrote:
> 
>> - Make FontCache thread-safe, but do it via introducing a completely
>> separate thread-safe AtomString type and leave the current one as it is
>> (I don't have a good grasp of how difficult this would actually be)
> 
> I had to chuckle at this point because the obvious name for this new 
> thread-safe AtomString class would be AtomicString, the prior name of 
> AtomString.

If we make a separate thread-safe code path, I’m not sure we need to create a 
variant of AtomString at all.

AtomString optimizes string comparisons (by paying up front every time you 
construct one with a hash table lookup) and memory use (by sharing the same 
memory for all equal strings), but there’s no reason we can’t compare two 
strings without using AtomString. I’m doubting that once we figure out what 
we’re trying to do that we’ll need AtomString.

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