Cook Computing

Jim Hugenin has released IronPython 0.6. Also. Jason Zander, CLR Product Unit Manager, has announced that Jim is joining the CLR team. Taken from the distribution this is a sample WinForms app:

from System.Windows.Forms import *
from System.Drawing import *

f = Form(Text="Windows fun with IronPython", HelpButton=True,
         MinimizeBox=False, MaximizeBox=False)

f.FormBorderStyle = FormBorderStyle.FixedDialog
f.StartPosition = FormStartPosition.CenterScreen

b1 = Button(Text="Say Something", Location=Point(30,30), Size=Size(100,30))

def push(data, event):
    l = Label(Text="IronPython Is Alive!", ForeColor=Color.Red)
    l.Location = Point(30, 50+f.Controls.Count*25)
    f.Controls.Add(l)

b1.Click += push

f.Controls.Add(b1)
f.ShowDialog()

Performance is a key issue here and I wrote some simple code to get a very unscientific rough feel for what IronPython can achieve. The following code running in IronPython does about 1,000,000 calls to Add per second:

class Adder:
    def Add(self, x, y):
        return x + y

z = 0
adder = Adder()
for i in range(10000000):
    z = adder.Add(z, 1)
print z

whereas the following C# code does about 30,000,000 calls per second (deriving from MarshalByRefObject to prevent inlining of the call - its 20 times faster when inlined):

class Adder : System.MarshalByRefObject
{
    int Add(int x, int y)
    {
            return x + y;
    }

    public static void Main()
    {
        Adder adder = new Adder();
        int z = 0;
        for (int i = 0; i < 100000000; i++)
            z = adder.Add(z, 1);
        System.Console.WriteLine(z);
    }
}

This order of performance difference doesn't seem too bad to me if you want the benefits of coding in Python, and you can always re-implement performance critical code in C# later on. Optional typing and type inference might be another way of approaching optimization but I don't know if there are any plans for that in Python.

I'm looking forward to seeing the slides for Jim's talk at OSCON last night and the blogging about it.

Lookout is now available from the Microsoft download center.

BTW, Lookout is a .NET application which uses the Lucene.NET library:

Lucene.Net is a complete up to date .NET port of Jackarta Lucene a hight-performance, full-featured text search engine written entirely Java. See http://jakarta.apache.org/lucene for more info on Jakarta Lucene.

UPDATE: Lookout no longer available from the Microsoft download center but instead from the Lookout site which is linked from the MSN Sandbox site

The C# switch statement does not allow you to drop through case blocks unless the block is empty. So how do you share the same code for more than one case? The C# Frequently Asked Questions blog provides the answer:

class Test
{
    static void Main()
    {
        int x = 3; 
        switch (x)
        {
            case 0:
                // do something
                goto case 1;
            case 1:
                // do something in common with 0
                goto default;
            default:
                // do something in common with 0, 1, and anything else
            break;
        }
    }
}

Allowing drop through for empty cases makes for readable code but is perhaps slightly inconsistent.

class Test
{
    static void Main()
    {
        int x = 3; 
        switch (x)
        {
            case 0:
            case 1:
            case 3:
                // do something in common with 0, 1, and 3
            break;
        }
    }
}

Eric Gunnerson asks for suggestions about what should be added to the version of C# after Whidbey. My only suggestion was for covariant return types. I don't come across the need for this feature every day but every now and then I find cases where they would be useful. It can save some casting, enhance static type checking, and make code clearer.

It turns out that Covariance and Contravariance for Delegates are already supported as of Whidbey (I just verified this works in beta 1).

Several blogs have linked to Boo recently and last night I downloaded the distribution to investigate some of the ways in which it is different to C#, e.g. type inference, first class functions, automatic variable declaration, duck typing, syntactic attributes and syntactic macros.

Before getting into the new stuff I chose something familiar:

import System
import CookComputing.XmlRpc from CookComputing.XmlRpc

[XmlRpcUrl("http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx")]
interface IStateName:
        [XmlRpcMethod("examples.getStateName")]
        def GetName(num as int) as string

obj as IStateName = XmlRpcProxyGen.Create(typeof(IStateName))
Console.WriteLine(obj.GetName(1))

Just booted up, started Outlook, and was offered an update to Lookout version 1.2 from Microsoft. Joel Spolsky may have got it wrong.

From the Lookout site (dated 07/16/2004):

