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

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

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

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

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 >

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

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

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

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

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

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

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

> 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

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] 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] 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] 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] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 20, 2020, at 4:08 PM, Sam Weinig wrote: > > For the ones conditionalizing adding to ADDITIONAL_BINDING_IDLS, those IDLs > should just have the appropriate Conditional=* extended attribute added, then > they can be included unconditionally in the makefile. > > For the ones

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 20, 2020, at 3:09 PM, Sam Weinig wrote: > > For the Platform.h issue, I think we could probably engineer things in the > short term to have a script phase that produces a Defines.txt that the other > script phases and build rules depend on. We definitely can, and it’s simpler than

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

It would be wonderful to drastically cut down the repeated mentions of the same filenames. People not on Xcode platforms probably focus primarily on Xcode projects for this frustration. But I find it ridiculous how many places I have to add things. For example, to add AbstractRange I had to add

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

Oops, I was in the middle of writing this and hit send by mistake ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

Please note that this is a Cocoa-only, Xcode-only conversation. As Sam pointed out, there’s a whole different “will you please switch to CMake” conversation. That’s not an easy switch to make for programmers working on the Apple platforms, but we might do it at some point if we can work out the

Re: [webkit-dev] Trailing space changes in "expected.txt" files

> On Sep 26, 2020, at 8:13 PM, Darin Adler wrote: > > by rebasing and either regenerating the expected.txt files hand editing. … resolve the conflicts by rebasing and either regenerating the expected.txt files with run-webkit-tests or by hand editing the expected.txt files.

[webkit-dev] Trailing space changes in "expected.txt" files

Hi folks. This afternoon, I changed dumpAsText so it strips trailing spaces. https://trac.webkit.org/changeset/267640 As part of that change, run-webkit-tests temporarily will ignore trailing spaces in expected.txt files, so they can be checked in with, or without, the spaces. Over the

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

> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa wrote: > > There are quite a few cases where data members are references but then those > can also be replaced by a simple member function which retrieves the value of > the smart pointer member variable and returns a reference. I think this should

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

> On Sep 23, 2020, at 10:32 AM, Darin Adler wrote: > >> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote: >> Every data member to a ref counted object must use either Ref, RefPtr, or >> WeakPtr. webkit.NoUncountedMemberCheck

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

> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa wrote: > Every data member to a ref counted object must use either Ref, RefPtr, or > WeakPtr. webkit.NoUncountedMemberChecker > My > only worry here is

[webkit-dev] Could use some help from people who care about the WinCairo port

The patch for this bug https://bugs.webkit.org/show_bug.cgi?id=216428 is failing to build on WinCairo because of some kind of precompiled header problem. I could use some help figuring out what I did wrong. —

Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

> On Sep 3, 2020, at 11:14 PM, Fujii Hironori wrote: > > BTW, I don't like to idea adding a new rule, but keeping old style code. It > introduces divergence between the guideline and actual code. Do we really > need a new rule that one doesn’t necessary have to follow? I understand that you

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

> On Aug 31, 2020, at 9:33 AM, David Bokan wrote: > > We've made lots of improvements to the spec, notably around issues raised in > Mozilla's standards-position > . Do you think those improvements address Maciej’s concerns from last

Re: [webkit-dev] Plugin process

> On Jul 20, 2020, at 7:35 AM, Michael Catanzaro wrote: > > Then we can make the plugin process specific to PLATFORM(COCOA) Side note: It will be specific to PLATFORM(MAC). — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org

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

> On Jul 16, 2020, at 3:33 PM, Adrian Perez de Castro wrote: > > enabling/disabling features changes the set of source files to > build, which results in different source files being #included from each > unifier source compilation unit. Let’s stop doing it that way. Just compile the files and

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

> On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro wrote: > > It is not feasible to test unified builds for all the possible combinations of > target architectures and set of features enabled at build time (there is a > combinatorial explosion of configurations). Keeping non-unified builds in

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

> On Jul 16, 2020, at 12:54 PM, Kirsling, Ross wrote: > > Non-unified build fixes are done to support *all* platforms, because sudden > unification shifts can happen anywhere. I’m not sure that benefit is worth the additional code churn. I understand that it’s frustrating to run into a

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

