RSS Feed

Swift on Linux

I was one of many who downloaded and ran Swift on Linux.

It’s spiffy.

But…. (you knew that was coming)

I like Swift. I’ve written what I call a “stupid parser” in Swift that performs quite admirably. But there isn’t an editor for Linux that has all the nice little bits that exist in Xcode.

That’s problem 1.

Then there is the fact that you have basically the language running in a command shell.

That’s problem 2.

I have no doubt that there are people working tirelessly (or tiredly) to get a GUI up and running that is Swift compatible. Unfortunately, those people were not Apple.

What Apple Did Correctly

If you have ever dealt with the GNUstep project (and I have on many occasions) you will discover that the applications it generates look like directories. That’s because they try to emulate what was done on NeXTSTEP – except it doesn’t quite work. Applications look like directories. Ick. The only way to make them look like applications is to run something that is (from Linux users view) nonstandard.

More ick.

Instead, Apple makes applications look like applications. Well, for the moment, they look like applications you run from the command line. That will change.

What to Expect in 2016

By the end of the year I expect there will be projects that allow you to build GUI programs. That will be spiffy.

There will be editors, probably even a playground.

What to Expect RIGHT NOW

You can build programs in Linux for x86 that run in the console. Yes, I ran a “Hello World”. Woo hoo.

And, of course, they did delegates correctly.

Microsoft has already said that they plan on supporting Swift in Windows (hopefully it won’t be a mangled version).

Swift is a nice, clean language. If you are used to C# or Objective C, then I would seriously suggest you look into it. I can easily see it surpassing both of them.

This could be the one language that rules them all.


Apple’s new language (oh, update, it’s new again), Swift

Apple has a new language called Swift.

Oh, it’s been updated, it’s new again and now all my old files don’t compile. (sigh)

One thing I really, really like about Swift is that it fixes a lot of problems that were inherent in Objective C. Don’t get me wrong, I’m a bare-metal kind of person. I really do not like interpreted languages. I can give you many reasons (speed, speed, speed), but primarily it would be speed.

Swift is the first language that I have not worried about speed. It feels like bare metal (even thought I know it isn’t – a parser that I rewrote in Swift ran HORRIBLY slow until I reworked it and make it more Apple-y).

It is a language in progress. Yes, that progress can be annoying. One day your code works, then an update arrives and now it is broken. Googling can get you answers that are completely wrong. Apple’s documentation at times is a wee bit too terse. No, what is the word that is more terse than terse? Oh, right, “missing”.

But it’s not a bad language.

So why are people actively hating on it? I suspect they have very little knowledge of other languages. For example, PERL (or PERIL) to me is a write-only language. I once was required to modify a small section. It took me ages (probably a week). But even though I KNEW what it did, it wasn’t obvious. Not because I used the secret handshake, there are at least five in PERL, but because the language is just so obtuse. This is why you see so few articles about bad PERL scripts – how would you know?

(Yes, some of you are good PERL writers, please do not inundate me with “PERL is great because…” – yes, I know the reasons, I just don’t agree)

Then we have the one language that I NEVER had a good understanding of: SNOBOL. SNOBOL is an incredibly powerful language. People have written compilers in several pages of code (I think I saw a C compiler written in five pages – sans code generator). However, it is so dense and hard to understand that it makes PERL look positively chatty.

Here is an introduction:

It starts off simple enough and looks procedural. Until you get to patterns. You have two parts that kinda-sorta work together. Here is a page laughingly titled “A Quick Look at SNOBOL”:

Okay, Hello World looks easy… what are you… holy guacamole what is THAT?!?! That would be the part where people who dream in regular expressions live.

We could delve into other languages like Lisp – a language designed for those who do not believe we have enough parenthesis in the world and who love counting them.

It’s not that I dislike these languages, I actually like Lisp, it’s that when deciding what is a good or a bad language, many of these people compare Swift only to C, C++ or C#. They think that “modern” (who came up with that moniker? PR? Shoot them) languages are good languages.

