Re: [webkit-dev] git-webkit pr now supports --no-ews / --ews flags

This is great! As it is said in "Ghost Dog: The Way of the Samurai", it is bad when one thing becomes two. Can we pick one name for this feature? Either —no-ews (git-webkit) and no-ews (GitHub) or —skip-ews (git-webkit) and skip-ews (GitHub)? Thanks, Geoff > On Jan 26, 2023, at 11:36 AM, Aakas

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

Is the idea that a checker failure should block landing a patch, or just that it should start a conversation with your patch reviewer about why this case is an exception? Maybe the ’should’ clause in the error message could clarify. In general, I do think it’s helpful to flag any new raw pointe

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

>> However, this change requires moving class-scoped enums out into the >> namespace scope. > > Seems worthwhile. Doesn’t seem to me like it would have far reaching effects. I agree. > +using Type = DOMAudioSessionType; Did you do this to make the patch smaller, or do you prefer this style

[webkit-dev] Ben Nham is now a WebKit Reviewer

Hi folks, I’m happy to announce that Ben Nham is now a WebKit reviewer. 🎉 Ben is an expert in many Apple technologies, and in Performance and WebPush in particular. Please feel free to reach out to Ben for reviews. Thanks, Geoff ___ webkit-dev mailing

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

Thanks for gathering this data! >> What are some notable cases of recent regressions that have landed because >> of non-use of commit queue and caused serious problems? > > Some recent examples of regressions that would have been prevented by > mandatory commit/merge-queue as proposed: > > htt

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

> As such, I also think that the non-unified EWS being green should not be a > blocker to landing a patch. But I think having it there for information will > help the situation. At minimum, even if every engineer simply ignores the > non-unified EWS, it also makes it easier for someone trying to

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

>> What is the goal of this proposal? > > The goal is to increase the stability of the build Is this goal distinct from preventing regressions from landing? If so, how? > , speed up EWS by preventing regressions from landing What are some notable cases of recent regressions that have landed bec

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

> As we move to GitHub, I would like to propose we strengthen our protections > on `main` by making MergeQueue and CommitQueue mandatory. What is the goal of this proposal? What problem are you trying to solve, and with what level of urgency? Thanks, Geoff > On Jun 2, 2022, at 2:35 PM, Jona

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

Do I undertand correctly that the proposal here is (a) Immediately Deprecate ChangeLogs (b) Immediately end support for posting patches from Subversion checkouts? If so, do you know how many regular WebKit contributors still post patches from Subversion checkouts, and, if that

Re: [webkit-dev] ChangeLog Deprecation Plans

>> Commit message is tied to a commit, so editing commit without breaking >> commit-message is hard (how to revert one change from one commit without >> rewriting commit message? It requires some git hack). Separate independent >> COMMIT_MESSAGE file can solve this problem and makes local develo

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

The original question was, as I understood it, was do we need to support non-unified builds as an essential requirement for a given port, and if so, why? I’d like to finish answering that question, before we wonder off-topic and consider whether supporting non-unified builds as an optional way t

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

style stack traces. > > - Saam > >> On Jun 24, 2020, at 12:17 PM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: >> >> Is "-fno-inline -fno-optimize-sibling-calls” still on the table? >> >> Thanks, >> Geoff >> >>

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

Proskuryakov >> <mailto:a...@webkit.org>> wrote: >>> >>> >>> >>>> 19 июня 2020 г., в 1:11 PM, Mark Lam >>> <mailto:mark@apple.com>> написал(а): >>>> >>>> >>>> >>>>&

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: >> >> Can you explain more about what "O3 with no-inlining” is? How does >> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about >> stack trac

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

Can you explain more about what "O3 with no-inlining” is? How does --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about stack traces, or would something still be different about stack traces? And again, I think this discussion would get a lot more focused if the change co

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

Better JSC debugging in exchange for worse debugging in non-JSC code that calls through to WTF is not a great tradeoff. Is there a way to localize this change to only JSC? Do we know for sure that this change would get stress tests running, or are we just guessing? Can we find out? It’s easier

