Today I had to convert a binary expression to a lambda and then use in a where clause on a collection. Easy enough, I thought, make an ExpressionLambda, compile it, substitute it into the where clause, no worries.

This is the first cut of the code:

public class ClassWithProperties {
    public string Prop { get; set; }
}

static void ExpressionCrashes() {

    var expr = Expression.Equal(Expression.Property(Expression.Variable(typeof(ClassWithProperties)), "Prop"), Expression.Constant("value2"));

    var props = new[] { Expression.Parameter(typeof(ClassWithProperties)) };
    //Throws <variable '' of type 'SOCSTest.ClassWithProperties' referenced from scope '', but it is not defined>
    var lambda = Expression.Lambda<Func<ClassWithProperties, bool>>(expr, props).Compile();

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Should return <"value2", "value2">
    items.Where(lambda);
}

The expression is a basic one – it calls an equality comparison on a property off an object and a constant. It is equivalent to this:

value.Prop == "value2"
//Where value is a parameter of type ClassWithProperties

Googling for this exception and just general expression and lambda stuff kinda hints at people having the same problem as I am but with no fast solution. It was Jon Skeet’s answer to question I didn’t understand on StackOverflow that finally put me onto the right track.

In order to compile a lambda from an expression, you need to provide all instances of ParameterExpression that appear in the expression tree when creating a lambda expressionn (i.e. when calling Expression.Lambda<T>(Expression, params ParameterExpression[])). The Expression engine will not match types and names parameters in an expression – as far as it’s concerned different instances of ParameterExpression are discrete parameters.

Rewriting the above code yields something that doesn’t crash:

static void ExpressionWorks() {
    var variable = Expression.Variable(typeof(ClassWithProperties));
    var expr = Expression.Equal(Expression.Property(variable, "Prop"), Expression.Constant("value2"));

    var props = new []{ variable };
    var lambda = Expression.Lambda<Func<ClassWithProperties, bool>>(expr, props).Compile();

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Returns <"value2", "value2">
    items.Where(lambda);
}

As you can see, we reused the instance variable in both expression declaration and Expression.Lambda call. Everything works fine now.

Getting the parameters from Expression at runtime

My situation was such as that I had to deal with an already created expression. So I couldn’t simply take the variable parameters that are used to create an expression and reuse them when creating a lambda. The solution was to traverse the expression tree and get a list of all the ParameterExpression instances that are contained in the expression and pass those to Lambda function.

Luckily, ExpressionVisitor API provides an easy way to achieve this. All you have to do is inherit from ExpressionVisitor and implement one function to trap all the goodies we need:

public class ParameterVisitor : ExpressionVisitor{

    List<ParameterExpression> m_Parameters;

    public IEnumerable<ParameterExpression> GetParameters(Expression expr) {
        m_Parameters = new List<ParameterExpression>();
        Visit(expr);
        return m_Parameters;
    }
        
    protected override System.Linq.Expressions.Expression VisitParameter(System.Linq.Expressions.ParameterExpression p) {

        if(!m_Parameters.Contains(p))
            m_Parameters.Add(p);
            
        return base.VisitParameter(p);
    }
}

We can even create an extension method to hide all complexity of creating a lambda:

public static Func<TSource, TResult> CreateLambda<TSource, TResult>(this Expression expression) {
    var visitor = new Bluecap4.Core.Expressions.ParameterVisitor();
    var parameters = visitor.GetParameters(expression);
            
    return Expression.Lambda<Func<TSource, TResult>>(expression, parameters).Compile();
}
//Usage
static void ExpressionWorks() {
    var expr = Expression.Equal(Expression.Property(Expression.Variable(typeof(ClassWithProperties)), "Prop"), Expression.Constant("value2"));

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Returns <"value2", "value2">
    items.Where(expr.CreateLambda<Func<ClassWithProperties,bool>>());
}

Nullable is a value type

It’s a struct that can be null. The only reason why int? intVal = null; compiles is because C# compiler supports nullable types. You cannot define the same kind of struct yourself.

The decision to make Nullable<T> a value type actually makes sense if you think about it. Calling its member methods and properties will always succeed, i.e. NullReferenceException will never be thrown. This gurantees that HasValue never throws a NullReferenceException.

