VDR Plugin Survey 2008

I’ve started a small survey about VDR and the VDR plug-ins and kindly ask you to participate.

http://e-tobi.net/survey/

The main reason for this survey is, that there are currently more than 300 plug-ins available for VDR (according to the English and German VDR Wiki).

That’s a lot!

As a member of the Debian VDR packaging project (we currently just have about 120 plug-ins packaged), I would like to know, which are the plug-ins that are really used and which are the ones that aren’t used at all.

As a result of this survey, we would like to drop Debian packaging support for some of the rarely and not used plug-ins that are not maintained by their authors anymore and identify interesting plug-ins that might be good candidates for an official release in Lenny +1 .

This survey is not just about the Debian VDR packages. It’s main focus is on VDR and VDR plug-ins in general and I hope, it will be useful for other distribution maintainers and developers as well.

I will make the results and all the collected data available to the public under the terms of the Creative Commons Licence (CC-BY-SA), after the survey has been finished.

The survey is completely anonymous! You have to register with an email address and a password, but they will only be stored as an SHA hash in the database and will be randomized once more, before the data is made available to the public. The survey will not send any emails or do other nasty stuff!

If you have any problems with the survey or your are missing a plug-in, just write me a small note to: vdr-plugin-survey-2008@e-tobi.net

Thanks for your participation!

Tags , ,

Posted in | Posted on 31 Aug 2008 14:08by Tobi | no comments

