Author: jrwren

Yes, I am crazy. Why would any programmer want this combination? I think it is a combination of wanting to work with the best tools, in this case Visual Studio 2008 and CodeRush and wanting to target Win32, OSX, and Linux all at once. The very nice part is that thanks to the hard work of other people, you don’t even have to run in Mono on Win32.

1. Install the GTK# SDK
   You can get it from here: http://medsphere.org/projects/gtksharp/releases/2.10.4/gtksharp-sdk-2.10.4.msi
   The project page is here:
   http://medsphere.org/projects/gtksharp/
   Thanks to the good folks at medsphere for maintaining this windows installer. Presumably they use this in their applications.
2. Create a new Windows Forms Project in Visual Studio.
   
   Its fine to keep 3.5 framework selected. Mono supports the core parts of 3.5.
3. Remove the references to System.Windows.Forms.dll
4. Add reference to atk-sharp, glib-sharp and gtk-sharp in the following paths:
   C:\Program Files (x86)\Medsphere\Gtk# Runtime\lib\gtk-sharp-2.0\atk\atk-sharp.dll
   C:\Program Files (x86)\Medsphere\Gtk# Runtime\lib\gtk-sharp-2.0\glib\glib-sharp.dll
   C:\Program Files (x86)\Medsphere\Gtk# Runtime\lib\gtk-sharp-2.0\gtk\gtk-sharp.dll
5. Change your Platform target to x86 from AnyCPU in the project properties.
   
6. Write some test code

[STAThread]
static void Main()
{
    Application.Init();
    Window myWin = new Window("My first GTK# Application! ");
    myWin.Resize(200, 200);
    myWin.Destroyed += new EventHandler(myWin_Destroyed);
    Label myLabel = new Label();
    myLabel.Text = "Hello World!!!!";
    myWin.Add(myLabel);
    myWin.ShowAll();
    Application.Run();
}
static void myWin_Destroyed(object sender, EventArgs e)
{
    Application.Quit();
}

7. Run the application
   

Enjoy your 3rd option for a pure .NET programming GUI Toolkit on Win32. Winforms and WPF are great, but GTK# does fill a certain niche.

Its no secret that I came to C# after doing lots of Perl. I treasure my Perl experience. Many claim that Perl is unreadable, but I argue that the language is as good as the programmers using it. I’ve seen pages of equally unreadable PHP, VB, and yes, even C#. I’ve used Perl libraries as references for how things work. Many Perl libraries are examples of great highly readable code. Language doesn’t matter.

Perl’s documentation is a testament to open source languages. I learned Perl with perldoc installed an the perl man page. It taught me the Perl way of data structures and as I got more advanced I ran into Arrays of Arrays(AoA), Arrays of Hashes(AoH), Hashes of Arrays(HoA) and Hash of Hashes(HoH). These are all defined in the perllol perldoc.

Some of the most confusing Perl that I ever did read or write was confusing because instead of building explicitly named types, convention was relied on too much over configuration and everything was just a HoHoHoHoHoHoH. I think it was a joke about Santa Clause.

All that said, there are times when you really want a HoH or a HoHoH or a HoHoHoH. That is Dictionary<string,Dictionary<string,string>> or Dictionary<string,Dictionary<string,Dictionary<string,string>>> or Dictionary<string,Dictionary<string,Dictionary<string,Dictionary<string,string>>>> for you non perl types.

A little over a year ago, Eilon Lipton wrote a post on using anonymous types as Dictionaries. I rather liked it, but That was just a H (Dictionary<string,string>).  I recently had the need for a HoHoA.

I’m not advocating using this code or ever writing code like this. In fact, I discourage it. If you can find a way to do the same thing but with compile time checks, please do that instead. The problem with using anonymous types as dictionary literals is that you won’t know until runtime that you have made a mistake. WRITE YOUR UNIT TESTS!

public static Dictionary<string, string> ToDictionary(this object source)
{
    var dict = new Dictionary<string, string>();
    var props = source.GetType().GetProperties();
    Array.ForEach(props, p => dict.Add(p.Name, (string)p.GetValue(source, null)));
    return dict;
}
public static Dictionary<string, IList<string>> ToDictionaryOfStrings(this object source)
{
    var dict = new Dictionary<string, IList<string>>();
    var props = source.GetType().GetProperties();
    Array.ForEach(props, p => dict.Add(p.Name, (IList<string>)p.GetValue(source, null)));
    return dict;
}
public static Dictionary<string, Dictionary<string,string>> ToDictionaryOfDictionaries(this object source)
{
    var dict = new Dictionary<string, Dictionary<string, string>>();
    var props = source.GetType().GetProperties();
    Array.ForEach(props, p => dict.Add(p.Name, (Dictionary<string,string>)p.GetValue(source,null).ToDictionary()));
    return dict;
}
public static Dictionary<string, Dictionary<string, IList<string>>> ToDictionaryOfDictionariesOfStrings(this object source)
{
    var dict = new Dictionary<string, Dictionary<string, IList<string>>>();
    var props = source.GetType().GetProperties();
    Array.ForEach(props, p => dict.Add(p.Name, (Dictionary<string, IList<string>>)p.GetValue(source, null).ToDictionaryOfStrings()));
    return dict;
}

Yes, you have to call the right method, it isn’t magic. Yes, these extension methods pollute all objects with their clutter. They do work when you need them though!

var things = 
new
{
    Humans = new { Johny = new[] { "Guitar", "Docks" }, Gina = new[] { "Diner", "Pay" } },
    Dogs = new { Sparky = new[] { "beer", "baseball" }, Toto = new[] { "witch", "kansas" } },
    Marsians = new { Marvin = new[] { "death ray", "moon laser" }, Quato = new[] { "speech", "power" } }
}.ToDictionaryOfDictionariesOfStrings();

Assert.IsTrue(things.ContainsKey("Humans"));
Assert.IsTrue(things.ContainsKey("Dogs"));
Assert.IsTrue(things.ContainsKey("Marsians"));
var humans = things["Humans"];
Assert.IsTrue(humans.ContainsKey("Johny"));
Assert.IsTrue(humans.ContainsKey("Gina"));
var gina = humans["Gina"];
Assert.IsTrue(gina.Contains("Diner"));
Assert.IsTrue(gina.Contains("Pay"));
var dogs = things["Dogs"];
Assert.IsTrue(dogs.ContainsKey("Sparky"));
Assert.IsTrue(dogs.ContainsKey("Toto"));
var sparky = dogs["Sparky"];
Assert.IsTrue(sparky.Contains("beer"));
Assert.IsTrue(sparky.Contains("baseball"));

Good times.

OK, it isn’t exactly broken, it just doesn’t know about vista’s virtual path features. This means you can run the exe as a non-admin user and it does not get installed properly.

The work around is to not run the installer as a regular use and wait for UAC to invoke itself. It never will. Instead, save the .exe file and right click on it and choose "Run as administrator…"

Now the program will actually get installed to C:\Program Files or C:\Program Files (x86) instead of the virtual are c:\Programs\data\user\blah\wahterver\it\is\vista\has\some\crazy\features.

Why am I using GIT? Well, unfortunately because I have to. Cloning was easy enough but just typing git help or git help clone and I immediately miss the polish of bazaar. The "I have to" is in reference to the no longer ignorable myriad of projects now hosted at github. IMNSHO all of these should have opted to be hosted a launchpad. But as we have seen in the past in technology, the best solutions don’t always win. Sometimes the solution with the loudest voice wins. (VHS>Beta?) (DAT>DCC?) (Blueray>HDDVD?)

I replied to a blog post by Tosos over here:

The reply was long enough that I thought it warranted posting here too. I expand on why “var” is not dangerous and can go away. I also describe why it isn’t duck or dynamic or anything but strong and static. If you know F# this is nothing new to you.

Here it is:

I love these.

@Mike Borozdin:
Consider F#’s definition of methods(functions). It is just as strongly typed as C#, yet the compiler is left to infer the return type.

In the example above the return type is not weak, it is not vague or dynamic or relying on duck typing. The return type is the anonymous type defined by the select clause of the linq statement. All of the static type checking and strength of warnings and errors of the compiler will still occur.

I’d like to see similar syntax, but drop the var, it is needless noise.

e.g.

public GetFirstPageOfFiles(string dir)
{
  return Directory.GetFiles(dir).Take(10);
}

The signature of the method GetFiles takes a string and returns a string so we (and the compiler) KNOWS that GetFirstPageOfFiles returns a string.

But have we simplified the language as much as we can? F# wouldn’t make me specify the type of the argument to the method. It would infer it.

public GetFirstPageOfFiles(dir)
{
  return Directory.GetFiles(dir).Take(10);
}

Again, the argument to GetFiles is string so the compiler knows how to turn the method signature of

public GetFirstPageOfFiles(dir)

into

public string GetFirstPageOfFiles(string dir)

Where the compiler can’t infer, it should give an error and require the explicit use of the type.

This exactly the behavior of var now.

