Friday, November 04, 2005


On the horizon

There are always a couple of projects that I've been meaning to check out for a while, but seldom have the time to do so. Well, today I heard about a new research operating system called singularity. It is a microkernel based system with a goal of providing dependable computing - this is very similar to one of the goals of Minix 3. It would be very interesting to compare the approaches of the two systems.

Another project that I've been meaning to look at is C-cured, which is described on the home page as a source-to-source translator for C. So what it does is process C source code, and generates new C source code that has dynamic checking of memory references. The heart of C-cured is CIL, an analysis framework for C source code. The CIL project also originated at Berkeley.

My to-investigate list has had the Squeak project on it for a while (version 3.8 of Squeak is now available). Squeak is a graphically rich, object-oriented, environment based on Smalltalk. One of its goals is to be easy to use, and to provide a good environment for teaching children about programming - very laudable stuff. I've found Squeak hard to get into (after a 5 minute play months ago... I'm not being very fair to the system...), but I think that is because I've approached the system with the wrong mindset - I've been using Unix/Windows/C/C++/vi/... for far too long, and haven't been able to get my head around the smalltalk programming environment in the limited time that I've had. Anyway, ages ago I read the Back to the Future OOPSLA paper, and have been meaning to re-read the sections on the object memory and storage management. On that note, I'll stop typing this, and go do some reading (or more likely, sleeping).


The house got sold this week, which means no more opens (yippee!). Trying to live in a house whilst it is on the market is no fun at all... Heather and I were both very impressed with Paul Kloeden, whom we chose as our real estate agent. He kept us fully informed during the entire sale process, and impressed us not only with his professionalism but also his enthusiam. I'd happily recommend Paul to anybody else wanting to sell their house.

With all the packing, planning etc... I haven't managed to get any coding this week. It's unlikely that I'll get any done next week, or indeed the next few months as I'm likely to be fully booked out with painting/gardening/renovating/etc... which I'm looking forward to doing during the summer.

Wednesday, November 02, 2005


Edwards Birthday

Happy First Birthday Edward!

It's hard to believe that it is Edwards first birthday today - where has the year gone? It's been great to see Edward grow into a happy, smiling toddler who is ready to take on the lounge room today, and the world tomorrow!

Monday, October 31, 2005


XML Books

A surprise package came in the mail for me today - some books that I ordered from BargainBookCo all arrived in great condition two weeks earlier than expected. The books were:

I would have been happy with just Definitive XML Schema, but it was cheaper to buy all three books from America, and pay shipping to Oz, than it was to buy the single work locally... Well, I'm delighted!

I've been lagging behind on XML technologies, and have thought for far too long that XML is just a tree-structured data - that's a bit like saying that Java is just a programming language. I've come to appreciate that XML refers to a larger basket of technolgies, including XML-namespaces, XPath, XQuery, XSLT, XML-Schema, and XHTML (is this a reasonable list of core XML technologies?). Whilst I'm an XML-newbie, I believe that this group of technologies is really more powerful at describing data than traditional IDL's as used by Sun-RPC (based on XDR - I just had to slip a 3-letter-X-acronym in there!), Corba, or COM. The trigger for changing the way that I viewed XML was the realisation that there was more to XML than just arbitrarily defined tags that get sloppily defined and slapped onto a chunk of data. Whilst you can use XML that way, it is also possible to have rigorous definitions of the data - just as you get with IDL's. XML need not lack rigour, but if you choose to, you can have less rigour and rapid prototyping of the data structures. Best of all, rather than having to hand code custom parsers or interpreters, there is an extensive toolkit of existing software that can perform validation, parsing, and transformation of the data. It all sounds too good to be true - but I'm sure that if I join the XML 'dark side' there'll be no return - and hopefully I'll be more productive.

I've been talking XML-pidgin for far too long - it's time to become fluent.


Traps for Python players

I've just been tracking down errors. Before getting into the details, here is a quick pop-quiz. What is the difference between the functions f and g?
def f(x,y=0):
    y += 1
    print x,y
def g(x,y={}):
    y[x] = y.get(x,0) + 1
    print x,y[x]

What happens if the functions are called repeatedly? E.g.

print "f", f(0)
print "f", f(0)
print "g", g(0)
print "g", g(0)

The output is:

f 0 1
f 0 1
g 0 1
g 0 2

As you can see, the 'function' g is not a pure function. There are side-effects with the initialisation of parameter 'y' to a mutable object (in this case, a dictionary) so that repeated invocations have differing behaviours. If you want purely functional behaviour a direct way of working around this problem is to explicitly initialise each parameter. E.g.

> g(0,{})
0 1
> g(0,{})
0 1         <<< no side effect
> g(0,{0:27})
0 28

The problem with this approach is that it requires the caller to be aware of which default parameters are mutable, and that get mutated. A cleaner solution is to use a default value of None, and to explicitly establish the default when required inside the code body. This requires a small change to the code, but the caller no longer cares about the side-effect. Applying this idea to the function g() above gives the new code:

def g(x,y=None):
    if y is None: y = {}
    y[x] = y.get(x,0) + 1
    print x,y[x]

Now to the error that I had this morning. The function looked like:

def dostuff( t=Tree() ):
    # Add new nodes to the tree
    return tree

It all worked beautifully for a single invocation, but trying to repeatedly run the function in the same process failed for the reasons outlined above. I'm sure the original author of the code was aware of the side-effects, but it is certainly no fun for the poor sucker who has to track the errors down.

On a related issue, a feature that I would love to see in Python is a const modifier for function/method parameters that would raise an exception when an attempt is made to modify a mutable parameter. Whilst const would not solve the problem that I had this morning, it would make Python more readable given the subtle differences between mutable and immutable objects.


Made some quick updates to rip3, and removed the Windows specific code (CreateFile() etc...) with standard I/O functions - it all worked, and I was unable to recreate the error that I had earlier. I'll put it all down to a stupid error caused by sleep-deprived coding (note to self: go to bed at sensible times!). It would be nice to get rip3 running on other platforms, but there some endian issues to be resolved - the Minix 3 filesystem has been written for the x86 (little-endian) architecture, so there is a little bit of byte swapping to be done before it will run on Sun/Alpha/... platforms. Hope to release the changes by the end of the week.

This page is powered by Blogger. Isn't yours?