What's it all about, Alfie?

Amazing, but they did it. Apple lifted the NDA on all iPhone developers. Great. I guess the pressure worked. Good enough. I've already heard that the Pragmatic Programmers are back 'on' with their iPhone development book. Nicely done. I'm not in the market - yet, but when I am, it'll be nice to know these guys have a book that I can get as PDF and view on my MacBook Pro.

Well... that's been an unusually awkward period for Apple. I'm glad it's over. The Good Guys are better than that.

I've been working exceptionally hard these last few days, and it should come as no surprise that it's a thankless, horrible job, but they saddled me with it and rather than drag it out, I want to get get this crap done, and move on. Unfortunately, this will probably mean that I'll be rewarded with even more horrible and distasteful work on this project in the future. I suppose on one had I should be happy that in these times I have a well-paying job in the financial sector. But I tell you this... I'd easily work for less to do something that wasn't as distasteful.

Even this place, a year ago, was a better place. But this Death March project that I'm being forced to be on is just draining my will to live. It's bad. But I'm trying my best to stay optimistic - tonight I'll get more than 4.5 hrs. sleep, and that will be a welcome relief.

I've got people looking, but so far nothing really exciting where the work is at least as interesting as this, and is a long-term commitment. No more short-term consulting jobs. I just sure hope this horrible crap is over soon.

This morning I got word that the MacVim maintainers released Snapshot 35 with several bug fixes and added features including faster drawing. I had to get it right away.

After some testing I'm still a bit surprised that the ATSUI renderer is not proving to be any faster on my MacBook Pro than the default renderer. My last theory that they are both being backed by the same Core Graphics methods would lend weight to the non-difference, and that might be effected by the graphics card being used. So maybe on a slower box or worse graphics card, the difference is clear, but on mine they are dead even.

Not bad... just interesting. I love Vim.

One of the support crew in London pointed out to me that a Money Market ticker in one of the applications fed from my ticker plant was not updating properly. That the quote from my source had both the bid and ask less than zero was interesting. What happened was the conversion I did from working in "all positive" price to "mixed sign" prices on the calculation of 'Best Price' in the client code had a bug. Basically, there is a test for a 'good' quote that the bid and ask are in the right relation to one another - with a little 'fudge' factor, and also that they are not horribly disparate either.

The problem code looked like:

    if (((fabs(mAsk) <= 0.5) ||
         (1.1*fabs(mAsk) >= fabs(mBid))) &&
        (fabs(mBid)*1000.0 > fabs(mAsk))) {
      retval = (mBid + mAsk)/2.0;
    }

where the firs check is to make sure that if the ask is small enough we don't mess with the check - like 0.05/0.10 quotes. The second check is the problem... without the fabs() calls, it works for positive numbers: of the ask is bigger than the bid, and the ask isn't too much bigger than the bid, then we take the mid point. Easy.

But if we put the fabs() calls in there and try to work with negative numbers, we're messed up. Negative bids need to be numerically less than the asks but with the fabs() calls, they get flipped to being numerically greater than the asks. This is the problem.

If we change the code to look like:

    if (((fabs(mAsk) <= 0.5) ||
         ((mBid - mAsk)/fabs(mAsk) <= 0.1)) &&
        (fabs(mBid)*1000.0 > fabs(mAsk))) {
      retval = (mBid + mAsk)/2.0;
    }

then we're looking at the percentage change and that works for both signs - positive and negative.

I put this into the clients and things started ticking nicely - if you can call a negative price quote 'nice'. It was just interesting to me that I thought I had it right the first time, but you have to be very tricky about throwing around fabs() in your code.

I was looking at iTerm again this morning as a new version was released and I had forgotten that they had an option to remove the vertical scroll-bars on the windows and still have a scroll-back buffer activated by the multi-touch gesture on my MacBook Pro. This was a nice feature. So I thought - I wonder if it's possible with Terminal.app? Answer: No, not really.

I googled a lot of hits and all said they got it working, but I think they got it working on a previous version of Leopard - not 10.5.5, because everything they mentioned that 'worked' I tried and it didn't work. Not a bit. I looked into the nib file and no lock there, but I think I got a hint at the reason it's not possible any longer: Terminal.app allows the user to resize the window.

If you have that working, then there needs to be some 'area' or buffer on the right side of the window where the resize gadget fits, and if you try to remove the scroll bar, you run into trouble. Firefox 3.0.1 had this problem on Liza's MacBook Air - you need the status bar at the bottom to 'hold' the resize widget or you get into trouble. So the solution would have to be that if you didn't want the scrollbar, you'd have to remove the resizing widget and then the user may not easily know how to resize the window.