Microsoft is not going to fix the bugs, I found :-(

Last week I found an issue with Microsofts C# compiler, which does not generate warnings about unused variables in some cases. I’ve reported it to Microsoft and to my surprise, got an answer today.

Unfortunately they are not going to fix it :-(

…our guidance for customers who are interested in discovering unused elements in their code is to use FxCop. …we are not actively enhancing the compiler’s detection of these conditions and will not be making the changes you suggest.

FeedBackID 362970

Tags , ,

Posted in | Posted on 28 Aug 2008 12:42by Tobi | no comments

Unit test of the day

5 unit tests covering a single line of code:

[TestFixture]
public class A_SwissRounding
{
    private SwissRounding _rounding = new SwissRounding();

    [Test]
    public void Should_round_down_to_zero_when_having_zero_to_two_and_a_half()
    {
        Assert.AreEqual(1.00m, _rounding.Round(1.0010m));
        Assert.AreEqual(1.00m, _rounding.Round(1.0249m));
    }

    [Test]
    public void Should_round_up_to_five_when_having_two_and_a_half_to_five()
    {
        Assert.AreEqual(1.05m, _rounding.Round(1.0250m));
        Assert.AreEqual(1.05m, _rounding.Round(1.0490m));

    }
    [Test]
    public void Should_round_down_to_5_when_having_five_to_seven_and_a_half()
    {
        Assert.AreEqual(1.05m, _rounding.Round(1.0510m));
        Assert.AreEqual(1.05m, _rounding.Round(1.0749m));
    }

    [Test]
    public void Should_round_up_to_10_when_having_seven_and_a_half_to_ten()
    {
        Assert.AreEqual(1.10m, _rounding.Round(1.0760m));
        Assert.AreEqual(1.10m, _rounding.Round(1.0990m));
    }

    [Test]
    public void Should_not_round_multiples_of_five()
    {
        Assert.AreEqual(1.00m, _rounding.Round(1.0000m));
        Assert.AreEqual(1.05m, _rounding.Round(1.0500m));
        Assert.AreEqual(1.10m, _rounding.Round(1.1000m));
    }
}

public class SwissRounding
{
    public decimal Round(decimal value)
    {
        return Math.Round(value*20, MidpointRounding.AwayFromZero)/20;
    }
}

:-)

Tags ,

Posted in | Posted on 26 Aug 2008 18:16by Tobi | no comments

The Microsoft .NET C# compiler has it's issues as well

While working on porting StructureMap to Mono I stumbled across some bugs in the Mono C# compiler. I did expected this, fixed or worked around the bugs and reported them. What I didn’t expected, was to find some trivial bugs in Microsoft’s C# compiler as well. It’s nothing critical, but annoying. Consider this code:

using System;

namespace Test
{
    public class BuggyClass
    {
        private string foo = String.Empty;
        private int _bar = 5;
        private int _wrongBar = 5;

        public int Bar
        {
            get { return _bar; }
            set { _wrongBar = value; }
        }

        public void DoSomething()
        {
            string msg = "foo" + 1.ToString();
        }
    }
}

It contains three variables and fields which are never used, so I would expect the compiler to emit three warnings. But csc does nothing - in none of three different versions:

c:\tmp\--->C:\WINDOWS\Microsoft.NET\Framework\v3.5\csc.exe /warn:4 /target:library test.cs 
Microsoft (R) Visual C# 2008 Compiler Version 3.5.30729.1
, fr Microsoft (R) .NET Framework Version 3.5
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.


c:\tmp\--->C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe /warn:4 /target:library test.cs 
Microsoft (R) Visual C# 2005, Compilerversion 8.00.50727.3053
fr Microsoft (R) Windows (R) 2005 Framework, Version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. Alle Rechte vorbehalten.


c:\tmp\--->C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\csc.exe /warn:4 /target:library test.cs 
Microsoft (R) Visual C# .NET-Compilerversion 7.10.6001.4
fr Microsoft (R) .NET Framework, Version 1.1.4322
Copyright (C) Microsoft Corporation 2001-2002. Alle Rechte vorbehalten.

This point goes to the Mono C# compiler, for correctly identifying these warnings:

c:\tmp\--->C:\Programme\Mono-1.9.1\lib\mono\1.0\mcs.exe /warn:4 /target:library test.cs 
test.cs(19,20): warning CS0219: The variable `msg' is assigned but its value is never used
test.cs(7,24): warning CS0169: The private field `Test.BuggyClass.foo' is assigned but its value is never used
test.cs(9,21): warning CS0169: The private field `Test.BuggyClass._wrongBar' is assigned but its value is never used
Compilation succeeded - 3 warning(s)

You might say, that this is just a trivial warning and usually it doesn’t hurt to have some unused variables around. But look at the Bar property above. It sets a different value than the one it returns. Looks like a serious bug to me - maybe caused by wrongly renaming the field. If this isn’t covered by a unit test and the compiler doesn’t even give a warning, chances are good, that this bug will find it’s way into production code.

I’ve also reported this to Microsoft’s Bug Nirvana BugTracker (FeedbackID 362970).

Tags , ,

Posted in | Posted on 22 Aug 2008 13:28by Tobi | no comments

Doing .NET the "hard" way

One of my favorite tools for .NET development is the dependency injection framework StructureMap from Jeremy D. Miller. It’s free and it’s Open Source, but it’s only available in the Windows world. Compared to Castle Windsor, StructureMap is much more lightweight and compact, but with the recent enhancements in the upcoming release just as powerful.

So I thought, it couldn’t be so hard, to make StructureMap work with Mono and package it for Debian, but actually, it’s not THAT easy.

The heavy usage of .NET 3.5 features, like lambdas, requires a recent development version of Mono. Took me 2-3 hours to have Mono and Monodevelop compiled from SVN and installed in parallel to my old Mono packages to /opt/mono. But that’s working fine now.

The StructureMap VS2008 solution loads fine in Monodevelop, which makes life a lot easier. The only 3’rd party-dependency that StructureMap has, is Rhino.Mocks (another of my favorite development tools). The Rhino.Mocks assembly seems to work with Mono, but compiling it from source is probably much harder, because of it’s dependency to DynamicProxy, so I decided to leave that by side for now, skip StructureMap.Automocking and concentrate on the core parts of StructureMap.

After working about a week on this, I already found three bugs in the Mono C# compiler, but the good news is, that StructureMap now compiles fine with some small patches (that Jeremy hopefully will include in the upcoming release).

Luckily, StructureMap is very well covered with unit tests, which makes testing it on Mono much easier. The state of affairs is, that most of the tests go green. I have about 70 failures within more then 600 tests and I’m pretty confident, that I can solve the remaining issues as well.

Tags , , ,

Posted in , | Posted on 21 Aug 2008 01:19by Tobi | no comments