> On Jul 14, 2020, at 2:38 PM, Simon Fraser wrote: > > Could someone educate me about ? When should I use this > instead of individual wtf headers? Forward.h is analogous to forward-declaring a class ('class IntPoint;' instead of ‘#include “IntPoint.h”'), but it works for many often-used

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

We need to be cautious about adding header includes to other headers. Adding includes to .cpp files is likely fine and not a deeply consequential decision, but adding to headers is something that can have a massive effect on build times over time. > On Jul 13, 2020, at 10:44 PM,

Re: [webkit-dev] Platform.h vs. makefiles

> On May 10, 2020, at 10:07 PM, Maciej Stachowiak wrote: > > I think the best way to configure WebKit is to use a separate data file, > neither a header nor a makefile or similar, that defines the options in a > single place with clear syntax. Then everything else is generated from that. >

[webkit-dev] Platform.h vs. makefiles

Hi folks. The Platform.h configuration file family has been useful for WebKit for a long time. We created it to try to organize configuration options in WebKit so the would not be spread out through the whole project. One way to look at these, particularly the ENABLE options, is as a set of

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

Here’s my take: The source code we check into the WebKit repository is there for the convenience of the people *contributing* to WebKit, and is need not be the sole input when building and packaging WebKit for distribution. Including ICU sources in a GTK WebKit tarball would not necessarily

Re: [webkit-dev] Accidental binary bloating via C/C++ class/struct + Objective-C

> On Jan 13, 2020, at 5:52 PM, Yusuke Suzuki wrote: > > We can purge type-encoding-string if we use Objective-C NS_DIRECT feature > (which makes Objective-C function as C function calling convention, removing > metadata). > However, this does not work universally: with NS_DIRECT, Objective-C

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

> On Aug 23, 2019, at 7:26 AM, Antti Koivisto wrote: > > Could WTF::makeUnique simply use FastMalloc by default? We could then remove > most of these messy annotations. > > This would require replacing std::unique_ptr with a type that knows how to > free the objects correctly (bring back

Re: [webkit-dev] Moving to Python 3

> On Jul 16, 2019, at 12:46 PM, Alexey Proskuryakov wrote: > > - They shouldn't make it excessively difficult to do WebKit engineering on > older versions of macOS. > > "Excessively" is not clearly defined, but it seems obvious that there is a > tradeoff between tools work difficulty, and

Re: [webkit-dev] Incremental unified builds on macOS

It’s unlikely the problem is due to unified builds, since those are just source files with includes in them. But I have encountered problems like this before; sometimes they are things affecting lots of people and I’ve been able to fix them. When trying to understand causes of this kind of

Re: [webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs

> On Jun 15, 2019, at 9:13 PM, Aakash Jain wrote: > > 1) Do not upload archive (for layout-test-results) on bugzilla, instead > upload it to another server, unzip it and post a link to the results.html. > Pros: > a) Engineers won't have to download the attachment, unzip it, look for >

Re: [webkit-dev] Changing the svn commit hook to allow tabs for tests.

> On May 10, 2019, at 1:13 PM, Keith Miller wrote: > > I’m not sure I know what you mean by allow a whole-directory exception. Do > you mean a top level directory? Or some kind of parameter we pass to the hook > to ignore some directory for that run? I meant that we could add something the

Re: [webkit-dev] Changing the svn commit hook to allow tabs for tests.

> On May 10, 2019, at 1:00 PM, Keith Miller wrote: > > I don’t know if this is possible but it would be great if some > sub-directories could be excluded from the no-tabs pre-commit hook. Maybe we can rewrite the pre-commit hook to allow a whole-directory exception. Ideally I’d prefer not to

Re: [webkit-dev] Spam and indexing

Should we post instructions somewhere for people dealing with spam? I believe the instructions are: 1) Look up the email address of the account that posted the spam and disable it first, so spammers don’t get email about other steps. Do this by clicking on Administration, Users, finding the

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

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

[webkit-dev] Rename AtomicString to AtomString

So, did we reach consensus that we should rename AtomicString to AtomString? — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Compile error in WebGL2RenderingContext.cpp