Re: [webkit-dev] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

;https://www.webkit.org/meeting> and > make sure the pages says "2019 WebKit Contributors Meeting". After that, try > logging in and register again. The "https://webkit.org/auth/wregister > <https://webkit.org/auth/wregister>" is not used for registration

Re: [webkit-dev] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

https://webkit.org/auth/wregister Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at ad...@webkit.org to inform them of the time this error oc

Re: [webkit-dev] Drop x86 (32bit) JIT backend

No objection. Geoff > On Sep 13, 2019, at 1:39 PM, Yusuke Suzuki wrote: > > Hello all, > > Now, Xcode no longer has ability to build 32bit binary. > Fedora starts dropping x86 32bit kernel shipping. > Our x86/x86_64 JIT requires SSE2, so such CPUs can use JIT if they want by > switching x86 t

Re: [webkit-dev] JavaScriptCore to C++ JSLock questions

Hi Werner. There’s no API around this. If you’re sure you don’t need thread safety, you can probably manually change JavaScriptCore not to do that locking. Geoff > On Feb 15, 2019, at 6:54 AM, Werner Sharp wrote: > > Hi everyone, > > I’m working on a project that uses JavaScriptCore in inte

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

FWIW, I’ve always felt conflicted about this case. I very much prefer early return to if/else chains. However, “return f()” when f returns void is a bit mind bending. So, I can’t use my preferred style in functions that return void. Boo. Geoff > On Feb 7, 2019, at 12:47 PM, Daniel Bates wrot

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

>>> So hard to pronounce though! Why not UniqueString? It’s not quite as >>> explicit but close enough. >> >> Wouldn’t it be confusing to use UniqueString type for a string that is >> *common* in order to save memory? > > I would interpret it as UniqueString(foo) means “give me the unique copy

Re: [webkit-dev] Watch out for std::optional's move constructor

ng our own >> std::optional replacement. If we care about the state of a moved-from >> object, that is what std::exchange is for. I think we should do something >> to track and prevent the use of moved-from values instead of introducing our >> own std::optional replaceme

Re: [webkit-dev] Watch out for std::optional's move constructor

I don’t understand the claim about “undefined behavior” here. As Maciej pointed out, these are our libraries. We are free to define their behaviors. In general, “undefined behavior” is an unwanted feature of programming languages and libraries, which we accept begrudgingly simply because there a

Re: [webkit-dev] Watch out for std::optional's move constructor

> This expression WTFMove(*m_pendingWebsitePolicies) doesn't move > std::optional, but moves the content of the > std::optional, WebsitePoliciesData. I think your proposal doesn't work for > this code. The original code, which asserted, did this: if (auto pendingWebsitePolicies = WTFMo

Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

Honest question: What’s gross about using @font-face? It would be lots of test edits. That’s a bummer. But maybe it’s clearer for the tests to specify the font they want to use. It makes the test self-describing, eliminating the requirement that the user take a step outside the test to get the

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

> Interestingly, the improvement is not so large. In Linux box, it was 2x. But > in macOS, it is 15%. Is there something Linux-specific about CLoop or LLInt, or is this a compiler difference? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.

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

FWIW, this problem is caused by unified sources *and* precompiled headers. > 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

Re: [webkit-dev] bmalloc design question about relation with std malloc

If we have just a few allocations, we should use the mmap based allocator. This preserves the invariant that bmalloc can be used as a general-purpose malloc implementation. If we have lots of small allocations, we should probably reconsider the design. I’m not familiar with the new uses of std:

Re: [webkit-dev] Proposal: Do not support Windows fibers

If our Windows clients are cool with it, I think we should remove support for fibers. I don’t think our current implementation works super well with fibers. It is best not to include half-working code in the tree. Geoff > On Dec 5, 2017, at 11:19 AM, Michael Saboff wrote: > > Here is the rep

Re: [webkit-dev] RFC: Removing feature flag defaults in build-webkit

r=me Geoff > On Sep 21, 2017, at 11:54 AM, Tim Horton wrote: > > Hi, all! > > Would anybody mind if build-webkit stopped being a source of default values > of feature flags? > > We have defaults for feature flags in FeatureDefines.xcconfig for Xcode, > WebKitFeatures.cmake (and Options*.cma

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)

> - have code completion and symbol navigation work very nicely in Xcode Unified builds will likely make this work better. Fun fact about Xcode: The way it does symbol indexing for symbols in a header is that it compiles the header with a random .cpp and indexes the result. The more stuff in yo

Re: [webkit-dev] Breakpoints in #included .cpp files [Was: 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)]

Aug 29, 2017 at 8:48 PM, Simon Fraser <mailto:simon.fra...@apple.com>> wrote: > > On Aug 28, 2017, at 9:46 PM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: > > > >> The line numbers and filenames will be total nonsense if we just > >> con

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)

