Cook Computing

Ned Batchelder writes about the assembly download cache problem I mentioned a while ago. He used Filemon to diagnose the problem.

In the comments to the When to Change File/Assembly Versions post on her blog Suzanne Cook writes:

Yes, strongly-named assemblies already in the download cache will not be downloaded again if the assembly identity hasn't changed. To deal with this, our test scripts delete the download cache at the beginning of the test (gacutil /cdl). We find it preferable to make a one-time change to do that in scripts than to deal with the constant pains of changing versions often.

I spent a couple of hours last night porting XML-RPC.NET to the .NET Compact Framework. After I had stripped out all the server-side code and the XmlRpcProxyGen code which used Reflection.Emit (unsupported on CF) there were several issues, including the following:

• XmlNode.Select* methods are not supported on CF, so I had to write some code to replace use of these methods.
• The overload of Activator.CreateInstance which takes two arguments, used in this case for instantiating arrays, is not supported so I had to instead invoke the constructor of array types explicitly.
• The property of AllowWriteStreamBuffering of HttpWebRequest defaults to false in CF, instead of true in the full framework, to encourage less memory usage I presume. I set this to true because, strictly speaking, chunked output is not part of the XML-RPC spec.
• The WebClientProtocol class in CF has less functionality and so I removed the dependency on this.

I don't have a device running the Compact Framework so I'm only testing the code in the emulator. If there is anyone who would like to use it in a real device, let me know and I'll send a dll for testing.

A long time ago I mentioned XSO (Exchange Server Objects), a remotable managed messaging API for Exchange. I've not seen any announcements yet and a fairly recent Tech-Ed interview with David Thompson, VP in charge of Exchange Server group, doesn't mention anything. The interview does, though, give the impression the Exchange group is floundering over more than just XSO.

Another language for Jason's .NET Langauges site: Scala.

Ralph Mason posted to the Mono list about his frustration with the lack of progress on a debugger for Mono:

This single thing will give the most major boost to mono of any possible code that could be written. Mono is a great piece of work, but it's being totally let down.

One of the replies was the usual open source argument of "Why don't you help out and try and contribute code to make the debugger better?". I think that is missing the point. A lot of people who might be interested in developing their .NET code on Linux don't have a compelling need to do so, and are not likely to want to spend a lot of time working on a debugger to get to that point. If it is in the interests of the Mono project to increase usage of Mono then, as Ralph says, it is better to direct effort towards the debugger than version 2.0 of Mono.

The good news is that Paolo Molaro replied to say that work will soon be starting in this area.

In this post yesterday I stated that the C# compiler does not allow the use of uninitialized variables. As David Buck pointed out in the comments to his post I linked to, this only applies to temporary variables and not instance variables. However instance variables are automatically initialized to known values. The C# spec says:

The following categories of variables are automatically initialized to their default values:

• Static variables.
• Instance variables of class instances.
• Array elements.

The default value of a variable depends on the type of the variable and is determined as follows:

• For a variable of a value-type, the default value is the same as the value computed by the value-types default constructor (11.1.1).
• For a variable of a reference-type, the default value is null.

Note: Initialization to default values is typically done by having the memory manager or garbage collector initialize memory to all-bits-zero before it is allocated for use. For this reason, it is convenient to use all-bits-zero to represent the null reference. end note

Compare this with C++ where there is no initialization of instance variables. This leads to a particularly insidious form of bug where code will seem to run successfully because the memory allocated to uninitialized variables just happens by chance to have values which don't cause any obvious problems. Either the program runs incorrectly or at some point blows up in an arbitrary way. I've seen many bugs caused by this and its not really acceptable in a language used for general purpose development.

Jason Bock has set up a site devoted to .NET Languages. Goals of the site are:

To provide up-to-date news on the latest in .NET language developments. If a new language is created, or a language has a compiler for the CLR, or an article is published relating to the inner workings of a language, this site keeps you informed via an RSS feed, which you can subscribe to here.

To develop in-depth language investigations. Over time, this site will have an article for each language targeted for the .NET runtime. This will be a never-ending process, but the intent is to give you information on compiler setup and syntactic features for languages you may not be familiar with. Some languages have some very interesting features that are not easily mapped to the CLR, and learning how the compiler writers had to work these features into the assemblies yields a lot of insight into the inner workings of .NET (at least I think so!)

To list essential .NET language resources. There are a lot of solid, thorough resources, both in book and article form, for the .NET developer who has a keen interest in languages and compilers.

I never had a serious model train set but I would have liked to work on the application described in Train Scheduling in Smalltalk. I've always found anything to do with scheduling interesting, with plenty of scope for complex algorithms and challenging coding.

In Bug rates in a Smalltalk project David Buck describes how he has observed a very low rate of bugs due to lack of static typing in Smalltalk. Regarding his point about most statically typed languages masking errors caused by uninitialized variables, this is not the case with C# where the compiler will not allow the use of uninitialized variables. On the other hand I have seen many errors of this type in C++ code. Any language being used for general purpose development should prevent this error.

