Anonymous Generic Lists

Kirill Osenkov made a pretty good example on how it is possible to create lists of anonymous types in C# 3.0. I knew about this because of a collegue at work and automatically said... we can do this with every single type, not just anonymous :)

I will just show a slightly different implementation of the List Factory provided by Kirill example:

public static class AnonymousExtensions
{
   public static IList<T> ToList<T>(this T item)
   {
      return new List<T>() { item };
   }
}

That implementation use type inference and extensions methods to achieve the following:

static void Main(string[] args)
{
   var customer = new {Name="John"}.ToList();
   customer.Add( new {Name="Bill"});
}

The interesting side effect is that with that definition we are not only providing the capability to create lists from anonynous types but for any type based on an example. In the next example we are going to use an integer, and create a list based on it.

static void Main(string[] args)
{
   var anotherList = 1.ToList();
   anotherList.Add(2);
}

I will try to continue writing stuff here and not let the blog dormant for a year (as I did :) ) but I cannot promise anything.

Hope you enjoyed this simple code.

Reflections on Microsoft Academic Summit (Chile)

Luckily I was invited to an excelent event last week, thanks to Microsoft for that ;).

For those that do not know, the Microsoft Academic Summit gathered researchers and professors from the most respected Latin American Universities and Microsoft Research Labs. Needless to say it was an amazing event, excelently organized, serious, cool and fun at the same time. People like Jim Miller (Chief Architect of .Net), Dave Probost (Windows Kernel), and Eric Horwitz, and other researchers gave very interesting talks about the future of the Computing.

My reflections of what has been an extensive event with interaction with some pretty serious people has been the following:

- As noted by Claudio Delrieux (My PhD Thesis Advisor), one achievement of Microsoft Research last year has been publishing aproximately 21% of the papers in Siggraph (For those that do not know it, it is the biggest, difficultier and most respected publication in the graphics area). Coincidence?? Hell no, they are doing hard science and Graphics is very coupled to several hot topics like Computer Human Interaction (new interfaces design - WPF for everyone :) ), Parallelism (new approaches to old problems), knowledge management (data visualization), etc.

- .Net is going to replace hard to code and interact Ajax based application with REAL Rich Applications on the browser. Macromedia's Flash would have obliterated already the competition if they would have the advanced support for development and interaction with server technology that .Net provides. Thanks to Microsoft that doesnt exists already and now .Net has a fair advantage through Silverlight technology.

- Jim Miller's showed us a Python/Javascript integration. He run an script using the DLR - Dynamic Language Runtime embeeded in a Silverlight application interchanging the lines between both languages (Quite a feat I must say)... I would say Smalltalk environment like for everyone on the web browser :). Why do I mention this?? Well this gives a pretty interesting advantage to create Game like teaching environments to learn programming languages and computer graphics.

- Game technology seams to be pretty hot in the Academic environments because it is fun and powerful, there are already lots of people that are doing pretty interesting things; however in Argentina that seams to be in its infancy if it isnt born yet. I recall a conversation between some argentinian researchers before the conferences that went like this way:
"The third etnic in the Games Development Conference were Argentinians, arround 10% of the attendants" - Professor 1
"Wow, thats a lot. If they are not studing in the universities, where do they study? - Professor 2
"They are not studing on the universities. ;)" - Professor 1 and me at unison.

More or less those are my reflections on what has been my interaction with the people invited to the conference. If you have any comment, just drop me a mail or leave a comment.

Greetings
Federico

Graphics Computing: not just games and entertainment

Its being a lot of time since my last update, I think I will have some time from now on to start writting about interesting graphics stuff again :) ...

Luckily I can say that our latest article with Claudio Delrieux (my PhD Thesis Advisor) has been finally published in the Microsoft Latin America Architecture Newsletter. If you dont receive it you can read it from their blog.

Graphics Computing: not just games and entertainment

Hope you enjoy it ;), and remember more thing will come in the near future.

Greetings
Federico Lois

Echos from the World Cup!!!

This is how we lived the blatantly amazing victory against the "Serbia and Montenegro" team. What can I say??? Argentina Rocks!!!.

