Archive for February 11, 2016

Thursday, February 11, 2016 [Tweets] [Favorites]

Using Xcode Bots

I’ve been using Xcode’s continuous integration feature for a few months now. Overall, I’m glad that I took the time to set it up. However, it’s been much more difficult to use than I expected, so I want to document some of the issues that I encountered, as well as the benefits:

I chose Xcode’s continuous integration instead of something like Jenkins because, coming from the makers of Xcode, I thought it would be easier to set up and less prone to breakage. This may well be true, but it’s not been anywhere near as simple as I’d hoped.

See also: Xcode CI, The missing manual and the Swift CI that uses Jenkins.

Update (2016-02-12): The workaround to get Xcode 7.2.1 bots working (via @CocoaKevin):

sudo /Applications/Xcode.app/Contents/MacOS/Xcode

However, I’m now seeing a bug where Xcode reports the bot integration as still running long after it’s finished (and the trigger has run).

I got multiple suggestions that setting Xcode Server to send e-mails to a Gmail account helps, but it didn’t for me.

Google AMP Launch Looms

George Slefo:

And, crucially, Google will favor AMP sites over others with the same search score in the results it shows consumers, said Richard Gingras, senior director, news and social products at Google.

Via John Gruber:

What about a site that already delivers clean HTML markup, minimal-to-no JavaScript, and images that load on demand (or, cough, a site with few-to-no images)? Why would Google favor an AMP site over such a site in search results?

Previously: Google’s Accelerated Mobile Pages.

Update (2016-02-16): John Gruber:

Important correction from Ad Age, regarding the claim earlier this week that Google would favor AMP page in search results.

Swift Mailing Lists Are Self-Selecting

Jason Brennan:

Generally speaking, if you’re an active participant of the the swift-evolution list, you’re already quite bought in on Swift. This is generally a good thing, since being bought in on Swift means you care a lot about its future, and you have a lot of context from working with current Swift, too.

But by only getting suggestions and feedback about Swift’s evolution from those bought in on Swift, the Swift team is largely neglecting those who are not already on board with Swift. This includes those holding out with Objective C on Apple’s platforms, and those using different languages on other platforms too. These groups have largely no influence on Swift’s future.

[…]

And thus, Swift becomes less likeable to these Objective C developers.

Swift Struct Storage

Mike Ash:

We can see that it’s exactly as we expected: when passing the struct to an inout parameter, the struct is laid out contiguously in memory and then a pointer to it is passed in.

[…]

struct storage in Swift is ultimately pretty straightforward, and much of what we’ve seen carries over from C’s much simpler structs. A struct instance is largely treated as a loose collection of independent values, which can be manipulated collectively when required. Local struct variables might be stored on the stack or the individual pieces might be stored in registers, depending on the size of the struct, the register usage of the rest of the code, and the whims of the compiler. Small structs are passed and returned in registers, while larger structs are passed and returned by reference. structs get copied whenever they’re passed and returned. Although you can use structs to implement copy-on-write data types, the base language construct is copied eagerly and more or less blindly.