By the way, the Cincom Smalltalk community blogs are worth subscribing to, for a different perspective on developing applications if you don't already use Smalltalk.

I was investigating access to the root folder of Exchange mailboxes yesterday and came across am Exchange-oriented WebDAV explorer called Mistaya and a .NET WebDAV API called WebDAVlayer, by Henning Krause. These may be of use for anyone doing work with the WebDAV functionality of Exchange.

It looks like you cannot access the root folder via WebDAV, only the "Top of Information Store folder" sub-folder which corresponds to the top level of the view you see in Outlook, the folder containing Inbox. I'm working on an application which stores information in an item in the root folder and given all the trouble we have had with MAPI - threads hanging if objects are released when the Exchange server goes offline, very long calls at random intervals which can't be timed out, etc - I was interested to see if we could use WebDAV instead. The big advantage of WebDAV is that we would have complete control of the client-side code, instead of relying on the code in MAPI32.dll. This would make it easy to implement timeouts on calls. Ignoring the lack of root folder access for the time being, the next step will be to compare the performance of the two protocols.

bricolage \bree-koh-LAHZH; brih-\, noun: Construction or something constructed by using whatever materials happen to be available.

The Internet is a global bricolage, lashing together unthinkable complexities of miscellaneous computers with temporary lengths of phone line and fiber optic, bits of Ethernet cable and strings of code.

--Bernard Sharratt, "Only Connected," New York Times, December 17, 1995[/quote]

Version 0.9.0 of XML-RPC.NET is now available at www.xml-rpc.net.

Features:

• XmlRpcServiceAttribute has a new AutoDocumentation property which allows automatic documentation to be switched off.
• Handles XML-RPC response encodings other than UTF-8. XmlRpcMemberAttribute fixed.
• XmlRpcClientProtocol has new ProtocolVersion property to allow HTTP v1.0 to be specified.
• XmlRpcClientProtocol has new KeepAlive property (default is true). With some servers it may be necessary to set this to false when running with the current beta of the 2.0 CLR, for example if you start seeing the "Underlying Connection Was Closed" exception or the second call on a proxy appears to hang.
• Multi-dimensional arrays handled correctly.
• dateTime parsing supports "yyyy-MM-ddTHH:mm:ss" to handle blog service providers which return invalid XML-RPC dateTime values in this format.
• Includes Joe Bork's xmlrpcgen utility to generate source code for proxies.
• Release runs on version 1.0 of CLR upwards.

To Do

• FAQ needs updating with info about new features.
• If a struct has been marked as an optional member of another struct, then all the members of the child struct must be marked as optional.
• Provide some way of logging XML-RPC request and response documents.
• Determine if and how component support should be improved.

MAPI programming is ugly. It needs a lot of attention to avoid memory leaks. Therefore I was interested to see an article on Extended MAPI with C#. This describes the use of a library called MAPI33. It looks like a thin layer over the MAPI API. I'm not sure about the use of an Error enumeration to return errors from each method. This adds a big coding overhead and is not really the .NET way of doing things.

We went to see I, Robot at the weekend. It turned out to be better than I expected for this type of blockbuster movie (if you ignore the amazingly clumsy product placement). I thought the robots were great, looking like something designed by Jonathan Ive and, except for some of the action scenes where the CGI got a bit out of hand, fitting seamlessly into the film. I'd go so far as to say the best acting was done by the main robot, Sonny, but that may be a reflection of the rather cliched roles and shallow portrayals of the other characters. Certainly by the end I was more concerned about Sonny's fate than that of the human protagonists.

Its been so long since I read the Asimov stories I can't say how accurately the film conveys their spirit. The 3 Laws of Robotics are used to move the plot along without going too deeply into their consequences, but there is enough to stimulate the imagination.

To sum it up, if you don't take the plot too seriously and ignore the crude product placement, its a fun film to watch with a few ideas to chew on after you have left the cinema.

I just wasted a couple of hours. I was doing some final testing of the long overdue next release of XML-RPC.NET and found that whereas running unit tests from Visual Studio worked fine, building the release and running the tests from NAnt resulted in a failure in the most recent test I had written. After going down lots of dead ends I finally wondered whether I had somehow placed the XML-RPC.NET dll in the GAC and it was being loaded from there. This triggered off another thought about the download cache, and sure enough clearing the cache solved the problem. Somehow, even though I was rebuilding the assembly, the loader was choosing the old version in the cache. Very frustrating. The release will have to wait until tomorrow now. To clear the download cache:

gacutil /cdl

Microsoft have released Virtual PC for Mac version 7. A year ago I described why earlier versions would not run on the G5 machines. Must have been some rewrite judging by the time it has taken.

The new iMac machines are very elegant but more than one person as commented on the apparent lack of physical stability. It does look a bit precarious sat on that small footprint stand. It also won't look quite so nice with cables plugged into the ports on the back of the machine.