approximate the answer by benchmarking svn up for individual revisions. Geoff > On Aug 29, 2017, at 2:21 PM, Dan Bernstein wrote: > > > >> On Aug 29, 2017, at 1:39 PM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: >> >>> I see. The right question

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)

> I see. The right question to ask would have been how much change occurs in > their working copy between consecutive incremental builds. If you want to help make our benchmark righter, please do share any data you have about the average content of an incremental build that is distinct from a d

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)

>> We have some preliminary data that says incremental builds will be OK, but >> not a full benchmark. >> >> Here’s a full benchmark I propose to test incremental builds: >> >> Start 7 days ago in SVN history. Do a clean build. >> >> SVN update forward by 24 hours. Do an incremental b

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)

> This isn’t the scenario I find myself in most often. A much more common > scenario is working on a change; touch one or two files, and then compile and > test/debug. Rinse and repeat. We’ve already tested this case. The worst case slowdown, if you touch a small file that's in the same bundl

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)

> I worry about adopting unity build because while it makes clean builds > faster, it also slows down incremental builds. As a developer, I rarely do > clean builds, I mostly do incremental builds so this would likely make my > experience worse? We have some preliminary data that says increment

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)

> I wonder whether the unified sources builds would still allow us to > keep using compiler caches like ccache. Our plan is to use ccache. > Second question/caveat is, wouldn't the bundle build penalize too much > incremental builds? If your data is correct we would get a <20% build > time increm

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)

> The line numbers and filenames will be total nonsense if we just concatenate > multiple source files together. But that's very easy to fix if the script > that concatenates the sources also adds a #line statement between "files" to > change the filename and reset the line number to 1. See > h

Re: [webkit-dev] Question regarding per-file BSD license text

> My understanding is that if a non-Apple contributor adds a new file, their > affiliation should only be reflected in the copyright line and NOT in the BSD > license text itself (which reads "APPLE INC."), because the latter is a > "per-file copy of a project-wide license". Could someone confir

Re: [webkit-dev] Removing support for CSS regions

>> Given my concern is the compatibility, not the maintenance cost, what >> is the evidence that nobody is relying on this feature? It’s difficult to prove a negative. Impossible, in fact. Can anyone present evidence of a major client of CSS regions? If not, I think that lack of evidence — in co

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

Another minor comment: it seems like this new API returns raw data. It seems like the native way to use this would result in running untrusted data from the network through image decoders outside the Web Process sandbox. Do we have a way to avoid that? >>> >>> This came up w

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

>> Another minor comment: it seems like this new API returns raw data. It seems >> like the native way to use this would result in running untrusted data from >> the network through image decoders outside the Web Process sandbox. Do we >> have a way to avoid that? > > This came up while impleme

Re: [webkit-dev] Port WebKit to GNUstep

No. The bar is much higher for introducing a new port to WebKit. Geoff > On May 11, 2017, at 7:54 PM, Daniel Ferreira (theiostream) > wrote: > > Hi there, > > My name is Daniel Ferreira and as a Google Summer of Code project I > decided to tackle the ten-year-long[1] effort of porting WebKit

Re: [webkit-dev] Performance Difference between Webkit and Wekit2 API's

