Earlier this week, I attended the Oracle Partner Network day in London. I got attend many interesting presentations, and learned a lot about what's going on in the Oracle world.

As it has been a long time since I've used Oracle, this morning I decided to install Oracle on my iBook G4 with 512mb RAM. Officially, Oracle on OS X is only supported on OS X Server, so I was prepared for this to be a bit of a challenge.

The Oracle 10g Installer

I spent the afternoon playing around with the Oracle setup and got it working in the end. While I was running the Oracle Database Configuration Assistant (DBCA), the virtual memory usage on my laptop peaked at over 15 gigabytes, and things were getting pretty slow at this point. Having a gigabyte or two of RAM would have helped a lot here.

Processes ordered by VSIZE, and VM size peaking at over 15gb.

I had to change some things in init*.ora to get the database working. Each of the things I changed was in response to an error message thatI got while running 'startup':

• ORA-00205: error in identifying controlfile, check alert log for more info
  To correct this, I set the correct paths in the CONTROL_FILES parameter
• ORA-01103: database name 'SANDY' in controlfile is not 'DEFAULT'
  To corret this, I set the DB_NAME parameter to the name
• ORA-00201: controlfile version 10.1.0.2.0 incompatible with ORACLE version 10.0.0.0.0
  To corret this, I set the COMPATIBLE initialization parameter to 10.1.0.3

Success: Oracle 10g running on Mac OS X Tiger

Tonight I did some work on Wildcat BZR's diff and merge preferences. The preferences dialog now has a list of diff and merge tools that it know about, and can be chosen from a drop down list. Additional diff and merge tools can be supported by specifying the executable and what parameters must be supplied for diffing and merging operations.

At the moment, the following tools are know about, and I will be expanding this list when I have more spare time:

1. SourceGear DiffMerge
2. KDiff3
3. Apple opendiff

Earlier this week, I read Scott Hanselman's article about the Microsoft DLR team's LOLCODE implementation for the DLR. It's a good a read, and excellent news for the LOLCODE community.

Not wanting to see Mac (and Linux) users being left behind, I decided to get the DLR implementation of LOLCODE running on OS X under Mono. The tools required for this job are:

• Mono 1.2.6 (Preview 2)
• IronPython 2.0 Alpha 6 (for the Microsoft.Scripting assembly)
• Gardens Point Parser Generator (GPPG)
• Gardens Point Scanner Generator (GPLEX)
• LOLCODE for the DLR (Source code)
• This Makefile

Unzip everything, and place the Makefile in the LolCode directory, where the LolCode.sln file is. You may need to edit the paths at the top of the Makefile to ensure the referenced assemblies can be found. With a terminal window open in this directory, run make.

You should now have a working implementation of LOLCODE for the DLR on Mono. Please note, that although this can compile with Mono 1.2.5, it needs 1.2.6 to run properly.

A brief Wildcat BZR update...

Today I fixed the branch dialog in Wildcat BZR which was displaying correctly on OS X but not on Windows and Linux. Here is what it looks like now, running on Ubuntu:

Today and tomorrow, I'm on holiday from work. After having a pretty lazy weekend, I've decided to make my short holiday productive. I've installed Common Lisp and Ruby on Rails on my iBook, and have been playing around with Lisp, getting to know its syntax.

I've been cleaning up various directories full of text files on my iBook and have come to the conclusion that I have so many notes scattered around the place that I'm probably losing track of some things. The solution? A wiki. I'm playing with Instiki. It seems to meet my requirements, and was pretty simple to set up on OS X. Here are the steps I took:

1. Installing Ruby 1.8.5 from here
2. Installing rubygems from here
3. sudo gem install rails --include-dependencies
4. sudo gem install sqlite3-ruby --include-dependencies
5. unzip instiki 0.12.0
6. Run ./instiki

Then, pointing a browser at http://localhost, you'll be prompted to specify some details about the Wiki, and then be forwarded to the wiki's homepage:

While driving home from work today, I was thinking of how to write an algorithm in C# 2.0 that takes a string representing a multi-line text file, and return the lines, one at a time.

I know Mono's System.IO.StringReader class can do this, but I was thinking there must be a more efficient way of doing it. Here's what I came up with:

 public class LineReader
 {
     private string _source;
 
     public LineReader(string src)
     {
         _source = src;
     }
 
     public IEnumerator GetEnumerator()
     {
         bool finished=false;
         int nextChar=0;
         int readTo;
         string nextLine;
         while(!finished) {
             readTo = _source.IndexOf ('\n', nextChar);
             if (readTo==-1){
                 readTo=_source.Length-1;
                 finished=true;
                 if (readTo<nextChar){
                     yield break;
                 }
             }
             nextLine = _source.Substring(nextChar,readTo-nextChar);
             nextChar = readTo+1;
             yield return nextLine;
         }
     }
 }
 

