Transformative Streams

I’ve written here and there about my love of streams. I cover them a bit in the Swift Cookbook. Now that I’m updating it for Swift 3 via the Pearson Content Update Program, I have a little leeway to play around. I’m trying to expand the text with some fun new recipes.

Today, I wrote about “transformative streams”. A traditional stream, one that you write to with print(..., to:) is just a destination you write to such as stdout, stderr, or a file. A transformative stream fundamentally changes the text flowing through it. You can constrain text to all lowercase, or spell check it, or even print to your platform’s local notifications system.

I decided in this case to build a translation stream. It looks like you see in the following screenshot, converting English text to a foreign language when you print to the stream.

Screen Shot 2016-08-29 at 4.12.58 PM

As you see in this screenshot, my solution leverages Swift’s built in standard library print function. Swift enables you to print to streams. When using my ItalianStream.shared stream, material printed to the console is automatically translated to the language provided by that stream.

In my implementation, I wanted to be able to hit a few key points:

  • Any specific translation functionality needed to be decoupled from the printing stream so I could swap in and out various API providers without disrupting the implementation.
  • I wanted to be able to use many languages.
  • I had to offer a re-usable var member, which is required for stream printing.

To accomplish these goals, I decided to go heavily generic and protocol-oriented. I wanted to be able to slot in any language using a genericized stream type, which in turn would provide a shared stream instance for printing. If it sounds a little pretzel-y, it is.

The built-in standard library TextOutputStream protocol has precisely one requirement, a write method that accepts a string and does something with it.  In the code that follows, it translates the string and prints it out.

/// A text output stream that performs translation in
/// the process of printing
public struct TranslationStream<Language: EnglishTranslationProvider>: TextOutputStream {
    /// Writes the contents of the string to stdout after
    /// passing the string through an automatic translator
    public func write(_ string: String) {
        guard let translation = Language.translate(string) else { return }
        print(translation)
    }
}

The tricky bit is that my TranslationStream structure is generic. It  requires a type that conforms to EnglishTranslationProvider, allowing it to request a translation from that provider. Here’s what that protocol looks like:

/// A provider of string translations from English
public protocol EnglishTranslationProvider {
    /// Returns a shared instance of the provider
    static var shared: TranslationStream<Self> { get }

    /// Returns a translated string
    static func translate(_ string: String) -> String?
}

Each translation provider refers back to the TranslationStream type to  offer a shared translation stream to use when printing (you see this in the screenshot as ItalianStream.shared) and a translate method that returns a rendered version of the string. For example, here’s the implementation of my French provider type:

/// A stream type that automatically translates from English to French
public struct FrenchStream: EnglishTranslationProvider {
    /// Returns a shared instance of the provider
    public static var shared = TranslationStream<FrenchStream>()
    
    /// Returns a translated string
    public static func translate(_ string: String) -> String? {
        return FrenchStream.translate(string, language: "fr")
    }
}

Simple, right? There really isn’t much to it. It implements the two required members but otherwise delegates translation to a default translate method declared in a protocol extension.

My particular implementation takes a two-character language code and requests a translation from English via Google. I didn’t include the actual translate(_ string:, language:) method here because there are many competing APIs, which you can easily hook into, and they generally require both API keys and fees.

The important bit I’m trying to get across here is not “oh look, this translates” but rather “oh look, you can transform text by printing to streams”.  I thought the translation stream was a rather nice way to demonstrate how powerful this particular Swift feature could be.

How do you beautify guard-else conditions?

This looks horrible to me.

Screen Shot 2016-08-23 at 11.03.47 AM

This looks wrong too:

Screen Shot 2016-08-23 at 11.06.56 AM

And so does this:

Screen Shot 2016-08-23 at 11.07.50 AM

And this:

Screen Shot 2016-08-23 at 11.08.25 AM

And while we’re at it  these two too, both of which require hand-indenting while fighting Xcode:

Screen Shot 2016-08-23 at 11.17.53 AM

Screen Shot 2016-08-23 at 11.17.59 AM

This is among the least bad:

Screen Shot 2016-08-23 at 11.08.59 AM

What would you do to fix it?

Patrick Perini suggests:

Greg Titus thought using a simpler clause and a Never-returning function might be better. Here’s some code where I incorporated his feedback:

Swift Nostalgia: Letting go doesn’t mean saying goodbye

Just leaving this here.

I’ve filed a bug report about having to do non-generic implementations, which makes this a lot uglier than it needs to be. Jordan Rose wrote in response to my bug,

I’m pretty sure this is an overload ordering question, and I’m not convinced the compiler is wrong. If something is a more specific overload and marked unavailable, silently dropping back to the less-specific overload might be counterintuitive. (It also means the behavior of existing code could change silently if something is marked unavailable between releases.)

In any case, if you have any fixes or tweaks, as always please let me know and I’ll update.

Review: Man, I hate Cursive by Jim Benton

Screen Shot 2016-08-21 at 7scaled.58.09 PM

If you like good, stupid, subversive humor (and who among us does not?), consider pre-ordering Jim Benton‘s “Man, I Hate Cursive”.

Due out this October, this cartoon collection for “People and Advanced Bears” is silly, witty, and laugh-out-loud fun. It offers a collection of Benton’s more popular strips from Reddit, “shining a light on talking animals, relationships, fart jokes, and death” according to the book’s promo copy.

I liked it a lot. Admittedly, some of the humor leans off-color: it’s the kind of book you gift a friend, a fellow programmer, a geek, but not maybe your mom unless your mom is a friendly programmer geek, in which case, she’ll enjoy the laughs.

You’ll probably like it too, in which case, it’s excellent for leaving around on coffee tables if you’re a little uptight or in bathrooms, where its humor might be more appreciated during those deeply  philosophical times when you forget your iPad and don’t subscribe to the Ikea catalog.

Screen Shot 2016-08-21 at 7.57.05 PM

At just under a hundred pages, the book ended way too soon for me.  “Man, I Hate Cursive” is available for pre-order on Amazon ($11.07 paperback, $9.99) and will be published on October 18, 2016.

NetGalley provided me with a free copy of the book for this review.

Kid-fu: Pay for play

Screen Shot 2016-08-19 at 7.24.19 PMHow do you get your kid to try on all his shirts and pants before school starts? So you can sort them into trash, donate, wear, and “for playtime use only”? Answer: Playgrounds. Thank you playground team!

We used the “deal or no deal” rule. Two spins. You can “stick” or you can re-try, but no peeking at the next roll. Payment for each garment  after trying it on, taking it off and folding it. Coins placed into a cauldron (thank you Harry Potter camp) to be counted after we’re done. Any stained items treated with Oxyclean and thrown into the hamper.

For less than a couple of dollars, we got through his entire wardrobe with no complaints except “Don’t I have anything else that needs trying on?”

Source code follows:

Canonical Hex

So today, in the context of assembling color components, I decided that a hex value should always be padded to 2, 4, 8, 16, 32, or 64 characters when building out chunks.

Under this system, the number 256 should be “0100” and not “100”, representing the smallest standard memory footprint that will store the value. This allows chunks to be losslessly assembled together because there’s a consistent width for each component. If you need to use a larger padding value, you can re-pad to a larger minimum width.

While RGB colors come in 6’s, those are (in my opinion) three channels of 2-digit hex numbers, not a six-digit hex number.