Comparison to null

Under the hood, the compiler, in fact translates comparison to null to a call to HasValue. The below MSIL demonstrates that:

    .locals init ([0] valuetype [mscorlib]System.Nullable`1<int32> 'value',
           [1] bool hasvalue,
           [2] bool hasvalue2)

    //int? value = null;
    IL_0001:  ldloca.s   'value'
    IL_0003:  initobj    valuetype [mscorlib]System.Nullable`1<int32>
    //bool hasvalue = value.HasValue;
    IL_0009:  ldloca.s   'value'
    IL_000b:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue()
    IL_0010:  stloc.1
    //bool hasvalue2 = value != null;
    IL_0011:  ldloca.s   'value' //loads a variable onto evaluation stack
    IL_0013:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue() //calls HasValue
    IL_001b:  stloc.2 //Stores the result in location 2 (hasvalue2)

As you can see the generated IL for hasvalue = value.HasValue and hasvalue2 = value != null are identical.

null Assignment

Also from above code you can see that assigning null to a nullable value is the same as calling the parameterless contructor (which all value types have).

Ternary operator

C# compiler also does special things with ternary operator for nullable types. The following code compiles:

int? nullableIntVal = 4;
int intVal = nullableIntVal ?? -1;

The above is just syntactic sugar for calling HasValue and if it’s true calling GetValueOrDefault(). The compiler actually generates a temporary variable to call HasValue off in both Release and Debug modes. Not sure why that is. Below code illustrates the equivalent C# code to what the compiler generates for ternary operator.

int? nullableIntVal = 4;
int? temp = nullableIntVal;
int intVal = temp.HasValue ?? temp.GetValueOrDefault() : -1;

Summary

Nullable<T> is a special value type that has support from C# compiler to allow the following:

• null assignment – under the hood: calling defualt constructor.
• null comparison – under the hood: calling HasValue property.
• ternary operator ?? – under the hood: calling HasValue and conditionally GetValueOrDefault.

Application

The application in question is a fairly normal case of a business DSL where the domain rules are expressed in XML and the compiler generates an application for different platforms (web, mobile web, PDA, WPF). Code is written in C#, tested with MbUnit v.3 and NMock2.

This particular class parses XML and generates JSON to be later consumed by ExtJS library. The JSON is a declaritive form of the control that users will eventually see. This control is complicated and has many options. Hence the fatness.

Enter the unit tests

Now, unit tests are touted to be great for refactoring. They are. The usual approach is to write the tests, make sure they pass, then refactor and make sure the tests don’t break. Well, I want to take it one step further and let the writing of the tests guide the refactoring.

Thoroughly unit tested code tends to have really good code smells. This is mainly due to fact that in order to test all aspects of a large block of code, you must isolate all of its constituents. This is evident in all projects that are written in a TDD way. They are all very modular and modular is good(I think :-) ).

So my goal here is just simply write the unit tests and see where it takes me. I would imagine that just by making the code testable, it will become a little bit better.

I never invisaged this to become a full blown article, but now that I am here, lets introduce some numbers to make this more scientific. I will be using Microsoft Team Studio Analysis Tools throughout the process. Here is a snapshot of what the class looks like at the start:

As you can see the Build method is too big – 250 lines. This is bad. It’s one of those DoIt methods that does everything.

First refactor

Alright, lets get cranking. Straight away I noticed that I was reading a particular bit of XML and making decisions based on the node contents. This particular functionality has already been abstracted away in another class, so I might as well use that class. So I just refactored that without writing any tests before or after. That’s pretty naughty :)) Lets make it proper and rip this code into another function so we can test it.

Starting from the top of the method I am looking at a bit of code that parses an atribute and calls a method that is defined in the base class depending on whether or not the attribute exists.

Base class dependency

Now refactoring that into a method is not a problem, the problem is isolating the call to the base class. There is case to be made for having the base class contain all the dependencies that are required for all of its subclasses, however, just by skimming the code it looks like a lot of the methods there are simply in one place for convinience. So this could potentially be a case of Inheritance vs. Composition. Lets start off by abstracting this particular method into an interface and have our base derive from the interface. Then in our derived class we access that method through a reference to the interface, not implicitly.

