Archive for the ‘What I’m working on’ Category

Day three

February 3, 2009

I committed and pushed yesterday’s new stuff to the github repository. I’m blown away by the power and functionality of git/github.

Plan

  1. Clone the new Python test cases (KernelCoreLoadsTest and SystemConfigurationTest) into the Ruby branch.
  2. Design and build test cases that validate the behavior of the Kernel.ClassDevelopment subassembly (ClazzCreator, ClassDefinitionDescriptor, ZtxWorldBuilder). This subassembly builds ALL the subclazzes used by Zeetix, after the initial Kernel is loaded — assuring that each subclazz is built the same way. This subassembly also provides the behavior that does the right thing for “schema migration” — changes to a clazz with both instances and subclazzes. This is particularly crucial for Zeetix because a Zeetix ecology is always alive — it must be possible to create, load, unload, and forget clazzes on the fly.
  3. Design and build test cases that specify Assembly/SubAssembly behavior. This distinction is missing from the spike solution, and needs to be there. A subassembly is loaded and unloaded atomically, and inherits its prerequisites (and therefore dependencies) from the assembly that contains it. An Assembly determines which subassemblies to load based on runtime constraints such as language choices, platform capabilities, and so on.
    Design and build test cases that exercise loading persistent clazzes from the zeestore. While this behavior doesn’t seem critical to get ZeeUnit up and running — and therefore perhaps should be deferred — it seems so central to the larger paradigm that I fear the consequences of ignoring it. I know, I know — “YAGNI”. I’ll try to resist.
Advertisements

Day 2 progress

February 2, 2009

KernelCoreLoadsTest done

KernelCoreLoadsTest is running in Python. It demonstrates that SystemConfiguration, It, Behavior, Clazz, and Metaclazz are each present, along with their metaclazzes.

SystemConfigurationTest

SystemConfigurationTest is running in Python. This demonstrates that SystemConfiguration and its metaclazz are correctly wired together and correctly installed into the kernel core framework. This clazz is built “by hand”, instead of by the Kernel.ClazzDevelopment assembly, because portions of it are needed while the Kernel metastructure is being built.

This test exercises the behavior that was broken when I began this exercise, so that it doesn’t get broken again in the future.

First bug found and fixed!

February 2, 2009

One of the more important pieces of Zeetix plumbing is SystemConfiguration.

This clazz loads the current “ecology” (something like a Smalltalk image or Lisp environment). It’s loaded with clazz methods that do important things like load the kernel clazzes, construct the kernel namespace, and so on.

The very first test is “KernelClassesLoadedTest”, verifying that all is present and correctly stitched together. The very first clazz tested is SystemConfiguration. Boom. The clazz exists (nothing would work otherwise), but is missing from the global namespace. Bad bad bad. Zeetix MUST have the ability to load and unload assemblies (collections of clazzes, something like Ruby Gems), and that in turn demands run-time access to SystemConfiguration — the clazz, not the instance.

This would have been very difficult to track down, because the current instance is available from any object, and that instance points to its clazz. So it seems to work — until you try to, for example, get a new ecology (from the clazz, using the global namespace). It’s BEEN missing all along. Not any more.

Chalk up another big win for test-first development. Why didn’t I start this a long time ago?

Changing platforms

February 2, 2009

I’ve been forced to change to an Ubuntu platform.

This is perhaps not a bad thing, although it comes at an awkward time. I suspect that a great many PC users will find themselves doing the same, and perhaps it even represents a business opportunity for Zeetix, LLC and especially ZeeForge. In this post, I explain why.

Motivation

I have been keeping my old and creaky WinXP platform alive long past its prime because there IS NO viable WinXP alternative. The platform in question is a 32-bit 3.06GHz P4. It is nearly impossible to buy a 32 bit intel machine today. A PC buyer, today, is forced to buy 64-bit “multi-core” machines with slower clock speeds. Since virtually NO software currently supports parallel processing in any effective way, the effect is that today’s machines are slower. The OS I have depended on — 32-bit WinXP — doesn’t run on the new machines (although it may walk).

I’m therefore forced to choose a new OS. The choices available from Microsoft are 64-bit WinXP, Vista and Windows7. None is reliable, and Vista in particular simply doesn’t work. The bottom line?

