Archive for June, 2005

LAT 0.5.4 Released

I’m pleased to announce the release of LAT 0.5.4. Changes since 0.5.3:

  • SSL support
  • Allow drag and drop LDIF export from search results
  • Wrote man page
  • Added pt_BR translation
  • BUGFIX: Fixed build errors in lat.spec.in

Download a copy today!

Sunday, June 26th, 2005

LAT - Brazilian Portuguese Translation

Got a nice surprise this morning, a Brazilian Portuguese translation for LAT courtesy of Pablo Borges. I’ve checked it into the code repository if anyone wants to try it out.

Thursday, June 23rd, 2005

NASL Interpreter

I’ve been doing some work on the NASL interpreter the last couple of days. I did some minor code cleanup and I’ve started on creating stubs for the built-in functions.

As it stands today, the interpreter can take .nasl scripts and run them through a parser and lexer based on the NASL grammar. The functions and variables are recorded in a symbol table and then we start to interpet the code.

Once I’ve written code for all the stubs the interpreter will start working and be useful. I had gotten stuck working on this before but I think I’ve got a better handle on it this time.

Monday, June 20th, 2005

Sussen 0.12

Sussen 0.12 has been released. See the release notes and/or download a copy.

Monday, June 13th, 2005

GNOME News

Forgot to mention this on Friday but I saw that Jeff Waugh was looking for RSS feeds of announcements and news from GNOME-related projects. I sent him the feeds for Sussen and LAT. He thought they were cool so he added them to the GNOME News site.

Sunday, June 12th, 2005

RPMs and NUnit

Spent some time installing a copy of Fedora Core 3 in VMWare. Took a bit of time but it’s all working now.

I set this up so I could start on creating a .spec file for creating RPMs. I’ve created these before but this time I’m trying to create multiple packages from a single .spec file. Lots of trial and error there.

The other thing I’m working on is NUnit. I created a simple test (following one of the Mono samples):

using System;
using NUnit.Framework;

namespace SussenTests.Sussen.Oval
{
        [TestFixture]
        public class LorenTest
        {
                [SetUp]
                public void SetUp()
                {
                }

                [TearDown]
                public void TearDown ()
                {
                }

                [Test]
                public void TestSomething ()
                {
                        Assert.AreEqual (12, 12, "Integer");
                }
        }
}

I got it complied fine but I was kind of stumpped on how to run it. The documenation refers to two utilities nunit-console.exe and nunit-gui.exe but I didn’t have any of those in my Mono install.

Since I know the Mono guys are definitely using NUnit tests I started digging around their source tree and reading Makefiles. I discovered that Mono does build nunit-console.exe but doesn’t install it.

So I grabbed the source (it’s a very small program) and built it and tried running the test:

$ ./nunit-console.exe test.dll
NUnit version 2.2.0
Copyright (C) 2002-2003 James W. Newkirk, Michael C.
Two, Alexei A. Vorontsov, Charlie Poole.
Copyright (C) 2000-2003 Philip Craig.
All Rights Reserved.

OS Version: Unix 2.6.11.10    Mono Version: 1.1.4322.573

.
Tests run: 1, Failures: 0, Not run: 0, Time: 0.051508 seconds

So that works, but it looks like I’ll need to include nunit-console.exe in Sussen. That shouldn’t be a huge issue but it would be nice if it was included in Mono by default so I didn’t have to worry about it.

I mean why integrate NUnit into Mono if you are not going to provide the tools to use it? Maybe I’m just missing something. I’ll have to check on the Mono mailing list archives later and see if I can figure out how this came about.

Thursday, June 9th, 2005

Build System Update

Did some work this morning on the autotools-based build system and it’s now possible to only build certain parts of Sussen.

The configure options are –disable-client, –disable-agent and –disable-server

This should allow us to create separate binary packages for each component instead of having an all-in-one solution. My current thinking for package names is this:

  • sussen-common
  • sussen-agent
  • sussen-server
  • sussen-client

Wednesday, June 8th, 2005