blog community

Welcome to blog community Sign in | Join | Help
in Search

Frank Bakker

Frank Bakker talks about software development

  • Parallel Extensions for .Net Framework will be included in .Net 4.0

    I has been a while since I wrote a post on parallel programming. Since that time a lot has happend in field of parallel programming.

    Microsoft has been working hard on implementing the Parallel Extensions for .Net Framewok (PFX) and has now anounced that it will be a core part of the next version of the .Net Framework (right into mscorlib.dll). See the post on the PFX blog PFX blog . If you are interested in Parallel programming I strongly recomend reading up on the PFX blog. I also expect more details to be anounced at the upcoming PDC (to bad I won't be there).

    FPX includes a task scheduler that promisses to scale well beyond two of four CPU's / cores and allowes LINQ to objects queries to be executed parallel (PLINQ). The later, and probably lesser known aditions include so called Coordination Data Structures (CDS) these include thread safe collection classes, like stacks an queues. One of my personal favorites of the CDS is LazyInit<T>. LazyInit is a smart little helper class that makes it easy to implement Lazy Initialization of fields or local variables, of course this is done thread safe so that it can be used in parallel scenario's.

    Can't wait to use these new goodies in real life projects!

  • More fun with Extension Methods and Lambda's: Creating a generic tree visitor

    One of the most common data structures in Software Engineering is the tree. In the .Net framework for instance you can find them in the file system, the controls of a win-forms application, nodes in an XML document etc.

    A common task with trees is to traverse all nodes to look for a specific node or perform an operation on each node. This is usually called visiting. Many tree like data structures unfortunately don't have a built-in visiting mechanism, so we usually need to build this ourselves with something like a recursive method.

    What I wanted to do is to write an generic implementation to visit any recursive tree. While the basic algorithm to do this is not very complicated, there are two factors that make it difficult to make the implementation generic, the first is that the type of the nodes is different for each tree, the second is that the way to obtain the children of a node is different for each tree. C# 2.0 solved the first problem with generics, and now C# 3.0 has solved the second problem with Lambda expressions.

    A generic tree visitor should allow me to iterate all nodes as a single Enumerable<T>, which of course has the advantage that it can be used it a foreach or a Linq query. So the code I Would like to write to visit a tree would be something like the following:

    foreach (var node in root.VisitDepthFirst(n => n.GetChildNodes()))

    {

        // ...

    }

     

    Where VisitDepthFirst is a generic extension method that operates on the root object. The extension method receives a Lambda expression that is used on a node to retrieve all it's children. For most trees this is a single property or method which return a collection of all child objects.

    See the implementation of the depth first visitor below

    static public IEnumerable<T> VisitDepthFirst<T>(this T root, Func<T, IEnumerable<T>> childSelector)

    {

        if (root == null) yield break;

        // we return the root

        yield return root;

        // then we do a recursive Depth first search of all children and yield each item we find

        foreach (var child in childSelector(root).SelectMany(c => c.VisitDepthFirst(childSelector)))

        {

           yield return child;

        }

    }

    When testing this in a Win-forms application I first tried the following

    foreach (var control in groupBox2.VisitDepthFirst(c => c.Controls))

    {

        control.Text = "Done";

    }

    This however leads to a a few compiler errors. The first is has to do with the fact that groupBox2 is of type GroupBox and not Control therefore the compiler expects the Lambda expression to return IEnumerable<GroupBox > instead of IEnumerable<Control>. The second problem is that the ControlsCollection does not implement a generic IEnumerable<> at all but in stead only the non-generic IEnumerable.

    To fix this I had to be a bit more explicit about the type of the node and use Linq's Cast<>() Extension method to convert the Controls collection to IEnumerable<Control>. The following is the correct way to do this.

    foreach (var control in groupBox2.VisitDepthFirst<Control>(c => c.Controls.Cast<Control>()))
    {
        control.Text = "Done";
    }

    Likewise visiting all nodes in an xml document is done as follows

    foreach (XmlNode childNode in xmlDocument.VisitDepthFirst<XmlNode>(n => n.ChildNodes.Cast<XmlNode>()))

    {

    }

    To be complete I also created a breath-first search. I don't know if I'll ever use it, but why not.

    static public IEnumerable<T> VisitBreathFirst<T>(this T root, Func<T, IEnumerable<T>> childSelector)

    {

        if (root == null) yield break;

        Queue<T> open = new Queue<T>();

        // the open queue contains the items that have already been visited, but who's children have not

        yield return root;

        open.Enqueue(root);

        while (open.Count >0)

        {

            T item = open.Dequeue();

            foreach (T child in childSelector(item))

            {

                yield return child;

                open.Enqueue(child);

            }

        }

    }

    While I think this is a nice example of generics and Lambda's, I have to be hones that I'm not quite sure if this should have been implemented as Extension Methods. The problem here is that these extension methods operate on any object without restriction, which makes them pop up in intellisense all over the place once you add the using directive. The alternative ofcource is to make it a normal static method and loose the syntactic sugar of extension methods. 

    Any comments on that one?

  • Using C# 3.0 Extension methods and Lambda expressions to avoid nasty Null Checks

    In the project I am currently working on we use a domain model with a quite deep nested structure of classes, code like the following is quite common.

    // do something with the Adress
    Console.Writeline(Contract.Parties.Client.Adress.Street);

    The problem with this is that not all Contacts have a related Parties object and if we do have a Parties object sometimes the Client object is Null. This lead to writing a lot of code code like the following:

    if (Conract != Null &&
        Contract.Parties != null &&
        Contract.Parties.Client != null &&
        Contract.Parties.Client.Adress != null)
    {
        // do something with the Adress
        Console.Writeline(Contract.Parties.Client.Adress.Street);
    }

    There are a few problems with this code, the first of which is that it is quit verbose. Second it evaluates the same properties over and over again. In order to reduce the double work we could introduce some extra local variables and create a separete if statement for every step, this will make it even more verbose than it is allready.

    Of course C# 3.0 has a lot of new syntax tricks, like extension methods, lambda expression and type inference. I had seen some nice examples (mostly Linq related) but had not been using these features to the max myself. Somehow I got the idea that these features would help me solve the Null checking problem.

    I figured that the code I wanted to write was something like the following.


    if (Contract
        .NullSafe(c => c.Parties)
        .NullSafe(p => p.Client)
        .NullSafe(c => c.Address) != null)
    {
        // do something with the adress
        Console.Writeline(Contract.Parties.Client.Adress.Street);
    }

    The idea is that all parts of the path are expressed in separate lambda expressions which are chained together. If any link in the chain returns null, the rest of the path is never evaluated and the result of the whole expression will also be null.
    All I had to do to make this possible was write one single extension method that would operate on any object, I was quite amazed that I could do this with verry little code that, besides some generic stuff, was actually quite simple.

            public static TResult NullSafe<T, TResult>(this T target, Func<T, TResult> func)
            {
                if (target != null)
                    return func(target);
                else
                    return default(TResult);
            }


    All the generics make it look a lot more complicated than it actually is. This extension method receives two arguments, the first of which is the object it operates on and the second is a generic Func<T, TResult> delegate (the lambda expression). The return type of the extension method is automatically inferred from the return type of the lambda that is passed in. This allows you to call NullSafe again on the result of the first call and use IntelliSense to type p.Client in the second lambda.
    The nice thing about extension methods is, besides that they can operate on any existing class without changing it, that they can also operate on Null references without causing a NullReferenceException!! This makes it possible to test for null inside the extension method. If the object it is called on is not null it evaluates the lambda expression and returns the result. Otherwise it returns the default value of the expected return type, for reference types this is Null.
    To make life even better I created another overload of NullSafe that was even simpler

            public static void NullSafe<T>(this T target, Action<T> action)
            {
                if (target != null)
                    action(target);
            }

    Instead of a generic Func<T, TResult> delegate this one receives a Generic Action<T> delegate and returns void.
    This removes the need to retype the whole path inside the if, it actually removes the if altogether.

    Contract
        .NullSafe(c => c.Parties)
        .NullSafe(p => p.Client)
        .NullSafe(c => c.Address)
        .NullSafe(a =>
        {
            // do something with the adress
            Console.Writeline(a.Street);
        });

    To bad for me, my current project is still on C# 2.0 so I'll keep doing it old school style :-(

    Exercise

    If you would also like some practice with C# 3.0, I would like challenge you to write something that allows me to do the same thing for IEnumerable<T>, I would like to write something like the following

    foreach (Order order in Contract
        .NullSafe(c => c.Parties)
        .NullSafe(p => p.Client)
        .NullSafe(c => c.Orders)
        {
            // do something with order
            Console.Writeline(o.Amount);
        }

    Where Client.Orders is of type IEnumerable<Order>. The idea is that I want to iterate every Order in Contract.Parties.Client.Orders. If at any stage in the path (including the Orders collection) we encounter a Null reference we will just loop an empty enumerator and do nothing.

  • Will our current programming model survive multi-core hardware?

    For years the innovations of CPU's have been focused on increasing the speed at which a single sequence of instructions gets executed (mainly by increasing the clock frequency). In the last years this trend is changing from increasing sequential execution speed to parallel execution (multi CPU / hyper-threading / multi core). If this trend continues the number of processor cores will no longer be measured in dual or quad, but in K, M or G.

    Today's popular programming languages (both OO as procedural) encourage (or force) us to write software as a sequence of statements that get executed in a specific order. This paradigm is called an execution thread and it maps very nicely on the traditional CPU model which has a single instruction pointer. Executing tasks in parallel is made possible by calling a system API that creates a new execution thread. This is more a platform than a language feature, which requires even more system API's to do the required locking and synchronization.

    Generally multi threading is considered an advanced and error prone feature. This is why it is generally used only in situations where parallel execution is an explicit requirement, like in server processes to handle multiple client requests and in GUI applications to allow background processing while the UI keeps handling user events. In situations where tasks could be executed parallel, but there is no direct need to do so, we usually stick to our traditional sequential programming model. This is a great waste of the hardware’s parallel processing ability

    My personally experience to non-sequential languages is pretty much limited to SQL and XSLT. Maybe it is time to spread the horizon and take a look at some of the modern Functional languages like F#  and Fortress. Who is with me?

  • Lack of support for generic base classes in Windows Forms designer

    Just recently having started my first real life .Net 2.0 project I wanted to utilize all the cool new features in my day-to-day job. One of those features is of course the support for Generics in C#. But, as with all cool stuff, getting your hopes up to high can get you disappointed.

    In our Windows forms application we use a design pattern in which a UserControl defines a callback interface which is implemented by a mediator. This makes sure we have a loose coupling between the UserControl and the source of the rest of the application.

    To avoid having a lot of duplicate code I decided to make a base class that does some of the stuff related to initializing the mediator. While every control will have a different mediator interface this called for generics (sample code is written by hand, so don't mind the compiler errors).


    class ViewControlBase : UserControl <TMediator>
     where TMediator : IMediator
    {
     TMediator _mediator;

     protected TMediator Mediator
     {
      get { return _mediator; }
     }

     public InitMediator(IMediator mediator)
     {
      _mediator = (TMediator) mediator;
      // some more generic stuff
     }
    }

    Now the viewControls are derrived from ViewControlBase like this

    class CustomerView : ViewControlBase<ICustomerMediator>
    {
     // ... Use typed access to the Mediator property
    }

    By using a generic base I was able to have Typed access to the Mediator in all the derived classes, and I avoided writing the initialization code over and over again. Hitting F5 proved all worked just as expected.

    But when I opened one of the ViewControls in the designer the designer was filled with an error saying something was wrong. Usually this means that you have to rebuild the solution, clean up, rebuild some more and eventually it works. Not is time :-(

    The error stated that the class CustomerView was not 'Designable' because it was not able to create an instance of ViewControlBase. That is true, it is however possible to create an instance of ViewControllerBase<TMediator>

    I found a work-around (or a dirty Hack) by creating an empty dummy class like this

    class CustomerView : CustomerViewDummy
    {
     //...
    }

    class CustomerViewDummy: ViewControlBase<ICustomerMediator>
    {}

    Now CustomerView is no longer (directly) derived from a generic class the designer stops complaining and shows the control in design view as expected. Since I didn't really like this solution I went back to old-school and duplicated the same code in every control (Bummer!)

  • Timezone aware DateTime stucture in .Net 2.0 ?

    The last year and a half I have been working on a project based on .Net framework 1.1, that (among other things) involved handling multiple time zones. If you have ever worked on such a project you either did it wrong without knowing or you have spent a whole lot of time getting it nearly 100% right. The biggest problems are the XML serialization that always assumes en DateTime represents local time, and the lack of a specific Date-only data type which is time zone independent. When it comes to handling DateTimes in different time zones .Net framework 1.1 just doesn't cut it.

    Framework 2.0 brings partly good news, only last week I happened to 'intellisense' over a new property on the DateTime structure; DateTime.Kind. It seems that Microsoft has found a use for 2 unused bits in the 64 bits that hold up the data for a DateTime structure. These 2 bits were not enough to store the actual UTC offset. Instead they choose for three possible values, Local, UTC and Unknown. This is a big improvement because it solves the incorrect XML serialization problem of UTC DateTimes.

    The lack of the actual UTC offset in the DateTime structure still has the downside of not being able to handle time zones other than UTC or your own (the one configured in the regional settings) without storing the offset in a separate field and doing your own transformations. Of course the DateTime being a structure which cannot be inherited from doesn't really help to create a generic solution for this one. Second it causes an ambiguity in the hour in the fall when the clock shifts to daylight saving time. This can cause an UTC time being converted to local and back to UTC not to be the same as the original. Last time this happened some of our unit tests broke because the daily build cycle runs exactly within this hour.

     

  • SQL Server 2005 vs. Office Web Components

    Last week I installed SQL Server 2005 Developer Edition on a development PC. This took almost as long as installing an Oracle server, which is not what I am used to when running a 'routine' SQL Server Setup.

    The SQL 2005 installer starts off with a check for all the prerequisites, and all lights were green. I choose an allmost default install of the client tools and the SQL instance itself. When half way installing the required components I got a message that I had a previous version of the 'Office Web Components' (OWC) installed. I needed to remove this previous installation and restart the setup of SQL Server. Bummer.

    Checking the 'Add / Remove programs' applet I found that there was indeed a OWC XP version installed, after choosing 'Remove' and clicking through the dialogs I was ready for a retry. Starting up de SQL server setup again choosing the same options as before, all lights green again and .... 'a previous version of OWC is found, please uninstall and redo all the stuff you did twice before ....grrrrr.

    Once again I fired up the add / Remove programs and found that now OWC 2003 was installed. Again I uninstalled it, did a reboot for safety and restarted the SQL Server Setup. What do you know... again the same message.

    For the third time (of the forth I forgot the actual count) I uninstalled OWC from the Add / Remove programs applet and immediately after removing it I reopened the Add / Remove programs and It was still there!! Even after another reboot, uninstall etc etc the Add remove programs still showed OWC 2003 installed.

    As a last resort I located the OWC11.msi on the SQL Server 2005 CD and reinstalled it directly from there. After this I was able to to re-run the SQL Server setup with no problem.

  • It seems to be my turn

    After both Raimond and Ramon tagged me I have no way to deny it, it's my turn to tell you five things you didn't know about me.

    1. By scanning the blogs of the previous victims it looks like the first item should be what your first computer and first programming experience is. My dad bought our first computer, an Atari 800 XL, when I was about 9 years old. It was the time when everyone else had a Commodore 64 and was trading C64 games. Since only a few games were available for the Atari, I was left to programming my own games in Atari Basic. A few years later we got our first PC and I learned Turbo Basic which allowed me to write programs without line numbers and goto statements! Around the same time my cousin got an Amiga which was pretty cool when we discovered AMOS Basic which allowed for very easy animations programming.

    2. Of course, more important than the above, I'm getting married to Dineke next September 20th. At this moment we are busy with the preparations. We have already booked the location, the band and the photographer. Right now we are trying to find the rings and the invitations cards.

    3. Currently I'm doing a little project with a friend of mine which brings me back to when I was somewhere between 16 en 19 years old. Together we are fixing up a Gilera Citta, for those who don't know, a Citta is a small moped, originally designed to go up to 25 km/h. At this moment my garage is filled up with moped parts and a partly re-assembled vehicle. I will dare to say that we are pretty thorough as we have replaced almost every single part that is still available from stocks.

    4. I have recently picked up a photography course. I noticed that a lot of people are buying digital Single Line Reflex camera's just because they have a lot of mega pixels. So I bought myself a Sony Alfa DSLR 100 (FKA the Konica Minolta)  and enlisted a photography course to make sure my money is well spend. Photography appeals to my passion for technology, but also teaches to look at the world in a different way.

    5. Now what else don't you know about me? Well if you read my blog (all 3 previous posts) you know that I work at Info Support and one of my main interest is Software Development. While my interest in programming began as a hobby when I was 9, currently don't do a lot of spare-time programming anymore (although I recently did write a SUDOKU solver but it still lacks a GUI, or does NUNIT count as a GUI). Instead I find other things to do in my spare time like playing online chess and of course #2, 3 and 4.

    The problem with piramid games is ofcource being at the bottom of the piramid, that's why I decided to choose only one next victim.

    To make sure we don't stick to IT related blogs; Robert Haasjes is a personal friend of mine who has a pesonal blog on Hyves as well as a (quite inactive) blog about wheelchair rugby, It's up to him to decide on which Blog he will tel us five things we didn't know about him.

    So, now I ame not at the bottom anymore :-)

     

  • Show source file and line number information in your Stack traces

    A while ago I wrote a blog-post about not breaking the stack trace while throwing an exception up the call stack. Stack traces are the very first place you look when finding the cause of an unexpected exception. Today I was once again saved by a stack trace. A project I am currently working on is starting a pilot in Cairo next week and had some trouble with a NullRefrenceException that was blocking one of the main scenarios. The entire pilot should be called-off, if this didn't get fixed right away.

    Luckily the application's crash screen did not only allow me to view the exceptions stack trace (which is pretty common), but we had also deployed the compilers .PDB files along with the application's assemblies. PDB files contain (among other things) information about which IL-instruction corresponds to which source file and line number. The Visual Studio debugger uses this to place the yellow arrow at the next line of code that will be executed. Because most people don't debug on their production environment why should you deploy these files? By default Visual Studio doesn't even generate them for a Release build.

    Besides assisting the debugger, the information in the .PDB files are also used at runtime when you call the Exception.ToString() method. At each level in the stack trace after the name of the executing method, the source file and the line number of the executing statement are added, if a PDB file is present for the assempley containing the method. This looks something like this.

    System.NullReferenceException: Object reference not set to an instance of an object.
       at Demo.Class1.Foo(Object parameter) in c:\projects\Demo\class1.cs:line 48 
       at Demo.Class1.Main(String[] args) in c:\projects\Demo\class1.cs:line 21

    With this information I retrieved the correct version of the source file from source control (of course we label the sources with the build-number in our build cycle) and scrolled to the line number I had found in the stack trace. This showed me the exact statement that caused the NullReferenceException in less than five minutes, without having to reproduce the error in the development environment (which would have been quite tricky in this case). By only looking at the code I was able to see that someone had made a configuration error while installing the pilot environment. Correcting the configuration error fixed the problem and the pilot was ready to go.

    So unless you have good reasons to hide information about your source code from your end users, you should always set the compilers 'Generate Debugging Information' option to true for Release builds and keep the PDB files along side the assemblies wherever they go.

  • Peek into the database during your unit test

    Have you ever had the following problem?

    You are debugging a unit test which has just inserted some records into your database. While the unit test is waiting on a breakpoint you want to see the result of the insert in the database. You start up SQL Query Analyzer type 'select * from customers' and hit <F5>. What happens? If you are lucky you get to see the table as it was before you started the unit test, if you are unlucky your query just 'hangs'. Now why is that?

    Anyone who understands a little bit about transactions knows this must be because the insert is done inside a transaction which has not yet been committed. Therefore the result of the insert is isolated from any other database process or a table lock might even prevent you from reading the table at all.

    When I ran into this (again) today I started thinking about it and found a solution which in fact is very simple. Before running your select * from customers you execute the command:

    SET TRAN ISOLATION LEVEL READ UNCOMMITTED

    The trick is that by setting the isolation level to 'read uncommitted' you can read the data that was inserted by the unit test code even though there might be table locks and the changes might eventually even get rolled back (which is usually the case in a unit test).

     

  • Keep your hands off my stack traces!

    When the first beta of the .Net framework was released one of the best features I thought was that the Exception.ToString() method shows you the stack trace from the place where the exception is thrown to where it is caught. Stack traces are your best friend when finding the cause of an unexpected exception. Back in the VB 6 time we spent a lot of effort harvesting this information ourselves.

    This is why I get really upset when someone screws up the stack trace information by doing something like the following.

    try
    {
        // method call that might throw an exception at some deeper level
        some.Method();
    }
    catch (Exception ex)
    {
        // some code to figure out what to do with the exception (maybe logging or whatever)
     
        // hmm in this case we do not really handle this exception after all, lets re-throw
        throw ex;
    }

    What is wrong with this code? It is the 'ex' behind the throw. When you re-throw an exception this way the stack trace information in the Exception object is cleared and it will appear to who ever catches it at a higher level as if the exception originated from the location where it is re-thrown, thereby loosing valuable information about the location where the exception really occurred.

    Inside a catch block you are allowed to use trow; (without an exception). The C# reference doesn't say very much about this, except that it is used when re-throwing the current exception object in a catch clause. Sounds like it is pretty much the same as when you do explicitly throw the exception you just caught as in the code example.

    There is however a big difference that is not directly clear from the documentation. When you use throw without an exception you are actually saying "lets pretend I never caught this exception". This causes the Exception to be thrown further up while preserving the whole stack trace from the original throw to the next catch up the call stack.

    Now pretty please, with sugar on top, use throw; instead of throw ex; inside a catch block, and leave my stack trace alone!

Powered by Community Server, by Telligent Systems