But that seems reasonable - and from what I'm hearing on the Google hits, it was working. It's too bad they took it out. Oh well... maybe in Snow Leopard they'll put it back - or at least use a consistent set of scrollbars for all windows.

This morning Apple released a new Software Update for Java on Mac OS X 10.5 and 10.4. For Leopard, Java is now updated to 1.6.0_07, 1.5.0_16, and 1.4.2_18 - all nice updates to their respective major versions. I haven't done any real code tests to see if it's that much faster, but it's an important development platform for me, so it's nice that they stay on top of the updates from Sun.

In the end - it's Java, what can you say?

"Necessary."

In a previous post I discussed getting Git running on Mac OS X 10.3.9 - which is what's running on frosty my Snow iMac G3 in my office. It would be running 10.4 if it had a DVD drive, but it's still fine and every now and then it's a hassle - like with installing Git, but in the end I have Git 1.6.0.2 running on it just fine, and that's what really matters.

This installment is about getting public and private access to the Git repositories that I'm planning on hosting on this box. While you don't have to have a central repository for team members to sync with, I will work this way as it also provides people with a way to anonymously get the repo and decide if it's got something for them.

Private Repository Access

While the traditional way to handle Private repo access is to have accounts on the machine for each team member, I'm going to use Gitosis. This is a neat little package that allows you to simply have the id_rsa.pub SSH public keys for the users and then have a single user (git) handle all the authentication and push/pull work with Git.

Let's get started. The first thing I did was to add the user 'git' to my Mac using the traditional System Preferences application. Just add them with a password, etc. that you know (it will not be visible to the team members) and then you're ready to go to the next step. Typically, this places the files for the account into /Users/git and that's OK with me as the repositories will be placed in a directory off this users' $HOME directory.

The Python that comes with OS X 10.3.9 is Python 2.3, and we're going to need a more up-to-date version - say 2.5. I got this from the PythonMac.org website. Install it and then make sure that /usr/local/bin is very near the beginning of your path (and the path for the 'git' user). Make sure that you have this in the right place by checking:

  $ python -V
  Python 2.5

If you get the right response, you're looking good.

Unfortunately, Gitosis is going to need a little more and that "little more" is the Python library 'setuptools'. We have to get that, and install it, which is pretty simple:

  curl -o setuptools-0.6c8-py2.5.egg \
      http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c8-\
              py2.5.egg#md5=1721747ee329dc150590a58b3e1ac95b
  sh setuptools-0.6c8-py2.5.egg

the URL in the second and third lines is really one line and you have to make sure to have the name of the file exactly as indicated as that's used by the installer to know what to do. Once this is done, we're ready for the next step - installing Gitosis.

While the Gitosis talks about the location of the install, I've found that it's good advice and there's only one little hitch on OS X 10.3.9 - that is, that the Gitosis commands are not deposited in the PATH. So, we need to get the package and install it:

  su - git
  git clone git://eagain.net/gitosis.git
  cd gitosis
  sudo python setup.py install

and then symlink the executables from their install locations on OS X 10.3.9 to the obvious - /usr/local/bin:

  cd /usr/local/bin
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-init .
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-run-hook .
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-serve .

At this point, we're ready to initialize Gitosis for the one user (me):

  su - git
  cd /Users/git
  gitosis-init < /Users/drbob/.ssh/id_rsa.pub
  chmod 755 repositories/gitosis-admin.git/hooks/post-update

where the SSH public key file (/Users/drbob/id_rsa.pub) can be from your other machine, or where ever - I just happened to already have all my public keys on this server, so it's easy.

A point worth mentioning is that the last chmod command is needed because the setuptools doesn't properly set the execute permissions on the file and they need to be set in order for Gitosis to work properly.

We're ready to us the private access! I have already set up the DNS entry for git.themanfromspud.com to point to the machine, and put a hole for port 9418 in my router/firewall for this guy, so I can say from any machine:

  git clone git@git.themanfromspud.com:gitosis-admin.git
  cd gitosis-admin

and I'm ready to go!

At this point, it seems reasonable to follow the outline of steps here to add groups and users based on their SSH RSA public key files. I haven't needed to do that yet - but certainly will as time goes on. Got all the notes I need in VoodooPad.

Public Repository Access