What I consider a good language is one that allows me to get something done and allows me to go back three months and understand what the hell I did (I may operate in C, C++, C#, BASH, Javascript or others depending on the situation). Something that is powerful, but initially opaque, is not a good language. Something that is terse to the point I have to look things up (like BASH) is not a good language.

Swift has the possibility of being a very good language. It certainly understands the concept of delegates better than C# does (if you think C# “delegates” are delegates, you might want to read my previous post).

Since it appears that Apple is moving all of it’s development to Swift, I have also moved my development to Swift.

Now if they will only open-source it…  =^.^=

I Hate Patch Files

I do a lot of coding in everything BUT the latest and trendiest languages for my job. Typically it is C or C++ for either small (as in 16K of RAM) microprocessors or, if I’m lucky, Linux.

Today I want to talk a little bit about patch files. You either love patch files or you hate them. Frankly, I think a lot of people hate them, that profess to love them, but that is their issue, not mine.

If you never had to deal with a patch file, the concept is really simple. The program, patch, looks for lines in the source code that match then adds or removes lines between those lines. So if the lines were “abcdefg” and the patch file was “abCDEfg” (where CDE were lines to be deleted), the result would be “abfg”.

Conceptually simple, elegant and, for the most part, foolproof.

Except for one little tiny thing. It is based on the assumption that code rarely ever changes. This is, of course, a bad assumption. Most software products have a 5-10 year lifespan (except for Windows – a whole different topic). In other words if it is code you didn’t write, don’t have control of, there IS no guarantee that it won’t substantially change tomorrow. Or next week. Or the day before you have to make that “minor tweak that shouldn’t take but a day”.

Which is why I hate patch files.

But I need the modifications, which is why I use patch files.

This is a case of there is no “right way” or “elegant way” without reinventing the wheel and maintaining it yourself.

So what is the solution? Beyond forking the project and maintaining it yourself there are only a few options:

  1. Document the order the patches need to be applied
  2. Document what each patch does (do not rely on code as documentation – it isn’t and it doesn’t)
  3. Explain how you derived the patch file. That may seem obvious now, but in three years you are going to go “wow… I must have been seriously brilliant back then”
  4. DO NOT ASSUME other people’s code will remain constant. If third party code is mission critical, keep a copy of the old code as a back up. Older code is better than no code or code that is wrongly patched.
  5. Never, ever, assume that you can just “patch and go” and slap that on a timeline projection. If the third party code has changed significantly (it will), then you will be doing yourself a disservice.

Patches are a good way to maintain tweaks to software, but they are fraught with assumptions. The best method of assuring that you don’t end up in a “redevelopment cycle” is to maintain clear and concise documentation as to what each patch does and why it does so.

You Don’t Understand Delegation

Okay, for reasons best understood by myself, I attempted to create delegates under C++ (no templates because, frankly, they just make an ugly language look uglier). I managed to hack something that worked, but have grave concerns that it is incorrect.

I was right.

In his article The Gang Of Four Is Wrong And You Don’t Understand Delegation, Jim Gay goes through what we THINK delegation is and what delegation REALLY is.

And he is right.

I spend a lot of time in Objective C. I love Objective C. It makes OOP fun. In Objective C you can do true delegation. It isn’t a hack, it is part of the language.

C++ is a lot like Darth Vader. It is the dark side. You don’t program in C++, C++ programs you (as they say in Russia). C++ is the program of “no”. NO you can’t have delegates. NO you can’t do that (because I arbitrarily said so). The list of No’s goes on and on. Why have people flocked to C#? It is less “no’ish”.

Other than that, it’s not bad. Perhaps one day I’ll write a book titled “C++ – The Good Parts” on how to write readable, useable, and most important, fun C++.

Rather than summarize a summation of a long article, read Gay’s article. It won’t take long. You will learn something important.

Time to Kill the Screen Saver

Once upon a time all good (and bad) programmers used a giant tube. This tube was called a “CRT” (cathode ray tube) which was, in essence, an electron gun pointed at their face. Between their face and the gun were these things called “phosphors” that would react when electrons came their way nudging out a photon.

At the time, we thought all was good.

Then came the discovery.

If you left a computer screen on long enough, whatever was up, whether it was Biblical text or porn would get “burned” into the screen. Oh, sure, one could just turn the screen off (a button), but that would require the programmer to move his/her hand about 8″ PLUS he/she would have to remember to press it again in the morning.

That sounded way too much like work!

Fortunately, technology came to the rescue in the form of the screen saver. This would either turn the display off or shift the contents of the display around, assuring that nothing would ever get burned in again.

The End.

Well, it would have been had not some of those dastardly technology people come up with LCD display. These displays were lighter, smaller, and in many ways better than the CRT. Best of all they didn’t use phosphor! Hooray!

No more screen burn in and no need for screen savers!

The End.

Well, it would have been if it weren’t for the fact that LCD displays ALSO have issues with static images. It appears that some of the pixels get “stuck” (or partially stuck). This can result in a “ghosting effect”.

Fortunately, there are multiple ways to fix this. One is by displaying an inverse of the screen (Apple recommends an all white image). Some programs cycle through all the pixels. The net result is that it fixes this problem and eliminates ghosting.

The End.

Well, it would be have been except these are all terrible solutions. Let’s drop back and take a look at WHY.

* Many people still use LCD’s that are lit by very thin and very narrow florescent tubes which don’t last forever
* Unless you have technical skills, it is very difficult and very expensive to replace these tubes
* In many systems displaying a “black screen” does not turn off the light

But, you may say, LED backlights eliminate that problem! Yes, however they still consume power.

We need to kill the screen saver and instead allow the computer to turn off the display.

Even better, we need “system savers” – systems that power themselves down when not in use. There are multiple ways to do this – “hibernate” under Windows brings your energy usage to nil while “sleep” cuts it in half (or more). The move to solid state drives is already happening as we seek faster systems.

We need to consider that “down time” is every bit as important as “up time” and that there are good ways and bad ways to idle our systems.

But first and foremost, we need to get rid of the screen saver. As someone once remarked, it does nothing but entertain the janitor.

Objective C on Ubuntu 12.04.3 With Blocks and ARC

Whew, just the title is enough to give you conniption fits!

The goal is to create Objective C compiler, GNUstep, and use ARC (automatic reference counting) and blocks (those cool un-threads).

My first misstep was using the instructions here – which aren’t bad, but when you try to get things working in an IDE (I use Codelite just because it seems to be pretty stable, multipurpose, and lets me modify things), things go SERIOUSLY wonky. Part of it, I think, is that Linux tries to use gobjc which is seriously not right.

So, like a good programmer, I burned things to the ground and started over.

Instead I used the instructions GNUstep_under_Ubuntu_Linux as my starting point and built a series of scripts, rather than do everything in one, big blow. It’s a lot, so please be patient.

NOTE: These instructions will NOT work for Ubuntu 12.04.1 because the compiler is too old.

Why I did what I did (raison d’être)

My eventual goal is to build a “more Linux” like application with Objective C. This means that (eventually) I wanted dynamic libraries that were “Linux-like” and an application that is “Linux-like”. The idea that an application is a directory works on the Mac, but that is not Linux. Nor is Windows Linux. Attempting to cram a paradigm in a system that refuses to accept it does not make you clever – it just makes it unacceptable by mainstream users.

And while GNUstep make is designed to create .app directories, it is, to be honest, not terribly helpful where I want to take this. CMake is a nice, rugged, dependable package that has been used for some time. No, it is not a GNUstep package, but neither is Linux. Adapt to the platform, don’t argue that you are right and everyone else is wrong.

Lastly, GCC is an old, creaky, hard to maintain compiler. LLVM/Clang is an awesome compiler that appears to be both modern and extendable. I see no reason to continue with outdated technology – we don’t do that with hardware, why persist with software?

That is where Objective-C on Linux stands today.

Step 0 – Burn it to the Ground

I initially started with a clean install of Kubuntu 12.04.03 LTS and updated all the packages that need to be updated.

You can get there from here but you have to be aware of a couple of things:

  • /usr/local/lib should not have any GNUstep libraries. If it does you may have issues
  • IDE’s are notoriously persnikety – currently I’m using Codelite but that may change
  • Finding documentation on building GNUstep is an exercise in frustration – worse some flags work and some do not. I’ll tell you how I built it and got it to work.

Because I want to make sure where things fail, I broke things up into a lot of scripts. This helped a lot in debugging things. I also used VMWare to checkmark everything. I also ran under VMWare – this allowed me to back up and retest all my scripts.

Step 1 – Download: A New Hope

Okay, to get things rolling we will need PROBABLY the following packages. I say probably because I didn’t spend time trying to weed out which ones were actually used and which ones were not. If this makes you unhappy, feel free to figure out which ones are not used.

sudo apt-get install build-essential git subversion ninja
sudo apt-get install libffi-dev libxml2-dev libgnutls-dev libicu-dev
sudo apt-get install libblocksruntime-dev libkqueue-dev
sudo apt-get install libpthread-workqueue-dev autoconf libtool
sudo apt-get install curl
sudo apt-get install auto-apt
sudo apt-get install libjpeg
sudo apt-get install libjpeg-dev libtiff-dev libpng12-dev
sudo apt-get install libcups2-dev libfreetype6-dev libcairo2-dev
sudo apt-get install libxt-dev libgl1-mesa-dev

Step 2 – Download: Cmake 2.8.12

Next we download CMake. We can’t use the one that Ubuntu 12.04 uses because it is too old. In this case it doesn’t hurt to use the latest and greatest (at this time).

curl -O
tar -xzf cmake-2.8.12.tar.gz

Personally, I really like CMake on Linux and I mostly like it on Windows (that is a whole different story for a different blog). You either like it or you hate it – rarely do I find anyone who is indifferent about it. However, in this case, we need it to build clang.

Step 3 – Get a BIG Cup of Coffee

Next we begin our serious downloads. Many of these are very large and will take some time. Note that we are not using a specific revision, but the trunk build for pretty much everything. Part of where I went wrong was attempting to use specific versions – which may work but doesn’t give you the patches and fixes that occur over the years.

git clone
svn co
svn co libobjc2
svn co gnumake
svn co llvm
cd llvm/tools
svn co clang
svn co core/gscoredata
svn co core/sqlclient

The last two (gscoredata and sqlclient) you probably don’t need and I won’t show how they are built. I need to use a database and plan to use Coredata to do so.

Step 4: Build CMake

Finally, once we have everything downloaded, we can begin our builds. The first item is CMake.

cd cmake-2.8.12
sudo make install
export PATH=$PATH:/usr/local/bin
echo 'export PATH=$PATH:/usr/local/bin' >> ~/.bash_profile

Once this is complete, you should be able to type cmake –version at the point and get the version of cmake.

Step 5: Build Clang

With CMake built we can move on to clang. Clang is possibly my favorite build because there are no errors and no warnings – it is very professional feeling code.

cd llvm
mkdir build
cd build
cmake ..
sudo make install

At this point you MAY have to create a new terminal session for everything to work correctly. If things later on complain about not finding clang, that typically seems to work for me.

Step 6: Build objc2

What is probably the most annoying part is that even though you see it referred to as “libobjc2” what gets built is, in fact, a library called libobjc and libobjcxx. The ONLY way to tell the difference (according to some) is that the eventual file is

echo "export CC=clang" >> ~/.bashrc
echo "export CXX=clang++" >> ~/.bashrc
source ~/.bashrc
export CC=clang
export CXX=clang++
cd libobjc2
rm -rf build
mkdir build
cd build
cmake ..
make debug=no
sudo -E make install

If you look in /usr/local/lib you SHOULD see and

Step 7: Build GNU make

This is one of the steps that tripped me up and tripped me up bad. Once I got it in the scripts, everything started working better.

export CC=clang
export CXX=clang++
cd gnumake
./configure --enable-objc-nonfragile-abi
sudo -E make install

I’m sure this makes more sense to someone else than it does me. To me make should not have any bearing on the code that is generated. But apparently someone else sees it differently.

Step 8: Build libdispatch

Some people recommended against building libdispatch – which to me seemed funny considering that some of these very same people argued for the custom building of clang. Color me puzzled.

export CC=clang
export CXX=clang++
cd libdispatch
./configure CFLAGS="-I/usr/include/kqueue" LDFLAGS="-lkqueue \   -lpthread_workqueue -pthread -lm"
sudo -E make install
sudo ldconfig

Note that I run ldconfig. This may or may not be necessary – at one point I got frantic and just threw them in at random (I was very frustrated). At best it helps, at worst it does nothing – but doesn’t hurt.

Step 9: Build GNUstep make

This was, by far, one of the most frustrating pieces of code to build. I had multiple configurations (one of which seemed logical) but in the end only one seemed to work. If you can figure out what I did wrong, please tell me!

export CC=clang
export CXX=clang++
cd core/make
./configure --enable-debug-by-default --enable-objc-nonfragile-abi --with-layout=gnustep
sudo -E make install
echo ". /usr/GNUstep/System/Library/Makefiles/" >> ~/.bashrc
source ~/.bashrc

At this point it is very important to open another shell to continue – if you don’t GNUstep make will whine, cry, and ask you “are we there yet?” every 10 seconds.

Step 10: Build GNUstep base

Did you open a new shell like I asked you to? Okay, but don’t come crying to me when it barfs up all over the couch like a cat.

You have probably thought “hum… I may have to go and edit ~/.bashrc and clean it up (yes, you probably will).

Building the base is… an exercise in weirdness. You must pass one item to the configure, –disable-mixedabi which, to be fair, is clear as mud. Reading the configure help and you get the following “helpful” information: “Disables the combined use of fragile and non fragile ABI so that base can be built taking full advantage of the nonfragile ABI” – because keeping track of retain/release etc. was SO much easier. Ugh. Sometimes we need to drag the community kicking and screaming into the 21st century.

export CC=clang
export CXX=clang++
cd core/base/
./configure --disable-mixedabi
sudo -E make install

When I look at development my goal is to use “best available tools”. For Objective C that is ARC and clang.

Step 11: Build GNUstep gui

This is the easiest step to build (right or wrong). The only time I had it fail was when I forgot to start a new shell after step 9 (you did start a new shell, right?).

After all the funky parameters, the GUI is pretty straightforward. Configure-make-install. Almost like it was a normal Linux program.

export CC=clang
export CXX=clang++
cd core/gui/
sudo -E make install
sudo ldconfig

Again, I don’t know if I don’t need the ldconfig or not.

Step 12: Build GNUstep back

This is what makes the gui work. If you don’t know what this is, go to GNUstep and read the documentation.

What I have discovered is that if this DOESN’T build, it’s because a) you forgot to start a new shell after step 9 or b) you did the steps out of order or c) something is missing (shrugs).  If it DOES build correctly it doesn’t mean you have a working system – if you forgot a parameter you could have built something that will puke because the ABI doesn’t match.