As for #3, I would NOT want this to be the default behavior. The default behavior should be strong-static types. As strong and as static as possible. That said, some compiler support for the equivalent of duct typing via reflection would be rather nice. AFAIK what you are asking for is already available through a 3rd party library from David Meyer at http://www.deftflux.net/blog/page/Duck-Typing-Project.aspx

With respect to default behavior being duck, Phil Haack is wrong, everyone is wrong. If you want that, use Iron Ruby or Iron Python.

I wrote about my uncertainty about the GetEnumerator duck here: http://jrwren.wrenfam.com/blog/2007/07/21/c-has-duck-typing/  It may have been necessary. If it wasn’t necessary, I’d call it a mistake. Maybe it was an accident. I don’t know.

Could I be more against duck typing? Yes, I could be against it entirely. I could completely misunderstand it. Unfortunately I’ve written in duck languages. I’ve probably written more code in PHP, Python and Perl than I have in C#. (I wrote A LOT of Perl and PHP.)

My simply request is to require the manual selection of behavior of duck, like Boo. Yes, I say “like boo” a lot, but much could be learned from boo. Boo had extension methods before C#. Boo has duck in a strong, static typed language. Of course, boo is not a special case. It is best to learn as much as possible from neighbors so that you can make your own decisions about things. My request is probably going to be granted. Charlie Calvert wrote about the dynamic keyword and dynamic blocks as a possible solution to this.

I do not write business applications. Oh sure, I write applications for a business. This business makes money. The applications which I write helps them make more money. However, these applications are in the domain of product engineering. They are not in the domain of running the business. They do not deal with cash flow, inventory, accounts receivable or payable. There is no letter opener of death involved with any of my application users.

My applications have no Business Logic. The business processes could change at this company and my applications don’t know anything about it. We solve engineering problems. That said, separation of UI and Business Logic is still a strong concern. It isn’t Business Logic. It is Application Logic.

Why mention this? I feel like there are programmers out there who say to themselves, “I do not write business applications, therefore this silly separation of business logic does not apply to me.” These programmers are wrong. Separation of application logic from UI code is valid not matter what the application. Separation of Concerns extends to every type of software. I cannot imagine a type of software from which separation of concerns does not benefit. I’ll go so far as to say that if you think you have a case: that you are wrong. If you think you can justify it to me, I will simply redesign to a case which does fit.

Do you write math apps?  Separate your Math Logic from your UI.

Do you write engineering apps? Separate your Engineering Logic from you UI.

Do you write medical apps? Separate your Medical Logic from your UI.

Do you write biology apps? Separate your Biology Logic from your UI.

Do you write Anthropology apps? Separate your Anthropology Logic from your UI.

Do you write Sociology apps? Separate your Sociology Logic from your UI.

Do you write Psychology apps? Separate your Psychology Logic from your UI.

Do you write Legal apps? Separate your Legal Logic from your UI.

Do you see a pattern here? Separate your seeing of patterns from your UI.  Good.

I previously had a list of things I wanted. Yes, I am like a 2-year old. I want. I want. I want.

mdavey posted a link to a channel 9 video which made me rethink my request. Oh I still want all of the original list and… I want more. I want more. I want more.

• List Literals – it is silly that I even have to request this
• Dictionary Literals – see list literals for comments
• Extensible Literals – the .NET BCL already has this really great type conversion system. You ask for a type converter for a specific type and whether or not it can be converted between two types. One of these types is often a string. You can write your own converters and register them with this system of type converters. It is very elegant and beautiful. The compiler should use this to let me express my own literals. Type initializers are nice, but this would be nicer.
• Variable Generic Type Parameter Arity – Chris Marinos had a use case for this and had to implement a solution in a much less elegant way because he was missing this feature. Its a request in Java too. Cliff Biffle says that Mongoose has them, but I can’t find whatever became of the smalltalk inspired language.
• Restricted Types – The same post on Variable Generic Type Parameter Arity, Cliff reminded me of my favorite Modula-3 feature. He points out that Dylan has it. I like Modula-3’s approach to this using Subtypes. This paper by Cardelli, Donahue, Jordan, Kalsow and Nelson does a great job of explaining Modula-3’s simple but powerful type system. Not all of the subtypes in M3 make sense in a .NET world. We already have a well defined type system and some of the constructs would not mix. One concept that I think would mix well is range subtypes. Imagine that you know a value is always going to be between zero and 100. You can define a subtype of int and use that type throughout your program. The compiler actually checks that variables of this type are never out of this predefined  range. Type Conversion is automatic from int subtype to int type, but not the other way. It is awesome if for nothing other than eliminating IndexOutOfRangeException on array indexers.

Yes, I do want my cake and to eat it too.