Interesting things about this implementation:

  • You have to use Swift.max because Int has its own max symbol.
  • I was initially convinced to drop strtol() in favor of the built-in radix initializer, but this does do away with leading 0x support, which you have to strip yourself. (I did not include stripping in this implementation.) In my SwiftString repo, I’ve reverted to the old-style conversions.
  • Greg T’s version with fls instead of my convoluted log2 stuff is vastly improved, so I’ve substituted it in-place here.
  • My goal is to produce full-width number-chunks that can be assembled to represent components, whether for storing information, for channels, or for clarity in reading. An RGB group of (0xFF, 0x7, 0xFF) must be “FF07FF”, not “FF7FF”. So yes, there will be leading zeroes. If you want to interpret  output as numbers, use a canonical prefix (0x).
extension String {
    /// Left pads string to at least `minWidth` characters wide
    public func leftPad(_ character: Character, toWidth minWidth: Int) -> String {
        guard minWidth > characters.count else { return self }
        return String(repeating: String(character), 
            count: minWidth - characters.count) + self
    }
    
    /// Returns String's hex value
    /// - note: Non-compliant strings default to 0
    /// - note: An earlier version used strtol(), 
    ///   which accepts leading "0x". This does not.
    public var hexValue : Int { return Int(self, radix: 16) ?? 0 }
}

public extension Int {
    /// Returns Int's representation as hex string using 0-padding
    /// to represent the smallest standard memory footprint that can
    /// store the value.
    public var hexString : String {
        let unpaddedHex = String(self, radix:16, uppercase: true)
        let stringCharCount = unpaddedHex.characters.count
        // thanks, Greg Titus
        let desiredPadding = 1 << Swift.max(fls(Int32(stringCharCount - 1)), 1) 
        return unpaddedHex.leftPad("0", toWidth: Int(desiredPadding))
    }}
}

As always, corrections, improvements, suggestions welcome.

When did Ikea ditch the sunshine, rainbows, and unicorns?

The new Ikea catalog arrived yesterday. Is it me or have they turned over their design to some crazed Swedish goth intern? My new catalog feels more Hitchcock and “Vogue Editorial” than “Affordable purchases for people who wish they could fix their out-of-control lives.”

Ikea’s gone from cute girls in a colorful apartment (top, 2015) to psychotic butcher knives that think they’re actually vegetables (check out that shadow) and this recurring weird backdrop thing, which makes me think they couldn’t afford an editor to crop the photos properly (bottom, 2016).IMG_1527

Suddenly, they’ve transitioned from simple product images inspiring you to simplify and organize  your life to a kind of nightmare clutter scenario where all reason has fled and you apparently must buy every product available from the company and store them in the open without drawers, cupboard doors, or any break in sanity.

IMG_1521

Look at that poor woman standing at that kitchen island. Her entire body communicates the tenseness from barely having a spare inch of counter space, banging her knees against all the junk on the two shelves, the shame of putting your dishes out for public viewing. Inside, she’s screaming “I will never get my life under control and it’s all IKEA’s fault! For just $499!”

(By the way, I love the LED light at the middle of the right page of the 2015 catalog. Mine is black, not red, and it’s perfect between my two computer monitors. Folds up out of the way when not in use.)

IMG_1526

Apparently 2016 is the year of dark spaces, drawn blinds, and Carmen cosplay. You can pretend to die of consumption in the gloomy shadows of your living room, while dressed in red and practicing ballroom in the  (perhaps) 2 square meters of space between couches.

And can you think of anything scarier than your sofa actually being your home. Last year, a beautiful, open plan living room, with a family happily getting work done on the laptop and reading to a kid. They seem happy, their plants seem happy, the lightness and brightness no doubt makes them feel free and open and relaxed. Compare that to this year.IMG_1525

No, Ikea, a sofa is not the home. And who are all those strange people who wandered into this poor woman’s life just to stare at and harass her?

Here’s Elsa. Elsa thought she’d have a lovely relaxing time, putting up her feet before picking up the kids and stopping by an organic locally sourced market for take out to eat while perched on a variety of ottomans and sleeper couches.

