Parity and Settings

Clean up deployments

user=<user> repo=<repo>; gh api repos/$user/$repo/deployments --paginate -q '.[].id' | xargs -n1 -I % gh api --silent repos/$user/$repo/deployments/% -X DELETE

Clean up action runs

user= repo=; gh api repos/$user/$repo/actions/runs --paginate -q '.workflow_runs[] | select(.head_branch != "master") | "\(.id)"' | xargs -n1 -I % gh api --silent repos/$user/$repo/actions/runs/% -X DELETE

In the example bellow, we create a new server with host “localhost” and port “8080” by calling NewServer with WithHost and WithPort functions, which are examples of functional options.

This pattern allows for more readable and flexible configuration of objects. With this pattern, it’s easy to provide default values, and the API remains clean and easy to use even as more configuration options are added. Also, it’s clear which options have been set, and which have not.

type Server struct {
    host string
    port int
}

type ServerOptions func(*Server)

func WithHost(host string) ServerOptions {
    return func(s *Server) {
        s.host = host
    }
}

func WithPort(port int) ServerOptions {
    return func(s *Server) {
        s.port = port
    }
}

func NewServer(opts ...ServerOptions) *Server {
    s := &Server{}
    for _, opt := range opts {
        opt(s)
    }
    return s
}

func main() {
    s := NewServer(WithHost("localhost"), WithPort(8080))
}

This pattern is notably utilized in Go’s gRPC package, among others. The gRPC package provides numerous predefined functions for common options.

The problem is the famous Two Sum: “Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target”.

It’s incredible how fast Go is. It’s also amazing how fast Python got in the last few years, LeetCode uses Python 3.10. Despite being the language I enjoy the most, I was slightly disappointed by Swift.

Python

• Runtime: 44ms
• Memory: 15.1 MB

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        """
        :type nums: List[int]
        :type target: int
        :rtype: List[int]
        """
        map_ = dict()
        for i, v in enumerate(nums):
            comp = target - v
            if comp in map_:
                return [map_.get(comp), i]
            map_[v] = i        

Swift

• Runtime: 45ms
• Memory: 14.5 MB

class Solution {
    func twoSum(_ nums: [Int], _ target: Int) -> [Int] {
        var map: [Int:Int] = [:]
        for (i, v) in nums.enumerated() {
            let compl = target - v
            if let compl = map[compl] {
                return [compl, i]
            }
            map[v] = i
        }
        return []
    }
}

Go

• Runtime: 9ms
• Memory: 4.4 MB

func twoSum(nums []int, target int) []int {
   m := make(map[int]int)
   for i, v := range nums {
       c := target - v
       if c, ok := m[c]; ok {
           return []int{c, i}
       }
       m[v] = i
   }
   return []int{}
}

However, one concept that eluded my interest for quite some time was bitwise operators. The generally intimidating tone of resources and books, often suggesting their use only for “complex stuff”, kept me at bay. I could never understand the real utility of using bitwise operators as I never had to do bit twiddling myself for the kind of problems I have been solving so far.

Why use bitwise operators?

As the name suggests, bitwise operators works on the individual bits.

Bitwise operators enable you to manipulate the individual raw data bits within a data structure. They’re often used in low-level programming, such as graphics programming and device driver creation. Bitwise operators can also be useful when you work with raw data from external sources, such as encoding and decoding data for communication over a custom protocol.

The Swift Programming Language Book

I won’t go into the details of how these operators work as The Swift Programming Language Book do a much better job. Instead, I’ll strive to stay focused on a thought-provoking use case, setting the stage for our main discussion: Swift’s OptionSet.

Imagine you want to store a boolean value. How much memory would it take? The smallest amount of space a variable can take is 1 byte. The reason for this is that it is the smallest unit of addressable space that a CPU can reference. Even a boolean, which only needs to represent true or false – theoretically just 1 bit – still consumes an entire byte, with the remaining 7 bits merely filling space. This can be a glaring inefficiency when we’re aiming for memory conservation.

let bool = true  // 0b0000_0001
var bool = false // 0b0000_0000

In most applications, there are numerous flags at play. Consider Unix file permissions for instance. A user might be granted permission to read, write, execute, or even all of these simultaneously. When you execute chmod 777 file in your terminal, this is essentially what you’re doing - toggling flags on and off.

To make the most out of the available space programmers would combine multiple flags into a single byte allowing them to store up to 8 different boolean values. So, in one byte you can store up to 8 boolean values.

let x: UInt8 = 0b0000_0001 // execute - in base 10 this 1
let w: UInt8 = 0b0000_0010 // write - in base 10 this is 2
let r: UInt8 = 0b0000_0100 // read - in base 10 this is 4

let rwx: UInt8 = 0b0000_0111 // read, write, execute - in base 10 this is 7