The Buenos Aires Team of Huddle in one of the most important points of celebration for the Capital people: "El Obelisco".

"The Frozen Death" is all around us.

Recently I read a pretty interesting article about Open Source Projects "Frozen Death", also known as "Death by Inactivity" coming from the very heart of one of the most successful Open Source projects in the world. How the hell that can happen? Well it came from no more and no less than NUnit, by far one of the most successful enterprise projects arround. The complete article can be read here: http://nunit.com/blogs/?p=1.

What can I say about the issue? I really feel in my guts that no project is exempt of it; in my own experience with "Project Xenocide" we have been fighting the Frozen Death for a long time. Sometimes it gets very hard, other times it is just plain imposible to devote the time or energy needed for such an endervour. However, at least in Xenocide, I have an excelent team that can overcome the nonesayers negativeness and cover the holes caused by lack of the management team time and I am really proud of them. Sometimes I found myself with lack of motivation (not always you are in a good mood to do things), others it becames just plain imposible to even code a line or communicate with your team. On the other hand, in my case I feel relieved about the great things that a deeply cohesive and great team can do even when faced with the reality of a dauntingly complex project, lack of time, lack of tools or even lack of domain expertise.

In my humble opinion a post like the one that the NUnit team have done is to be admired, even though most people do not see it. They have decided to fight the bull with their bare hands and I honestly believe that the outcome of a decision like that cannot be other but true success, satisfaction and personal growth.

As that I send them Kudos on the great project they are running and as such I will continue to be a very happy user of their great tool. On regards to the Project Xenocide Team, this is no more than a call to action (like the ones that we have seen in the past) to push the "Frozen Death's Shadow" far away from us as we have successfully done in the past. That is my commitment, what is yours?

On the news

On the news section, last weeks had been pretty interesting on personal achievements.

First, I was approved to start the PhD on Computer Science on "Universidad de Buenos Aires" one of the highest rated universities in Argentina. My PhD will focus on realtime rendering so I am sure that I will be able to write a little about it soon.

Another interesting news has been that Fun with Singletons series had been published by "Level Extreme .Net Magazine". Click here to link to the magazine edited article. Thanks to Martin Salias (Editor of Level Extreme .Net) to believe this series has the potential to be published in the magazine.

I have already a couple of articles to publish that I will write as soon as I have some free time. So, stay tuned.

Greetings
Federico

Fun with Singletons in C# 2.0 (Part 2)

And here we go again :)

Last entry we talked about the "Generic Singleton" and how to achieve such an artifact without partial specialization templating (aka full blown C++ templating engine). In this entry we will focus on allocators, what they do, what is their responsability, what we can do with them, and maybe some little history about their existence.

Allocators in one shape or another can be tracked to the very beginning of the programming endervour. There had always been a necesity to allocate resources, the most basic resource to allocate was memory; so in procedural language we relied either on the compiler to do stack allocation of memory or on specific constructions or library calls (as in C) to do the work. Using those approaches the specific allocation strategy was hidden from the programmer by those calls.

Sometimes things didnt worked as expected and those default allocation strategies fall short, mostly when a lot of space has to be allocated to be used in special ways; for example in mathematical code (memory must be aligned and consecutive to better use the cache of the processor) or in code with high performance requirements. At that moment most programmers relied in custom strategies to handle those situations doing just a single call to get all memory required in one step.

When object orientation got mainstream and languages like Smalltalk and C++, some objects were a little too big and costly to initialize, we again relied on allocators to recicle the memory we used or objects :) .

Then someone thought, what if we let the programmer specify the memory/object allocation strategy giving a binding to the underlaying allocation system. Then the allocators where given a name and an existence in its own. And light filled the sky and allocators where born :D

Ok, enough history. Now we are going to the nitty gritty details (I love this part). IMHO the best way to accomplish something is knowing where we want to go. Now lets suppose we have our "Static Allocation Singleton" from Part 1, now what if we write something like this:

/// <summary>
/// An StaticSingleton using an StaticAllocator used just 
/// to simplify the inheritance syntax.
/// </summary>
public class StaticSingleton<T> : Singleton<T, StaticAllocator<T>> where T : class
{ }