It’s time for me — and, I assert, millions of PC users like me — to move to Linux. Specifically, Ubuntu.

Why today?

The cooling fan on my old platform died this morning. A new one will come tomorrow or the day after. I can’t afford the downtime. The cooling fan is only the latest piece of the old machine to wear out. I lost nearly 400G of archives because the old Firewire connection (supplied by the equally old SB Audigy sound card!) died, and scribbled on the volume during my last backup. After a trip to MicroCenter, a new sound card, new Firewire card, new backup volume, and a day spent loading, rebooting, unloading, rebooting, updating, rebooting — you know the drill — its been days since I did any productive work. The fan bearings have been squealing for weeks (I tried to buy a new one yesterday, but of course MicroCenter doesn’t stock the odd size used by Gateway), and this morning the squealing — and the fan — stopped. Ouch.

The Plan

The new laptop (from which I’m typing this) is dual-booted between Vista and Ubuntu. Here’s the plan:

1. Boot into Vista, plug in the backup drives, and coalesce two mostly empty volumes (1.5T and 1.0T) into the one larger one, giving me 1T of clean backup space.

2. Format and partition the 1T drive for Linux, using the Vista partition manager.

3. Restore, from the 1.5T Win volume, the code I need (python, ruby, sql, and a bunch of related stuff) to a directory tree I can access from Ubuntu. I think, though I’m not sure, that most of this is in the new master repository I just pushed to github on Saturday.

4. Boot into Ubuntu and create the development environment I’ll need. This means:

4a. Create the necessary databases in mysql, as well as the needed users.

4b. Download and install linux versions of Komodo and Wingware.

4c. Download, install, and configure Apache

4d. Insure that Python, ModPython, and Perl are at compatible rev levels.

5. Exercise and debug the Zeetix/ZeeForge installation on Ubuntu.

Hopefully, by the end of the exercise, I’ll be able to then continue the ZeeUnit (ZeeTest, ZeeTestTest, etc) development process on Ubuntu.

Getting started

January 31, 2009

Goal

Build the minimum needed to make a working ZeeTest binding for python, ruby, and javascript.

Context

A spike solution (with minimal tests) with server-side code in Python and browser code in Javascript works. The existing kernel code is bloated and contains naive and bogus code that I wrote years ago when I understood neither Python nor Zeetix. Buried inside that is the prize.

Strategy

  1. clone the relevant parts from Python into a Python binding of ZeeForge, driven by the requirement to make ZeeTest (and ZeeTestTest, ZeeTestUI::TestApplication, and so on) work.
  2. Construct and rely on test case assemblies in KernelTest — CoreTest, AssemblySupportTest, and others — to assure the continued correct behavior of the relevant Kernel modules as I remove the crud.
  3. When done (or along the way?), I clone/copy the result to Ruby, ensure that the Ruby binding also works.

Meanwhile, I need the minimal SQL and database that supports it. I think that’s there, I wonder how this is tested. This sounds like a TestResource (for other tests), and also has its own tests.

New Tests

  • KernelTest.KernelCoreTest.KernelCoreLoadsTest: Validates that the Kernel.Core clazzes have been loaded.
  • KernelTest.AssemblySupportTest.AssemblyLoadUnloadTest: Validates that assemblies can be loaded and unloaded.

Notes

  • I created KernelTest to hold the tests needed to preserve the integrity of the Kernel.
  • Created KernelCoreLoadsTest in KernelTest, because the CommandLineLauncher needs to have the KernelCore in order to do anything uself.
  • This already requires me to add KernelTest and such to SystemConfiguration (in Kernel/AssemblySupport), currently as an explicit import. This is WRONG WRONG WRONG. I need to load and unload assemblies — so I need to add tests to KernelTest/AssemblySupportTest
  • Thus, I created “AssemblySupportTest/AssemblyLoadUnloadTest”.
  • AssemblyLoadUnloadTest will have profound implications for SystemConfiguration, because assemblies will need prerequisite/dependent machinery — machinery that doesn’t exist today.
  • As I discover needed tests in Ruby, I’m building them in Python and validating that they work. The plan is to then use those tests to keep things working while I slash unnecessary junk from the existing Python code.