Archive for January 8, 2016

Friday, January 8, 2016

Exploring Swift Array’s Implementation

Ankit Aggarwal:

Swift declares a C struct in its SwiftShim’s module inside GlobalObject.h called _SwiftArrayBodyStorage

[…]

  • count is the number of elements currently stored in the buffer

  • _capacityAndFlags is used to store two things:

    • first is the capacity of the buffer
    • second “Is the Element type bitwise-compatible with some Objective-C class?”

Via David Smith:

Apparently C-like performance, memory safety, resizing, copy-on-write, and ObjC bridging all together is hard

The subscript implementation in _ContiguousArrayBuffer has an interesting note:

Manually swap because it makes the ARC optimizer happy.

The method is also marked with a mysterious nonmutating keyword, which the Swift language guide mentions but does not explain. This could be an optimization to avoid unnecessary writebacks or a way to make the compiler enforce that the setter does not actually change any properties of the structure (just the contents of the memory they point to).

Update (2016-05-03): Jasdev Singh:

Stepping through Sidney’s example, we can see how nonmutating signals that a setter doesn’t modify the containing instance, but instead has global side effects.

Slow Swift Array Type Inference

Benjamin Encz:

Slow compile time in Swift? Try to rearrange some of your expressions.

Update (2016-01-20): Bryan Irace (tweet):

I had a problem. The new iOS application that I’m working on – written 100% in Swift – was noticeably taking much longer to compile than should, given its size (~200 files). More concerning, it was suddenly a lot slower than only a couple of weeks prior. I needed to get to the root of the problem as soon as possible, before it got any worse.

The first step was to add -Xfrontend -debug-time-function-bodies to my Swift compiler flags […] This causes the compiler to print out how long it takes to compile each function […]

Six Colors’ Apple Report Card

Jason Snell:

Generally, our panel praised the quality of Apple’s hardware design and reliability. As John Moltz wrote, “Apple hardware continues to be one of its great strengths.” “Better than ever,” wrote Stephen Hackett. “No one else seems close,” wrote Rich Mogull.

[…]

If the broad perception is that hardware remains an Apple strength, here’s the flip side: the perception that Apple’s software efforts lag behind.

[…]

Serenity Caldwell framed the issue as one of focus. “iOS still feels buggy and unfinished. iPad Pro launched without any key Apple iOS apps. Too many software projects for one year.” As James Thomson wrote, “iOS and OS X are improved, but it feels that many other things are barely held together with digital string.”

Other panelists were far less generous. “Software quality has really gone downhill,” wrote Khoi Vinh. “Apple’s software quality continues to drop,” wrote Adam Engst. Rob Griffiths praised iOS but had harsh words for OS X: “Longstanding seemingly ‘simple’ bugs don’t get fixed.”

I agree that Apple’s hardware quality continues to be great. Aside from reverting to mDNSResponder, I have not seen an overall improvement in software quality this year. With Mac OS X 10.11, I’m still regularly seeing problems with Finder, Mail, Safari, Disk Utility, Preview, Calendar, Spotlight, and Time Machine that were not present in previous versions. I hear a lot about Mail from my customers, and Mail in 10.11 overall seems to be even less reliable than in 10.10. And old bugs from 10.10 and even 10.9 remain. iOS has always been relatively less buggy for me, but it still has some annoying bugs as of 9.2. I hear people saying that Apple kind of did a Snow Leopard in 2015, but I’m just not seeing it.

Our panel’s message is clear: Apple has a lot of work to do to repair its relationship with third-party software developers. “Apple’s heading towards a crisis point,” wrote Andy Ihnatko. “In 2014, I said that I’d never seen Apple developers less happy. Things are even worse a year later[…]

[…]

The developers on our panel specifically cited long delays to process approvals and builds, with iTunes Connect being “the least reliable this year than at any time in the last seven years,” according to James Thomson.

I agree with all of this. Swift, and the way Apple has handled its open sourcing, is mostly a bright spot, though.

Generic Collections, SubSequences and Overloading

Airspeed Velocity:

And before long you smack your head against one of the more confusing things about generic collections: a sequence’s SubSequence doesn’t necessarily contain the same element type as that sequence. This usually manifests itself in one of those compiler errors that has you yelling “what are you talking about you infernal machine” at the compiler before eventually realizing what you’ve done wrong and sheepishly fixing it.

[…]

There’s nothing about this definition that forces the elements of SubSequence to be anything specific. Really, this needs a where clause on the typealias – something that Swift doesn’t currently support[…] So, in the mean-time, the way around this is to specify any requirements like this as part of the declaration.

Apple Mail Ignores Named Anchors

Adam C. Engst:

I now have direct confirmation that Apple is aware that the versions of Mail in both OS X 10.11 El Capitan and iOS 9 do not properly honor navigating to standard HTML named anchor tags.

[…]

Frankly, I find this bug extremely distressing, not because it’s all that significant — you can always just scroll down in the TidBITS issue — but because named anchors were described in the 1992 CERN document (presumably by Tim Berners-Lee) that was the very first public documentation of HTML. It boggles the mind that Apple’s engineers could bungle such a simple behavior that sits at the very core of HTML, and fail to fix it in the two minor updates to El Capitan and iOS 9 released so far.

Microsoft Solitaire Was Developed by a Summer Intern

Wes Cherry (via Hacker News):

I wrote it for Windows 2.1 in my own time while an intern at Microsoft during the summer of 1988. I had played a similar solitaire game on the Mac instead of studying for finals at college and wanted a version for myself on Windows.

The code is nothing great…the only slightly interesting thing is the optimizations I did to get card dragging to work smoothly. Back in those days getting a pixel onto the EGA buffer took getting out a hammer and chisel and chipping away at the silicon for an eternity.

Object oriented programming was a newish thing back then and there wasn’t a C++ compiler available for windows, so it has a goofy message passing architecture to get polymorphism and inheritance.

At the time there was an internal “company within a company” called Bogus software. It was really just a server where bunch of guys having fun hacking Windows to learn about the API tossed their games. A program manager on the Windows team saw it and decided to include it in Windows 3.0. It was made clear that they wouldn’t pay me other than supplying me with an IBM XT to fix some bugs during the school year - I was perfectly fine with it and I am to this day.

Copyright © 2000–2024 Michael Tsai.