New Adventures in Software by Dan Dyer

To accompany the first release of the Watchmaker Framework, I’ve posted the first two parts of a tutorial that shows how to use it:

• Part 1 – A Brief Introduction to Evolutionary Algorithms
• Part 2 – Implementing Evolutionary Algorithms in Java with the Watchmaker Framework

Part 3 will be up sometime soon(ish) and will demonstrate how to solve a real problem with Watchaker and EAs.

As usual, constructive comments, corrections and suggestions are all welcome.

Version 0.1 of the Watchmaker Framework for Evolutionary Algorithms is now available for download from the project page on java.net (where you will also find details of implemented and planned features). The framework requires Java 5.0 and a familiarity with generics.

Feel free to download and play. You can leave comments and suggestions here or on the project site.

The Watchmaker Framework for Evolutionary Algorithms brings the power of evolution to Java with a simple and flexible API. This is still very much work in progress but, if you are interested, there is working code and examples available from the Subversion repository. Suggestions for improvements are encouraged.

My workaround for NTLM support with Subversion in IDEA 5.1 is not necessary with the latest early-access version of IDEA 6.0, which seems to have all-round better support for Subversion, as well as a bundle of other neat features.

Having configured the Apache to perform authentication for Subversion using the Windows Domain controller, I was disappointed to find that IntelliJ IDEA’s Subversion plug-in (svn4idea) does not currently support NTLM authentication. Like SmartSVN, which does support NTLM authentication in its latest incarnation (version 2.0.2), svn4idea is based on the javasvn library.

Armed with this information, I thought I’d see what would happen if I dropped SmartSVN’s javasn library over the top of svn4idea’s. The good news is that it mostly works. The only issue I have come across is that the svn4idea plug-in fails to load when the IDE is restarted if you configure it to save your credentials. With IDEA 5.1.1 the IDE just hangs on start-up and with 5.1.2 you get an error dialog.

This situation can be avoided by not checking the “save credentials” box when you are prompted for your Subversion username and password. Instead you will have the minor inconvenience of entering your password once per session. If your credentials are already stored on disk and the IDE is not starting, delete the credentials.xml file in the svn4idea configuration directory (on Windows you’ll find this somewhere under C:Documents and SettingsyournameApplication DataSubversion).

A word of warning: this configuration is almost certainly not supported by JetBrains.

A few years ago I knocked up a Log4J appender that used ANSI escape sequences to colour-code log messages based on their priority. This is quite an effective way of dealing with the information overload from console logging without having to disable the lower log levels. Your eyes are immediately drawn towards the more important messages but the detailed information is still there for you to diagnose the problems.

Unfortunately I can’t get it to work under Windows (even using Cygwin), but if you are using an ANSI-enabled terminal (such as most of the Linux terminals), it’s pretty helpful. It’s also trivial to implement, so here it is:

import org.apache.log4j.ConsoleAppender;
import org.apache.log4j.Level;
import org.apache.log4j.Priority;
import org.apache.log4j.spi.LoggingEvent;   
 
/**
 * Colour-coded console appender for Log4J.
 */
public class ANSIConsoleAppender extends ConsoleAppender
{
    private static final int NORMAL = 0;
    private static final int BRIGHT = 1;
    private static final int FOREGROUND_BLACK = 30;
    private static final int FOREGROUND_RED = 31;
    private static final int FOREGROUND_GREEN = 32;
    private static final int FOREGROUND_YELLOW = 33;
    private static final int FOREGROUND_BLUE = 34;
    private static final int FOREGROUND_MAGENTA = 35;
    private static final int FOREGROUND_CYAN = 36;
    private static final int FOREGROUND_WHITE = 37;   
 
    private static final String PREFIX = "\u001b[";
    private static final String SUFFIX = "m";
    private static final char SEPARATOR = ';';
    private static final String END_COLOUR = PREFIX + SUFFIX;   
 
    private static final String FATAL_COLOUR = PREFIX
      + BRIGHT + SEPARATOR + FOREGROUND_RED + SUFFIX;
    private static final String ERROR_COLOUR = PREFIX
      + NORMAL + SEPARATOR + FOREGROUND_RED + SUFFIX;
    private static final String WARN_COLOUR = PREFIX
      + NORMAL + SEPARATOR + FOREGROUND_YELLOW + SUFFIX;
    private static final String INFO_COLOUR = PREFIX
      + NORMAL+ SEPARATOR + FOREGROUND_GREEN + SUFFIX;
    private static final String DEBUG_COLOUR = PREFIX
      + NORMAL + SEPARATOR + FOREGROUND_CYAN + SUFFIX;
    private static final String TRACE_COLOUR = PREFIX
      + NORMAL + SEPARATOR + FOREGROUND_BLUE + SUFFIX;   
 
    /**
     * Wraps the ANSI control characters around the
     * output from the super-class Appender.
     */
    protected void subAppend(LoggingEvent event)
    {
        this.qw.write(getColour(event.getLevel()));
        super.subAppend(event);
        this.qw.write(END_COLOUR);   
 
        if(this.immediateFlush)
        {
            this.qw.flush();
        }
    }   
 
    /**
     * Get the appropriate control characters to change
     * the colour for the specified logging level.
     */
    private String getColour(Level level)
    {
        switch (level.toInt())
        {
            case Priority.FATAL_INT: return FATAL_COLOUR;
            case Priority.ERROR_INT: return ERROR_COLOUR;
            case Priority.WARN_INT: return WARN_COLOUR;
            case Priority.INFO_INT: return INFO_COLOUR;
            case Priority.DEBUG_INT:return DEBUG_COLOUR;
            default: return TRACE_COLOUR;
        }
    }
}

This should work with both the latest version of Log4J, which includes a TRACE level, and the previous versions. Using it is simply a matter of making sure the class is on the classpath with Log4J and referring to it from the configuration file.