> 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
> 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
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
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
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
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 W
> 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,
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
> 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
> 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
> 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
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
___
> 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
___
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
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
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
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
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,
> 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
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
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
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
> 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
23 matches
Mail list logo
