Cook Computing

I wasted some time the other day with a C++ memory management issue. I was using a class, call it class X, which took a reference to another class, say class Y, in its constructor. I mistakenly assumed that the constructor would copy the required data from the reference to class Y. Unfortunately that was wrong and the program blew up. It turned out that class X stored the reference to class Y as a member variable, acessing the instance of class Y later on after I had deleted it. So I had to ensure that the lifetime of the instance of class Y encompassed the lifetime of the class X instance, which complicated my code.

Maybe I've been corrupted by working with COM for several years but I think that reference counting with smart pointers is the only maintainable way to manage objects in trad C++. Although garbage collection makes things even easier in .NET and Java, it does make non-memory resource management considerably harder. Which reminds me, what did happen to the Chris Sells project to determine the cost of ref counting in .NET?

UPDATE: Looks like the ref counting project is still making progress, as of a couple of months ago anyway.

Another Virtual PC snippet. Chris Anderson is running Longhorn in a Virtual PC session:

I have an XP virtual session that i run on my XP laptop. The other day I upgrade the XP virtual machine to run the latest Longhorn build. Very cool. In preparation for the PDC I was trying out some libraries that we were creating. So, I turned on the "Undo Disk" feature - basically you can run the session and then at completion choose to throw away all the changes to the machine, completely. Very cool.

So all you people going to the PDC need to make sure Virtual PC is installed on your laptop. You don't want to have to wait until you get back to the office to run the Longhorn handout. Note you'll need to take a DVD drive too.

Returning to Virtual PC, I'd seen some reports about the Virtual PC for the Mac not running on the new G5 machines. Omar Shahine explains why. Its all to do with endianess. Earlier PowerPC processors were bi-endian as this pretty ancient Byte article explains:

The PowerPC is a bi-endian processor; that is, it supports both big- and little-endian addressing modes. This bi-endian architecture enables software developers to choose either mode when migrating OSes and applications from other machines. The OS establishes the endian mode in which processes execute; the default mode is big-endian. Once a mode is selected, all subsequent memory loads and stores are determined by the memory-addressing model of that mode.

To support this hardware feature, 2 bits in the MSR (machine state register) are maintained by the OS as part of the process state. One bit (ILE) specifies the endian mode in which the kernel runs when processing an interrupt; the other (LE) specifies the processor's current operating mode. Thus, the mode can be changed on a per-process basis, which is critically important for foreign OS emulation.

When an interrupt occurs, the processor saves the current MSR and loads an MSR for the interrupt-processing routine. The value of the ILE bit in the old MSR is copied into the LE bit in the new MSR. When execution resumes in the interrupted process, its MSR is reloaded with its LE and ILE bits intact.

It seems that the G5/970 chip does not have this feature, though I couldn't find anything explaining why it has been dropped.

Why don't machines all use the same endianness. Probably for the same reason that every computer manufacturer had to have their own version of Unix. There were even middle-endian machines where the number 0xDEADBEEF was stored as BE EF DE AD. William Verts suggests:

You may see a lot of discussion about the relative merits of the two formats, mostly religious arguments based on the relative merits of the PC versus the Mac. Both formats have their advantages and disadvantages.

In "Little Endian" form, assembly language instructions for picking up a 1, 2, 4, or longer byte number proceed in exactly the same way for all formats: first pick up the lowest order byte at offset 0. Also, because of the 1:1 relationship between address offset and byte number (offset 0 is byte 0), multiple precision math routines are correspondingly easy to write.

In "Big Endian" form, by having the high-order byte come first, you can always test whether the number is positive or negative by looking at the byte at offset zero. You don't have to know how long the number is, nor do you have to skip over any bytes to find the byte containing the sign information. The numbers are also stored in the order in which they are printed out, so binary to decimal routines are particularly efficient.[/quote]

Its one of those irritating seemingly unnecessary issues that has caused me extra work over the years, much like the choice of the backslash for the path separator in DOS and Windows. I often wondered whether the reason for this was sheer bloody-mindedness to be different but according to the Myths About Microsoft page:

UNIX's chdir/cd, mkdir (shortened to md), and directory tree notions were grafted onto DOS's drive letters, and the slash (/) converted to a backwards slash (\) in a move that has driven "bilingual" people crazy ever since (it wasn't for that purpose; MS had already used "/" as an option delimiter where UNIX used the "-", and felt they couldn't change that for fear of breaking backwards compatibity).