Timing tests show that with the following test harness running on my 1.33GHz iBook G4 running Mono 1.2.5, parsing a 1000 line text file 1000 times takes 2.7 seconds on average using this algorithm and 3.4 seconds on average using StringReader.

 public static void Main(string[] args)
 {
     StreamReader sr = new StreamReader("sample.text");
     string test = sr.ReadToEnd();
     System.DateTime start = DateTime.Now;
     for (int i=0;i<1000;i++){
         LineReader lineReader = new LineReader(test);
         foreach (string s in lineReader){
         }
     }
     System.DateTime finish = DateTime.Now;
     double seconds = (((double)finish.Ticks) - ((double)start.Ticks)) / 10000000;
     Console.WriteLine("{0} seconds",seconds);
 }
 

Yes, StringReader handles both LF and CRLF line endings, and has a PushBack method to allow jumping back to the previous line, but for pure speed of parsing standard text with LF line endings, this algorithm seems to be around 20% faster than StringReader, and 30% faster than using Split to turn large string into an array of one string per line.

Update on 14th November 2007:
I ran the same tests on Windows XP with Microsoft .NET 2.0, on a dual core 3GHz PC, and produced this graph which compares various ways of splitting the large string into one string per line:

The source of Wildcat BZR is now available on Launchpad and there is a homepage which has a list of features, screenshots and a roadmap. It has been tested on Windows XP and OS X. It should also work on Linux. The external diff and merge support is somewhat limited at the moment. Everything is explained on the project page.

I have re-worked the algorithm for reading the directory structure and Bazaar status of files in Wildcat BZR, and verified that it works correctly on Windows XP:

I started writing a Bazaar client this weekend. After two days, here's what I've got:

Currently supported features are:

• Init
• Commit
• Add
• Pull
• Merge
• Push
• Commit
• Merge using an external merge tool

I've only tested it on OS X at the moment, but it should be able to work on any platform that supports wxWidgets (Linux, Windows, Mac, etc). There are a few things I want to clean up in the application before I release a 0.1 version on the Internet:

• Dialogs like the commit and add ones need their layout made nicer
• At the moment, only Apple's FileMerge is supported as an external merge tool. I plan on getting SourceGear's DiffMerge working as well.
• I need to add diffing and history support
• I need to change the way it walks the directory tree, as it's slow with large projects

Today I wrote a Bazaar plugin for CruiseControl.NET. Having Bazaar work with our continuous integration system was the next step in evaluating it as a Subversion replacement. The plugin was simple to write, and is available on Launchpad.

It's been 3 and a half months since the last release. During that time I've moved to a new flat, and been pretty busy with work, so haven't had a lot of time to work on the COBOL compiler.

This release introduces support for writing sequential data files. My target for this release was to have it compile the example "students.cbl" from the University of Limerick's Intorduction to Sequential Files correctly. I came across one issue in doing this: The tutorial has a PERFORM loop specified as:

PERFORM UNTIL StudentRec = SPACES

I've been following IBM's VS COBOL II grammar which doesn't cover non-arithmetical relational conditions in PERFORM loops. My code which makes this work is not the most elegant solution, but it does get the job done.

Version 0.1.14 of the Wildcat COBOL Compiler is available in both source and binary form here.

The other thing that's been taking up my time recently is the experimentation I've been doing with version control software (aka source code management software). Over the past 4 weeks, I've been using Bazaar a lot. It's the version control software used by Canonical's Launchpad. I have created a project on Launchpad for the Wildcat COBOL compiler.

Last week, I set up the Bazaar version control system on Solaris 9. I installed the following packages:

• python-2.5.1
• pycrypto-2.0.1
• paramiko-1.7.1
• bzr-0.90

I got the Python package from the Sun Freeware site, and installed it using pkgadd. The two python modules - pycrypto and paramiko - were installed using these commands:

python setup.py build
sudo python setup.py install

Bazaar, being written in python, was also installed using the setup.py script. I discovered a small problem when building Bazaar on Solaris 9: _dirstate_helpers_c.h attempts to #include stdint.h, which doesn't exist and results in a "No such file or directory" error. To get around this problem, I changed that line to include <sys/types.h> instead. Building Bazaar after that went smoothly.

When using Bazaar on Solaris 9, make sure that /usr/local/lib is in your LD_LIBRARY_PATH.

