FxCritic

SVG XmlSerializer Classes

2011-03-31T19:39:00.000-07:00

I've been struggling lately with getting a parser of the SVG file format working in .NET C#. Scavenging the web in search of one has turned out that the few that do exist are often coupled to vector graphics rendering libraries and/or are often incomplete.Some have turned to writing their own simple SVG parsers, usually just for the support of paths, which was not enough for my purposes.

Thinking that SVG should be a simple enough file format to handle, being XML-based, I tried to automatically generate classes for it using the XSD tool.It didn't work right out the bat because of some ill-defined attributes in the SVG.xsd file, but I finally managed to work around it and generate class files that XmlSerializer can read and write, and even tested them successfully with an Inkscape file.

Without further ado, you can find the source here. Feel free to use it for whatever you feel like and to comment if any questions pop out.

Ramblings on the Command design pattern

2009-11-11T12:24:00.000-08:00

I was recently in need of implementing a mechanism for Undo/Redo for a GUI and was led to reminisce on the good old Command design pattern. Basically, I led myself to imagine what was the cleanest and most minimalist way of implementing the pattern in the .NET framework, specifically taking advantage of the C# 3.0 approach to functional programming.

It turns out implementing a generic Command pattern in C# 3.0 is so easy and powerful, via a clever use of delegates, that even the need for some of the classes specified in the original pattern is virtually eliminated.

Here's the implementation of a CommandExecutor class, which single-handedly deals with all the reusable aspects of the pattern:

public class CommandExecutor
{
  private int currentCommand = -1;
  private readonly List<Command> history = new List<Command>();

  public event EventHandler StatusChanged;

  public bool CanUndo
  {
    get { return currentCommand >= 0; }
  }

  public bool CanRedo
  {
    get { return currentCommand < history.Count - 1; }
  }

  public void Execute(Action command, Action undo)
  {
    if (command == null)
    {
      throw new ArgumentNullException("command");
    }

    command();
    if (undo != null)
    {
      history.RemoveRange(
        ++currentCommand,
        history.Count - currentCommand
      );
      history.Add(new Command(command, undo));
    }
    else
    {
      history.Clear();
      currentCommand = -1;
    }

    OnStatusChanged(EventArgs.Empty);
  }

  public void Undo()
  {
    if (CanUndo)
    {
      history[currentCommand--].Undo();
      OnStatusChanged(EventArgs.Empty);
    }
  }

  public void Redo()
  {
    if (CanRedo)
    {
      history[++currentCommand].Execute();
      OnStatusChanged(EventArgs.Empty);
    }
  }

  protected virtual void OnStatusChanged(EventArgs e)
  {
    var handler = StatusChanged;
    if (handler != null)
    {
      handler(this, e);
    }
  }

  private class Command
  {
    private readonly Action execute;
    private readonly Action undo;

    public Command(Action execute, Action undo)
    {
      this.execute = execute;
      this.undo = undo;
    }

    public Action Execute
    {
      get { return this.execute; }
    }

    public Action Undo
    {
      get { return this.undo; }
    }
  }
}

With this functor based implementation, commands can be easily passed into the executor along with the undo method, either as references to existing methods, or as lambda expressions.

Using the delegate indirection, this type of implementation conveniently eliminates the need for implementing a common Command interface, which makes it that much more reusable, as you can easily pass in methods of classes which you did not implement, or very easily and concisely transform specific method calls into commands without the need to implement yet another class.

Also, using the scoping semantics of anonymous delegates, you can easily use closures as data members for sharing immutable data between the execution of the command and the undo operation. For instance, consider the following example:


public class Test
{
  private readonly CommandExecutor executor = new CommandExecutor();

  public void TestScoping()
  {
    int sum = 0;

    for (int i = 0; i < 10; ++i)
    {
      var scopedData = i;
      executor.Execute(
        () => sum += scopedData,
        () => sum -= scopedData
      );
    }

    for (int i = 0; i < 10; ++i)
    {
      executor.Undo();
    }
  }
}

In this example, scopedData is used in the closure of the command delegates. Each iteration of the for-loop produces a different numeric value, which is implicitly preserved onto each command execution. By undoing the command, the sum gets preserved.

If instead the for-loop counter variable was passed, the undo commands would not be adequately preserved, as that variable would have been shared between all closures of all commands. In this way, you can adequately choose the level of sharing between command executions and undo operations, and effectively use the principles of functional programming to insulate each command execution from side-effects, while at the same time writing clean, concise, and efficient code.

Lightweight Fiber/Coroutines implementation on C#

2008-05-19T10:51:00.000-07:00

I was recently experimenting with exploiting the C# 2.0 iterators to simulate continuations, as suggested in Wesner Moise's blog and came up with what seems to be a general and reasonable way to implement fibers in .NET.

To implement a logical execution thread we basically need a stack to keep track of "subroutines" and a "program counter" to keep track of the current execution point. Basically we take on the IEnumerator interface as the basic type for program counters.

Simulating an execution is simply a matter of stepping through the current IEnumerator routine. Every time this enumerator yields a subroutine, the current routine is pushed onto the stack and the "program counter" switches to the new routine. Every time a routine terminates, the stack is tested for parent routines by popping().

Here's the lightweight fiber implementation and a small sample of how to use it:

public class Fiber
{
    private readonly Stack<IEnumerator> stackFrame =
        new Stack<IEnumerator>();
    private IEnumerator currentRoutine;

    public Fiber(IEnumerator entryPoint)
    {
        this.currentRoutine = entryPoint;
    }