Hopefully you've seen the news about Lookout and Microsoft MSN at this point.

Today we're also pushing out a new 1.2 release which incorporates the latest set of bug fixes, and a couple new goodies.

The main feature is that this version no longer has any nagware to ask for referring friends! Thank you to all that did recommend to friends- we know it takes a lot for you to do so, and that is not forgotten.

If you elect to pick up the new 1.2 release, its the first release from Microsoft. Here are some notes about it:

• There is a minor change to the EULA, mostly stating that the agreement is now between the user and Microsoft rather than the user and Lookout Software.
• The tell-a-friend functionality is removed
• The license key functionality is removed
• The new advanced search UI is in place
• A few sundry bug fixes.

Please send us feedback and let us know how it goes!

Thanks!

Blaine Buxton has several quotes from Paul Graham's Hackers and Painters including this one:

I suspect few housing projects in the US were designed by architects who expected to live in them. You see the same thing in programming languages. C, Lisp, and Smalltalk were created for their own designers to use. Cobol, Ada, and Java were created for other people to use.

If you think you're designing something for idiots, odds are you're not designing something good, even for idiots.

Spot on about architects. I also think C++ is the counter-example to C, Lisp, and Smalltalk in this context.

I recently came across this in the Visual Studio 2005 beta 1 documentation:

The System.Runtime.Remoting.Channels.Ipc namespace defines a communication channel for remoting that uses the Interprocess Communication system of the Windows operating system. Because it does not use network communication, the IPC channel is much faster than the HTTP and TCP channels, but it can only be used for communication between application domains on the same physical computer.

In the main application I'm working on at the moment we are using a custom channel based on named pipes to get good performance and I'd hoped that the IPC channel would at least equal this so that we could ditch our custom code. However I did some experimentation over the weekend and the IPC channel is currently about 50% slower than the TCP channel which in turn is about 50% slower than our named pipe channel. Of course, this is a beta and I was also running the code in Virtual PC which might have affected IPC more than the other channels, but I expected better performance than this.

The other Remoting disappointment in Whidbey is that I couldn't find anything to do with security. I'd been half expecting that security would be added to the remoting infrastructure in Whidbey but I guess that has been postponed until Indigo.

UPDATE: Remoting guru Ingo Rammer has pointed out that security has indeed been added to Remoting in Whidbey. You can specify authenticationMode (None, IdentifyCallers, ImpersonateCallers) and encryptionMode (None, Sign, EncryptAndSign) on the TcpServerChannel. The docs show how you can determine the identity of the caller:

// Identify the calling principal.
IIdentity remoteIdentity =
    System.Runtime.Remoting.Messaging.CallContext.GetData(
        "__remotePrincipal") as IIdentity;
if (remoteIdentity == null)
{
    message.Append(" by an unknown caller");
}
else
{
    message.AppendFormat(" by {0}", remoteIdentity.Name); 
}

I was asked to look into a remoting problem where objects were being disconnected even though sponsorship was implemented on the client. Instead of using the framework class ClientSponsor, a custom SponsorManager class had been developed which had additional methods such as UnregisterAll and which could be configured to specify that Dispose should be called during unregistration. In the context that this was being used it was a very useful class except that it didn't work - objects were being disconnected unexpectedly. I modified the code to use ClientSponsor and leasing started working as expected. I had a quick look at the ClientSponsor implementation using Reflector to check what was different and it immediately became obvious: ClientSponsor overrides InitializeLifetimeService to return null, thereby indicating that an infinite lease should be applied. Without this the default lease will be applied to the SponsorManager object, will never be renewed, and the object will eventually be disconnected. From this point onwards the server will be unable to call the sponsor object to renew leases and objects will start to be disconnected.

public override object InitializeLifetimeService()
{
    return null; 
}

Another point to note is that the client needs to register a channel so that the server can make the lease renewal calls.

If you use the Microsoft LDAP API (wldap32.dll) and you want support for non-ASCII characters even when using the wide char versions of the functions, you must configure version 3 of LDAP:

ULONG LdapVersionOpt=LDAP_VERSION3; 
ULONG ret=ldap_set_option(hLDAP, LDAP_OPT_VERSION,
    (void*) &LdapVersionOpt);

Easy to forget, as I found out recently.

Just back from a two week vacation in Achiltibuie in NW Scotland. The weather was good, the mountain walking magnificent, and the general chilling out was just what we needed.