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,

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

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

[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

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

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

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

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,

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

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

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

k 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 >> >>> On J

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

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

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

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!

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

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

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

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

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

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

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 replacement. >> >&g

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

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 =

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

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:

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

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

; > > > On Tue, Aug 29, 2017 at 8:48 PM, Simon Fraser <simon.fra...@apple.com > <mailto:simon.fra...@apple.com>> wrote: > > On Aug 28, 2017, at 9:46 PM, Geoffrey Garen <gga...@apple.com > > <mailto:gga...@apple.com>> wrote: > > > >> Th

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)

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

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

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

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

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

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

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 >

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

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

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

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

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]

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

Re: [webkit-dev] Another WPT bite

> Another concern is the ease of running tests for developers: drag > 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 >

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 <gga...@apple.com >> <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

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:

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

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

; split(…).length = 129 (probably because there’s an extra newline in >> there somewhere) >> e.stack lines according to editor = 128 frames >> >> 3. Safari >> test reported reentry count = 31701 >> split(…).length = 31722 (I don’t know why

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

osoft.com/en-us/scripting/javascript/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 1

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

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

> On Feb 22, 2017, at 12:16 PM, Filip Pizlo <fpi...@apple.com> wrote: > > >> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen <gga...@apple.com> wrote: >> >> I’ve lost countless hours to investigating CrashTracers that would have been >> ea

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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 -

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

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

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

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

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

[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

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

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

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 bryan.woodr...@boxspy.com wrote: Apologies in advance for cross-posting – not seeing any activity on webkit-help. Caveat: Due to divergence in the

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

, and Saam’s true patch count is 91. Geoff On Aug 4, 2015, at 11:07 AM, Geoffrey Garen gga...@apple.com 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 https://www.webkit.org

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:

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 http://bugs.webkit.org/. Another important project we’re working on right now is finishing our implementation of ES6. A quick way to get a list

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 p.jacquem...@samsung.com wrote: Hello, I am trying to protect the MiniBrowser from executing faulty JavaScript code taking too much time / CPU.

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

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 gga...@apple.com mailto:gga...@apple.com wrote: I think it would be better for JavaScriptCore to handle micro tasks natively. It’s not so great

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 utatane@gmail.com wrote: Hi WebKittens, I've landed the update of

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 JSObjectRef

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

Re: [webkit-dev] virtual and override

Bokay. Geoff On Feb 20, 2015, at 4:11 AM, Antti Koivisto koivi...@iki.fi 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.

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

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

. To use bmalloc on EFL port, I file a new bug 140162 for now. When patch is ready, I will upload it to the bug. Thanks, Gyuyoung On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com javascript:_e(%7B%7D,'cvml','gga...@apple.com'); wrote: Hi folks. We’ve been using bmalloc

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

Hi folks. We’ve been using bmalloc on Mac and iOS for some time now, and it is fast and stable. Is there a Linux maintainer who would like to take on enabling bmalloc on Linux? The implementation is Unix-y, so it should “just work”. I can advise on this project, but I don’t have a Linux build

Re: [webkit-dev] If you like writing memory smashers, you'll love this

As of r177317, FastMalloc can be disabled at runtime. This means that you can use system memory analysis tools like GuardMalloc, MallocScribble, Instruments allocation tracking, leaks, and heap to debug memory issues in WebKit nightly builds, spade builds, and release builds. Is this in

Re: [webkit-dev] If you like writing memory smashers, you'll love this

But zone introspection isn’t enough to get malloc/free backtraces, which is what you need in order to to do leaks analysis and allocation tracking. (And, of course, TCMalloc didn’t support scribbling, guard edges, guard malloc, and so on.) http://trac.webkit.org/changeset/153767

Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

, at 8:11 PM, Geoffrey Garen gga...@apple.com wrote: Hi Ian. From looking at the source, it tries to drop all locks from the current javascript VM before calling the delegate, and when it does that it asserts if the VM is busy garbage collecting. That’s right. I'm guessing there needs

[webkit-dev] If you like writing memory smashers, you'll love this

As of r177317, FastMalloc can be disabled at runtime. This means that you can use system memory analysis tools like GuardMalloc, MallocScribble, Instruments allocation tracking, leaks, and heap to debug memory issues in WebKit nightly builds, spade builds, and release builds. FastMalloc

Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

Hi Ian. From looking at the source, it tries to drop all locks from the current javascript VM before calling the delegate, and when it does that it asserts if the VM is busy garbage collecting. That’s right. I'm guessing there needs to be some sort of guard there to make sure the VM

  1   2   3   4   >