Tuesday, January 17, 2017

Swift write-ups

I have written a dozen or more files on Swift-related topics and put them on github here.  I like markdown, it's easy and portable and it works well on github, which is also easy.  I've been using the MacDown editor.  I like it too.

The stuff I like the best is a detailed look at libraries and frameworks on macOS, which got big enough that I broke it out into another repository here.

I haven't posted regularly on blogger in 4 1/2 years.  People still come by.  My Swift posts from Dec 2015 have about 1100 page views, and those from last week more than 70.  I hope that at least one person finds value in one of these posts.  That would be enough for me.

I know there is stuff on the site that is broken or outdated.  If you would like to revisit a topic, please let me know in a comment.

Wednesday, January 11, 2017

More about Swift

It's always something.  I decided I was done with the math book on Thursday.  On Friday,  I started thinking about Swift.  It took me a day to get in the groove again updating a lot of Playgrounds from Swift2, and then the weekend and this morning to update SudokuBlocks to SudokuBlocks3.

I plan to do some write-ups on various Swift topics, but I probably will not update the Swift2 book.

The first write-up is not just an .md document but also an Xcode project.  It describes how to make a Swift app with a custom view and a window controller, drawing on Hillegass and other stuff I've picked up.  It shows how to communicate between the window controller, the view, and simple Swift classes in the project.  It is quite simple, but may help someone, so that's why I'm publishing it.

It is on github here.  The README tells the story, and the project is there as well.


SudokuBlocks again

My app for Color Sudoku stopped working on macOS Sierra.  So I got up to speed with Swift3 and migrated the code so it will build and run again.  The project is in a public repo on github.

It is pretty cool, if I say so myself.  In addition to doing Sudoku without symbols, just using colored blocks, there are some bells and whistles.  There is a facility for hints



You can set breakpoints to try a branch and return easily to that point.  You can load and save puzzles from text files.  The app contains a number of puzzles of different degrees of difficulty.  I can put a copy of the app on Dropbox once I figure out the new public link system, if there is any interest.

Thursday, December 8, 2016

new book

I have written a new book, called Integration for fun. It is 18 MB on Dropbox here.

I enjoyed writing it and I hope someone actually finds it useful. I would be grateful to hear about errors or other issues.

Wednesday, December 23, 2015

Command line swift

It is perhaps quixotic (unrealistic or impractical), but I like doing things without Xcode sometimes. Xcode is a complicated beast. So in testing code I've been doing

swift test.swift

from the command line, updated from

xcrun swift test.swift

which I used to do.

I was excited to find that it is possible to use code in more than one Swift file, like this:

swiftc file1.swift main.swift -o prog
./prog


Credit:
http://stackoverflow.com/questions/29089861/how-to-import-modules-without-an-xcode-project-in-swift


Reading the man page for swift and swiftc I find these ideas:

swiftc -emit-library card.swift

which runs and gives libcard.dylib but I have no idea how to import it from Swift.

There is also -emit-module, which gives card.swiftdoc and card.swiftmodule but I have no idea how to use them.

Maybe I should look inside Xcode and try to figure out how it accomplishes what it does?

CommonCrypto5

I came across another introductory article about how to import CommonCrypto from Swift.

Recall what we did before following this post:

Method 1:

- obtain a bridging header by adding a dummy Objective-C file in Xcode
- in the header, do #import <CommonCrypto/CommonCrypto.h>

The library functions will be available from an Xcode Swift Cocoa app project.

Method 2:

Make CommonCrypto quack like a Framework by putting a file module.map with appropriate code, inside the directory that holds OS X SDK frameworks:


/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform\
/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks


With that single change:

- we no longer need the bridging header from an Xcode project
- we can use CommonCrypto in a framework
- we can use it in an Xcode Playground

- we can also do this:


test.swift:
import CommonCrypto
print(CC_SHA1_DIGEST_LENGTH)

> swift test.swift
20
>


The referenced article shows a different way to use CommonCrypto inside a framework (where the bridging header trick won't work).

Put the module.map

module.map:
module CommonCrypto [system] {
header "/usr/include/CommonCrypto/CommonCrypto.h"
export *
}


inside your project directory (not necessary to use Xcode). Following the instructions:

Now add the new module to Import Paths under Swift Compiler – Search Paths in your project settings. Use ${SRCROOT} in the module path (e.g. ${SRCROOT}/CommonCrypto) to insure that the project works no matter where it’s checked out.

Then you can just use import CommonCrypto.

Other notable items:

- use of NSData and NSMutableData types for the buffers
- size_t(key.length) and size_t(data.length), in calling the functions

Tuesday, December 22, 2015

Swift 2 book

I've been reworking my "book" on Swift, to update from Swift 1 to 2 and add some more examples. It is still early days, but after a week of work I am ready to put up a rough draft here.

You can read it right there on github, or you can clone the project and build the html with Sphinx if you have that. Here is a gist of a small part of it: