Programmer's Weblog

BHO.CVX Trojan

Friday, December 21, 2007

My friend got this on his computer. The most annoying thing for him was that his antivirus software would popup a warning message about this Trojan every now and then.

The BHO probably stands for Browser Helper Object; I could find it inside the Add-ons to IE, but deactivating it didn't help. Thankfully the antivirus was yelling which file the Trojan is in, it couldn't delete it because it was in use. Even in safe mode the file was locked.

I was able to delete it from command line after booting up the computer using windows install CD and choosing Recovery mode (or sth like that, I have German Windows :) ).

0 comments

Evil locale

Sunday, December 16, 2007

.NET is trying to protect developers from making simple mistakes while providing them with all sorts of non obvious problems completely for free.

The simple mistake is trying to mutate a struct returned by a property. Line 14 in the example code raises compile time error. This line is otherwise completely fine except that it doesn't make sense -- the Start property is returning a copy of the value type Point.

 1 struct Point {
 2     public int x;
 3     public int y;
 4 }
 5 class Line {
 6     Point start;
 7     Point end;
 8     public Point Start {get {return start;}}
 9     public Point End {get {return end;}}
10 }
11 public class Main {
12     public static void Main() {
13         Line l = new Line();
14         l.Start.x = 2
15     }
16 }

The example comes from here The page explains that in such a case IronPython will also fail (by design) with an error.

Now about the free errors. They are all sponsored by the evil locale. Parsing in .NET takes the operating system's locale into account. In Poland the floating point numbers are written using coma instead of a dot. So 2.3 is written as 2,3. Trying to parse your settings file containing floats on a computer with Polish locale will throw an exception if there are any dots in them.

But it is not just parsing. If you invoke ToUpper on a string it also takes locale into account. In Turkey they have dotted i and dotless ı. The letter i (the dotted one obviously) has upper case equivalent which has a dot above it (expressible in unicode). If you have good fonts you should be able to see it right here: İ.

One more thing, when dealing with DateTime think about Buddhist Era in Sri Lanka :).

Labels: ,

1 comments

Resolver One - Beta

Saturday, December 8, 2007

There are plenty of languages laying around. They are tools with advantages and disadvantages. Knowing them allows us to know which are best to the job at hand. Recently I reflected on which languages would I use for different tasks.

If I had an idea for a killer web site I would go with Ruby on Rails. I have done one app using it and was very happy with it.

If I were making a windows app, I would code against .NET. The language of choice for this task would be Nemerle. Nemerle is a functional language with powerful macros (don't confuse with C macros) targeted at .NET Framework.

What would I use to add some processing to a spreadsheet? Python would be my first choice :). Resolver One allows to script a spreadsheet with Python. The Beta has just been released [download].

Labels:

0 comments

IronPython bug that cost me a can of Coke

Sunday, December 2, 2007

This is a bug in IronPython I have lost a can of coke over :). When I was pair programming the other day, we hit an assertion that we really expected to pass. It was an assert equals on two two-element lists. My partner, started to rewrite the assertion into two equals, one for each of the elements. I said that it was vain attempt and I bet him a coke that it would fail too ... well, I guess you know what happened.

What is the bug? Have a look at that. 

IronPython 1.1 (1.1) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> from System import IntPtr
>>> IntPtr.Zero == IntPtr.Zero
True
>>> [IntPtr.Zero] == [IntPtr.Zero]
False
>>>

BTW IntPtr is a value type like for example int, float and DateTime.

Together with Konrad we have launched debugger and observed the interpreter trying to compare the lists.

One would expect that to compare lists, is to compare the lengths, and check if all the corresponding elements are __eq__. But the implementation is to invoke internal to interpreter static Compare method (don't confuse it with IComparable.CompareTo) for each element rather than __eq__, and return true if the result is 0. I think that is because this how the things are in Python.

This Compare(object, object) method has a chain of if-else statements in which some value types are treated specially. That let me believe that the problem is only with value types. It looked like the interpreter would fail on a value type that is not IComparable. At some point the interpreter tries to cast the values to IComparable. DateTime is, for example, one value type not covered in the case analysis but it implements IComparable.

I was quite satisfied with the theory that only value types are affected, but as I was writing this post I realized that I don't remember anywhere Equals being called in the code. So what happens if an object is not IComparable but has Equals?

First I tried to find such a type among the .NET Foundation Classes. Seems that they all have them both defined or none of them. Nice convention, but there is nothing to prevent me from defining such a class myself. I defined it in Nemerle and compiled to a dll. Yes, IronPython interpreter failed to compare lists of equal objects of this class as equal.

To sum up, the bug affects types defined outside IronPython (or more specifically types that don't adhere to IronPython specific interfaces for comparison) that have Equals but don't implement IComparable.

The boxed value types don't follow the convention of having CompareTo alongside Equals, because while there is obvious way of implementing Equals for boxed values (comparing bits of the struct it points to), there is no obvious way of implementing CompareTo. If you use Reflector, you will see that System.ValueType.Equals is comparing bits.

Fortunately, this issue is no longer present in IronPython 2.0 alpha 6.

Labels:

5 comments

Better zip before copying over local network

Saturday, December 1, 2007

Sending source tree over local network is slow. The project tree of Resolver with binaries and installers generated is about 150 MB. As part of the distributed build it needs to be sent over to each machine that is part of it, which takes about 2.5 minutes each. We usually do a distributed build on 4-5 machines. That makes 10 minutes of copying.

I tried rsync, thinking that there are usually very few differences between trees developers want to build, but that was complicated and shaved off just 30 seconds. Most of the time was spent computing the delta, the data sent over was indeed small. Needless to say I abandoned that approach.

Andrzej suggested zipping the tree before sending. Why haven't I thought about it before rspec! At least I had occasion to familiarize myself with this awesome program.

The zipping time using 7z is only 20 sec. The zip can be copied over in just about 5 seconds, which makes it 30 times faster! Hooray for simple solutions!

So how much do we save sending a zipped tree? The build, had it run on a single machine, takes about 3 hours. Let's first analyze the situation assuming 2.5 minute sending time.

During the first 2.5 minutes, when the tree is being copied to the first machine, no machine is yet running tests. After the first machine receives the tree, it starts running tests; in the meantime the tree is being copied to the second machine. At the end of the first 5 minutes, we have one machine that has been running tests for 2.5 minutes, and one that has just received the tree. Fast forward to 10 minute mark, we have one machine that has been running tests for 7.5 minutes, one for 5 minutes, one for 2.5 and one just received a tree. In total it makes 15 minutes worth of testing done in 10 minutes.

In the above example there are 5 machines involved. One is sending out the tree to 4 others. Had they been all running tests for 10 minutes rather than copying files around or waiting for them to arrive, they would have done 50 minutes worth of the build, quite a difference!

4 comments