Cook Computing

Just a minor C# issue I came across yesterday. I needed to assign an error code to the protected HResult member of a class derived from the .NET Exception class. The following code does not compile, resulting in an "assigning uint to int" error message and casting won't work and casting to int doesn't work because the value is too large

HResult = 0x80045000;

In a case like this you need to use the unchecked keyword to indicate that you're not bothered about the arithmetic overflow:

HResult = unchecked((int)0x80045000);

Krzysztof Cwalina describes some new delegate-based APIs added to the .NET collection libraries. A couple of points came to mind on reading this.

One, would it be better if the methods returning List<ItemType> instead returned IEnumerator<ItemType>, using an iterator for the implementation? This would give you more flexibility in what you do with the output.

Two, just a minor point, but I'd not paid much attention before to the fact that the type of an anonymous method is inferred by the compiler. Along these lines delegate inference is used to simplify the syntax used for assigning to delegate variables. Instead of this:

class SomeClass
{
   delegate void SomeDelegate();
   public void InvokeMethod()
   {
      SomeDelegate del = new SomeDelegate(SomeMethod);
      del();
   }
   void SomeMethod()
   {...}
}

you can now write:

class SomeClass
{
   delegate void SomeDelegate();
   public void InvokeMethod()
   {
      SomeDelegate del = SomeMethod;
      del();
   }
   void SomeMethod()
   {...}
}

Wes Felter:

I think you have to go even further and consider each Linux distribution to be a separate operating system which application developers must port to, test, and support. And there's still the problem of apps that are included in some distributions but not in others.

Reminds me of when I first started out as a developer. Every version of Unix was different and even on MS-DOS you had dependency problems with code compiled using different manufacturs' C compilers. After being molly-coddled in the Windows world for several years where these problems hardly seem to exist anymore, this is the one aspect of Linux that really puts me off spending any of my own time on that OS.

Anders Hejlsberg has a brief Channel9 interview on Programming data in C# 3.0. I found this valuable for a link in one of the comments to the Comega language page which I'd not come across before. I've now read two of the articles linked on that page: Modern Concurrency Abstractions for C# and Unifying Tables, Objects and Documents, and can recommend them both as well worth reading (note: PDF documents).

If you really do want to draw UML in Visio, Scott Hanselman points to UML Symbols for Microsoft Visio from the OMG Final Specification.

Martin Fowler has a piece on specifying UML diagrams using text. I've never really been that keen on UML diagrams in design documents, mainly for practical reasons:

• Design documents usually have to be written in Word and that means a lot of effort pasting UML Visio diagrams into documents, or trying to get in-place editing to work, which although a great idea has never seemed robust enough to be relied upon. Therefore UML diagrams in a document adds a big overhead, especially when you then have to maintain one or more separate Visio files with the Word document.
• UML diagrams usually appear in A4 or letter size design documents, which means there is simply not enough space to describe a complex design. Imagine trying to cram an architectural or mechanical engineering drawing onto such a small paper size , compared to a typical size of, say, A1.
• I see a lot of design documents which try to buy some legitimacy by including some simple UML class diagrams illustrating class hierachies and not much else. These don't convey much information and waste a significant amount of time in their creation.

Maybe I've used the wrong UML diagramming tools, starting off with Rational Rose which used to be (still is?) an appalling piece of software, but I'd prefer a more textual approach for a lot of design work, something like Eiffel which can be used as a high level design language and which allows you to flesh out the design into an implementation, yet enabling you at any time to view the design without the implementation detail. High-level diagrams can be useful but any more detail and they become counter-productive.

Microsoft developer Maoni has some more interesting GC-related information, this time on Using GC Efficiently . While you don't want to get bogged down in micro-optimization too early, it important to bear stuff like this in mind when designing high performance .NET apps. Premature de-optimization is the root of a lot of evil.

I came across another piece of software which uses XML-RPC.NET today: Xindice.NET. It provides a .NET interface to Apache Xindice (pronounced zeen-dee-chay) via its XML-RPC interface. Apache Xindice is described as:

The Xindice Core server is a database server designed from the ground up to store XML data. The Xindice server is what is termed by the XML:DB Initiative as a Native XML Database. You could also refer to it as a seamless XML database which might be an easier to understand description.

This is all new to me but this DevX article makes things a little clearer. XPath is used to query a Xindice database and XML:DB XUpdate is used to update XML contained in a database, updating specific elements of an XML document without rewriting the whole document.

After sorting out a problem with some ICMP "ping" code last week, it was nice to see that there is a Ping class in Whidbey, as described in Justin Rogers' post TraceRoute Whidbey using System.Net.NetworkInformation.

I was ashamed a few days ago to realize that I don't know all that much about how the Internet works. A support issue came in where one server was failing to ping another server using the ICMP protocol (using the ping as a preliminary check that the target server was alive before connecting via MAPI). The support person asked me "Do ICMP pings use specific ports?". I had to some research to find out the answer. This page has some discussion on the same question:

Discussing a port is typically something associated with TCP or UDP traffic. ICMP traffic is neither of these and hence in terms of icmp, there is no such thing as port 0 as part of the protocol itself. Instead, there are ICMP type and codes that define the purpose of the icmp packet. That being said, an ICMP packet can be used to report ont he status of a TCP or UDP port 0, such as with a type 3:code 3 packet notifying a host that a specified port is unreachable. Note that ICMP is IP protocol 1.