Though I don’t have specific numbers to share, WebKit2’s design generally provides much better performance under these conditions: (1) Faster: Long-running JavaScript programs on iOS; (2) Faster and smoother: Scrolling; (3) Faster and smoother: More than one webpage open at once; (4) Less memo

Re: [webkit-dev] Another WPT bite

> Another concern is the ease of running tests for developers: drag&dropping > tests into a browser instead of running a server. Yeah, it’s a pretty big concern if you can’t just drop a simple test case into a browser. > We can partially accommodate this by rewriting > testharness.js/testharne

Re: [webkit-dev] Another WPT bite

> What we're suggesting is to give preferential treatments to > testharness.js over js-test.js / js-test-pre.js when you were already > planning to write a test with the latter two scripts. OK, I think this makes sense. But I still think the very best kind of test is a flat file with 10-20 lines

Re: [webkit-dev] Another WPT bite

> Is it time to make testharness.js the recommended way of writing LayoutTests? What are the costs and benefits of testharness.js? We usually try to make regression tests reductions of some larger problem to aid debugging and to make testing fast. But testharness.js is 95kB. That's kind of the

Re: [webkit-dev] !!Tests for equality comparison

> but == should be used for testing things where 0 is just another number, like > indexes: > > if (index == 0) >… The index case is especially annoying because we use -1 to indicate notFound, so !index means “the first valid index” rather than “no index”. It’s pretty odd to think of false

Re: [webkit-dev] !!Tests for equality comparison

>> On Apr 27, 2017, at 16:30, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: >> >> I’ve never really liked this style rule, and I’ve always felt like it snuck >> into the style document without much discussion. > > It date from 2009: https://bugs.

Re: [webkit-dev] !!Tests for equality comparison

I’ve never really liked this style rule, and I’ve always felt like it snuck into the style document without much discussion. Even so, I usually tolerate it. Geoff > On Apr 27, 2017, at 4:06 PM, JF Bastien wrote: > > Hello C++ fans! > > The C++ style check currently say: > Tests for true/fals

Re: [webkit-dev] Proposal: upstream the WPE port

I think the biggest consideration here is the problems we’ve noticed in the C API that have produced poor designs that we don’t intend to support going forward. Does the WPE port’s API need to be backwards-compatible in a source or binary way? Is it practical for the WPE port’s API to mirror t

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

quot;RangeError: Maximum call stack size exceeded”) >> e.stack lines according to editor = 10 frames >> >> 2. Firefox >> test reported reentry count = 222044 >> split(…).length = 129 (probably because there’s an extra newline in >> there somewhere) >

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

script/reference/stacktracelimit-property-error-javascript>). > Firefox does now. > > Does anyone object to us adopting Error.stackTraceLimit and setting the > default to 10 to match Chrome? > > Mark > > > >> On Mar 16, 2017, at 11:29 PM, Geoffrey Garen > &

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Can you be more specific about the motivation here? Do we have any motivating examples that will tell us wether time+memory were unacceptable before this change, or are acceptable after this change? In our motivating examples, does Safari use more time+memory than other browsers? If so, how lar

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:16 PM, Filip Pizlo wrote: > > >> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen wrote: >> >> I’ve lost countless hours to investigating CrashTracers that would have been >> easy to solve if I had access to register state. > >

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

I’ve lost countless hours to investigating CrashTracers that would have been easy to solve if I had access to register state. I also want the freedom to add RELEASE_ASSERT without ruining performance due to bad register allocation or making the code too large to inline. For example, hot paths i

Re: [webkit-dev] CSS Parse error in element.