That’s why the flag to set permission to read, write and execute is 7. Because the binary integer 0b0000_0111 is the decimal integer 7. However, to manipulate these individual bits (to turn them on and off), we need some way to identify the specific bits we want to manipulate. Unfortunately, the bitwise operators don’t know how to work with bit positions. Instead, they work with bit masks.

Bit masks

A bit mask is a predefined set of bits that are used to select which specific bits will be modified by subsequent operations. In the example above we set 3 masks, one for read, one for write, and another for execute. So, continuing with the example, suppose we want to set the permission to read and write:

// Masks
let x: UInt8 = 0b0000_0001 // execute
let w: UInt8 = 0b0000_0010 // write
let r: UInt8 = 0b0000_0100 // read

// To set (turn on) a bit we use the bitwise operator OR (|)
let rw: UInt8 = r | w // 0b0000_0110 - in base 10 this is 6
let rwx: UInt8 = r | w | x // 0b0000_0111 - in base 10 this is 7

For more detail on all other operators and how these operators work read the excellent Swift Programming Language Book.

Hold on a second, we began this discussion with a promise of memory efficiency. Yet the earlier example doesn’t really seem to save any memory. Normally, 3 booleans would consume 3 bytes. In contrast, the previous example demands 4 bytes (3 bytes to establish the bit masks, and 1 byte for the flag itself).

It’s essential to consider scale here. Bit flags truly shine when you’re handling numerous identical flag variables. In the previous example, we were focusing solely on one permission set: the user permissions (or owner permissions in Unix terminology). Now, imagine that you also want to set permissions for a group and other users. Or even more challenging, envision setting permissions for 100 users. Instead of one permission set (the owner), now you have 100. Using 3 Booleans per permission set (one for each potential state) would consume 300 bytes of memory. Employing bit flags, you’d need just 3 bytes for the bit masks, and 100 bytes for the bit flag variables, amounting to 103 bytes of memory in total – roughly a third of the memory usage.

Ok but this is all about Swift and iOS development, why bother to save a few bytes of memory, right? Probably your use case won’t scale to tens of thousands or even millions of similar objects to be worth the added complexity.

That being said, there’s another scenario where bit flags and bit masks prove beneficial, and it’s well-utilized by UIKit and SwiftUI. Imagine a situation where you have a function capable of accepting any combination of eight or more different options – for the sake of simplicity, let’s stick with an 8-bit base. One approach to define such a function would be to use eight individual Boolean parameters:

func someFunc(
    option1: Bool,
    option2: Bool,
    option3: Bool,
    option4: Bool,
    option5: Bool,
    option6: Bool,
    option7: Bool,
    option8: Bool,
) {}

Crazy, right? Now imagine you want to call this function with options 2 and 7 set to true:

someFunc(
    option1: false,
    option2: true,
    option3: false,
    option4: false,
    option5: false,
    option6: false,
    option7: true,
    option8: false,
)

Well, thanks to Swift’s argument label this doesn’t sacrifice readability but I hope you understand the mess.

Swift’s OptionSet

Swift’s OptionSet solves exactly this problem. Take for example the .padding() modifier on SwiftUI – used to add a specified amount of padding to one or more edges of the view. The .padding() modifier and many other SwiftUI and UIKit functions receive an OptionSet. When you apply a .padding() with [.top, .bottom, .leading, .trailing] you are not passing an Array of Enum cases, you are passing an OptionSet.

By definition, all option sets conform to the RawRepresentable protocol through inheritance, which allows for the raw value of an option set instance to store the instance’s bitfield. This raw value needs to conform to the FixedWidthInteger protocol, such as UInt8 or Int. In turn, the FixedWidthInteger protocol extends the capabilities of the BinaryInteger protocol by including binary bitwise operations, bit shifts, and overflow handling.

Continuing the example above, we could define an OptionSet:

struct MyEightOptions: OptionSet {
    let rawValue: UInt8 // Stores our flags

    static let option1 = MyEightOptions(rawValue: 0b0000_0001) // 1
    static let option2 = MyEightOptions(rawValue: 0b0000_0010) // 2
    static let option3 = MyEightOptions(rawValue: 0b0000_0100) // 4
    static let option4 = MyEightOptions(rawValue: 0b0000_1000) // 8
    static let option5 = MyEightOptions(rawValue: 0b0001_0000) // 16
    static let option6 = MyEightOptions(rawValue: 0b0010_0000) // 32
    static let option7 = MyEightOptions(rawValue: 0b0100_0000) // 64
    static let option8 = MyEightOptions(rawValue: 0b1000_0000) // 128

    static let all: MyEightOptions = [
        .option1,
        .option2,
        .option3,
        .option4,
        .option5,
        .option6,
        .option7,
        .option8,
    ]
}