This is what it looks like now:

class Builder {
   public DoStuff(string blah){
      //impl
   }
}

class GridBuilder : Builder{
   public void Build() {
      var elem = Element.GetAttribute("Blah");
      DoStuff(blah);
   }
}

Let’s tweak it as described in the previous paragraph:

interface IBuilder {
    DoStuff(string blah);
}

[code lang="csharp"]
class Builder : IBuilder {
   [Obsolete]
   public DoStuff(string blah){
      //impl
   }
}

class GridBuilder {
   
   IBuilder _Builder;
   
   public GridBuilder() {
     _Builder = this;
   }
   
   public GridBuilder(IClientBuilder b) {
            m_ClientBuilder = b;
    }
   
   public void Build() {
      var elem = Element.GetAttribute("Blah");
      _Builder = DoStuff(blah);
   }
}

So what I have done is put that DoStuff into an interface and marked the implementation as Obolete. This is more out of convinience to get the compiler to show me where else this method is being used. Turns out this was the only case where it was used in GridBuilder. I could have just as well used text search, but hey, if there is a fancy compiler feature, why not use it? Notice that I also added a dependency constructor so I can compose GridBuilder in a unit test.

Let's make a unit test for this use of DoStuff. As I am doing that I realised that my base class is in a different assembly and required some code duplication from another test project to make the test not crash. The fact that I had to do that is a pretty bad, but my copying the common setup file and including it in my test project is even worse. We can come back to that later, lets concentrate on what we are doing now. Might as well use the Obsolete attribute to remind me to refactor the unit test later on.

Finally, I can test Build

So, after a long time setting up GridBuilder's dependencies I am finally here - the test runs. Lets review what I've achieved so far and have a peek at the metrics. So here is the summary of what was required just to make the test run:

• Two instances of referring to the base class have been abstractes into two interfaces.
• Found a bug where if a required element is present but contains no nodes the builder crashes.
• The test creates a total of three mock objects with a total of five Stubs and one Expect.
• The test needs to pass in an Xml element with two elements and one atribute.
• Found a small refactoring job that is not really related to the unit testing aspect of this excercise.

Code metrics:

So I didn't get anywhere as far as most metrics are concerned, in fact I almost went backwards, if anything. Let's keep going. So now I have a unit test that runs the Build method lets keep trying to test more and more parts of it.

Before I go on, I would like to emphasize the fact that I had to create lots of mocks and pass in lots of dependencies just to make one method not crash. Here is the unit test. Definitely too much for ONE method:

        [SetUp]
        public void Setup() {
            m_Mocks = new Mockery();
            m_Settings = new InlineBuilderSettings {
                Compiler = m_Mocks.NewMock<IWebCompiler>(),
                ComponentName = "Test"
            };
            //Used by setup method
            Stub.On(m_Settings.Compiler).GetProperty("ServerCompiler").Will(Return.Value(null));
            Stub.On(m_Settings.Compiler).GetProperty("ServerType").Will(Return.Value(typeof(Data.ServerAplication)));
        }
        
        [Test]
        public void BuildShouldCallRequireComponentWhenViewAttribute() {

            var iClientBuilder = m_Mocks.NewMock<IClientBuilder>();
            var iBuilder = m_Mocks.NewMock<IWebBuilder>();

            Builder builder = new Builder(iClientBuilder, iBuilder);
            m_Settings.Element = 
                new XElement("Grid", new XAttribute("View", "test"), 
                    new XElement("Source", new XAttribute("View", "DataTest")),
                    new XElement("Fields"));

            Expect.Once.On(iClientBuilder).Method("RequireComponent").With("test", m_Settings.Element).Will();
            Stub.On(iClientBuilder).Method("GetComponentInfo").Will(Return.Value(new ComponentInfo()));
            Stub.On(iBuilder).Method("AddConfig").Will();
            Stub.On(m_Settings.Compiler).Method("AddInclude").Will();
            
            builder.Setup(m_Settings);
            builder.Build();
        }

Realistically, in order to complete the build process we need all those dependencies. That's pretty fundamental. However, it should be possible to reduce the amount of dependencies ONE method has.