+Alex > On Feb 3, 2017, at 1:17 AM, Atul Sowani wrote: > > At present I am focusing on CSSParser::findURI() particularly and > CSSParser::realLex() other related functionality in CSSParser.cpp - hope I am > on right track. ;-) > > Please let me know if I should be looking at some other functi

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> My take-away from this discussion so far is that there is actually very >> little consensus on usage of auto, which means there’s probably very little >> room for actual style guideline rules. >> >> I think there are two very limited rules that are probably not objectionable >> to anybody. >

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> e.g. I think this is great: >> auto ptr = std::make_unique(bar); >> Proposed rule: if the type is obvious because it's on the line, then auto is >> good. >> Similarly: >> auto i = static_cast(j); >> auto foo = make_foo(); >> auto bar = something.get_bar(); // Sometimes, "bar" is obvious. > I'm

Re: [webkit-dev] [webkit-reviewers] usage of auto

I’m open to auto, but skeptical. (1) Research-ability. I read a lot of code that is new to me, that I have never written. I find type statements to be useful as documentation for where to look for more information about how data structures and algorithms relate to each other. Traversing a tree

Re: [webkit-dev] Thread naming policy in WebKit

Alternatively, we could just change thread name from a char* to a struct { char*, char* } that contains a long name and a short name. Geoff > On Jan 5, 2017, at 9:37 AM, Brady Eidson wrote: > >> >> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI > > wrote: >> >> On T

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

EncodedJSValue was always just a work-around to convince the compiler to put a JSValue in registers (instead of on the stack, with different compilers disagreeing about where on the stack). I agree with removing EncodedJSValue if possible. Did something change to make this possible? For example

Re: [webkit-dev] Please hold off on commits

I’m sorry to say that, as of this morning, we’re still holding off on commits. EWS and some Mac performance bots are back online, but some Mac performance bots and all iOS performance bots are still down. Geoff > On Nov 5, 2016, at 12:23 PM, Maciej Stachowiak wrote: > > > Hello everyone, >

Re: [webkit-dev] Asserting versus throwing in internals and testRunner objects

I vote for throwing a JS exception. In my experience, tests that crash are harder to deal with than tests that throw JS exceptions. A backtrace is a less informative than the message “you called internals.X without a frame”. Symbolication takes a long time. And sometimes we have trouble associa

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

“take” grinds my gears too — though I’ve gotten used to it, more or less. I read “object.verb()” as a command, “verb”, directed at “object” (or sometimes as a question, “verb?”, directed at “object”). I think most APIs are phrased this way. And if I were Antonin Scalia, I would make the original

Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

👍 To make this policy easy for new folks, I agree with Ryosuke that we should extract a JS and CSS style guide that is separate from Inspector-specific concerns. Geoff > On Jul 6, 2016, at 10:17 PM, Filip Pizlo wrote: > > I like the idea of adopting inspector style for JS builtins! > > It m

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

>> Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and >> “MonotonicTime"? Clock is a nice clear noun. Also, time is an illusion >> caused by parallax in the astral plane. > > I think time is the right term. "3pm" is a "time", not a "clock". Also 42 > seconds since monoton

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

> 3 - There exists a solution - non-templated custom classes - that removes > both classes of subtle bugs, without the template creep. Hard to argue with this. Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and “MonotonicTime"? Clock is a nice clear noun. Also, time is an

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

Since double is not a user-defined type, my understanding is that your template specializations in the std namespace are undefined behavior. Geoff > On May 22, 2016, at 10:46 PM, Michal Debski wrote: > > Hi, > > sorry but this really bugs me. Isn't this enough? > > namespace WTF { > > usi

Re: [webkit-dev] Importing Test262 into WebKit

Is that 20min even when running in parallel (i.e., about 80min when running serially)? That’s…. a lot. How much time is that per test? Geoff > On May 12, 2016, at 4:02 PM, Keith Miller wrote: > > Hi everyone, > > For those of you that have not already heard of Test262, it is a continually >

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

> On Apr 18, 2016, at 2:08 PM, Michael Catanzaro wrote: > > On Mon, 2016-04-18 at 22:36 +0300, Konstantin Tokarev wrote: >> Are there any objections for lowering GCC requirement from 4.9.0 to >> 4.8.4 (only for JavaScriptCore without B3)? I'm going to fix arising >> compilation errors myself. >

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 >> (only for JavaScriptCore without B3)? I'm going to fix arising compilation >> errors myself. Yes. We want to move forward in C++ language support, not backward. Any platform not worthy of native compiler developmen

Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