Who would ever have expected an entire gang from Twitter to take up residence on the other side of her monster sofa, laughing at her, mocking her, and critiquing her lounging style. That gang of four sure think Elsa is a hoot. And all at the same time, creepy Helmut from down the road just stares at Elsa with unrequited longing. I think perhaps he’s humming ska songs from the 1980s to her.

Poor Elsa. This is what comes of living in the middle of a photographic studio, without doors to keep out strangers, no storage for clothing, a ragtag group of floating sofas for the young ones to sleep upon, and three mysterious remote controls to remind her a time when she had a real house to call home.

Oh Ikea. It’s time to say goodbye to 2015, with its misty bright hopes for a world of knotty pine. 2016 has arrived with its dark bleak dystopian furniture and a bookshelf that looks like an insurance liability court case ready to happen.

IMG_1523

(As a side note, I had no idea that sleeper sofas crept out of their homes while we were at work to embrace that secret 24-hour life. It must get crowded at the bowling alley and at the local microbrewery when affordable furniture sits around, drinking lager, and sharing the stories you thought were kept secret.)

Being overly clever with dates

To find out the distance, say in days, between two dates, call a calendar’s dateComponents(_:, from: , to:) method and pass it the unit you want to use. This call returns a DateComponents instance. You can then find out how many days fall between the two by looking at the returned instance’s.day property.

But what if you want to write a more general method that returns the distance for pretty much any unit you throw at it, whether it be days, minutes, seconds, or years?

Either you can write a really complex switch statement or you can build an extension for DateComponents that allows you to subscript using any Calendar.Component. (Essentially performing the exact same switch statement but as a built-in feature.) And that is, exactly what I did today.

Here are my distance functions, which use subscripting to access the component information after pulling the distance from the shared calendar:

static public func distance(_ date1: Date, 
    to date2: Date, 
    component: Calendar.Component) -> Int {
    return Date.sharedCalendar
        .dateComponents([component], from: date1, to: date2)[component] ?? 0
}

public func distance(to date: Date, 
    component: Calendar.Component) -> Int {
    return Date.sharedCalendar
        .dateComponents([component], from: self, to: date)[component] ?? 0
}

The subscripting itself, along with a full refresh of my NSDate (well, Date now) utilities can be found at my github repo. This has been one of my more popular (and personally neglected) repositories that dates back almost a decade and I’m happy to say I’ve cleaned it up quite a bit while updating it to Swift.

I’m using a much better way to calculate “same” (for example, same date or same week) by creating a canonical form from the dates and then comparing the canonical versions. For dates, that’s midnight at the start of the day. For weeks, it’s midnight at the start of the week. (update: Sebastian Celis points out the existence of compare(_ date1: Date, to date2: Date, toGranularity component: Component), which is part of swift-corelibs-foundation)

I’ve added in quite a lot of formatter and string options, and doing this in Swift is a pure delight. (It’s a pity playgrounds don’t let you code using gyb-nastics. There’s a lot of redundancy in my code.)

All the date offsets are now much cleaner, and completely migrated to date components (as they should have been years ago).

As always, if you want any requests or changes, ping me now while I’m paying attention to this because my primary interest is migration to Swift and not dates per se. And thanks in advance for any feedback.

More fun with sequences!

I want to share a little conversation from Swift-Users. KS Sreeram wrote:

I’m trying to initialize a byte-array efficiently with minimal copying with the following steps:

1. Create an empty byte array.
2. Reserve sufficient capacity in the array.
3. Use mutable pointers into the array to fill in the data.
4. The actual size that was filled is known only after it is filled in.
5. I would like to set the size of the array to the actual size.

I couldn’t find any methods for doing the last step. Is there a way to do this?

Dave Abrahams’ response:

Create a Sequence that represents the elements you’re going to append, e.g.:

 var a = [1, 2]
 a.reserve(256)
 a += sequence(first: 3, next: {$0 < 1000 ? ($0 + 3) * 2 : nil})

There are lots of ways to make Sequences, but the overloaded sequence() functions are probably the easiest.

Sadly: