This is part of a series on FootlessParser, a parser combinator written in Swift.
I find these steps helpful when setting up any new open source framework project in Xcode.
Create a new project in Xcode, and select OS X framework if it is for both iOS and OS X. The iOS framework target can be added later, besides OS X frameworks are more practical for unit testing. No simulators needed.
Do not select to add it to Git right away. Because of this.
And that’s it. I so do love a fresh project.
Create root folders “tests” and “source” and move stuff in place in Xcode
The file structure of Xcode projects looks better, especially on GitHub, if the code for the product itself is in “source” and the test code in “tests”. It’s better than just dumping all Xcode targets in the root folder. Especially for this project, as it will have test targets for both unit tests, speed tests and integration tests.
Share the only scheme.
Schemes are not shared by default in Xcode. It’s best to share this now since you’re bound to be making changes to it in the future, and if it’s not shared no one else will receive those changes. While you will be merrily coding along, assuming what you see everyone else sees too.
Which licence to release open source code under is of course entirely a matter of preference. Personally I agree most with the Eclipse licence because I would prefer anyone who make any changes to make them public and open source as well. But I also want my open source projects to be available to as many people as possible, and the MIT license is very popular and compatible with most other licences, including GPL. And it is used by all the open source frameworks this project uses. It is also very short, which is always a good thing for legalese text.
Upload to GitHub
After adding some actual code it’s time to share the work with the world. It is easiest to use GitHub for Mac as it both creates the project on GitHub and uploads the code.
This post is part of a series on FootlessParser, a parser combinator written in Swift.
The goal is to define parsers like this:
let parser = function1 <^> parser1 <*> parser2 <|> parser3
parser will pass the input to
parser1 followed by
parser2, pass their results to
function1 and return its result. If that fails it will pass the original input to
parser3 and return its result.
- a function which takes some input (a sequence of tokens) and returns either the output and the remaining unparsed part of the input, or an error description if it fails.
- a single item from the input. Like a character from a string, an element from an array or a string from a sequence of command line arguments.
- Parser Input
- most often text, but can also be an array or really any collection of anything, provided it conforms to CollectionType.
Initially FootlessParser will be the simplest possible implementation of a parser combinator in Swift. It will:
- have at least rudimentary error reporting, because it makes writing parsers so much easier.
- not parse ambiguous grammars. Each parser will return at most one result, not a list of all possible results.
- not handle left recursion. Like most parser combinators.
- probably be slow. It’s going to be very interesting to see how slow.
- Memoization, should help with speed.
- Left recursion.
- Ambiguous grammars (maybe).
- SequenceType as input.
This post is part of a series on FootlessParser, a parser combinator written in Swift.
Before Swift my only contact with functional programming was a couple of half-hearted attempts at reading Erlang, all of them resulting in me running away screaming, clutching my aching head. But learning functional concepts in Swift proved far easier, probably because the syntax is closer to what I was used to. So I read Functional Programming in Swift and everything was well and good until one of the last chapters, “Parser Combinators”, and the headache was back. Luckily I managed to stay quiet and in place this time. I downloaded the code for the chapter, turned it into a framework and hacked away until I had implemented a CSV parser, but I still didn’t really understand it.
The parser library from the book has 6 swift files and more than 50 functions (including operators), all but 10 consisting of only one line. Stepping through the code in the debugger lead to a call stack a mile long where I never seemed to reach a function that did some actual work and then returned, instead it appeared to be just functions all the way down. I don’t mean this as criticism of the chapter in particular or functional programming in general, it is more a description of my lack of understanding at that point. So to improve on that and understand functional programming and parser combinators better I am implementing one myself; FootlessParser.
The name comes from the scientific name for Swifts, “Apodidae”, from Greek “apous” meaning “without feet”. The word also has alternate meanings, depending on how the parser turns out it will either be apt or self-deprecating, in any case two of my favourite things.
I will write about the development here. There doesn’t seem to be any complete parser combinator frameworks in Swift out there, hopefully this will be useful to others as well.
BTW I really do recommend the book for anyone interested in functional programming and Swift, it is well written (and offers a real challenge in the last chapters).
When creating a new project in Xcode it is best to leave the “Create Git repository” box unchecked because it will immediately add all files to Git, including those that are specific to you and are of no interest to anyone else. Instead you can run this script from the project folder, which will add only the files that should be under version control:
# create the ignore file
cat > .gitignore <<_EOF_
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
git add .
git commit -m 'Initial commit'
Many people are, like me, unable to use a keyboard and mouse/trackpad for longer periods of time. The solution, as always, is to use your head.
Moving the Mouse Pointer
iTracker doesn’t automatically start controlling the mouse pointer when launched, even if you tell it to in the preferences. Nor will it do anything when you click the icon in the menu bar and select “Track” from the menu. It will only start working when you press the global keyboard shortcut for pausing and resuming iTracker (Cmd-Shift-T by default).
iTracker is the only Mac head mouse software I know of that actually works. It uses the web camera on your Mac to locate your face, see which way it is moving, and move the mouse pointer accordingly. Sounds weird, but it quickly becomes second nature. After adjusting speed and sensitivity you should be able to reach all corners of the screen just by turning your head.
In The ultimate word processor, I described my ideal application for writing. Here is a much more thorough description of its key features and basic workflow:
It’s a bit hard to classify, but here goes:
- Integrated Writing Environment:
Like the Integrated Development Environments (IDE) programmers use, it tries to provide writers with all the tools they need, and lets them adapt it to their workflow.
- Semantic Text Editor:
It lets you describe what the text means as opposed to how it looks.
- Word Processor:
This term is normally used for Word, OpenOffice, Pages etc, but these are more page layout applications than literally “word processors”. TextSmith, with its various plug-ins for importing, transforming and exporting text, can literally perform “word processing”.
But the best description is probably just “Writing Application” (as in; an application for writing).
The ultimate writing software should let you:
- go back to any previous version of any part of the text.
- keep different versions of the same part of the text, and easily switch between them.
- focus on content and structure.
- write any type of text meant for humans.
- export to any format imaginable.
- collaborate with other people.
In May 2004, Adam C. Engst wrote about WriteRight: The Writer’s Word Processor where he laid out his idea of the perfect word processor. Over 6 1/2 years later there is still no such thing. Scrivener is a major leap forward but I feel it is still lacking in some areas, so here I have outlined my own ideas for the perfect writing software. Unfortunately all the good names are taken. The mediocre ones too. So I give you:
Continuing from last week’s ideas for Scrivener‘s corkboard, here are some suggestions for the rest of the application.
Preview when configuring a compile
When it’s time to get my writings out of Scrivener, there will often be a lot of back and forth to get the output just the way I want it. It would save a lot of time if there was an instant preview when configuring the compile settings.
Link to media files
If I drag a movie into the Research folder the entire file is moved into the project. This makes the project file way too big, so instead I create aliases of movies and import them. This works fine, but I lose the ability to play the movie inside Scrivener. It would be nice to have the option to link to media files instead of importing them. I know you can link to files in “Document References”, but then they are hidden away somewhere in the Inspector and easily forgotten.
Export files by drag & drop
I have collected a lot of PDF files in the Research folder, but if I drag them out of Scrivener and onto the desktop nothing happens. I can export using File – Export – Files…, but dragging is quicker and more intuitive.
When I open a project that has been synchronised with a folder and there are changes in that folder, Scrivener very helpfully informs me of this and asks if I want to synchronise the changes back into the project. But if I make changes in Scrivener and then close the project without synchronising with the folder first, which I often do, nothing happens. It would make for a better workflow if the synchronisation occurred automatically when opening and closing the project.
This is just nitpicking really, but there could be an option to enforce one text format for a document. That way I can forget about how the text looks and focus on the content. All this boils down to is make “Paste and Match Style” the default action when pasting and dragging text.
Scrivener is an excellent application and the closest anything has come to a great word processor (as opposed to a page layout application, which is what most word processors really are). Fiction and non-fiction writers alike love it, and I fully recommend it for writing anything longer than a blog post. But it’s so full of functionality and customisation options that it can be a bit unintuitive at times. So here are a few ideas for improvements.