Next refactor

My next target was a reasonably self contained code block that I did "Extract Method" method on. Two more unit tests. Slight improvement in maintainability and complexity.

Next one is a big sucker. This block produces about 5 output objects that are dumped to JSON later on. I actually moved to another two classes. One to perform the build and another to store the output.

Good improvement on all counts. Lets keep splitting the Build method and writing tests for it. As I am doing this I decided to make the GridBuilder a namespace within a project. There are a number of classes in it by now, might as well contain them in a folder.

Day later.

I have somewhat abandoned refactoring GridBuilder as I found a whole bunch of other tightly coupled classes. The unit tests have proven to be a great tool exposing those dependencies. They also become usefull when the refactoring becomes non-trivial - i.e. goes beyond just moving a block of code out of a method.

This is what the class looked like once I finished with it:

Now that I ran out of time that I gave myself for this task I think I have a few notes for future.

• Parsing an XML collection is ugly and tends to get messy when things need to be addded to the inner loop. I think for this scenario I would need some sort of visitor pattern implemented so that you could add things to the inner loop without having to alter the loop itself.
• Having implicit dependencies (like a dependency on a property of an actual dependency) totally breaks the unit tests. A situation where you create one mock and then have its method return another mock is a bit ridiculous.
• A unit test for a monstrous method will too be monstrous. There is almost 1-to-1 relationship between how fat the method is and how fat its unit test is. I think that if one aims to make unit test simpler, the code under test will in turn become simpler.

I would like to start off by comparing programming languages to spoken languages. Most will agree that the comparison is fair. Programming languages bear most hallmarks of real life languages. There is syntax, grammar, dictionary, there are historical reasons for why the language the way it is, etc. Generally speaking one is most fluent in their native tongue and could deal with a couple of others. Similarly in programming you have your native language – C family, VB, Pascal, Ruby, Python, Perl, hieroglyphics(PHP) etc.

My native language is Russian and that’s what I grew up with. From a reasonalby early age I learnt English and was reasonably fluent in it as a second language. I would like to equate this SECOND language to your FIRST programming language. The similarity, for the sake of this post, is that you think in your native language and translate it into code. The process, as those who speak other tongues would know, is similar. You form what you want to say in your head, translate all the words into the other language, rearrange the sentence if the target language requies so and then produce the output.

As with a second spoken language, writing programs eventually becomes second nature. Enter third (spoken) langague, e.g. French, that I learned in school. I found that my brain was stuck in this binary Russian/English mode and I could not add French to the mix, so my French was coming out very English like.

This is the problem I am facing with F#. It is SO compltely different that my C/C++/C#/Whatever-happy brain does not accept it. If comparing to spoken languages, it’s even further away from C than French is from English. It’s more like Japanese, where both the alphabet and the mindset are different.

So, coming back to the point of this dribble. I like words. I like the explicitness of procedural languages. I think it tends to follow how one thinks. if statements, while statements, assignment, parameter passing – they are all very logical.

My biggest hurdle understanding F# is the fact that the same syntax can be used for instantiation and matching. For example defining a function that takes a tuple with two members:

let func (a, b) = printfn "a: %d, b: %d" a b;;

The syntax is the same as when you define a tuple:

let tuple = (4, 5);;

Wheres a, say C++ would do something like this:

Tuple<int, int> = new Tuple<int, int>(4,5);

void func(Tuple<int, int> tuple) {
}

F# seems to just use all these symbol operators for everything and I just can’t let go of my attachment to words. List.Add is logical, [4;5;]@[6;7] is less so, especially considering that the operands cound be either values or lists.

Speaking of words, here is some lingo that you will undoubttedly come across as you learn a functional programming language. The list is not complete and some words are not simple definitions, but quite complex concepts – like combinators – those will make your head hurt extra good :))

