Do you need help on a specific subject? Use the contact form (Request a blog entry) on the right hand side.

2015-12-31

Segmentation fault work around on xcode 7.2

With XCode 7.2 I sometimes experience a "Segmentation Fault". Once it happens, it becomes impossible to recompile my project.
This happens after updating the code while up to that point the code was compiler-error free.
I.e. I would build the project, execute the application, stop de application, make a minor fix, en then bomb: Segmentation fault. And there is (almost) nothing I could do to reverse this. Undoing the change and cleaning the project does not work. Once a segmentation fault, always a segmentation fault.

Until I stumbled upon a work around: My application has a main.swift file. I would select all other swift files in the project and remove them from the target in the "Target Membership" from the "File Inspector" panel.
Then hit Ctrl-B (i.e. rebuild the project).
Of course the build would fail, but this is not important.
Then add the files back to the target and hit Ctrl-B again.
Presto, the code now compiles again, without the segmentation fault!

If you are careful and select (in XCode) only the files that are included in the project then deselect the target membership and use Ctrl-B... then the file selection will remain and implementing the work around will only take a few seconds.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-12-10

How to create an Unsafe(Mutable)Pointer

Swift is rather restrictive in the creation of pointers. But when we do low level programming it is sometimes necessary to use pointers. Especially when interfacing to the C-APIs of the underlying Unix system.

The "&" is used in arguments to create a pointer. But cannot be used in other places for the same purpose.

So how to create a pointer outside of a function argument?

Well, Apple has provided us with the withUnsafeMutablePointer and withUnsafePointer functions to deal with this. They take a few arguments and a closure. The argument is converted into a pointer that can subsequently be used inside the closure.

An example:

        var telemetry = Telemetry()
        let result = withUnsafeMutablePointer(&telemetry, {
            ptr in
            // From here on 'ptr' is a UnsafeMutablePointer<Telemetry>
            ...
        })

The same can be done for UnsafePointer as well.
And there are variations on withUnsafeMutablePointer and withUnsafePointer that allow for multiple pointers to be created at once.
The result is the result returned from the closure, which is neat too. In fact the conversion functions are defined as this:

public func withUnsafeMutablePointer<T, Result>(inout arg: T, @noescape _ body: UnsafeMutablePointer<T> throws -> Result) rethrows -> Result

Hence they do not only return the result from the closure, but they will even rethrow any execptions the closure might throw.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-12-03

Swift example: How to load a nib/xib file into a view on OS-X

Many simple application use just a single nib/xib file, the MainMenu.xib. And while that works fine, as soon as the application becomes more demanding it gets cramped rather quickly.
Also, Apple suggests that the MainMenu.xib file should only be used for the main menu and that we should add xib files for other windows and views as necessary.

This post shows how to load a view from a different xib file and make it visible. We wil do this the old fashioned way, without storyboards.

For non-document based applications I will use MainMenu.xib for the menu and the main window. Then I will add another xib file containing a view. This view will be loaded into the main window explicitly. The view will use a NSViewController.

Create the project, a simple cocoa application for OS-X. This project comes with the main menu xib already set up the way this example needs it.

Since we want to load a view from a different nib into the window, it would be nice to have access to the view component of the window. To do this, add an outlet to the AppDelegate. Also, we will need an instance of NSViewController to attach the loaded view to, create it in AppDelegate as well:

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    @IBOutlet weak var window: NSWindow!

    @IBOutlet weak var view: NSView!
    
    var myViewController = MyViewController!

    func applicationDidFinishLaunching(aNotification: NSNotification) {
        // Insert code here to initialize your application
    }

    func applicationWillTerminate(aNotification: NSNotification) {
        // Insert code here to tear down your application
    }

}

In Interface builder, connect the view outlet to the view inside the window. Select the "Window". Right-click the delegate object, click drag the circle behind the "view" and drag it onto the window. When completed it should look like this:



Now create a new OS-X User Interface file. Select the "View" template. I saved it as MyView.xib. In this view I added a textfield and a button like this:



Next, create the view controller. Add a new Swift file called MyViewController.swift to the project. In it, add an outlet for the textfield and an action for the button:

import Foundation
import Cocoa

class MyViewController: NSViewController {
    
    @IBOutlet weak var textField: NSTextField!
    
    @IBAction func countButtonAction(sender: AnyObject?) {
        var count = textField.integerValue
        count++
        textField.integerValue = count
    }

}

Switch back to the MyView.xib file and change the class of the File Owner to MyViewController:


Connect the outlet and action to the textfield and the button. And important: Also connect the "view" outlet to our new view:



Almost done, now the final step: loading the nib file and displaying its contents. We do this in the AppDelegate:

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    @IBOutlet weak var window: NSWindow!

    @IBOutlet weak var view: NSView!
    
    var myViewController: MyViewController!

    func applicationDidFinishLaunching(aNotification: NSNotification) {
        // Insert code here to initialize your application
        myViewController = MyViewController(nibName: nil, bundle: nil)
        view.subviews.removeAll()
        view.addSubview(myViewController.view)
    }

    func applicationWillTerminate(aNotification: NSNotification) {
        // Insert code here to tear down your application
    }

}

That is all, build and run the project.

You will notice that you need to clean up the appearance of the window, but for today, I will leave that exercise for you.

Note: The name of the nib file (or xib file) must be the same as the name for the ViewController. Otherwise the instantiation of the controller will fail.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-11-30

Swift Example: Binding a NSTableView to an Array

After the introduction to Cocoa bindings in the previous post, todays example is a little more complicated. Unfortunately Apple is lacking in easily accessible documentation: I had to spend a couple of days in frustration before I finally got the tableview bindings working. Though there are some blogs on this subject I found that none worked for the version of xcode that I am using here (7.1).

So here goes:

This is how the app will look:



Each row will contain a label, a textfield and a button. The content for the label and the textfield will be in a table, and the button will be linked to the object that is shown in the table. As you see above, the button will be disabled if the textfield is empty.

All the code that is necessary (in AppDelegate.swift) looks as follows:

class ParameterTableRow: NSObject {
    var name: String = "Parameter Value:"
    var value: String?
    func setButtonClicked() {
        print("Set button clicked")
    }
}

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    @IBOutlet weak var window: NSWindow!

    dynamic var parameterTable: Array<ParameterTableRow> = []
    
    func applicationDidFinishLaunching(aNotification: NSNotification) {
        // Insert code here to initialize your application
    }

    func applicationWillTerminate(aNotification: NSNotification) {
        // Insert code here to tear down your application
    }

}

In the AppDelegate class itself, I only added the definition of the parameterTable. Notice that this property must be made dynamic. Otherwise the runtime cannot intercept the messages to and from the property.
The parameterTable contains items of the class ParameterTableRow that for convenience was included in the same file (AppDelegate.swift).
It is advisable that the ParameterTableRow class inherits from NSObject  It must implement the KVO and KVC protocols and inheriting from NSObject is the easiest way to achieve this.

The name and value properties are displayed in the table, and the button in the table-row will call the method setButtonClicked.

Now, the part that is difficult to show: the bindings.

In Xcode/IB create a window with a table. Also create a row-like NSView that is populated with a label, a textfield and a button. In the table remove the content of the Table Cell View and replace it with the row view. The end result should look like this:


Note that I also added two buttons "add(+)" and "remove(-)" at the end.

Next, drag an Array Controller:


into the objects of this xib file. The result should be this:


The Shared User defaults Controller appears automagically, don't worry about it. We will not touch it.

The Array Controller must be bound to the parameterTable in our delegate. Select the Array Controller and open up the bindings inspector:


Under "Controller Content" open "Content Array" and bind to the delegate like this:


Since we will be using a Add(+) button to create new items in the table, we also need to tell the Array Controller which kind of items to create. Do this in the attributes inspector of the Array Controller:


Fill in the Class Name and use the fully qualified name: This starts with the project name and follows the path from there. In our case it is simply "TableBindingsExample.ParameterTableRow".

That is all for the Array Controller.