So, an echo request is not about a port. It is about whether or not the icmp packet being sent is able to make it to the destination host, that host is up, and icmp echo requests are permitted and processed. Note that it is possible for a response to be recieved to an icmp packet even if a host is down. A router that is locally attached to the subnet of the target host might respond telling you the desintation is unreachable for various reasons. Additionally, routers between your host and the destination host could respond notifying that the communication is administraively prohibited (such as icmp packets being blocked in an acl).

Under normal circumstances you send an echo request and expect an echo reply. If you send an echo request and recieve nothing in return, you can asume several things... The destination host does not exist or is powered off. Also, it's possible the icmp packets are blocked and configured to provide no response indicating a reason. Also, there could be a problem with routes between you and the destination host that prevents the traffic from making it to the destination or back and no ttl exceeded message was sent.... the list goes on..

and this page has an overview of ICMP:

Internet Control Message Protocol (ICMP), documented in RFC 792, is a required protocol tightly integrated with IP. ICMP messages, delivered in IP packets, are used for out-of-band messages related to network operation or mis-operation. Of course, since ICMP uses IP, ICMP packet delivery is unreliable, so hosts can't count on receiving ICMP packets for any network problem. Some of ICMP's functions are to:

Announce network errors, such as a host or entire portion of the network being unreachable, due to some type of failure. A TCP or UDP packet directed at a port number with no receiver attached is also reported via ICMP.

Announce network congestion. When a router begins buffering too many packets, due to an inability to transmit them as fast as they are being received, it will generate ICMP Source Quench messages. Directed at the sender, these messages should cause the rate of packet transmission to be slowed. Of course, generating too many Source Quench messages would cause even more network congestion, so they are used sparingly.

Assist Troubleshooting. ICMP supports an Echo function, which just sends a packet on a round--trip between two hosts. Ping, a common network management tool, is based on this feature. Ping will transmit a series of packets, measuring average round--trip times and computing loss percentages.

Announce Timeouts. If an IP packet's TTL field drops to zero, the router discarding the packet will often generate an ICMP packet announcing this fact. TraceRoute is a tool which maps network routes by sending packets with small TTL values and watching the ICMP timeout announcements.

I really should refresh my knowledge of the fundamentals of IP networking.

Just came across a posting by Cameron Beccario on The Anatomy of a Late Bound Expression, describing how methods are dynamically invoked in VB.NET. Its obvious from this why dynamic invocation is so much slower than static invocation in VB.NET. I've lost the reference now but I remember reading a discussion about the performance of the Java-based scripting language Groovy which uses dynamic invocation and as a result has much slower method calls than Java. There was some talk of using type inference to compile method calls statically where possible, which is what Nemerle appears to do.

OSNews has an article Celebrating Ten Years of BeOS. The nearest I got to BeOS was a demo at their offices in Menlo Park when I skived off work early on a Friday afternoon a few years ago. All I remember is being impressed by the playing of multiple MPEGs simulataneously, and asking about what their plans were making the OS multi-user. The demonstrator made some very non-committal noises about there being plans for this but it turns out that there was an internal debate going on about it:

Disagreements on how to implement proper multi-user functionality were also present, mostly between kernel engineers, Dominic and Pavel Cisler, the creator of the BeOS desktop/filemanager, Tracker. Pavel came from General Magic and later worked at Easel developing Gnome's Nautilus while today he works for Apple on Finder. Half of the engineers were citing kernel/fs changes and other half filemanager ones. Multi-user functionality was finally implemented but was never shipped because it was breaking a lot of apps that were created with single-user in mind (BeOS already had about 1500 applications at that point) and that was a business risk Be didn't want to take.

The lack of multi-user support effectively killed off my interest at that point.

I recently discovered that the poplular statename sample XML-RPC service at betty.userland.com is no longer available, so I'm making available some sample XML-RPC services here. The first is: Test Math Service. Over time I'll add some more so that people can exercise their XML-RPC client writing skills.

There still seems to be some interest in XML-RPC. I'm seeing roughly 5000 downloads per year of the XML-RPC.NET distribution. There are also the various aggregators, blogging engines, and blogging clients which use XML-RPC.NET.

If you're reading a technical blog like this and were around in the 70s/80s, the chances are that you have read Zen and the Art of Motorcyle Maintenance. It was essential reading if you were a bit geeky, along with Gödel, Escher, Bach. The book is based on a motorcycle journey across the USA, from St. Paul, Minnesota, to the West Coast, and I occasionally would try to plot the route on a large scale map, dreaming that maybe one day I would retrace the journey on a motorcycle. So I was excited to come across Zen And The Art Of Motorcycle Maintenance Travel Route which has full details of the route (via Dewayne and Shadow his Webdog). Even better, if you follow the links off this page you come to the ZMMQuality site which has a set of 12 photos from Pirsig's original trip in 1968.

Yes! These are the pictures taken on Robert Pirsig's very own camera as he, Chris, Sylvia, and John made that 1968 epic voyage upon which his book "Zen and the Art of Motorcycle Maintenance" (ZMM), was based. The captions for these twelve pictures were written by Pirsig himself. These 12 photos seem to be the only existing photos from that trip. Mr Pirsig said that if he had known his book was going be so famous, he would have taken more photographs. When you bring up the first photo in this Album, look closely at the reflection in the shiny gas tank. You can faintly discern the image of John holding the camera as he took that photo!