Sunday, October 30, 2011

Silverlight mdcm merged into Colby Dillion's main fork!


Yesterday, I was excited to see that my Silverlight and WPF fork of mdcm was merged, in its entirety, into Colby Dillion's main mdcm fork.

Since my efforts have now become more "official", I think it could be worth recalling some of the specific issues that are currently applicable in particular to the Silverlight library of mdcm:

  • The Silverlight class library is currently using Silverlight version 5 Release Candidate. It should be fairly straightforward to revert to Silverlight 4, but there may be some incompatibilities especially with respect to network access.
  • I have tried to implement managed support for JPEG codecs in the Silverlight project, but I have so far stumbled on 12 (and 16) bit support. The available open source JPEG codec libraries (FluxJpeg.Core and LibJpeg.Net) only support 8 bit images, and I have not yet been able to extend either of the libraries to 12 bit support. Furthermore, these libraries only support lossy compression.
  • Silverlight 5 will open up new possibilities for the mdcm Silverlight library, since P/Invoke is now supported when running in so called "elevated trust" mode. In particular, it should be possible to implement network server and full image codec support through calls to native libraries. So far, I have not implemented any of these ideas.
  • I have not made any extensive efforts with the MonoTouch project yet; in particular, no image support is implemented. Basic functionality is there though, DICOM file parsing and network client for example works out-of-the-box.



Wednesday, October 12, 2011

LINQ and Dictionaries

LINQ is a very powerful technique for operating on collections of objects in .NET. If you for example have a collection of integers, it is a simple task to pick the even numbers from the collection using LINQ:

int[] ints = new[] { 1, 3, 6, 8, 9, 10 };
IEnumerable<int> evens = ints.Where(i => i % 2 == 0);


Similarly for dictionaries:

Dictionary<int, int> intDict = new Dictionary<int, int> 
    { { 2, 3 }, { 3, 5 }, { 6, 7}};
Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0);


What? Compilation error?!?

In fact, the intDict.Where() statement is not entirely correct. From the LINQ point of view, Dictionary<,> and other classes implementing the IDictionary<TKey, TValue> interface are actually regarded as implementations of the IEnumerable<KeyValuePair<TKey, TValue>> interface. Thus (ignoring for a moment that we could also have used the var keyword), the correct evenKeys assignment should read:

IEnumerable<KeyValuePair<int, int>> evenKeys = 
    intMap.Where(kv => kv.Key % 2 == 0);

Now, my guess is that in the normal case one would rather have the above assignment to return a Dictionary. Fortunately, LINQ also provides a number of ToDictionary method overloads. So for the evenKeys assignment to return a Dictionary we simply type:

Dictionary<int, int> evenKeys = intMap.Where(
    kv => kv.Key % 2 == 0).ToDictionary();

What?! Compilation error again?

Yes, because the ToDictionary method also operates on IEnumerable<T> objects. You need to tell the compiler how you want to design your Dictionary based on this arbitrary type T. For correctness, our evenKeys assignment has to be expressed as follows:

Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0).
    ToDictionary(kv => kv.Key, kv => kv.Value);


For dictionaries, this explicitness may appear quite counter-intuitive, and there are several forum questions on the Internet indicating that this API design indeed has caused confusion (here, here and here for example).

After giving this issue some thought, I believe I have come up with an approach to bypass this hurdle of confusion. I have implemented the following extension method in a static utility class:

public static Dictionary<TKey, TValue> ToDictionary<TKey, TValue>(

    this IEnumerable<KeyValuePair<TKey, TValue>> source)

{

    return source.ToDictionary(kv => kv.Key, kv => kv.Value);

}

This overload of ToDictionary takes any object that implements the IEnumerable<KeyValuePair<TKey, TValue>> interface, which is a common return type when invoking LINQ operations on dictionaries, and returns a Dictionary<TKey, TValue> object using the same keys and values as the dictionary in the argument list. With this extension method defined, I now actually can enter:

Dictionary<int, int> evenKeys = intMap.Where(
    kv => kv.Key % 2 == 0).ToDictionary();

without getting the annoying compilation error.

Now this is all good and well, but I then decided to take the issue even one step further. Wouldn't it be good if for example the Where() extension method when operating on a Dictionary by default returned a Dictionary with the same keys and values?

Well, it can of course be done! And here is the solution:

public static Dictionary<TKey, TValue> Where<TKey, TValue>(

    this IDictionary<TKey, TValue> source, 

    Func<KeyValuePair<TKey, TValue>, bool> predicate)
{
    return Enumerable.Where(source, predicate).
        ToDictionary(kv => kv.Key, kv => kv.Value);

}

When this method is defined, it effectively hides the general Where(IEnumerable<T>, Func<>) extension method when the IEnumerable<T> object also implements the IDictionary<TKey, TValue> interface. Having the above Where() extension method defined now even makes it possible for us to apply our first dictionary LINQ attempt without compilation error:

Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0);

Unfortunately, this method will always return a Dictionary object, regardless of whether intDict is a SortedDictionary or SortedList or another object implementing the IDictionary<TKey, TValue> interface. At this point, I have no viable solution for returning the same dictionary type that was used as input to the specialized Where method. The quest for a solution will continue nonetheless.