Lovely, eh?

export CC=clang
export CXX=clang++
cd core/back/
sudo -E make install
sudo ldconfig

Step 13: Does it Work?

As I have tried to indicate, just because all the steps went well doesn’t mean you have a working system. You could have some files from GCC (which implements Objective C that is incompatible with what we are building here… of course… because who wants a functioning system?) or you may have missed a configuration step. What it boils down to is that the only way to tell is to compile, link and run the thing.

Here is some code that Tobias Lensing wrote that is a nice test of blocks. Note that you HAVE to comment out dispatch_release(queue); for this to compile under ARC.

Create the following code and save it in a file called test.m

// main.m
// Just a little test case for Objective-C 2.0 on Ubuntu
// Created by Tobias Lensing on 2/22/13.
// More cool stuff available at
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#import <dispatch/dispatch.h>
int main(int argc, const char * argv[])
        int multiplier = 7;
        int (^myBlock)(int) = ^(int num)
            return num * multiplier;
        NSLog(@"%d", myBlock(3));
        dispatch_queue_t queue = dispatch_queue_create(NULL, NULL);
        dispatch_sync(queue, ^{
            printf("Hello, world from a dispatch queue!\n");
        //dispatch_release(queue);  // can't use this under ARC
        [NSApplication sharedApplication];
        NSRunAlertPanel(@"Test", @"Wow it works!", @"OK", nil, nil);
    return 0;

And compile it using the following:

clang `gnustep-config --objc-flags` -fobjc-arc -fobjc-nonfragile-abi --fblocks -lobjc -ldispatch -lgnustep-base -lgnustep-gui `gnustep-config --objc-libs` test.m

This should create a file called a.out (surprise!). Executing this file should display:

2013-02-24 01:08:20.981 main[6710] 21 Hello, world from a dispatch queue!

as well as a GUI box that looks something like this:


The following are scripts that I used to create a working Objective C with GNUstep and ARC. Feel free to use them.

Step 14: Putting this in an IDE

I’m currently using the Codelite IDE to write with. For the most part it is well done except for environment variables – it doesn’t appear to use the ones in the shell. In order to get it to link I had to add –L/usr/GNUstep/Local/Library/Libraries so it would pick up the libgnustep-base and the libgnustep-gui.

Step 15: Making it Look like a Linux Application

The biggest problem with GNUstep is that it doesn’t act like a Linux application. First, menus pop up as a strange, separate block. To get them to look like, well, menus, type this on a console:

defaults write NSGlobalDomain NSInterfaceStyleDefault NSWindows95InterfaceStyle

Next is this weird icon or miniwindow. If you are running KDE or Gnome, it just looks ugly and out of place. To fix this, use the following:

defaults write NSGlobalDomain GSSuppressAppIcon YES

Where do we go From Here?

Eventually the goal is to reduce the runtime so that bundles rather than being directories (or worse, directories of directories) appear to the user as dynamic libraries.

However, for the moment, we will stop here.


My World and Welcome to IT


My name is Cat. I’m old. Don’t ask how old because I won’t tell you. I apparently started this in an alternate dimension because I don’t remember starting a WordPress account.

So there you go.

However, it accepted my password (“1234” just FYI but don’t tell anyone) so it must be mine. Actually, my spouse, Neko, asked if I don’t have multiple personalities.

We’ll know if I post comments to my post.


Get every new post delivered to your Inbox.