I set up the Bazaar distributed version control system on three machines today (two Macs and one Debian), after Kevin mentioned it a couple of weeks ago. Iplayed around with merging and branching - it seems pretty similar to Git, and I'm not sure what all of the advantages and disadvantages are. Git seems marginally faster, but Bazaar seems to be simpler to install on different platforms (it has a native Windows version, and doesn't need Cygwin like Git does). On OS X and Linux, Bazaar's installation was as simple as Git's.

To get SSH support in Bazaar, it needs the pycrypto and paramiko Python libraries installed. They're available from Debian's repository, but on OS X, I had to install them manually.

I plan on using Bazaar for Wildcat COBOL's version control, so I'll be able to give a more detailed account of how good I think it is and compare it to Subversion later.

I installed git on my iBook today as some of my projects are starting to become rather large, and in desperarate need of some form of revision control. Installing git was simple. I used fink to install expat first, then installed git from source, which went flawlessly.

I've played with branching and merging, and it all works nicely. This is the first time I've seen merging go 100% smoothly with no human interaction. No more Subversion for me, apart from at work.

If you've not tried git yet, give it a shot, and if you don't know why it's better than everything else, watch this video.

It's that time again - a new version of the Wildcat COBOL Compiler for Mono and .NET is out. Version 0.1.13 introduces experimental support for reading sequential data files, and making use of level 88 data definitions. I'll explain these advances in some more detail...

Consider the following excerpt from the fileread.cbl program which is included in the version 0.1.13 ZIP file (click to enlarge):

This code opens a file, and reads the first line. This data is stored in the StudentFile record which has been declared in the FILE SECTION of the DATA DIVISION. The code then loops until EndOfStudentFile evaulates to be true. EndOfStudentFile was declared as a level 88 member of the StudentFile record. Level 88 is special in that it can be used to store and test for certain conditions. Here, it is used to indicate whether or not the end of the sequential data file has been reached.

Inside the loop, the DISPLAY statement prints out the values of some parts of the StudentFile record, then the next record is read from the file, until the end of the file has been reached. When the end is reached, EndOfStudentFile is set to true, and the loop exits.

The READ statement can have "AT END" and "NOT AT END" sections inside it, which specify code to execute when each of those conditions is true.

This diagram shows the logic the compiler uses when compiling READ statements:

The code used in this example is based on Introduction to Sequential Files from the University of Limerick.

I put together a CCNet Dashboard Widget for OS X. This is a dashboard widget that shows the status of CCNet automated software builds. Here's a screenshot:

I realise this widget has a very limited target audience as it's for OS X and CCNet traditionally runs on Windows, but I found some information relating to running CCNet on Mono recently: here and here.

In my limited spare time, I've managed to add integer and string types to my COBOL compiler for .Net, and also add the ability to type stuff in at the command line. Numbers, strings and things typed in at the command line can now be set as the values of existing variables. The next step will include floating point numbers, the COBOL equivalent of structs, and maybe some maths.

Click the image to watch the flash movie...

I spent a little time this evening beginning to write my .Net COBOL compiler. After that, I played around with software for recording what I'm doing on my desktop and saving it as a Flash movie. Click on the image below to view a quick preview of the compiler in Flash...

Since last Tuesday afternoon, I've been learning about and implementing a secure key exchange and encryption algorithm, using Blowfish and the Diffie-Hellman key exchange. I've been doing this in C, using the freely available BigDigits library for dealing with large prime numbers. I've found the BigDigits library to be very handy, and it seems to be quite efficient. I've written my own functions to wrap up Blowfish in a way that character buffers can be passed from one machine to another over the network, with encryption that's transparent to the application (at the socket level). Next, I'd like to get the same thing working in C#, but I discovered today that the C# library provided be the people who wrote BigDigits actually just imports Win32 DLL functions and presents them in a nice .Net-friendly way. I'm intending my code to run on Mono as well as Microsoft .Net, so I think writing the algorithms in pure C# is the approach I will be taking. |

apt-get install dpkg-dev patch dh-make debhelper devscripts gnupg lintian diffstat
I'm now ready to make my first Debian package. I've spent most of this morning/afternoon reading up on Debian and Ximian development mailing lists. Unfortunately tonight I also found some more problems with Mono on Debian/SPARC after running 'make check', so I don't have anything of interest yet.

I found this in my notes today at work. It is a simple way to get a list of people who have edited a file in a CVS repository:

cvs log | grep author | awk '{print $5}' | sort -u

We use CVS a lot at work. I've started playing around with Subversion at home, but have found that the database needs rebuilt sometimes, which I don't like the feeling off. I'm worried that the corruption that happens sometimes could lead to data loss. Reminds me too much of Source Safe :-(