• High Order Function – Function that can take functions as parameters and/or return a function
• Curried function – High Order Function that binds one or more of the parameters to a predetermined value and returns a function that takes less parameters.
• Purity – Functions not having side effects – i.e. the function produces an output without chnaging the input or modifying state somewhere else. This normally invoves using immutable data structures and combinators.
• Cons operator (::) – Adding an element to the beginning of the list.
• Strictness – Evaluating parameters to the function before the function is evaluated.
• combinator – High order function that has no free variables. Short version is that this function only operates on its parameters, not any other functions or values defined elsewhere.
• Memoization – Remembering the result of a slow running function for future use (Caching).
• Imperative programming – “normal” programming – i.e. Procedural, Object Orientated, etc.

So, what does this mean for Australian bittorrenters?

Well, for once it means a giant step back for the studios. As RIAA has discovered, filing individual lawsuits agaist filesharers is pretty bad PR. Such bad PR, that they, in fact, tried to spin that they no loger sue the individuals, which of course is bogus. All in all, the content rights holders are discovering that suing individuals got them nowhere.

So, in order to eradicate the “problem of file sharing” the studios see a number of options available to them (apart from the obvious – i.e. providing product people want to pay money for), in order of increasing perceived effectiveness:

1. Suing individuals.
2. Send out notices to the ISP alerting them that infringement has occured an hope to scare some people off file sharing.
3. Making ISPs responsible for copyright infringement.

So, going after individuals is ineffective and expensive. The holly grail of Big Content is number 3 though. They would love to make ISPs culpable for illegal file sharing. That’s what all the three strikes laws attempts are about. If the studios can make ISPs liable for user infringement, they hope that ISPs will police their networks, maybe even to the point of disabling BitTorrent. So far getting ISPs to kick users off the network required legislative support worldwide (i.e. France and Korea) as it is clearly in violation of safe harbour provisions.

AFACT decided to approach this from a different angle and set a precedent that it’s reasonable to kick off alleged infringers for repeated offences. They went after the easiest target – the big ISP that publicly stated that they do not send infringement notices to users. iiNet council even argued that AFACT manufactured authorisation by sending out notices to the ISP that they knew were not going to be acted upon in preparation for this very court case.

Going back to why this is a step back for AFACT. Now that iiNet is in the clear it is obvious that ISPs are under no obligation to pass infringement notices on. They might have been a scare tactic that somewhat worked (maybe on 10% of the people who received them). Now the studios don’t even have that. It was an all in game for the studios and they lost.

Of course AFACT will appeal, but they have lost a lot of momentum. Months, if not years worth of momentum. My prediction is that they will make a token effort in appealing and instead concentrate on lobbying for three strikes law.

So the next big thing in copyright in Australia is ACTA. DFAT has publicly come out and said that Australia is not going to implement three strikes laws. I, however, do not trust them. Politicians and lobbyists involved in ACTA around the world have notoroiously been blowing smoke about it. I would take anything that anyone involved in a secret treaty negotiation with a grain of salt.

void c_rtti::foobar(a_rtti & a2) {
   c_rtti* c_ = dynamic_cast<c_rtti*>(&a2);
   if (c_) {
      ::foobar(*this,*c_);
      return;
   }
   b_rtti* b_ = dynamic_cast<b_rtti*>(&a2);
   if (b_) {
      ::foobar(*b_, *this);
   }
}

I have used the most non-trivial case where the above function is called with a2 parameter pointing to an instance of b_rtti, thus triggerring two dynamic casts. I used the same technique on the vtable implementation for consistency, although it doesn’t matter as the sequence of execution is the same for any combination of objects. The test ran for 4 million iterations.

Here is the test code:

        a& a_ = c();
        b bInstance;
        a& b_ = bInstance;
        a_.foobar(b_);

Just to show what actually happens in both implementations, here are the sequence diagrams.

vtable:

dynamic_cast:

The results

In debug mode, RTTI implementation is about 20% faster:

No RTTI - 1685 milleseconds.
With RTTI - 1295 milleseconds.(23.15% faster)

So this is pretty insignificant in a real life application and I doubt it would come in the profiler. By my calculation there is about 100 clock cycles (on a 1Ghz CPU) difference between the two per call.

In Release mode things get interesting:

No RTTI - 62 milleseconds.
With RTTI - 780 milleseconds.(-1158.06% faster)

The pure vtable version is ten times faster!!! Of course this again means very little in the real world. It’s worth noting that the RTTI verson is twice faster in Release mode. What is also interesting is that in Debug mode vtable is slower by 100 clock cycles, in release it’s faster by 200.