+1 Geoff > On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak wrote: > > > The recently released Safari Technology Preview has gotten more people living > on builds close to trunk, which is cool. Some people pointing out that the > current state of Fetch API causes problems - it's not quite com

Re: [webkit-dev] Mac CMake

> Just out of curiosity, is there any chance that Apple Mac WebKit > will be migrated to cmake within the foreseeable future? Based on initial experiments, I'm interested in CMake. We (Alex, really) haven’t had the time to finish the Mac CMake build and/or do a complete head-to-head comparison w

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

I volunteer for any future needs in the physical restraint department -- but in this case, I think (3) sounds like a good idea. Geoff > On Mar 3, 2016, at 11:35 AM, Darin Adler wrote: > > OK! > > Do we have volunteers to: > > 1) update the style guide webpage > 2) update check-webkit-style >

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

I like this change. Perhaps all ports can adopt this behavior. Geoff > On Feb 8, 2016, at 11:55 AM, Mark Lam wrote: > > Hi WebKit folks, > > For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s > implementation into an inlined function that has a single inlined asm > statem

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

> Seems like we should not have to wait long for the “long term”. It seems that > the built-in compiler could start magically transforming “@undefined” instead > of magically transforming “undefined” any time we like; likely a simple find > and replace job. Or it could do both during a transitio

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

For the time being, I like “x === undefined”. Long term, I’d like us to switch to “x === @undefined”. We use @ to indicate reserved words in built-ins. Currently, “@undefined" does not exist, but the built-in compiler magically transforms “undefined” a safe reserved word. The typeof and void 0

[webkit-dev] The great commit queue experiment

Hi folks. A bunch of us at the WebKit Contributors Meeting decided that we will spend the next week landing 100% of our patches through the commit queue. Please feel free to play along at home. If we see problems, we’ll document our experiences here: This is why I love or hate the comm

Re: [webkit-dev] Thought about Nix JavaScriptCore port

I think it would be nice to avoid tying the Nix build to update-webkitgtk-libs, since part of the stated goal is platform freedom. Geoff > On Nov 11, 2015, at 2:15 AM, Sergio Villar Senin wrote: > > On 11/11/15 08:04, Yusuke SUZUKI wrote: >> Hello WebKittens, >> >> JavaScriptCore use in non-O

Re: [webkit-dev] Mac CMake

👍 > On Oct 30, 2015, at 2:17 PM, Alex Christensen wrote: > > I got the Mac CMake build to the point where it can compile and link > frameworks successfully. We will get a buildbot up soon, but in the meantime > please try to add and remove files in the CMake build.Let me know if you have > an

Re: [webkit-dev] Using JavaScriptCore in an audio context

> A more general question could be : would Apple allow applications developers > to use the fantastic power of LLVM tools and libraries in a "safe" way ? That > would be an interesting line of work… That’s not a question for the webkit-dev list. Geoff ___

Re: [webkit-dev] (Legacy 2.1.1) LLINT: _llint_program_prologue CodeBlock::m_instructions[0] is NULL

The CodeBlock constructor is responsible for filling m_instructions. I’d start there. Geoff > On Aug 26, 2015, at 9:46 AM, Bryan Woodruff wrote: > > Apologies in advance for cross-posting – not seeing any activity on > webkit-help. > > Caveat: Due to divergence in the code base and the targ

Re: [webkit-dev] [webkit-changes] [187867] trunk/Tools

Saam’s true patch count is 91. Geoff > On Aug 4, 2015, at 11:07 AM, Geoffrey Garen wrote: > > Mark, > > While I am excited about Saam becoming a reviewer soon, this is the wrong > process. > > Please roll out this change and follow the procedure explained at > ht

Re: [webkit-dev] [webkit-changes] [187867] trunk/Tools