This doesn't look as bad as the other, but it took me a lot longer as I was stumped trying to figure out why it wasn't working. Basically, I wanted to add git:// as an xinetd service to the box, and I was getting a ton of errors like:

  $ git clone git://git.themanfromspud.com/gitosis-admin.git
  Initialized empty Git repository in /Users/drbob/gitosis-admin/.git/
  fatal: The remote end hung up unexpectedly

To start at the top, you need to make sure that we have the line for the protocol in /etc/services:

    git   9418/tcp       # Git Version Control Repo Viewer

and then in /etc/xinetd.d you need to create a file git-daemon which contains:

    # default: off
    # description: The git server offers access to git repositories
    service git
    {
        disable = no
        socket_type = stream
        wait = no
        user = git
        env = PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/libexec/git-core
        server = /usr/local/libexec/git-core/git-daemon
        server_args = --base-path=/Users/git/repositories/ --export-all --inetd
        log_on_failure += USERID
    }

and then send a kill -HUP to the xinetd process. The tricky point for me was the env = PATH=... line - without it the xinetd process does not know the path to the executables even with the path specified! So make sure it's there. After this, you should have the protocol working so you can say:

  $ git clone git://git.themanfromspud.com/gitosis-admin.git
  Initialized empty Git repository in /Users/drbob/gitosis-admin/.git/
  remote: Counting objects: 5, done.
  remote: Compressing objects: 100% (4/4), done.
  remote: Total 5 (delta 0), reused 5 (delta 0)

I have an old(er) Snow iMac G3 at home that I use for my CVS pserver and I wanted to get it working as my Git repo hosting server as well. The problem was that I didn't have a working Git executable for 10.3.9, and so I needed to get it from source and build it from scratch. This is all the little work I had to do to get that to work. Later, I'll discuss getting the repo hosting going, but that's gotta wait until after I get this done.

I had to get a lot of packages to make this all work, but now that I have them, getting new versions of Git should be easy. Lots of up-front work, but worth it in the end. As a matter of personal preference, I put all the projects in my ~/Developer directory, but you can put them in /usr/local/src or some other place. It really doesn't matter. Also, while you can specify any PREFIX you want, I've chosen the traditional /usr/local so that everything is thrown in there - for all packages.

NOTE: if all you're interested in doing is getting Git running on OS X 10.3.9 - then skip to the section at the end about Git - that's all you need. The rest of this preamble is all about being able to generate the man pages (docs) for Git, and since I am planning on using this for a while, it seemed reasonable at the time (HA!) to do it. What a lot of work for a few man pages.

A Big Help was provided by this page where a lot of the steps were the same, but a lot had to be changed. It was a good place to start, and he clearly, like me, wanted to have it all with Git, and went through the effort to figure it all out. Kindred spirits...

gettext

The problem is a chain of dependencies that OS X 10.3.9 doesn't have. In order to make the build in a "no failure" stream (that means building the core components first, and then get to the successive ones later) we need to start at the bottom. The bottom in this case is gettext. We need it for getopt. We need getopt for xmlto. We need xmlto for building the Git docs. Simple, but a lot of tedious work.

In order to install gettext we need to get it, configure it, build it and install it. Like most good GNU projects, it's pretty clear (if not short and quick):

  curl -o gettext.tar.gz http://mirror.anl.gov/pub/gnu/gettext/gettext-0.17.tar.gz
  tar zxvf gettext.tar.gz
  cd gettext-0.17
  ./configure
  make
  make check

which should look OK on the outputs, and then install it with:

  sudo make install

getopt

The next piece of the puzzle is GNU getopt as it's got the support for the long options - as opposed to the single-character kind in the getopt on OS X 10.3.9. So to get this guy installed we needed to:

  curl -o getopt.tar.gz \
      http://software.frodo.looijaard.name/getopt/files/getopt-1.1.4.tar.gz
  tar zxvf getopt.tar.gz
  cd getopt-1.1.4

but there are a few edits that are needed to make this work on 10.3.9. The first is in the Makefile itself. Change:

    LIBCGETOPT=1

to:

    LIBCGETOPT=0

and then change:

    LDFLAGS=

to:

    LDFLAGS=-lintl

At this point, we can make it and install it:

  make
  sudo make install

There were still errors in the make, but they aren't a problem at this point.

DocBook (XML Catalog)

