Archive for October, 2009

Howto databind a ICommand to an InputBinding – Update Comments Off

I have nice news, as i read in the What’s New in WPF Version 4 page in MSDN, data binding to InputBindings is now fully supported in WPF4.

Bind to commands on InputBinding

You can bind the Command property of an InputBinding class to an instance that is defined in code. The following properties are dependency properties, so that they can be targets of bindings:

    * InputBinding..::.Command
    * InputBinding..::.CommandParameter
    * InputBinding..::.CommandTarget
    * KeyBinding..::.Key
    * KeyBinding..::.Modifiers
    * MouseBinding..::.MouseAction

The InputBinding, MouseBinding, and KeyBinding classes receive data context from the owning FrameworkElement.

Update for post: CommandProxy: Howto databind a ICommand to an InputBinding

NHaml AST Parser – current state Comments Off

A while ago I’ve started to rewrite NHaml from its ground up to use an AST based parsing approach instead of directly creating the output while parsing. I did this because of the following reasons:

  • Separate parser from output generation
  • Allow to reuse the parser for syntax highlighting plugins like this one for Visual Studio or a possible ones for Sharpdevelop or Monodevelop
  • Error reporting with line and index of error source
  • Fully parse the document and report all errors at the end
  • Better maintainability since the separate steps are less complicated

Since this all dose not fit within the current codebase, so I’ve started an empty one at GitHub. Since i work the most time at trains offline, git is much more useable for me than SVN and i really like the GitHub forking model. So if the other members are agree, it is possible that we move the source code of NHaml to GitHub later.

Currently the entire codebase pass the haml-spec test suite from Norman Clarke. Big thank to Norman, without that spec it would have cost me much more time to bring the codebase to the current state. But this means not that it is useable. The current DebugVisitor which generates the HTML output from AST is only a intermediate step. It only output HTML and no compiler or any dynamic code is involved.

The next step, is to track the line number and character index for each node. This is ware i work on currently. And here it is:

This is a little test editor written with the Windows.Forms.RichTextBox. Initially I’ve used the WPF RichtTextBox, but since it is very very slow for this scenario and the optimization would cost much time I’ve switched over to Windows.Forms. Note: My goal is it no to create an editor for NHaml, i only use it for testing. As you can see not all nodes are highlighted yet.

The next step would be to report errors like when you only type “%” without a name behind (possibly this information could be used in a future syntax highlighting plugin too). After that I’ve want to extend the test suite for some missing parts like the alligator notation.

When all this is done, i plan to reintegrate the compiler and mvc stuff and publish it all together as NHaml 3.0. But don’t expect it to be soon.

Painless multi processing with Retlang 1

Retlang is a very nice and extensible library for handling multithreading the Erlang way, which means the concept of message passing and was created by Mike Rettig.

There is also a library from the Microsoft Robotics team called CCR which has the same goal. I’ve looked for it some time ago, but i dose not like its actor invocation syntax which looks really stodgily.

So lets start with some basic structures.


A fiber is an queue where you can add actions that then where dequeued and executed on a different thread. What thread this is depends on the type of fiber. Fibers are also support scheduling of the added actions for later execution and for continues execution.

All fibers are guarantee to execute only one action at the same time, which is very different to what the .Net ThreadPool dose. This is an important behavior, since it guarantees that all objects are thread safe when they are shared by the same fiber.

The following fibers are available (version

  • ThreadFiber – creates one thread and use this for execution
  • PoolFiber – uses the .Net ThreadPool
  • SynchronousFiber – only for Unit Testing
  • FormFiber – executes the actions on the Windows.Forms message thread
  • DispatcherFiber – executes the action on the given WPF Dispatcher

The last two are make the UI synchronization dead simple, and i plan to write later about them.

The most time you should use the PoolFiber, since it automatically distributes the action over all available CPUs and so it scale very well. Mike Retting measured that here.

ThreadFibers are should be only used if the added actions are taking a long time to execute. The reason is very simple. The most applications are creating a lot of fibers in their lifetime, in example one for each service. So you would have a lot threads in memory which only waiting for actions.

You should not share fibers for the whole application! Since fibers are guarantee to execute only one action at the same time, you would create a bottleneck. An exception are the Form- and DispatcherFiber because they are anyway restricted to execute only one action at the same time.


Channels are very lightweight in Retlang. They dose not have any threading code, all they dose is to deliver a published message of only one type to all of its subscribers.

As someone who knows the concept of a service bus, my initial thinking was to create global Channel<object> and handle all messages with it. But this is a very bad idea, since it creates a single bottleneck, its ugly (all subscribers a of type object) and it is not what Retlang is designed for.

There are also two other types of channels. The QueueChannel delivers the published message only to the first available subscriber instead of all. And the RequestReplyChannel blocks the sender until the subscriber sends back the reply.

how the channels help in multithreading when they dose not provide any threading?

This is where the Fibers fit in. An subscriber has to specify on which fiber it wants to handle the message. 

var fiber = new PoolFiber();

var channel = new Channel<string>();

channel.Subscribe(fiber, message=>{ Console.WriteLine(message); });

channel.Publish("hallo Retlang");


And that it is. All the other classes and interfaces are manly base classes and allow some nice extension points.