John Holdsworth (tweet):
The Injection plugin for Xcode is now a standalone app. This allows you to inject changes to class method implementations into a running application in the simulator or a macOS app. Injecting is now as simple as downloading the app and having it running in the background while you are working on a project in Xcode then using the menu bar item “Inject Source” (don’t forget to save the file!)
[…]
The app includes the “Xprobe” viewer for browsing an application’s memory.
It’s loaded into an app using the “Load Xprobe” menu bar item. Initially, Xprobe
displays a “sweep” of objects found by recursively following ivars pointing to other
objects from a set of seeds. Clicking on an instance link displays the ivars of that
object at that point in time. A snapshot can also be taken to freeze the state of the
entire application and store it as a standalone web page for later analysis such as
this file from Artsy’s
eidolon.
Developer Tool iOS iOS 10 Mac macOS 10.12 Sierra Programming Swift Programming Language Swift Runtime Xcode
Russell Ivanovic:
No worries you might say, go to Apple and buy a new Mac mini! Except when you do, you quickly realise there’s something up with the Mac Mini[…] Yes that’s right, it hasn’t been updated in 813 days…and the last update Apple made to them was mostly a downgrade in terms of performance. No one except the most desperate of people should even consider buying one of these things. The fact that Apple will still happily sell you a 2-3 year old computer for new prices is beyond insulting.
With the above in mind, I asked myself a question I haven’t really considered since switching to macOS (the artist formerly known as OS X) back in the early 2000’s. Do I actually need this computer to run macOS? I quickly realised I don’t. I need Chrome, I need a few basic apps and I need my Elgato EyeTV Diversity USB stick to be supported so I can watch TV. It turns out there’s another OS that has all those: Windows.
Update (2017-05-07): Russell Ivanovic:
Out of the box a few things struck me. Firstly: Just how small it was. If that iPhone 7 above doesn’t give you an idea, here it is sitting on top of my old Mac Mini.
Intel Mac Mac mini Windows
Archie Russell (via Hacker News):
One of the largest cost drivers in running a service like Flickr is storage. We’ve described multiple techniques to get this cost down over the years: use of COS, creating sizes dynamically on GPUs and perceptual compression. These projects have been very successful, but our storage cost is still significant.
At the beginning of 2016, we challenged ourselves to go further — to go a full year without needing new storage hardware. Using multiple techniques, we got there.
[…]
Because we were concerned that further rollout of dynamic thumbnail generation would place a heavy load on our resizing infrastructure, we targeted only thumbnails from less-popular images for deletes. Using this approach, we were able to handle our complete resize load with just four GPUs. The process put a heavy load on our storage systems; to minimize the impact we randomized our operations across volumes. The entire process took about four months, resulting in even more significant gains than our storage threshold adjustments.
[…]
Running our users’ original photos through lossless compression was probably our highest-risk approach. We can recreate thumbnails easily, but a corrupted source image cannot be recovered. Key to our approach was a re-compress-decompress-verify strategy: every recompressed image was decompressed and compared to its source before removing the uncompressed source image.
Previously: Real-time Resizing of Flickr Images Using GPUs.
Update (2017-01-30): I don’t know whether this is related, but Flickr is now showing thumbnails from other people’s photos in our private album.
Compression Flickr JPEG Optimization Web
Dave Abrahams and Ben Cohen (mailing list):
The first step in improving this [internationalization] situation is to regularize all localized operations as invocations of normal string operations with extra parameters.
[…]
When assigning a Substring to a longer-lived variable (usually a stored
property) explicitly of type String, a type conversion will be performed, and
at this point the substring buffer is copied and the original string’s storage
can be released.
[…]
With Substring and String being distinct types and sharing almost all
interface and semantics, and with the highest-performance string processing
requiring knowledge of encoding and layout that the currency types can’t
provide, it becomes important to capture the common “string API” in a protocol.
Since Unicode conformance is a key feature of string processing in Swift, we
call that protocol Unicode[…]
[…]
Index interchange between String and its unicodeScalars, codeUnits,
and extendedASCII views can be made entirely
seamless by having them share an index type (semantics of indexing a String
between grapheme cluster boundaries are TBD--it can either trap or be forgiving).
Having a common index allows easy traversal into the interior of graphemes,
something that is often needed, without making it likely that someone will do it
by accident.
[…]
In the long run, we should improve Swift string interpolation to the point where it can participate in most any formatting job. Mostly this centers around fixing the interpolation protocols per the previous item, and supporting localization.
[…]
This proposal depends on two new features in the Swift language:
Generic subscripts, to
enable unified slicing syntax.
A subtype relationship between
Substring and String, enabling framework APIs to traffic solely in
String while still making it possible to avoid copies by handling
Substrings where necessary.
Regarding this last point, note that String is a struct.
Chris Lattner:
I agree with Joe that Swift can learn a lot from Perl 6 grammar’s and we should take the time to do it right.
[…]
So why bless regex literals with language support at all? I see several reasons[…]
Language Design Localization Perl Programming Regular Expression Swift Programming Language Unicode
Matt Gemmell:
An increasing number of people — myself included — use an iPad for work. There are plenty of apps designed with that in mind, but I often find rough edges, as if the developers haven’t quite considered that people are potentially spending their entire day using the software.
The needs of iPad power users aren’t conceptually different from those of desktop or laptop users, but the nature of the hardware and its capabilities tends to cause some things to be overlooked. Based on my own experience, here’s some stuff that you, as a developer, should think about implementing if your customers are working with their iPads.
iOS iOS 10 iPad
Daniel Jalkut:
At this point you can usually just “size to fit” and Interface Builder will use its knowledge of the control’s class, and that class’s ability to size itself to suit its content. Or, if you’re using Auto Layout, it might mean that you need to ask Interface Builder to update the items’s frame, allowing Auto Layout to essentially size to fit for you.
In this case however I have a conundrum: both “size to fit” and AutoLayout insist this is the proper size and placement for the control, yet Interface Builder is still convinced the control will clip its content (the text of the menu item title).
[…]
I can’t win: if I let Auto Layout have it’s way, I get an annoying clipping notice. If I let the clipping notice have its way, Auto Layout throws a fit.
This hasn’t worked properly in years. Another reason to go nibless.
Bug Interface Builder Mac macOS 10.12 Sierra Xcode
