Stati of Projects

I’ve been jumping around from one project to another on an as-needed basis, and here is the current status of each.

RIEL – I’ve been updating the colorizing code, adding the functionality to use extended color codes on ANSI terminals, instead of the default 10.

Glark – In the midst of a major rewrite, for both code purity and functionality. The main changes so far are extensions to the path/file arguments, bringing in some functionality from find. Glark will also (with the imminent integration of RIEL) support extended colors.

PVN – This project was in heavy development until a month ago, when it went into a state of waiting for updates to Glark, since it will be using Glark for its seek (searching) subcommand.

DiffJ – This project I rewrote in JRuby, but that was a little too slow for a command-line application –  even heavily tweaked, I couldn’t get the startup time under two seconds. So I re-rewrote it in Java, and intend to revisit it to add more intelligent code comparisons, such as understanding that “if (a == b) foo();” is the same as “if (a == b) { foo(); }”

IJDK – Mostly dormant at this point. When I’ve rewritten Java projects, I’ve tried to extract the generic code from them and add them to IJDK, but I haven’t been heavily involved with any of my Java projects lately.

Java-Diff – A while ago this was brought up to date to use generics, and was refactored for code clarity. There hasn’t been any reason to update it since then.

DoctorJ – Alas, this is dormant. Some of its warnings have been integrated into the Java compiler, such as mismatched parameter names. It still goes beyond that level of pedanticalness, so it is most suitable in the development of projects where documentation is paramount, such as APIs.

Related posts:

Adding setup and teardown to RubyUnit Test Suite

The tests for pvn raise an interesting question to me. The pvn subcommands that wrap/extend the svn subcommands process the svn output, so the tests need svn output to run.

I’ve considered doing mock objects for svn, but that became confounding, where I was essentially mocking all of the svn subcommands that I need. So I’m leaning in the direction of doing operations against a “real” Subversion repository. On a 234M Subversion repository, it takes around 0.4 seconds to do a backup (cp -r), when both the source and the target locations are on the SSD in my machine.

So it’s feasible for the test sequence to be:

  • back up the svn repository (0.4 seconds)
  • check out the svn repository checked out to working copy (4 seconds)
  • working copy modified, with added, changed and deleted files and directories (< 10 seconds for all tests)
  • svn repository restored to backed up version (1 second)

I’m still considering how to go about this, but in the meantime I’ve written the following for adding suite-wide setup and teardown for the pvn base testcase. Note that this is on a class:

require 'runit/testcase'

module PVN
  class TestCase < RUNIT::TestCase
    include Loggable

    WIQUERY_DIRNAME = "/Programs/wiquery/trunk"

    class << self
      def setup
        @@orig_location = Pathname.pwd
      end

      def teardown
        Dir.chdir @@orig_location
      end

      def suite
        @@cls = self

        ste = super

        def ste.run(*args)
          @@cls.setup
          super
          @@cls.teardown
        end
        ste
      end
    end

Project pvn

pvn, here on GitHub, is my newest project, a front-end to the Subversion command-line program “svn”. This program will unite my various svn programs, such as svndelta, and my various scripts.

I’ve been building it from scratch, with a core of commands wrapping those in svn, and new commands. At this point the only more-or-less fully working subcommand is log, which extends svn log to use “relative revisions” (explained below), and displays colorized output. I plan to add the functionality so that a user can set the format and colors for log output.

What is probably the most innovative functionality in pvn is that revisions may be “relative”, meaning that +N is the Nth revision, and -N is the Nth revision before the most recent one. In a large project, revision numbers can get into the six and seven digits, and it’s much easier to think of “the latest checkin I did”, as opposed to “my checkin with revision 317127”.

I don’t have a timeline, but my goal is to have the functionality of the log and diff subcommands implemented by the end of the year.