To summarise. The real life value of this performance analysis is zero. If you are Google and you had 100 PhDs design the program and another 100 wrote the library routines for it, doing this optimization will improve the performance by about 0.000001%. In any other case, this is textbook case of premature optimisation.

<rootNode p1:xsi="http://www.w3.org/2001/XMLSchema-instance" p1="http://www.foo.bar" xmlns="http://www.foo.bar">
</rootNode>

Turns out the answer is pretty simple. I was correct in my assumption that in order to create a namespace alias one must simply add an attribute to the node. However the xmlns namespace is special and one cannot use the string xmlns or use the default namespace. Instead one must use XNamespace.Xmlns – like so: new XAttribute(XNamespace.Xmlns + "xsi", "http://www.w3.org/2001/XMLSchema-instance"). Here is complete code:

XNamespace xsi = XNamespace.Get("http://www.w3.org/2001/XMLSchema-instance");
            XNamespace defaultNamespace = XNamespace.Get("http://www.foo.bar");
            XElement root = new XElement(defaultNamespace + "rootNode",
                new XAttribute(XNamespace.Xmlns + "xsi", xsi.NamespaceName),
                new XAttribute(xsi + "noNamespaceSchemaLocation", @"..\path\to\schema.xsd"));

<rootNode xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="..\path\to\schema.xsd" xmlns="http://www.foo.bar" >
</rootNode>

This Week in Tech has a dedicated half hour every show for the past two months about the iSlate and that’s getting a bit nauseating. I commend Valleywag for making light of the situation.

Now that I offloaded my disgust at the hype around the device I can offer my 2c. The two things that make this a non-niche device are:

• Haptic display that will give you feedback when you touch it. This, IMHO, will make more-than-two-finger typing somewhat feasible.
• A hybrid LCD/E-Ink display as suggested by Techdirt. Combining high-contrast and low battery consumption of E-Ink with versatility of LCD can make such hybrid an absulute killer.

As far as I am concerned if the device is less groundbreaking than the above, it’ll flop. I think that in order for Apple to pull this off, the device has to be perceived as the technology of the future, even though the original product is ordinary.

I also think that the hardware itself has to be innovative. There has been a bit of a murmour that the success will depend on the content deals Apple makes for this device. I think that’s less relevant. The content availability hasn’t made the Apple TV successful and I think that because there wasn’t much innovation in the device. It’s almost as though the device needs to be able to play stuff that wasn’t bought through the store (read pirated) easily in order for it to be successful.

Duncan Riley explains in detail how the whole study is flawed in great detail here. The government report has all the hallmarks of the justifications for going to war in Iraq. Especially the part where they say that the trial was a 100% success except for handling high traffic (especially video streaming) sites.

WTF???!!! I mean apart from those evil evil pirates who use bittorrent a lot of the traffic will be to youtube. And this brings me to the title of the post – the three douchbags.

Due to how Testra set up their filter, and I am using Telstra as an example here, if there is just one page on a site that is blocked, the whole site goes through a proxy. So it takes one douchebag to upload something potentially objectionable up on youtube, second douchebag to object to it and a third douchebag to place that page on a blocked list and to grind youtube to a halt for everyone.

Knowing the very vocal conservatives in this country the video in question will probably be some documentary about abortion with a half a second still shot of a bloody foetus which is perfectly fine by youtube standards and even by most broadcasting standards. Once the site is on a black list I seriously doubt an ISP can proxy all their youtube traffic through a single proxy. Not without spending quite a bit on their proxy farm anyway.

Imagine the outrage. All the school kids coming home will have to wait 10 minutes for the video of a dog driving a race kart. Guess what’s going to happen. They will go into very very slimy corners of the internets to find out how to circumvent the filter. God knows what else they are going to find there. Heck even the older people who can vote will not take too kindly to having their internet slowed down.

It’s not going to fly. I can just see wikileaks ending up on a blocked list, along with a thousand of “what’s blocked” sites set up by pundits that will pop up in the near future. It will be continual bad press for the government. I am going to vote for the Pirate Party.