RSS Feed

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 http://www.cmake.org/files/v2.8/cmake-2.8.12.tar.gz
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 https://github.com/nickhutchinson/libdispatch.git
svn co http://svn.gna.org/svn/gnustep/modules/core
svn co http://svn.gna.org/svn/gnustep/libs/libobjc2/trunk libobjc2
svn co http://svn.gna.org/svn/gnustep/tools/make/trunk gnumake
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
svn co http://svn.gna.org/svn/gnustep/libs/gscoredata core/gscoredata
svn co http://svn.gna.org/svn/gnustep/libs/sqlclient/trunk 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
./bootstrap
make
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 ..
make
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 libobjc.so.4.6.

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 libobjc.so and libobjcxx.so.

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
make
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
sh autogen.sh
./configure CFLAGS="-I/usr/include/kqueue" LDFLAGS="-lkqueue \   -lpthread_workqueue -pthread -lm"
make
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
make
sudo -E make install
echo ". /usr/GNUstep/System/Library/Makefiles/GNUstep.sh" >> ~/.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
make
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/
./configure
make
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/
./configure
make
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 blog.tlensing.org.
//
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#import <dispatch/dispatch.h>
int main(int argc, const char * argv[])
{
    @autoreleasepool
    {
        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
    }
    @autoreleasepool
    {
        [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:

linuxObjcTest

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

https://github.com/feloneouscat/UbuntuARCandObjectiveC

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

Hi,

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.

Follow

Get every new post delivered to your Inbox.