And then have it in our function instead of all those parameters:

func someFunc(options: MyEightOptions) {
    if options.contains([.option2, .option7]) {
        print("\(options)") 
    }
} 

someFunc(options: [.option2, .option7]) // MyEightOptions(rawValue: 66)

Much cleaner, right? Also, we have context now. In the example above MyEightOptions(rawValue: 66) stores de integer 66 wich is the binary integer 0b0100_0010, indicating that option2 and option7 are flagged on.

I hope this article has helped you to understand these SwiftUI and UIKit constructs and how OptionSet works behind the scenes.

Core Data is an object graph and persistence framework amongst the list of frameworks provided by Apple. It’s available on iOS since iPhone SDK 3.0. Yep, it’s really old and mature, which in software usually translates to “stability”. But equally, it’s starting to show its age when it comes to integrating the framework into new ones like SwiftUI.

Core Data has undoubtedly contributions to give to the hot topic around SwiftUI and MVVM since the introduction of a new property wrapper to integrate the framework into SwiftUI: @FetchRequest. Actually the framework has its caveats to integrate into Swift it self since the framework was built with Objective-C; Odptional has different meaning between the framework and the Swift language.

When experimenting with Core Data and SwiftUI, state management was one thing really mind-bending to me. Mixing an imperative framework with a declarative one feels really weird. Commits 195f451 and 57e5aa1 were me trying to deal with changes to Core Data’s NSManagedObject which conforms to ObservableObject not updating the view.

This playground is a simple example on how to recreate the same effect with SwiftUI since all the examples I found online implements the same design in a much more complex manner.

We’ll take the Apple’s Dev Training “Creating a card view” as an inspiration and starting point.

Data Model

First lets create the Data Model for our CardView. It’s a simple model holding a Theme to color our CardViews.

import Foundation

struct ColorCard: Identifiable {
    let id = UUID()
    var theme: Theme
}

Card View

The CardView has the following structure.

import SwiftUI

struct CardView: View {
    let colorCard: ColorCard

    var body: some View {
        Text(colorCard.theme.name)
            .foregroundColor(colorCard.theme.accentColor)
            .font(.headline)
            .padding(
                EdgeInsets(
                    top: 25,
                    leading: 5,
                    bottom: 25,
                    trailing: 5
                )
            )
    }
}

Content View

And finally our ContentView containing the List of CardViews. To create the gap between the List items we remove the list row separators .listRowSeparator(.hidden) and set the list row background to an InsettableShape .listRowBackground() defining a top and a bottom EdgeInsets padding. The final touch is to set the .listStyle(.plain) to .plain.

import SwiftUI

struct ContentView: View {
    @State private var colorCards: [ColorCard] = ColorCard.sampleData

    var body: some View {
        List {
            ForEach(colorCards) { colorCard in
                NavigationLink(destination: colorCard.theme.mainColor) {
                    CardView(colorCard: colorCard)
                }
                .listRowSeparator(.hidden)
                .listRowBackground(
                    RoundedRectangle(cornerRadius: 5)
                        .background(.clear)
                        .foregroundColor(colorCard.theme.mainColor)
                        .padding(
                            EdgeInsets(
                                top: 2,
                                leading: 10,
                                bottom: 2,
                                trailing: 10
                            )
                        )
                )
            }
            .onDelete { idx in
                colorCards.remove(atOffsets: idx)
            }
        }
        .listStyle(.plain)
        .navigationTitle("Color Cards")
        .toolbar {
            Button {
                colorCards.append(ColorCard(theme: Theme.allCases.randomElement()!))
            } label: {
                Image(systemName: "plus")
            }
        }
    }
}

A complete Playground App is available on github reposity SwiftUI List CardView Example.

Kidding, I don’t know if this is the best way but I am luck enough to be working with Python 3.8 and this seems to be a good opportunity to use the new Walrus := operator.

This even seems to be a popular question on Stack Overflow.

from itertools import islice

list_ = [i for i in range(10, 100)]

def chunker(it, size):
    iterator = iter(it)
    while chunk := list(islice(iterator, size)):
        print(chunk)

In [2]: chunker(list_, 10)
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
[30, 31, 32, 33, 34, 35, 36, 37, 38, 39]
[40, 41, 42, 43, 44, 45, 46, 47, 48, 49]
[50, 51, 52, 53, 54, 55, 56, 57, 58, 59]
[60, 61, 62, 63, 64, 65, 66, 67, 68, 69]
[70, 71, 72, 73, 74, 75, 76, 77, 78, 79]
[80, 81, 82, 83, 84, 85, 86, 87, 88, 89]
[90, 91, 92, 93, 94, 95, 96, 97, 98, 99]