Adobe (Hacker News, MacRumors):
But as open standards like HTML5, WebGL and WebAssembly have matured over the past several years, most now provide many of the capabilities and functionalities that plugins pioneered and have become a viable alternative for content on the web. Over time, we’ve seen helper apps evolve to become plugins, and more recently, have seen many of these plugin capabilities get incorporated into open web standards. Today, most browser vendors are integrating capabilities once provided by plugins directly into browsers and deprecating plugins.
Given this progress, and in collaboration with several of our technology partners – including Apple, Facebook, Google, Microsoft and Mozilla – Adobe is planning to end-of-life Flash. Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.
Previously: Thoughts on Flash.
Update (2017-07-27): See also: John Nack, Dan Masters.
Adobe Adobe Flash Datacide Mac Sunset Web
Fogus (via Hacker News):
Lately I’ve been reading old computing papers, articles, journals, magazines, and memos and tweeting about them as I work my way through. The most recent exploration was of an Apple internal memo about the history of Apple’s involvement with Pascal. The memo is cursory, but it does provide an interesting snapshot of the history of Pascal within the company.
David Craig:
Apple II and III Pascal were based on UCSD Pascal, but Lisa Pascal and Macintosh MPW Pascal were based on the Wirth ETH Pascal and not UCSD Pascal. Lisa Pascal was licensed to Apple by Silicon Valley Software (SVS) which Apple maintained (Al Hoffman was Apple’s main Lisa Pascal developer).
[…]
Per my Pascal history, Jef Raskin was to my knowledge not involved in the actual Apple II Pascal development effort, but was involved in convincing Apple to use the UCSD Pascal System as its internal development system instead of BASIC or 6502 assembly language.
[…]
From my experience, the pros for Pascal were it provided a high-level development language which supported step-wise refinement and information hiding (i.e. units). Structured programing and separately compiled and loaded modules (i.e. UNITs) were very important here. Cons … Pascal not built into the Apple II and had to be purchased for several hundred dollars. Pascal also required 64K of memory which means you had to also purchase the Apple II 16KB Language Card. You also had to have a minimum of 2 140KB disk drives on your Apple II (each cost around $500 I recall). I had 4 disk drives for my Apple II Pascal efforts (3 drives were in my opinion the minimum but 4 made Pascal programming much easier and ended up saving time — typical tradeoff of $s versus time).
Apple II Bill Atkinson History Lisa Mac Pascal Programming Steve Wozniak
Mike Ash (Hacker News):
objc_msgSend has a few different paths it can take depending on circumstances. It has special code for handling things like messages to nil, tagged pointers, and hash table collisions. I’ll start by looking at the most common, straight-line case where a message is sent to a non-nil, non-tagged pointer and the method is found in the cache without any need to scan. I’ll note the various branching-off points as we go through them, and then once we’re done with the common path I’ll circle back and look at all of the others.
Greg Parker:
Incrementing to the end of the cache requires an extra instruction or two to calculate where the end of the cache is. The start of the cache is already known - it’s the pointer we loaded from the class - so we decrement towards that.
[…]
The extra scanned-twice check prevents power-draining infinite loops in some cases of memory corruption or invalid objects. For example, heap corruption could fill the cache with non-zero data, or set the cache mask to zero. Corruption like this would otherwise cause the cache scan loop to run forever without a cache hit or a cache miss. The extra check stops the loop so we can turn the problem into a crash log instead.
There are also cases where another thread simultaneously modifying the cache can cause this thread to neither hit nor miss on the first scan. The C code does extra work to resolve that race. A previous version of objc_msgSend handled this incorrectly - it immediately aborted instead of falling back to the C code - which caused rare crashes when the threads were unlucky.
Mike Ash:
However, Objective-C does not require objc_msgSend.
[…]
Instead of objc_msgSend, the runtime can provide a function which looks up the method implementation and returns it to the caller. The caller can then invoke that implementation itself. This is how the GNU runtime does it, since it needs to be more portable. Their lookup function is called objc_msg_lookup.
[…]
However, each call now suffers the overhead of two function calls, so it’s a bit slower. Apple prefers to put in the extra effort of writing assembly code to avoid this, since it’s so critical to their platform.
Louis Gerbarg:
It actually is not the extra function call that is the big hit, since if you think about it objc_msgSend also does two calls (the call to msgSend, which at the end then tail calls the imp). The dynamic instruction count is also roughly the same.
In fact objc_msgLookup actually ends up being faster in a some micro benches since it plays a lot better with modern CPU branch predictors: objc_msgSend defeats them by making every call site jump to the same dispatch function, which then makes a completely unpredictable jump to the imp. By using msgLookup you essentially decouple the branch source from the lookup which greatly improves predictably. Also, with a “sufficiently smart” compiler it can be win because it allows you to do things like hoist the lookup out of loops, etc (essentially really clever automated IMP caching tricks).
ARM Assembly Language Concurrency iOS iOS 10 Objective-C Objective-C Runtime Optimization Programming
David Sparks:
The best thing about this app is that it does the work for you. Timing provides automatic time tracking. As you jump around different applications, website URLs, emails, and even conversation partners in Messages, Timing quietly keeps track in the background. It then gives you an interactive timeline that shows you exactly when you did what. There’s even a rule system to take you even further down the road. There is a lot of data in this app that will shed new light on how you work.
Kirk McElhearn:
If you need to track your time, there are plenty of apps that can help you. Many of them are designed for freelancers who need to track billable time so they can invoice clients, but others track activity on your Mac, so you can know where your day has gone. Timing ($29, $49, or $79) combines both of these features, allowing you to easily start and stop projects, to know how much to bill, and also see which apps you use, and which websites you visit.
Daniel Alm:
This article illustrates how an app’s UI evolves during development, and highlights some subtle but important changes.
Timing looks nicer than RescueTime and, as a standalone app, does not upload your data anywhere.
Getting Things Done Hours App Mac Mac App Privacy RescueTime Time Tracking Timing