Vector’s inline capacity feature was originally created as an alternative to variable length arrays for most of the purposes people would want to put them. Imagine, for example, that you need a variable length buffer of characters that is almost always going to be less then 32 bytes. You write

Re: [webkit-dev] the name "AtomicString"

Seems to me we could fix the current problem by renaming from AtomicString to AtomString without causing any new problem. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

Let’s be clear about what we are discussing. The choice is not be between “final” and “override”. The choice is between “final override”, “override final”, and “final” for functions which are both overrides and final. — Darin Sent from my iPhone > On Dec 19, 2018, at 12:27 PM, Michael

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

> On Dec 19, 2018, at 1:52 AM, Fujii Hironori wrote: > > I'd like to change this because 'final' doesn't necessarily imply > 'override'. See the following stackoverflow: > https://stackoverflow.com/questions/29412412/does-final-imply-override I’d be happy to require both final and override if

Re: [webkit-dev] the name "AtomicString"

The name “AtomicString” was inspired by the term of art, “atom”, traditionally used in at least some programming language implementations for what I see now is often called interned strings. You’ll see a mention of that term in the article https://en.wikipedia.org/wiki/String_interning in the

Re: [webkit-dev] WebCorePrefix.h vs. config.h

> On Dec 9, 2018, at 10:34 PM, Fujii Hironori wrote: > > MSVC has /FI option. > > /FI (Name Forced Include File) | Microsoft Docs > > https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017 > > Unfortunately, it seems that MSVC's precompiled header

Re: [webkit-dev] WebCorePrefix.h vs. config.h

OK, here’s my answer after thinking on it a bit: Best would be to eliminate “config.h”: Change “config.h” into an empty file first, then remove all “config.h” includes, and then remove the file. But to do that, we need to make sure every build system for WebKit supports prefix headers. I don’t

Re: [webkit-dev] WebCorePrefix.h vs. config.h

> On Dec 8, 2018, at 2:56 PM, Darin Adler wrote: > >> On Dec 7, 2018, at 2:44 PM, Alexey Proskuryakov wrote: >> >> only keep config.h just to include WebCorePrefix for the lone build scenario >> where that's needed, and to undef new/delete? > > I thi

Re: [webkit-dev] WebCorePrefix.h vs. config.h

Useful background exists in Wikipedia: https://en.wikipedia.org/wiki/Prefix_header and https://en.wikipedia.org/wiki/Precompiled_header are relevant. Alexey, perhaps you know all of this already,

Re: [webkit-dev] WebCorePrefix.h vs. config.h

> On Dec 7, 2018, at 2:44 PM, Alexey Proskuryakov wrote: > > only keep config.h just to include WebCorePrefix for the lone build scenario > where that's needed, and to undef new/delete? I think the answer likely lies here: What is this lone build scenario where config.h is needed? — Darin

Re: [webkit-dev] Clarifying feature flags

A while ago Kentaro Hara did some IDL keyword cleanup. One of the best things he did was to make a single file with a list of all the keywords. In that case he was able to set things up so that if the file was inaccurate the build would fail; not sure if that’s practical for the various

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

> On Oct 31, 2018, at 7:52 AM, Konstantin Tokarev wrote: > > 31.10.2018, 05:18, "Fujii Hironori" >: >> wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like >> to rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h. >> Any suggestion? > >

