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.

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:

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.

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.

A colleague pointed me in the direction of lolcode - a programming language based on the lolcats. I found many compilers/interpreters on the website, and the one that really caught my eye was LOLCode.NET - a lolcode compiler for Microsoft's .NET runtime.

I just *had* to try that on Mono. Here's a screenshot of it working perfectly under Mono 1.2.4 on Mac OS X:

Update:
You can get the source code via SVN by following the instructions here. If you're trying to compile it on a Unix-like system (eg Linux, OS X), you'll need to place this Makefile in your lolcode-dot-net directory, and run make.

I've read a few reports which have mentioned a problem with .NET's String.IsNullOrEmpty static method where under certain circumstances it can cause a null reference exception at runtime. Bill at MSMVPS.COM has as article with some sample source code that can be used to test this problem.

I've done some experimentation and found that it only occurs when a program is compiler in release mode and run outside of the development environment on a PC with .NET 2.0 installed. Debug builds are not affected and neither are computers running Mono.

It looks like this may be a bug in the optimizations performed by Microsoft's .NET CLR or JIT on Windows. Microsoft have posted an article addressing this issue and have stated that it will be fixed in the Orcas CLR beta 1.

Needless to say, the .NET developer community are shocked that a flaw in the CLR with such serious consequences as this will not be fixed in the current version, but instead people will need to upgrade to a new and relatively untested technology preview.

The first bug has been reported by Pieter. There was an assembly missing from the list of files to be included in the binary release. The makefile has now been corrected and version 0.1.11 has been made available with the missing assembly included in the ZIP file. This problem affects all releases from 0.1.7 to 0.1.10. The symtpoms of the problem are this error message being displayed when trying to compile COBOL programs:

** (/usr/local/lib/cobolc/cobolc.exe:26939): WARNING **: The following assembly referenced from /usr/local/lib/cobolc/cobolc.exe could not be loaded:
Assembly: Wildcat.Cobol.Compiler.References (assemblyref_index=1)
Version: 0.0.0.0
Public Key: (none)
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/local/lib/cobolc).

This release now includes support for use of AND and OR in IF statements. The amount of language features remaining to be implemented before the compiler is actually useful is getting smaller :-)

As always, the latest release if available here.

The release includes updates to the NUnit tests for testing if statements like this:

Writing the rest of the IF statement unit tests will be boring, but will ensure that future changes don't break anything. I also plan on making sure the rest of the NUnit Assert methods work, as I've not used many of them yet in COBOL.

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.

This is another milestone in the development of the compiler - being able to compile COBOL programs that use GTK#. Again, I believe this may be the first time anyone's written a GTK# program in COBOL. The screenshot below shows the example from Mono's GTK Sharp beginners guide translated into COBOL and running on Mono on OS X.

The compiler can be downloaded from here. Some GTK# COBOL source code will be in the example section soon.

Today I compiled and ran my first Cocoa# application in COBOL - probably the first time anyone's ever had a working Cocoa# application written in COBOL.

The Wildcat COBOL Compiler now supports referencing packages like mcs does, which made this strange mix of technologies possible. It feels strange running a COBOL .NET GUI application on OS X.

The updated compiler and source is available here and the example is available here. Here's a screenshot of my Cocoa# test application running:

Tonight I got the Towers of Hanoi from kernelthread.com compiling with the Wildcat COBOL .NET compiler. I've packaged up version 0.1.6 of the compiler which can be downloaded from here, and the release notes are here.

The Wildcat COBOL compiler has been updated so that all math operations are implemented, although rounding and error handling are not finished yet. The latest release includes this update, the NUnit tests for the changes, and a version of Hello World using classes from the .NET framework which has been tested on Microsoft .NET, Mono and Portable.NET. This release also has improved compiler error handling. The development of the compiler is now taking a test-driven approach as support for NUnit progresses.

After adding experimental support for using .NET classes and attributes in COBOL source code, and some playing around with System.Reflection, I was able to get the Wildcat COBOL Compiler to compile a program that contains an NUnit test, and run it from NUnit's command line utility.

More information about running NUnit tests for COBOL programs, including example source code and GUI screenshots, is available here.

I had to add a couple of new things to the COBOL syntax, but kept them in line with what Fujitsu have already done in their NETCOBOL implementation for .NET.

Here is the program I wrote - you can see the simple NUnit test at the end:

000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. FRAMEWORK-TEST.
000030 AUTHOR. SANDY DUNLOP.
000040*Testing .NET COBOL Extensions
000050
000060 ENVIRONMENT DIVISION.
000070 CONFIGURATION SECTION.
000080 ATTRIBUTES "TestFixture".
000090 REPOSITORY.
000100     CLASS SYS-STRING AS "System.String"
000125     CLASS SYS-CONSOLE AS "System.Console"
000136     CLASS NUNIT-ASSERT AS "NUnit.Framework.Assert"
000140 DATA DIVISION.
000150 WORKING-STORAGE SECTION.
000160 77 NET-STRING OBJECT REFERENCE SYS-STRING.
000170
000180 PROCEDURE DIVISION.
000190 MAIN-PARAGRAPH.
000200     MOVE "Test Prog" TO NET-STRING
000210     INVOKE SYS-CONSOLE "WriteLine"
000220         USING BY VALUE NET-STRING
000210     STOP RUN.
000230 TEST-PARAGRAPH WITH ATTRIBUTES "Test".
000240     MOVE "teststring" TO NET-STRING
000250     INVOKE NUNIT-ASSERT "AreEqual"
000260         USING BY VALUE "teststring"
000270         USING BY VALUE NET-STRING
000280 END PROGRAM FRAMEWORK-TEST.

I plan on writing some NUnit tests for the compiler now, and making it all available online over the coming week.

The Wildcat COBOL Compiler for .NET can now compile the 99 Bottles of Beer program, and the output runs perfectly on both Mono and Microsoft .NET. Version 0.1.2 of the compiler is available for download here. The program that I compiled is slightly different to the one I found on the Web - two of the strings in the Working Storage section are defined differently.

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...