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:

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.

As of this evening, the Wildcat COBOL Compiler for .NET is now able to compile the 99 Bottles of Beer program, although when executed, the PERFORM loop runs one extra time at the end producing the following output:

Two bottles of beer on the wall, two bottles of beer! Take one down, pass it around, one bottles of beer on the wall!

One bottles of beer on the wall, one bottles of beer! Take one down, pass it around, one bottle of beer on the wall!

One bottle of beer on the wall, one bottle of beer! Take that down, pass it around, no more bottles of beer on the wall!

I'll fix that later when I'm not so tired, and get the next build online.

The first Wildcat COBOL compiler for .NET build has been made avialable here this evening. Some more general information is available here. This release has the ability to compile the simple "Hello World" program. I intend releasing another build fairly soon, with more complete support for variable subscripts and substrings - the only things preventing it from compiling the 99 bottles of beer program at the moment.

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.

Yesterday I began looking at technologies to use for a new project at work. I've narrowed my preference of programming language down to Java or C#, based on the systems the software will need to run on and what it needs to do. As a bit of a challenge, I thought I'd start off by getting the necessary tools installed on my Debian SPARC workstation. After much messing around with Jikes and the GNU Java compiler, I ended up using Jikes, Kaffe and Jikes-kaffe (a wrapper allowing Jikes to use Kaffe's classpath). On SPARC, Jikes segfaults unless Jikes-kaffe is installed, although Jikes-kaffe is not a dependancy.
Today I started looking at the C# approach. I installed Mono on Mac OS X and wrote my first multithreaded C# application using my favourite text editor, SubEthaEdit. I've started building Mono from source on Debian SPARC, but pthread support is b0rked, so I'll need to fix that myself - I doubt if many people care about Mono on Debian SPARC.

Update 20 mins later...
I've got pthread support working in Mono now. Looks like a configure script error causing things not to be defined properly. I'll make a patch for that later once I've found out exactly why it went wrong.