So our static singleton is just a Singleton of type T with an StaticAllocator of type T. Cooool! Isnt it?? Now lets get our hands dirty. So by now we know that our allocators will be the ones that will be in charge of specifying our allocation strategy. Now our singleton not only depends on T but on our Allocator too. In C# code it should be something like this:

public class Singleton< T, Allocator >
    where T : class
    where Allocator : Allocator< T >
{
    private static readonly Allocator<T> allocator;
    /// <summary>
    /// The Singleton implementation of the Instance method defer the creation policy to 
    /// its allocator, so this method just delegate the Instance retrieval to the 
    /// Instance method of the allocator.
    /// </summary>
    public static T Instance 
    {
        get { return allocator.Instance; }
    }
}

Even if you dont know already we have solved the Allocator Based Singleton problem. Where is the trick you might think? Well someone said (if anyone knows the source would be cool): "There are only a few problems in Computer Science that cannot be solved by an extra level of indirection." I applied that concept so now the Instance method just delegates the real allocation to the Allocator Instance :)

We have a big problem to solve yet, but we have solved it in the last singleton implementation. Guess who had been the lucky winner that will ensure that the allocator get created :D, yes our friend Reflection.

static Singleton()
{
    ConstructorInfo constructor = typeof(Allocator).GetConstructor(
        BindingFlags.Instance | 
        BindingFlags.NonPublic, null, 
        new Type[0], new ParameterModifier[0]
                            );

    if (constructor == null)
        throw new Exception("The allocator doesnt have a private/protected constructor.");

    try
    {
        allocator = constructor.Invoke(new object[0]) as Allocator<T>;
    }
    catch (Exception e)
    {
        throw new Exception("The Singleton Allocator couldnt be constructed", e);
    }
}

What if I create multiple allocators then can I create multiple instances of T? The answer is yes and no. Yes, you can create multiple instances of the allocator, and No they wont allow you to have multiple instances of T :) using the same trick that we used before.

Our allocator looks like this:

public abstract class Allocator<T>
    where T : class
{
 /// <summary>
 /// The parameterless protected Constructor.
 /// </summary>
 protected Allocator()
 { }

 /// <summary>
 /// The property returns the only instance of the Singleton Object in question.
 /// </summary>
 /// <remarks>This property implementation must enforce the Single Object property
 /// of Singletons throwing an exception.</remarks>
 public abstract T Instance { get; }
}

So how do our StaticAllocator look? Well, almost the same as our original singleton :O

public class StaticAllocator<T> : Allocator<T> where T : class
{
 static StaticAllocator()
 {
     ConstructorInfo constructor = typeof(T).GetConstructor(
             BindingFlags.Instance |
             BindingFlags.NonPublic, null,
             new Type[0], new ParameterModifier[0]);

     if (constructor == null)
         throw new Exception("The object doesnt have a private/protected constructor.");

     try
     {
         instance = constructor.Invoke(new object[0]) as T;
     }
     catch (Exception e)
     {
         throw new Exception("The StaticSingleton couldnt be constructed", e);
     }
 }

 private StaticAllocator()
 { }

 private static readonly T instance;

 /// <summary>
 /// The static allocator Instance property returns the instance created on class loading.
 /// </summary>
 /// <remarks>This means that the singleton is instantiated at the moment in which
 ///  a class has a reference to that type even if it never calls the Instance
 ///  method.</remarks>
 public override T Instance
 {
     get { return instance; }
 }
}

What if we want to do a LazyAllocator, well as in most textbooks we will leave that for the reader to implement by themselves (just dont tell anyone, you can get the source from here ;) ) So we did all this just to implement a LazyAllocator?? Hell no, what if I say you that you can have an abstract singleton to instance a concrete provider by itself just reading the concrete instance from a config file? Whould it be useful? Well I know of an specific scenario where it wont be only cool, but useful. When you are creating a Rendering Engine and the rendering provider could be Managed DirectX or OpenGL (and that cant be changed on the fly ;) ) then you just read the Renderer concrete class from a configuration file, and the user wont ever know what it is using as he is using an abstract class. :)

I must say that this entry was fun to write it, so I hope you enjoy reading it as much as I did writting it.

Greetings
Federico