bdash

I do agree that the choice of a narrower font for emphasized terms has the opposite effect from what is intended.

I'm impressed by Filip's knack for explaining complex topics in an approachable manner. His previous post on WebKit's locking infrastructure[1] is a similarly good read.

A few amusing parts of this post that stood out to me:

* A single sentence containing half a dozen links to Filip's previous work on garbage collection.

* "See here for the proof", linking to a 200+ line comment in WebKit's source.

* "But since this is JavaScript, we get to have a lot more fun".

[1]: https://webkit.org/blog/6161/locking-in-webkit/

JavaScriptCore code is either LGPL or BSD licensed, depending on whether it derives from the original KJS source base or is new code written by Apple. There's no APSL code in JavaScriptCore last I checked.

From the link you shared:

> Safari on _OS X_ supports WebDriver, which lets you automate web-content testing.

I don't see any mention of iOS in relation to WebDriver.

Note that Git ships with Xcode, not part of OS X itself. Xcode 7.3.1 updated Git to v2.7.4. Xcode 8, likely to GM in the next month or two, includes Git v2.8.4.

I believe that toggling a boot-arg only disabled SIP on early developer betas of OS X 10.11. For shipping releases of El Capitan you need to use csrutil from the recovery partition as a parent comment mentioned.

The Safari Tech Preview is a full-fledged copy of Safari that bundles its own WebKit frameworks rather than using the system frameworks. As it's a separate application it can have a different name, and use an independent copy of preferences, history, bookmarks, etc. from the system version of Safari.

WebKit nightly builds run your system version of Safari with an updated version of the WebKit frameworks. This means that the application you're running is your normal version of Safari. The WebKit nightlies do some shenanigans to convince the system to do things like display a different Dock icon, for instance, but for the most part they just let Safari be Safari.

In practice neither GCC nor Clang seem to be willing to believe that the vtable is immutable. See https://goo.gl/y0cx1r, for example, which shows only the first of two calls being devirtualized. The call to fprintf within B::work is sufficient to cause to both compilers to reload the vtable pointer, preventing devirtualization of the second call.

Interestingly enough, when a use of placement new is visible to the compiler it can prevent the conservative behavior mentioned above. In https://goo.gl/Y8rwYG the vtable store that placement new conceptually generates allows Clang to devirtualize the second virtual call. GCC doesn't appear to catch this case.

The benchmark page of the pybind11 documentation [0] compares build times and generated library size with Boost.Python.

[0] http://pybind11.readthedocs.org/en/latest/benchmark.html

Currying refers to the process of taking a function that accepts multiple arguments, and turning it into a sequence of functions, each accepting a single argument. The example you provide would be more aptly described as partial application, which is the process of fixing a number of arguments to a function, producing a function of smaller arity.

Its based on http://presentz.org, which sadly appears to no longer be maintained.

The plug-in provides a scripting interface that's only available to pages hosted via HTTPS on apple.com. The scripting interface exposes whether Safari is the default browser, and allows for prompting the user to change their default browser. To my knowledge the only place this was used was a "Welcome to OS X Mavericks" page that was shown shortly after installation of that version of OS X. I doubt that it's been used since.

The "Default Browser" plug-in is not responsible for the notification mentioned in that tweet. The plug-in has no opportunity to execute code when Firefox is launched, only when instantiated by a web page.

Besides, there's no need for a browser plug-in to detect when Firefox is run: the LaunchServices framework responsible for launching applications on OS X can simply check whether the application it is launching appears to be a web browser.

The vtable-based dispatch (described in detail at http://www.sealiesoftware.com/blog/archive/2011/06/17/objc_e...) is no longer in use.

Neat! One of the projects that I wrote when learning Rust was a BrainFuck interpreter and JIT for x86_64[1]. Interestingly, my JIT appears to be run some programs (e.g., mandelbrot.bf[2]) significantly faster than the versions compiled by bfc. That's despite including the optimization and code generation overhead in the timings of my JIT, but excluding them from bfc.

[1]: https://github.com/bdash/brainrust [2]: https://github.com/bdash/brainrust/blob/master/examples/mand...

The supported mechanism for disabling System Integrity Protection is via the recovery partition.

Apple has stated that the "rootless=0" boot argument to disable System Integrity Protection is temporary and will be gone in the GM version of El Capitan. Allowing this route to disable the feature would defeat the entire purpose of it.

Many JavaScript engines use IEEE-754 double-precision floats as their immediate value type, and fit pointers and integer within the NaN payload of the double representation. See https://wingolog.org/archives/2011/05/18/value-representatio... for a discussion of a few similar approaches and the tradeoffs of each.

The tag bits are zero when using the pointer as a pointer, so nothing special needs to be done in order to dereference them. The tag bits are only non-zero when non-pointer data is packed into the pointer, and in that case you inherently need special handling anyway.

We had a similar problem to solve for iOS and OS X and settled on the using FIFOs in that manner as well. A colleague wrote up a blog post about the various alternatives that were evaluated before settling on that approach: https://realm.io/news/thomas-goyne-fast-inter-process-commun...

I hadn't considered that you were focused on historical versions of WebKit as I was thinking of the latest shipping versions. You're quite correct about this for historical versions of iOS. Since then the iOS port of WebKit has been upstreamed into the WebKit SVN repository, and the WebCore content in the tags correspond exactly to the source that's built.

> it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.

They're all at http://trac.webkit.org/browser/tags/. You can map from the LC_SOURCE_VERSION baked into one of WebKit's frameworks back to one of those tags.

I'd love to try and get to the bottom of the Safari performance issues you're seeing. My email address is in my profile, please drop me a line if you wouldn't mind.

The kernel is actually a hybrid of Mach and FreeBSD. See http://en.wikipedia.org/wiki/XNU for details.

Is node-webkit going to be renamed to node-blink at some point? It seems misleading to continue using WebKit in the name when it's not been based on WebKit for quite some time.

Small nit: the website uses a <video> element and only provides an Ogg Theora video. This means that the video isn't visible in Safari on OS X and iOS, or in Internet Explorer on Windows. In Safari on OS X this results in an empty set of controls being visible for the video element. In Safari on iOS I see a non-functional play button where the video would be. Furthermore, since the <source> element doesn't have a type attribute browsers have no way of knowing up front that they can't play the video and are forced to start loading the video to determine if it's playable.

Private windows continue to respect the user's search engine preference.

To be pedantic, WKWebView from the new, modern WebKit API, gets access to the JIT. The existing UIWebView does not.

Have you filed a bug report about Safari overwriting prepopulated fields? If not, and you don't want to deal with the painful experience that is bugreport.apple.com, feel free to drop me an email with more details about what you're seeing.

As of OS X 10.9.2 and iOS 7.1 the setting has been removed and autocomplete=off is always ignored.