    public bool Step()
    {
        if (currentRoutine.MoveNext())
        {
            var subRoutine = currentRoutine.Current
                           as IEnumerator;
            if (subRoutine != null)
            {
                stackFrame.Push(currentRoutine);
                currentRoutine = subRoutine;
            }
        }
        else if (stackFrame.Count > 0)
        {
            currentRoutine = stackFrame.Pop();
        }
        else
        {
          OnFiberTerminated(
              new FiberTerminatedEventArgs(
                  currentRoutine.Current
              )
          );
          return false;
      }

      return true;
    }

    public event EventHandler<FiberTerminatedEventArgs>
       FiberTerminated;

    private void OnFiberTerminated(
       FiberTerminatedEventArgs e)
    {
        var handler = FiberTerminated;
        if (handler != null)
        {
            handler(this, e);
        }
    }
}

public class FiberTerminatedEventArgs
  : EventArgs
{
  private readonly object result;

  public FiberTerminatedEventArgs(object result)
  {
      this.result = result;
  }

  public object Result
  {
      get { return this.result; }
  }
}

Now to implement a small recursive test program:

class FiberTest
{
  private static IEnumerator Recurse(int n)
  {
      Console.WriteLine(n);
      yield return n;
      if (n > 0)
      {
          yield return Recurse(n - 1);
      }
  }

  static void Main(string[] args)
  {
      var fiber = new Fiber(Recurse(5));
      while (fiber.Step()) ;
  }
}

This will print all the numbers from 5 to 0 by using fiber recursion. By yielding an IEnumerator, the fiber recursive function pushes the current fiber execution down to the recursive call. Test it yourself on the debugger and step through the execution to understand the basic mechanism.

With such a fiber/coroutine methodology its possible to define logical execution threads controlled by your application in which all involved iterator routines can be arbitrarily interrupted and resumed while preserving context.

Cool stuff once it clicks on you. Nice going for C# 2.0 iterators.

Immutability and the good old 'const' keyword

2008-05-09T02:18:00.000-07:00

With all the recent interest on C# functional programming and language integration of related concepts, one of the more interesting ideas is that of expressing immutability of an object.

An object is immutable if no methods beside the constructor can modify its internal state. Automatic verification of immutability is far from trivial, so many have been asking about how one could specify that an object is immutable at compile-time.

This would be interesting in multithreaded functional algorithm implementation, since we could potentially disregard parallelism concerns during function composing. All the shared data between functions was carefully protected simply by the fact that the data itself is immutable.

A couple of days ago I led myself to think: "Wait, isn't this what the const keyword in C++ was all about?". In fact, it's interesting how easily one could verify in C++ that an object was indeed immutable. Simply declare a const reference to an object and you only have access to const methods, which are methods guaranteed by the programmer that they won't change the object's internal state.

C# effectively abolished lots of extraneous keywords, in a quest to end unnecessary verbosity and functionality perhaps, but could it be that we're on the verge of witnessing a comeback of the so-called 'const programming'? No doubt it is an interesting way of solving the problem AND making sure that everything's verified at compile time. But it definitely increases the complexity in programming.

NSvn Handling of Repository Externals Property Text

2008-04-18T01:40:00.001-07:00

This first post does not entirely relate to the .NET framework itself, but rather to a useful assembly implemented by the Ankh SVN project: NSvn.

NSvn is a managed assembly to programmatically call Subversion commands like Update, Commit and others. It's a rather straightforward, and usable, library. However, there are some strange behaviors regarding some of its innards which can lead to some rather obscure bugs.

One of the latest I encountered was the handling of the svn:externals property in code. Here's a small annotated snippet of the endeavour:

Client client = new Client();
client.Checkout(sourceSVN, projectName, Revision.Head, NSvn.Common.Recurse.Full);

Basically I instantiated a NSvn.Client instance and performed a checkout of a repository located in sourceSVN into the directory projectName.

PropertyDictionary dictionary = client.PropGet("svn:externals", projectExternalsDir, Revision.Head, Recurse.None);
Property externalsProperty = dictionary[Path.Combine(sourceSVN, "Externals")];

One can then proceed to access the svn:externals property via the PropGet method. This returns a PropertyDictionary which one can access. The Externals property itself has to be retrieved from the dictionary by specifying the full repository path.

The problem began when we reached the point of actually modifying the value of the property, in particular, when adding a new external repository line:

string values = Encoding.UTF8.GetString(externalsProperty.Data);
values += newExternal + '\n';
values += newExternal + '\n';
byte[] vals = Encoding.UTF8.GetBytes(values);
client.PropSet(new Property(externalsProperty.Name, vals), projectExternals, Recurse.None);

By doing this, NSvn threw a SvnClientException indicating that there was an error parsing the property text.

It turns out that each Externals line has to be separated by a '\n' (not a '\r\n'!), but it's absolutely vital that the last line does not have ANY separator whatsoever. Adding a TrimEnd call to the end of values does the trick:

byte[] vals = Encoding.UTF8.GetBytes(newValues.TrimEnd('\n'));

Strange thing...

FxCritic launches

2008-04-09T04:38:00.000-07:00

"The word critic comes from the Greek κριτικός, kritikós - one who discerns, which itself arises from the Ancient Greek word κριτής, krités, meaning a person who offers reasoned judgment or analysis, value judgment, interpretation, or observation. The term can be used to describe an adherent of a position disagreeing with or opposing the object of criticism." - Wikipedia

FxCritic is a blog dedicated to giving reasonable criticism of Microsoft's .NET framework and associated libraries and utilities. Expect commentaries about new functionalities, framework inconsistencies, bugs, weird tweakings, workarounds, interesting ways to achieve desired effects, etc.