Virtual PC for Windows is now available for download by MSDN subscribers. I've not been able to get Linux Redhat 9 .0 working very well with VMware 3 so I thought I'd try Virtual PC (I know RH9 may work better with VMware 4 where it is a supported OS but we've not upgraded to that version of VMware yet). Installation went very smoothly, the only niggle being getting X Windows to work. I had to change the screen depth to 16 from 24 in the XF86Config file, by booting in single user mode (it was starting X automatically and displaying garbage otherwise), and then chose the "Generic Monitor, 1280x1024 @ 74 Hz" setting using the "Display Settings" GUI app so that I could increase the screen resolution to 1024x768. I'd read something which suggested that Virtual PC would support 16 and 32 bits, not 24, but I couldn't get it to work with depth set to 32. However my knowledge of X config is extremely limited so it may be well be possible. I suppose that now I know what to change I could choose these settings during installation. This MSDN KB article has some more information on installing Linux on Virtual PC.

Omri Gazitt mentions the usual trials of installing pre-alpha software, presumably the Whidbey release of .NET from what he writes, and suggests:

Nevertheless, my word of advice to folks who install our PDC bits: do it on a virgin machine that you are OK with wiping if you ever need to use it for something else...

Just what you need Virtual PC or VMware for.

I've bought a socket current meter to measure how much it costs to keep a pc running 24x7. I just plugged in my Shuttle pc and discovered that it consumes just under 90 watts when idling. Running at about 50% CPU this rises by about 5 watts then up to about 100W at 100% CPU. So left on for a year, sitting there idle most of the time, we're looking at about 800 KWHrs or £48 at 6p a unit (the price on the most recent bill I could find).

The Shuttle also has a standby mode where power consumption drops to about 50W, which is more than I expected.

I also measured a Dell Precision 340, which has a faster Intel processor than the Athlon XP2200+ in the Shuttle, and this registers about 80W when idling. However this jumps up to 130W when running at 100% CPU.

Finally the one component I currently keep running all the time, the ADSL modem/router, consumes about 12W, a small cost to pay given that this is sometimes flaky when starting up from cold.

Seen on the ll1-discuss list, a post from Jeroen Frijters:

Erik Meijer wrote:

> I guess that you will like C#'s anonymous methods then.

It's better than Java, but they're still not closures. You can't access ref arguments inside an anonymous method.

This caught my attention because of my entry a few months ago on Closures and C#.

Matt Berther and Greg Reinacker have pointed out an implementation difference between the XML-RPC endpoints exposed by Movable Type and Typepad. The root cause of problem is that the XML-RPC value type dateTime.iso8601 does not contain a timezone. According to the XML-RPC spec:

What timezone should be assumed for the dateTime.iso8601 type? UTC? localtime?

Don't assume a timezone. It should be specified by the server in its documentation what assumptions it makes about timezones.

The two implementatons - although they expose the same XML-RPC API - make different assumptions about the timezone. MT assumes that all dateTimes are specified in the timezone selected in the weblog config, whereas TypePad assumes that they contain either an implicit timezone, i.e. the time is in UTC, or an explicit timezone, e.g. "2003-08-11T20:34:15-6:00". However the latter case is not valid a XML-RPC value and cannot be passed by compliant XML-RPC libraries.

This can lead to confusion when using XML-RPC.NET (and maybe other libraries). If the client sets a .NET DateTime value to, say, 20:34, this time is treated as being in the local timezone. However when the DateTime value is passed into an XML-RPC method the resulting dateTime.iso8601 value will contain "2003-08-11T20:34:15", so losing the timezone information. TypePad will then take this to be 20:34 UTC, which is not what the client might be expecting.

To summarize:

Movable Type - the time in dateTime.iso8601 values is in the timezone configured for the weblog

Typepad - the time in dateTime.iso8601 values is in UTC.

The article The Case Against Extreme Programming is worth reading (via Greg Vaughn). This quote from the article sums up my doubts about XP:

As XP increases in popularity and hits the mainstream, more and more teams will attempt XP, probably without a clear understanding of what is really involved. They will most likely be drawn in by XP's "low discipline" practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).

I know of one group who, when asked for the design documentation of their current project, replied "We don't have any documentation, we do XP". Needless to say they weren't really following any XP practices.

I suspect you need high-calibre motivated and disciplined developers to get XP to work and that development groups who struggle with more traditional development processes will struggle even more with XP. So examine why the current development process doesn't work well before jumping to XP. The same problems may well make XP even less effective.

I spent some time over the weekend playing with Mono on Linux. I found that .Net code which failed to port to Mono a few months ago now runs successfully. Before trying anything more ambitious - such as testing XML-RPC.NET on Mono - I decided that I needed to build the Mono debugger. Unfortunately I couldn't get this to compile, no doubt because versions of the required libraries on my machine were incompatible. I'll try again this weekend coming.

I noticed something on the Mono mailing list a couple of days ago. Someone had posted about getting Mono running on G4 and G5 hardware and Miguel de Icaza replied:

You might want to help the SharpDevelop guys finish SWT and finish their SharpDevelop port to SWT. That is the project that needs the most help.

Mono on PPC is happening due to a contract we have to support it.

Interesting. IBM or Apple?