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

> 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

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

> 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

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

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

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

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] Moving from WTF::Optional to std::optional

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

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

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

Re: [webkit-dev] Mailman web interface missing

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

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

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

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

> 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

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

> 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

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

> 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

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

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 ___

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

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

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

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

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

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

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

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

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

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

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

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,

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

> 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

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

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev > wrote: > >> One subtle thing is that even when a member variable is already Ref / RefPtr >> / CheckedRef / CheckedPtr, we must create another one in stack as seen here: >> https://commits.webkit.org/267108@main > > (I asked rniwa to

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa wrote: > > Alternatively, we could add a new member function which returns CheckedPtr > like `pageChecked()`. Yes, I think that would be a good approach that would complement the static checker. —

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

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

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

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

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

> 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

[webkit-dev] Gardening our pull requests

Hi folks. I love to keep the WebKit project moving along, and one way that I personally like to contribute is helping get pull requests reviewed. I looked at the list of pull requests for the project, excluding closed requests, draft requests, and requests that have been reviewed:

Re: [webkit-dev] Remove the version labels in GitHub

> On Oct 22, 2022, at 12:11 PM, Caitlin Potter wrote: > > Would it make sense to, rather than referring to downstream browsers, have a > canonical WebKit version number that could be exposed in about:version or > something? A friendly semver-ish thing + short git hash could be a lot more >

Re: [webkit-dev] Nicks in contributors.json

> On Oct 24, 2022, at 1:57 PM, Alexey Proskuryakov via webkit-dev > wrote: > > 1. Finding people on Slack. For this, they would probably need to stay on > https://webkit.org/team. If they were consistently the Slack nicknames. But they often aren’t! The nicknames currently in there don’t

[webkit-dev] Remove the version labels in GitHub

Hi folks. I understand it can be super critical to understand what version someone was testing when reporting a WebKit bug. But I, at least, haven’t found the version field at bugs.webkit.org useful in the 20+ years I have been working on this project. Now we have that same noise in GitHub.

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev > wrote: > > assuming every local variable / variable in stack is stored in a smart > pointer, function arguments are safe to be raw pointers / references via > transitive property What about the case where the function argument is

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 3:35 PM, Ryosuke Niwa via webkit-dev > wrote: > >> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote: >> >>> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev >>> wrote: >>> >>> assuming every local variable / variable in stack is stored in a smart >>> pointer,

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote: > > One alternative is to make bar() return RefPtr although that would be a bit > heavy handed in the case of trivial function calls like this: > document().frame()->ownerElement() I don’t quite follow. You just said that all arguments

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

I don’t think I can notice these patterns. I would be able to program this way if I had an analysis tool, but otherwise this simply seems too complicated. I can’t see the types of intermediate values to know if they are CheckedPtr or RefPtr or raw pointers or whatever. A variation on the first

Re: [webkit-dev] Compile times and class-scoped enums

> On Jan 20, 2023, at 9:50 AM, Jer Noble via webkit-dev > wrote: > > I attempted to address this in , > which (on this machine) reduces the total compile time of Document.h in the > WebCore project from about 1000s to about 200s. That’s good. >

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

I am hoping this ends up being practical. In the CSS code I have recently worked on there are many short-lived references, and in some refactoring I was not able to change them all to smart pointers without a measurable performance degradation in Speedometer, so the code might need redesign to

Re: [webkit-dev] GPU Process on all platforms eventually?

> On Nov 14, 2022, at 4:45 PM, Fujii Hironori via webkit-dev > wrote: > > When will we remove WebKit1? Apple can’t remove WebKit1 from iOS or macOS while keeping old apps working, so we won’t be able to remove it any time soon as long as Apple is shipping new versions of WebKit. To cite one

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

> On Mar 28, 2023, at 4:57 PM, Laurence Rowe via webkit-dev > wrote: > > I was hoping to try and wrap the jsc-only build into a rust crate since the > existing rust wrappers either include gtk dependencies or only wrap the lower > level api and link against the system libraries. What’s the

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

> On Nov 28, 2023, at 3:02 PM, Chris Dumez wrote: > > FYI, my understanding is that the person gets a *green* checkmark when the > person is present in contributors.json (common case), even if not marked as a > reviewer in that file. Does anyone know why we chose green for all contributors

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

I support using standardized and widely enough available language features directly instead of through macros whenever we can. It’s similar to when we drop our own classes and use the ones from the C++ standard, which I think has been good for the project. It’s also fine with me to use the