Next, lets bind the Table View to the Array Controller. We need to make two bindings, one for the content and one for the selection. Select the Table View in the object navigator of the xib file and open its bindings inspector. Create the bindings as shown below:


Forgetting to create the selection indexes bindings will cause problems later when table rows are deleted. (When the remove button only removes the last entry, you will know that you forgot this binding)

While we are at the Table View, we can also enable multiple selection in the attributes inspector:


Note the "Selection" checkbox "Multiple" is selected here to enable multiple row selection.

Next bind the Parameter Value Textfield (not the cell with the same name!!). Select the Parameter Value and open up the bindings inspector. Create the Value binding as follows:


Note that the value is not bound to the array controller but to the Table Cell View. When the runtime fills in the column, it sets the "objectValue" in the Table Cell View to the corresponding ParameterTableRow object. Hence we need to bind to the objectValue and specify the property "name" of our table row object.

Do the same for the Text Field of our table row as follows:


For the button we do not bind the content, but the target. And possible the arguments, however our target has no arguments. Bind the target of the button as follows:


Clicking the button will call the setButtonClicked method, but we want to disable the button if the textfield is empty. There is a binding for that... :



One final thing: connect the Add(+) and Remove(-) buttons to the Array Controller and connect them to the corresponding actions. Use the simple ctrl-drag for this, drag from the + button to the Array Controller object and select the "add" action. Do the same for the - button and the "remove" action. The Connections inspector should show this for the add button:


That is all, now the project should work as intended. Compile and run.
I have tried to show all the steps, if I missed something, please let me know.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-11-26

Swift Example: Using Cocoa Bindings to connect a NSTextField to a String.

Bindings are a neat way to wire up a GUI. They connect a GUI element to a variable in such a way that updates to the interface are reflected in the variable, and updates to the variable are reflected in the interface. It is a powerful concept, but there are a few snags along the way.
In the MVC parlour, a binding can (up to a point) replace a Controller. You will probably not want to go that far, but at least for simple GUI's it is possible (as we shall see in this example).

To introduce the concept, lets look at a very simple example: Connecting a textfield to a String variable.

Since this is going to be a very simple example, I want to put the variable in the AppDelegate like this:

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    var parameterId: String = "Any Name"

Here we hit the first 'snag'. This won't work since later on we need to specify the property of a container that can be bound to the textfield. So we need to introduce a wrapper class like this:

class StringWrapper {
    var str: String
    init(str: String) {
        self.str = str
    }
}

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    var parameterId: StringWrapper = StringWrapper(str: "One")

Er.. no, actually that won't work either. The StringWrapper Swift class is not KVO/KVC compliant. While it is probably possible to add the necessary protocols, it is way easier to simply inherit them from NSObject. Like this:

class StringWrapper: NSObject {
    var str: String
    init(str: String) {
        self.str = str
    }
}

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    var parameterId: StringWrapper = StringWrapper(str: "One")

That is all for the AppDelegate, the rest is done within Interface Builder.

Open up the MainMenu.xib file and make sure you display the object/property hierarchy.
Next pick a ObjectController and drop in in the "Objects", it should show up like this (the Object Controller is placed under the "Font Manager"):


Select the Object Controller and bring up the "Bindings Inspector". Here we have to set the "Content Object". Select the "Bind to" checkbox, and select the "Delegate" from the popup box after it. In the "Model Key Path" enter "self.parameterId". Once you entered "self." a popup should appear from which you can choose "parameterId". If that does not happen, check the spelling and the code in AppDelegate.swift before continuing.


Now the controller knows where to find the variable, but it does not know about the textfield the variable should be connected to. To connect the controller with the textfield, we start from the textfield. I.e. we connect the textfield to the controller instead of the other way around. This way it is possible to connect multiple textfields with a single controller, should you ever want to...

Select the "Window" and drop the "NSTextField" in it. You can also add a label should you want to.
Now select the "Text Field":



and bring up the "Binding Inspector" again. This time we edit the "Value" binding as follows:


Click the "Bind to" check box, select the "Object Controller" and enter "self.str" in the Model Key Path. The "Controller Key" remains empty (will be filled in automatically later), and ignore the warning symbol. There is no popup selection box this time (or rather, it is empty). Maybe this will be fixed in a future version of xcode.

Now compile and run the app. You won't see the updates you'll make in the textfield, to see that the variable is actually updated, add an observer:

class StringWrapper: NSObject {
    var str: String {
        didSet {
            print("New value = \(str)")
        }
    }
    init(str: String) {
        self.str = str
    }
}

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    var parameterId: StringWrapper = StringWrapper(str: "One") {
        didSet {
            print("Will never be called")
        }
    }


Notice that only the wrapper observer is called, the "parameterId" observer is never called.

One more thing: When you want to update the value of parameterId.str do not simply assign the value, but use a KVC compliant method. Thus do not:

        parameterId.str = "Will not update the view"

But do this:

        parameterId.setValue("Will update the view", forKey: "str")

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-11-23

Instantiating a Swift class unknown at compile time at runtime

In objective-C it was possible to instantiate a class at runtime just from the name with NSClassFromString. In Swift this is no longer possible, however we could still use the old objective-C method with a little extra effort to obtain the necessary names etc. All in all it does not look 'nice' to me. There should be a better way...

In general, it could be said that instantiating a class completely unknown at compile time is a questionable practise. Sure there are some situations in which we can justify anything, but usually we do know something about the class, for example that it implements a certain protocol...

And that is all that is needed to use a more Swift-like way to hop around the aforementioned restriction.

If the unknown class has to implement a known protocol we can demand that the unknown class inherits from a known class. And we can specify for a known class that it must implement a "newFromSelf" method. And we can then use the newFromSelf method to create as many new objects as necessary at runtime.

In the example below a library function is made that needs to create instances of a "data end detector". That is, a network server receives data from a client and has to know when all data has been received. However the nature of the data is not known to the library. Hence a call-back or closure is necessary that identifies the end-of-data.
A further complication arises because the end-of-data closure must be able to handle segmented data transfers. I.e. the closure must have associated internal parameters that are preserved across invocations. Hence the closure is no longer a closure but becomes a class.
And since the library function should be able to spawn multiple threads each processing its own data stream, the library function should be able to create as many instances of the end-of-data detector as necessary.

    /// An child class of this is used to find the end of the data.
    
    class EndOfDataDetector {
        
        
        /// When 'endReached' is called, this buffer pointer will point to the newly received data.
        ///
        /// - Note: The value will most likely be different on each call to 'endReached'.
        
        var buffer: UnsafePointer<UInt8>?
        
        
        /// When 'endReached' is called, bufferSize will indicate how many bytes were received.
        
        var bufferSize: Int?
        
        
        /// This function should only return 'true' when it detects that the received data is complete. It is likely that this function is called more than once for each data transfer. I.e. if the method to detect the end of the incoming data is not a unique single byte, a child implementation must be able to handle segmented reception. Every received byte-block is only presented once to this function.
        
        func endReached() -> Bool {
            return false
        }
        
        
        /// All child classes must implement the newFromSelf function if SocketUtils.accept() is used. The newFromSelf function should set the internal state of the new object into a state that allows 'endReached' to be called for the first time.
        
        func newFromSelf() -> EndOfDataDetector {
            assert(false)
        }
    }

Now the library user can create a child class from EndOfDataDetector and implement the endReached() as well as the newFromSelf() function. When the library needs a new instance for a new connection request it can simply call newFromSelf() to create a new data end detector.

An example for a detector that is used to find the end of a JSON message:

class JsonMessageComplete: SocketUtils.EndOfDataDetector {
    
    var countOpeningBraces = 0
    var countClosingBraces = 0
    
    override func endReached() -> Bool {
        for i in 0 ..< bufferSize! {
            if (buffer! + i).memory == ASCII_BRACE_OPEN { countOpeningBraces++ }
            if (buffer! + i).memory == ASCII_BRACE_CLOSE {
                countClosingBraces++
                if countOpeningBraces == countClosingBraces {
                    return true
                }
            }
        }
        return false
    }
    