Mark, While I am excited about Saam becoming a reviewer soon, this is the wrong process. Please roll out this change and follow the procedure explained at https://www.webkit.org/coding/commit-review-policy.html. Thanks, Geoff > On Aug 4, 2015, at 11:03 AM, mark@apple.com wrote: > > Revis

Re: [webkit-dev] Contributing to webkit Open Source project

Hi Mukesh. Welcome to the project. How did your project turn out? If it was successful, the best place to start is to post patches to bugs.webkit.org . Another important project we’re working on right now is finishing our implementation of ES6. A quick way to get a lis

Re: [webkit-dev] Infinite JavaScript loop blocks the MiniBrowser

Mark, do you know how to restart JavaScript after it has reached a watchdog time limit? Geoff > On Jul 28, 2015, at 9:09 AM, Pascal Jacquemart > wrote: > > Hello, > > I am trying to protect the MiniBrowser from executing faulty JavaScript code > taking too much time / CPU. All browsers norm

Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

y, at least) for the Web case. Or are you > saying it would have a fallback runloop for non-Web contents? > > Regards, > Maciej > >> On Jul 6, 2015, at 3:24 PM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote: >> >> I think it would be better for J

Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

I think it would be better for JavaScriptCore to handle micro tasks natively. It’s not so great for each client to need to reinvent the microtask runloop abstraction. Geoff > On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI wrote: > > Hi WebKittens, > > I've landed the update of the ES6 Promise im

Re: [webkit-dev] Invocation with undefined this on JS binding object

Hi Xabier. Our bindings assume, by default, that the ‘this’ parameter passed to any DOM interface is an object of the interface’s type. This is how most DOM bindings work. Our bindings also assume that a requested property can be read from the ‘this’ object, which represents the DOM interface.

Re: [webkit-dev] JavaScriptCore cross context object sharing

> The documentation for JSContextGroupCreate states that "Contexts in the same > group may share and exchange JavaScript objects.” How is this done? Your C code can take a JSObjectRef from one context and use JSObjectSetProperty on another context’s global object in order to make the JSObjectRe

Re: [webkit-dev] JavaScriptCore: Garbage Collector Issue

Hi Max. The best way to get help with a potential bug in JavaScriptCore is to post example code that reproduces the bug to bugs.webkit.org. > I wrote a XCTest in Xcode which performs multiple calls of the JavaScript > library (with loops) but it always stops or freezes after the 292nd call. Ca

Re: [webkit-dev] virtual and override

Bokay. Geoff > On Feb 20, 2015, at 4:11 AM, Antti Koivisto wrote: > > We have traditionally marked virtual overrides with the 'virtual' keyword for > documentation purposes. Nowadays we also have the compiler checked > 'override'. Using both at the same time seems redundant. > > Should we ch

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

> I noticed that Apple Windows port turned off FastMalloc 1.5 years > ago (r156933) due to some issues. Is there any plan to port bmalloc > to Windows too to use the same allocator on all ports? Yes, I’d like to port bmalloc to Windows. Geoff ___ webkit

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

> To help to go ahead, I upload a patch to enable bmalloc on EFL port as well > as to remove TCMaclloc in CMake. Thanks! Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

It’s been about a month since I sent this notice, and it looks like bmalloc works on at least one version of Linux, so I’m going to remove TCMalloc in the next few days. Regards, Geoff > On Jan 6, 2015, at 4:00 PM, Geoffrey Garen wrote: > > Hi folks. > > We’ve been using bma

Re: [webkit-dev] Unused parameter warnings / errors / warning fixes

> Are there reasons any or all of these shouldn't be written as macros? Yes: Macros are terrible. Darin mentioned to me in person a way to resolve the problems I listed. I’ll follow up with a patch soon. Geoff___ webkit-dev mailing list webkit-dev@lis

Re: [webkit-dev] Unused parameter warnings / errors / warning fixes

> And I do agree that it can be inconvenient to deal with these warnings in > heavily #ifdef’d code. I think there are some good strategies for avoiding > that, and I’d like to talk about specific irritating cases so I can propose > the strategy I’d push for. Generally the strategy is to push mo

  1   2   3   4   5   >