Because xmlto is the key player in this fiasco, and because OS X doesn't have the default DocBook XSL stylesheets and XML files, we need to create them. It's not too bad, just make room for them, download them, and install them:

  sudo mkdir /etc/xml
  sudo xmlcatalog --noout --create /etc/xml/catalog
 
  sudo mkdir -p /usr/local/share/docbook/xsl
  cd /usr/local/share/docbook/xsl
  sudo curl -o docbook.tar.gz \
     http://voxel.dl.sourceforge.net/sourceforge/docbook/docbook-xsl-1.74.0.tar.gz
  sudo tar zxvf docbook.tar.gz
  mv docbook-xsl-1.74.0 1.74.0
  sudo xmlcatalog --noout \
     --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xsl/1.74.0/catalog.xml' \
     --create /etc/xml/catalog
 
  sudo mkdir -p /usr/local/share/docbook/xml
  cd /usr/local/share/docbook/xml
  sudo curl -o docbook4.2.zip \
     http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip
  unzip docbook4.2.zip
  sudo mkdir 4.2
  cd 4.2
  sudo unzip ../docbook4.2.zip
  sudo xmlcatalog --noout \
     --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xml/4.2/catalog.xml' \
     --create /etc/xml/catalog

Lot of work for something I don't plan on using, but that's the very nature of this exercise, it seems. Very time-consuming.

xmlto

Now that we have everything this guy needs, he's pretty simple (HA!) All we need to do is to get the package, configure, make and install:

  curl -o xmlto.tar.bz2 https://fedorahosted.org/xmlto/export/1/xmlto-0.0.21.tar.bz2
  tar --bzip2 -xvf xmlto.tar.bz2
  ./configure
  make
  make check
  sudo make install

AsciiDoc

The last requirement for the docs is to get asciidoc installed on your machine. So let's get the AsciiDoc project as a tarball from it's downloads page - or use curl, as I did:

  curl -o asciidoc.tar.gz http://www.methods.co.nz/asciidoc/asciidoc-8.2.7.tar.gz
  tar zxvf asciidoc.tar.gz
  cd asciidoc-8.2.7

In the INSTALL file in the project, it explains that you might need to edit a few of the directory locations, and sure enough, I did. The biggest one is the location of the Vim support files. To do this, change the line in the install.sh file to look like:

  VIM_CONFDIR=/usr/share/vim/vim62

which is where Vim's support files are for OS X 10.3.9.

There is a problem in asciidoc with regards to the usage of /etc on Mac OS X. The fact is on OS X, /etc is really /private/etc and so this bug was reported, and the fix is to change asciidoc.py line 127 (or thereabouts) from:

      directory = os.path.abspath(directory)

to:

      directory = os.path.realpath(directory)

At this point, you are ready to install asciidoc by simply following the INSTALL instructions:

  sudo ./install.sh

Git

If you're just interested in getting Git running - no docs, then you can start the process here. It's pretty simple - get, configure, make, and install:

  curl -o git.tar.gz http://www.kernel.org/pub/software/scm/git/git-1.6.0.2.tar.gz
  cd git-1.6.0.2
  ./configure
  make
  sudo make install

If you followed all this crazyness, and want to install the docs (man pages) as well, then you can type this:

  make all doc
  sudo make install-doc

and then make sure that you have /usr/local/share/man in your MANPATH to pick these guys up.

At this point, you're ready to use Git, and if you went through all the work I did, you can view the man pages as well. Took a couple of hours, but it's worth it in the long run - I plan on using Git for a while.

Now I need to get a server set up - which is what caused this detour in the first place...

I've gotten through most of my book on Git, and I have to say, for something that's so easy to use in a stand-alone mode, getting it going on a server for sharing is incredibly difficult. Now I see the point of Gitosis.

Gitosis is a open source project written in Python 2.5 to manage the Git repository scheme with a single account and supposedly make it easier to handle all the set-up issues of Git. Well... after digging through this all, I have to say it seems to make things easier. But 'easy'? Not in a million years. I've put up CVS servers in a few minutes - and Gitosis might make it easier, but it's still a serious pain in the neck. And this doesn't cover the git:// read-only access - this is just for the SSH-based uploading.

I'm going to have to take some time to work through all this, taking notes as I go, because there looks to be a ton of steps to get right in order to be able to host a Git repo. Then there's gitweb - the web viewing tool, and git-daemon - the read-only git:// server. This is going to take a while.

I was setting things up for Git and I came across the setting to have the Git 'merge' command actually pull up an external application - and in this case opendiff. I had always used FileMerge.app from my old NeXTSTEP days (it wasn't called that, back then, but it was the same tool), and loved the way it showed my differences in as concise a way as possible. It's really pretty impressive graphics work for a file diffing tool.

What I didn't know about was the fact that Apple had aliased the command-line opendiff to the FileMerge.app! Now I could easily use this diffing tool in all kinds of places. I was really jazzed. I do love working on this platform.