    override func newFromSelf() -> SocketUtils.EndOfDataDetector {
        return JsonMessageComplete()
    }
}

In the library function we can now use something like: let newEndDetector = endDetector.newFromSelf() assuming that endDetector is the argument that the library function received.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-11-19

Namespaces in Swift, resolving collisions.

Though Swift does support namespaces, it is not obvious what the namespace is for the standard libraries. This can easily create conflicts when we want to name a function of our own making and happen to pick the same name as a standard function. And there are a lot of standard functions...

Often enough the argument list of a function will prove to be sufficient for the compile to figure out which function we did intent to call, but there are cases where the compiler needs some assistance.

For example the UNIX accept function is defined as follows:

int accept(int, struct sockaddr * __restrict, socklen_t * __restrict)

I defined an accept function with the following signature:

class SocketUtils {
        
    static func accept(socket: Int32, interval: NSTimeInterval?, timeout: NSTimeInterval? = nil) -> AcceptResult { .. }
}

Unfortunately the compiler will nag when I try to use the Unix accept function:


Obviously the compiler thinks that my own accept function should be used, while I want to use the accept from the UNIX system library.

The solution is simple: use the fully qualified name for the system function.

Turns out, the fully qualified name for any system function starts with the name of the project:

let connectionDescriptor = MyGreatProject.accept(socket, &connectedAddrInfo, &connectedAddrInfoLength)

Works just fine!

Note: The fully qualified name for my own accept function is of course:
MyGreatProject.SocketUtils.accept

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.

2015-11-16

Swift gotcha: Using the same pointer in two arguments

Working with buffers and pointers to buffers in Swift is surprisingly easy. But sometimes a shortcut can end up biting the hand that typed it...

Consider the following case:

func test(a: UnsafeMutablePointer<UInt8>, b: UnsafeMutablePointer<UInt8>) {
    print("a = \(a), \(a.memory), b = \(b), \(b.memory)")
    print("a3 = \(a[3])")
    print("b3 = \(b[3])")
    b[3] = 6
    a[3] = 7
    print("a3 = \(a[3])")
    print("b3 = \(b[3])")
}

var buf = [UInt8](count: 20, repeatedValue: 0)
var v: UInt8 = 40
for i in buf.startIndex ..< buf.endIndex {
    buf[i] = v++
}

test(&buf, b: &buf)

print(buf[3])

What would be the value printed by the last statement?
Of course this would not be a gotcha if that value was not 6.
Thing is, the function's arguments are pointers to an array, and in Swift arrays are passed by value. That behaviour seems to extend to pointers and the memory they point at.
This becomes clear if we look at the result of the first print statement in the function:

a = 0x00007fd422809950, 40, b = 0x00007fd42040c660, 40

It is clear that the pointers point to two different memory area's, but both these area's contain the same values. Then as the function completes, the memory area's are merged such that the area belonging to the later argument is copied over the area pointed at by the first argument.

This has a few implication: first is that inside the function we can be sure that pointers will point at different memory area's, even if we "know" that both pointers refer to the same base value.
The second is that there is copying overhead even though pointers are used.

Now, you may argue that the above is contrived, you would surely never use the same pointer twice in an argument list right?
Well...

Consider this case:

test(&buf[0], b: &buf[4])

This works as intended (when the test function uses the UnsafeMutablePointer  not UnsafePointer!), the printout shows that both pointer point to the same area:

a = 0x00007fcbe072bb10, 40, b = 0x00007fcbe072bb14, 44

When dealing with pointers we can also write &buf[4as &buf+the two are synonyms... right?

Nope... try this: test(&buf+0, b: &buf+4)

This yields: a = 0x00007fcbe072bb10, 40, b = 0x00007fcbe2009b94, 44

Whoa, suddenly the copying behaviour is back. This is very annoying when dealing with low level IO operations where it is sometimes necessary to pass back and forth pointers into buffers.

Using offsets and indicies as arguments is a good way to solve this potential problem.

Happy coding...

Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH

We don't get the world we wish for... we get the world we pay for.