Re: [webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

> On Sep 23, 2018, at 1:34 PM, Koby Boyango wrote: > > I will merge your changes to my fork Would you be willing to focus on upstreaming first, instead? That would also get you the latest improvements, but in a more sustainable way. — Darin ___

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

I don’t know. Sent from my iPhone > On Sep 17, 2018, at 7:49 AM, Filip Pizlo wrote: > > > >> On Sep 16, 2018, at 8:48 PM, Darin Adler wrote: >> >>> On Sep 16, 2018, at 5:59 PM, Filip Pizlo wrote: >>> >>> Which offline assemb

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

> On Sep 16, 2018, at 5:59 PM, Filip Pizlo wrote: > > Which offline assembler build step are you referring to? The one that is the “Offline Assembler” target in Xcode, which runs this command: ruby JavaScriptCore/offlineasm/asm.rb JavaScriptCore/llint/LowLevelInterpreter.asm

[webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

I noticed that the “Offline Assembler” build step was taking between 5 and 30 seconds every time I build. Really stands out in incremental builds. I realized that this step does not do any dependency analysis. Every time, it builds a hash of the input to see if it needs to recompute the

Re: [webkit-dev] Unified sources have broken our #include hygiene

> On Sep 1, 2018, at 5:14 PM, Simon Fraser wrote: > > Unified sources allow you to get away without #including all the files you > need in a .cpp file, because some earlier file in the group has probably > already included them for you. > > This means that when you add a new file to the

Re: [webkit-dev] Freenode spam counter-measure

> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev wrote: > >>> On Aug 5, 2018, at 2:38 AM, Philippe Normand wrote: >>> >>> Can one of the #webkit admin please set the +r mode on? This would help >>> reducing spam. Only messages from registered nicks would come through. >> >> I tried this by

Re: [webkit-dev] Freenode spam counter-measure

> On Aug 5, 2018, at 2:38 AM, Philippe Normand wrote: > > Can one of the #webkit admin please set the +r mode on? This would help > reducing spam. Only messages from registered nicks would come through. I tried this by typing this: /msg ChanServ set #webkit restricted on But ChanServ

Re: [webkit-dev] Proposal: Not supporting x86 w/o SSE2

Sounds good. There are clients of WebKit outside web browsing. A significant client like that on Windows at Apple is iTunes. I checked and Windows versions of iTunes require a processor with support for SSE2, so clarifying WebKit’s lack of support won’t

Re: [webkit-dev] Objective-C code in libwebrtc already assuming ARC?

> On Jun 6, 2018, at 9:39 AM, Dan Bernstein wrote: > > libwebrtc.xcconfig sets CLANG_ENABLE_OBJC_ARC to YES for the libwebrtc > target. Since RTCVideoCodecH264.mm is part of that target the file is > compiled with ARC. OK, great. That’s what I missed. I’ll get rid of the stray -fobjc-arc in

Re: [webkit-dev] Objective-C code in libwebrtc already assuming ARC?

> On Jun 6, 2018, at 9:28 AM, Darin Adler wrote: > > best keep working with manual retain and release best kept working > a non-tribal amount of code that already seems to assume ARC a non-trivial amount — Darin ___ webkit-dev mailing

[webkit-dev] Objective-C code in libwebrtc already assuming ARC?

Hi folks. As some of you have probably noticed, I’ve begun making changes with the goal of preparing us to move most Objective-C code in WebKit to ARC. In doing so, I have been exploring the existing code in the tree and the various projects in our source tree. The nine projects with

Re: [webkit-dev] Build issues due to anonymous namespace

> On Dec 3, 2017, at 12:16 PM, Filip Pizlo wrote: > > That also means not using static, for the same reason. FWIW, I think it’s a > good idea. Maybe. There is definitely no benefit in wrapping a class, structure, or type definition in an anonymous namespace. My comment was

Re: [webkit-dev] Build issues due to anonymous namespace

I think it’s also worthwhile to remove the anonymous namespace wrapping each of these DestroyFunc structures when renaming them. Generally speaking, anonymous namespace doesn’t work when compilation units are arbitrary, since they say “limit this to one compilation unit”. So I’m not sure we

Re: [webkit-dev] Unified sources build errors when adding new source files

Oh, I see. Errors in EWS in that bug. Looking. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unified sources build errors when adding new source files

> On Nov 21, 2017, at 6:54 AM, Javier Fernandez wrote: > > It builds perfectly with the no-unify tag, but I produces totally > unrelated errors when using the unified building. I wonder whether my > patch could make those errors arise because of altering the building >

[webkit-dev] EWS queues seem stuck

A couple of my patches have been sitting around all day and some of the EWS servers still say they are 15 patches behind. Are they stuck? Can someone bring them back to life? — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] Tests failing because WPT images not served at correct URL?

Youenn is helping me figure this out. My original guess about why it’s failing was probably wrong. You can follow along here >. — Darin___ webkit-dev

  1   2   3   4   5   6   7   8   9   10   >