I have also collected a few more similar LINQ extension method overloads in a Github project that I have chosen to call ... dictionarylinq

In this project you may find dictionary overloads for the Except, Intersect and Union extension methods. Due to their signatures, for these methods it has actually been possible to implement a specialized overload that returns the true input dictionary type, together with a designated overload with better performance for the Dictionary<TKey, TValue> class.

Included are also method overloads for the Select method when the return type of the Func<TSource, TResult> object is a KeyValuePair<TKey, TValue>. It would be relatively easy to add more method overloads to dictionarylinq, but for now this is what there is.

When the extension methods from the dictionarylinq utility class are included in your application, these methods will effectively hide the general extension methods in the System.Linq.Enumerable class. If you do want to fall back on the general methods in a certain scenario, either make an explicit cast to the IEnumerable<> interface:

IEnumerable<KeyValuePair<int, int>> output = 

    ((IEnumerable<KeyValuePair<int, int>>)input).Where(kv => kv.Key > 3);

or invoke the static method explicitly:

IEnumerable<KeyValuePair<int, int>> output = 
    Enumerable.Where(input, kv => kv.Key > 3);

Please also note that the dictionarylinq class library in the Visual Studio solution is a Portable Class Library. This means that the library uses the "least common denominator" of .NET Framework 4, Silverlight and Windows Phone 7 base class libraries. The library can be built once and consumed by all three .NET technologies without rebuilding. If you have not installed the Portable Library Tools, simply create a new designated class library project and include the source code from the dictionarylinq class library, or include the source code directly in your own class library or application.

I hope that this effort can be useful also to others than myself. For questions and comments on this work, please do not hesitate to contact me for example via a blog comment. If you are a Github user, please feel free to report code issues via the project's Issues tab.

Good luck with Dictionary and LINQ!

Friday, October 7, 2011

Getting the grip on your version control

I have recently been working with several different open-source projects that are available on Google Code, Github, CodePlex etc. The projects tend to use different software for managing version control, which in turn requires multiple SCM clients to be installed on the development system.

Version control software commonly used in open-source projects today include Subversion, Git and Mercurial. By default, the version control software is accessed through command-line interfaces. However, there are several different GUI wrappers available to facilitate the version control management. On Windows, different flavors of Tortoise are predominantly used. These tools are primarily shell extensions, enabling version control management inside Windows Explorer. TortoiseCVS for CVS version control was first in line, and it has inspired or formed the basis to followers like TortoiseSVN, TortoiseGit and TortoiseHg.

The various Tortoise tools makes version control management much easier and more efficient, and there is normally no problem having several of these tools installed at once on the same computer.

There is one annoying issue though: all the above tools use the same icons and icon overlays in Windows Explorer. It is therefore not immediately possible in Windows Explorer to determine which version control software that is being used to manage a specific folder.


Of course, if you enter the folder the version control administration sub-folders (.svn, .git, .hg, etc.) will be listed if you have configured Windows Explorer to display hidden folders. But this is a sub-optimal behavior; ideally the version control software should be detectable through some indication in the Windows Explorer list, or when hovering the mouse over the folder in question.

In case someone had experienced the same annoyance as I and found a workaround for it, I posted a question on the subject at StackOverflow. I got a few answers primarily explaining why the same icon overlays are used, but then I also got an eye-opening answer from Stefan K√ľng, lead developer of TortoiseSVN. Stefan suggested me to customize the version controlled top folder using the approach described here. This was exactly what I had looked for: a method for customizing the folder layout and provide explanatory text in the tool-tip when hovering over the folder with the mouse pointer!

My only remaining concern now was that I would have to do this customization manually for each version controlled folder, which would be quite tedious and error-prone when a large number of projects are involved.

But then, what do developers do, if not implementing solutions to repetitive problems?

Thus, I took the bull by the horns and came up with a simple yet efficient console application for managing the folder customization. The application identifies the version control software used in the specified folder, adds a tool-tip and sets the folder icon to indicate which software that is being used to version control the folder. Currently, the application identifies Subversion, Git and Mercurial, but if the conditions are right (version control administration files in a sub-folder with a fix name) it is a straightforward task to extend this list of software. The application source code is available under an open-source license (Eclipse Public License version 1.0) and can be obtained from here.

After running the application on the version-controlled folders in the image above, Windows Explorer will (after a few refreshes) provide the following display:


Hovering with the mouse pointer over a version control decorated folder will clearly indicate the version control software being used:


It is even possible to run the folder decorator application without changing the folder icons. If the icons are not available in the same directory as the folder decorator application, the classic folder icon will be maintained but the tool-tip will still be updated.

The icons have been obtained from the Open Icon Library. The Subversion icon is "Sub-optimal"; I was not able to find a better redistributable Subversion icon. For personal, non-redistributable use, a more identifiable Subversion icon is available here. If you so wish, download this Subversion icon file instead, rename it to svn.ico and replace the existing Subversion icon in the Visual Studio project with the downloaded one.

Happy version-controlling!