Random coding knowledge

Implementing conditional resolution of dependencies with Castle.Windsor

2020-05-27T01:00:00+01:00

Let’s say you are given the task of creating a console program to calculate the given element of the Fibonacci sequence.

Great, that’s easy enough. You can just use your favorite tools: VS Code and dotnet core.

You just open up your terminal, cd into the directory of your projects and type:


mkdir DependencyInjectionPlayground
cd DependencyInjectionPlayground
dotnet new console
code .

After a little thinking you write the code:


using System;

namespace DependencyInjectionPlayground
{
    class Program
    {
        static void Main(string[] args)
        {
            var n = Convert.ToInt32(args[0]);
            var fibonacciCalculator = new FibonacciCalculator();
            var output = fibonacciCalculator.Calculate(n);
            Console.WriteLine($"The {n}-th element of the fibonacci sequence is {output}");
        }
    }
 
    public class FibonacciCalculator
    {
        //Calculates the n-th element of the fibonacci sequence
        public long Calculate(int n)
        {
            if (n <= 2) return 1;
            return Calculate(n-1) + Calculate(n-2);
        }
    }
}

Then click save and go back to the console.


dotnet build
dotnet run 5

And you get the output:


"The 5-th element of the fibonacci sequence is 5"

Job well done.

That is until you realize that for large numbers it gets exponentially slower because of the nature of this recursive algorithm.

The damn thing has a time complexity of O(2^n)

As Rocky would say:

So, after you get your inspirational speech you go online and after some googling and Wikipedia reading you come across the article on Memoization.

You update your algorithm to take advantage of your newfound knowledge:


public class MemoizedFibonacciCalculator
{
    private long[] memoized;
    private int current;

    public MemoizedFibonacciCalculator()
    {
        memoized = new long[32];
        memoized[0] = 0;
        memoized[1] = 1;
        memoized[2] = 1;
        current = 2;
    }

    //Calculates the n-th element of the fibonacci sequence
    public long Calculate(int n)
    {
        //if we have calculated the n-th element already, return it
        if (n <= current) return memoized[n];

        //if we haven't then resize the array to hold the new values.
        Array.Resize(ref memoized, n + 1);

        //Calculate all the elements between the currently calculated element
        //and the n-th element and then save them.
        for (int i = current + 1; i <= n; i++)
        {
            memoized[i] = memoized[i - 2] + memoized[i - 1];
        }

        current = n;
        return memoized[current];
    }
}

It seems that using our original recursive algorithm sacrifices cpu speed versus the updated algorithm using memoization which sacrifices ram.

We don’t want to limit our users to one or the other as we don’t know where they are going to run this code.

It seems we’ll have to provide them the option to choose the algorithm on runtime.

This is where dependency injection comes into play. Switch to your trusty console and type:


dotnet add package Castle.Windsor
dotnet restore
dotnet build

After some reading of the Castle Windsor documentation you come across this interface: IHandlerSelector

A “go to definition” returns this:


    Summary:

    Implementors of this interface allow to extend the way the container perform component resolution based on some application specific business logic.

Perfect.

Let’s write a generic handler selector class that would allow us to apply basic selection criteria to the requested implementations:


public class GenericHandlerSelector : IHandlerSelector
{
    private readonly Func<Type, bool> filter;
    private readonly Func<IHandler, bool> predicate;

    public GenericHandlerSelector(Func<Type, bool> filter, Func<IHandler, bool> predicate)
    {
        this.filter = filter;
        this.predicate = predicate;
    }

    public bool HasOpinionAbout(string key, Type service)
    {
        return filter(service);
    }

    public IHandler SelectHandler(string key, Type service, IHandler[] handlers)
    {
        return handlers.First(predicate);
    }
}

This basically allows the bootstrap container code to apply logic to what implementation of an interface the container is going to use.

The code finally looks like this:


using System;
using System.Linq;
using Castle.Windsor;
using Castle.MicroKernel;
using Castle.MicroKernel.Registration;

namespace DependencyInjectionPlayground
{
    class Program
    {
        static void Main(string[] args)
        {
            bool useMemoization = Convert.ToBoolean(args[1]);
            var container = BootstrapContainer(useMemoization);

            var n = Convert.ToInt32(args[0]);
            var fibonacciCalculator = container.Resolve<IFibonacciCalculator>();

            var output = fibonacciCalculator.Calculate(n);
            Console.WriteLine($"The {n}-th element of the fibonacci sequence is {output}");

        }

        static IWindsorContainer BootstrapContainer(bool useMemoization)
        {
            IWindsorContainer container = new WindsorContainer();

            container.Register(Component.For<IFibonacciCalculator>().ImplementedBy<FibonacciCalculator>());
            container.Register(Component.For<IFibonacciCalculator>().ImplementedBy<MemoizedFibonacciCalculator>());

            // filter -> this handler only affects implementations of IFibonacciCalculator
            // handler -> depending on input, choose the implementation we want
            var memoizationHandler = new GenericHandlerSelector(
                (filter) => filter == typeof(IFibonacciCalculator),
                (handler) => useMemoization
                    ? handler.ComponentModel.Implementation == typeof(MemoizedFibonacciCalculator)
                    : handler.ComponentModel.Implementation == typeof(FibonacciCalculator)
                );

            container.Kernel.AddHandlerSelector(memoizationHandler);

            return container;
        }

    }

    public class GenericHandlerSelector : IHandlerSelector
    {
        private readonly Func<Type, bool> filter;
        private readonly Func<IHandler, bool> predicate;

        public GenericHandlerSelector(Func<Type, bool> filter, Func<IHandler, bool> predicate)
        {
            this.filter = filter;
            this.predicate = predicate;
        }

        public bool HasOpinionAbout(string key, Type service)
        {
            return filter(service);
        }

        public IHandler SelectHandler(string key, Type service, IHandler[] handlers)
        {
            return handlers.First(predicate);
        }
    }

    public interface IFibonacciCalculator
    {
        //Calculates the n-th element of the fibonacci sequence
        long Calculate(int n);
    }

    public class FibonacciCalculator : IFibonacciCalculator
    {
        //Calculates the n-th element of the fibonacci sequence
        public long Calculate(int n)
        {
            if (n <= 2) return 1;
            return Calculate(n - 1) + Calculate(n - 2);
        }

    }

    public class MemoizedFibonacciCalculator : IFibonacciCalculator
    {
        private long[] memoized;
        private int current;

        public MemoizedFibonacciCalculator()
        {
            memoized = new long[32];
            memoized[0] = 0;
            memoized[1] = 1;
            memoized[2] = 1;
            current = 2;
        }

        //Calculates the n-th element of the fibonacci sequence
        public long Calculate(int n)
        {
            //if we have calculated the n-th element already, return it
            if (n <= current) return memoized[n];

            Array.Resize(ref memoized, n + 1);

            for (int i = current + 1; i <= n; i++)
            {
                memoized[i] = memoized[i - 2] + memoized[i - 1];
            }
            current = n;
            return memoized[current];
        }
    }
}

If we switch back to our trusty console and do a:


dotnet build
dotnet run 40 false
dotnet run 40 true

The false/true is user input for the use or not of Memoization.

Unless you are running this on a supercomputer, you’ll notice the difference in speed between the two algorithms.

If you want to do a little bit of digging I’d suggest measuring the exact difference in the time it took to run both of these using System.Diagnostics

Happy coding!

Setting up eleventy to work with github pages

2020-05-31T01:00:00+01:00

Ever since github started offering their GitHub Pages to use as a personal website for its users, I've been interested in using them. I've even tried setting mine up a couple of times but I always found that configuring jekyll and finding a proper theme that would play well with whatever versions of rubygems I already had was a pain.

Furthermore, there was no reason in my mind to have yet another development environment (Ruby's) installed on my local machine and kept up to date so that I could write a blog post once in a blue moon.

So, in the end, I never bothered with actually using my github page for quite some time.

I do tend prioritize things lower if there is significant friction when doing something with them and blogging with the github pages had quite a bit of friction involved.

It had been going like that for a while until a few days ago when I came across a youtube video about setting up a static site with eleventy. The tool seemed to get out of your way as much as possible and allowed you to simply write your markdown files to be processed into pages.

Within a few minutes I was convinced. I started yet again the process of setting up my github page and working with eleventy to create a decent static page as output.

Everything was working just fine and dandy until the time came to actually have github host the pages that eleventy outputs. There were alot of websites documenting how to do this process but I found them to be either too complicated (setup github actions, CI servers, etc) or the result would not be clean enough (have the eleventy static site output commited to the same repository as the code).

In the end, there was this blogpost by Tom Hiskey that mentioned in the TLDR:

If you're trying to deploy an Eleventy site to GitHub Pages, one option is to build it locally and fiddle about with settings.

But, as I already mentioned, I don't want to mix my static site (the output) with the code that is responsible for that (the input)

So I did the following:

Create a base directory, let's call it "blog"
Inside that directory we'll clone the github page, thanospapathanasiou.github.io
And we will also initialize another git folder called personal-blog

Our folder structure will end up being like this:

./blog/
./blog/thanospapathanasiou.github.io (git repository 1)
./blog/personal-blog/ (git repository 2)

With this folder structure, you can start writing your blogposts in the personal-blog folder and have eleventy running and serving them locally for any tweeks you might need to do before you commit them.

Be careful though. If you want to keep things clean and separated like I do then you don't want to commit the static html output in the personal-blog folder, you want to commit them to your github page.

The problem is that copying and pasting the changes from codingblog/_site/* to thanospapathanasiou.github.io/* can be such a pain.

Thankfully the good ol' Makefile comes to the resque! This is the one I wrote for my purposes.

You basically need three things:

Clean the codingblog/_site/* so you start from an empty base.

rm -rf _site/*

Build your eleventy static site into codingblog/_site/*

npx @11ty/eleventy eleventy --input=site --output=_site

finally, we need to copy that static file into our github pages folder.

First we need to clean up the github pages folder

find ../thanospapathanasiou.github.io/ -mindepth 1 ! '(' -path '../thanospapathanasiou.github.io/.git/*' -or -name '.git' -or -name 'CNAME' ')' -delete

Copy the output to the github page folder

cp -a ./_site/. ../thanospapathanasiou.github.io/

Step 3.1 is a bit complicated so let's break it down a bit.

Basically what we need to do is find all the items in the github page directory that are NOT in its .git folder, are not the actual .git folder itself, or the CNAME file (that's the file that has the custom domain name your blog will point to)

Now my proccess from creating a new blogpost is quite straightforward and with a lot less friction!

Create a folder with the blogpost's permalink in the /personal-blog/site/blog folder. Let's say that the name of that folder is setting-up-eleventy-to-work-with-github-pages
Create a index.md file and start writing
Open a terminal in the /personal-blog/ folder and run make run
Have your browser navigate to http://localhost:8080 and watch it for anything not displaying correctly
Once you are done with editing, run make publish and the changes will appear in the github directory
Commit and push the changes from both repositories
Profit?

I've found that the above proccess works really well for me, if you want to have a look at the repository for yourself then the link is here

Happy blogging!

Using FSLexYacc, the F# lexer and parser

2020-06-08T01:00:00+01:00

Lately I've been playing around with F# and specifically with using it for lexing and parsing. I've had to dig around a bit to get all the information needed to understand how to get a simple project up and running so I thought compiling that information would be a good idea.

This is going to be a tutorial that will help you setup a simple F# console application that will read the user's input and will try to evaluate it based on the basic math syntax that we will declare.

It should be able to evaluate input like:

1 + 1
(1 + -2) - (6 / 3)

Pretty advanced stuff, I know :D

If you don't feel like typing everything and just want to download the code and start tinkering then try the following:

npm install -g github-files-fetcher
github-files-fetcher -url="https://github.com/ThanosPapathanasiou/personal-blog/tree/master/code-examples/lexing-and-parsing"
code lexing-and-parsing

Otherwise, here's a step by step instruction to help you get up and running.

Setting up a project to work with FsLexYacc

Let's start with a brand new F# console app:

mkdir lexing-and-parsing
cd lexing-and-parsing
dotnet new console -lang=F#
dotnet run

That should give us the default console output:

Hello world from F#

In order to use the F# lexer and parser we'll need to add the FsLexYacc nuget package as a reference. So our next step is to run:

dotnet add package FsLexYacc

The way lexing and parsing works in F# is by generating F# code from two files, a .fsl one that contains the rules for the lexer and a .fsy one that contains the rules for the parser.

Lets create them:

echo '' > Lexer.fsl
echo '' > Parser.fsy

Next we'll need to edit the .fsproj file and add these two lines in the <PropertyGroup>

    <FsLexToolExe>fslex.dll</FsLexToolExe>
    <FsYaccToolExe>fsyacc.dll</FsYaccToolExe>

and these ones in the <ItemGroup>

    <FsYacc Include="Parser.fsy">
      <OtherFlags>--module Parser</OtherFlags>
    </FsYacc>

    <FsLex Include="Lexer.fsl">
      <OtherFlags>--module Lexer --unicode</OtherFlags>
    </FsLex>

    <Compile Include="Parser.fsi" />
    <Compile Include="Parser.fs" />
    <Compile Include="Lexer.fs" />

What these changes do is basically tell the F# compiler that it has the fslex and fsyacc tools at it's disposal and it will have to run the transformation of the Lexer.fsl and Parser.fsy files before the compilation starts. We can even specify the module name that the generated code is part of. I chose to keep it simple with Lexer and Parser.

You will notice also that we are including three files (Parser.fsi, Parser.fs and Lexer.fs) that don't exist as references in our project. These files will be generated from our .fsl and .fsy files by the lexer and parser tools as the output of the transformation I mention above.

At this point our project is setup to use the lexer and parser however since we don't have anything in the Lexer.fsl and Parser.fsy files the compilation will fail.

So lets add something!

Basic lexing

Lexing is the process of taking raw text and converting it into a sequense of tokens. A token is a string with an assigned meaning.

In our case we'll try to create a lexer and parser that will do something basic, evaluate simple mathematic operations. i.e. 1 + 1 should return 2, -1 + 2 = 1, (1 + 2) - (4 + 1) = -2 etc

So, our lexer should identify these tokens:

Number
Operator
Left Parenthesis
Right Parenthesis
End of input

This is the finished Lexer.fsl that tokenizes according to the above rules.

{
open FSharp.Text.Lexing
open Parser

let lexeme lexbuf = LexBuffer<_>.LexemeString lexbuf
}

let digit = ['0'-'9']
let operator = ['+' '-' '*' '/']
let whitespace = [' ' '\t']

rule tokenize = parse
| whitespace        { tokenize lexbuf }
| ['-']?digit+      { Number ( System.Int32.Parse( lexeme lexbuf ) ) }
| operator          { OP ( lexeme lexbuf ) }
| '('               { LPAREN }
| ')'               { RPAREN }
| eof               { EOF }
| _                 { lexeme lexbuf |> sprintf "Parsing error: %s" |> failwith }

Let's go through it and I'll explain it bit by bit.

First bit:

{
open FSharp.Text.Lexing
open Parser

let lexeme lexbuf = LexBuffer<_>.LexemeString lexbuf
}

I mentioned earlier that Lexer.fsl isn't written in F# but a custom language. That is true for the rest of this file but not for the bits between the { and }

Here we using F# to open the FSharp.Text.Lexing namespace that we need to access the input buffer LexBuffer that allows us have a look into what part is being tokenized.

We are also opening our own Parser module (the one that will be autogenerated by Parser.fsy). We need that because the definition of the tokens that we want to output is there.

Finally, we are declaring a small helping function that returns the matching characters of a token as a string. i.e. the characters 1, 2, 3 would be returned as "123"

Second bit:

let digit = ['0'-'9']
let operator = ['+' '-' '*' '/']
let whitespace = [' ' '\t']

rule tokenize = parse
| whitespace        { tokenize lexbuf }
| ['-']?digit+      { lexeme lexbuf |> System.Int32.Parse |> Number  }
| operator          { lexeme lexbuf |> OP }
| '('               { LPAREN }
| ')'               { RPAREN }
| eof               { EOF }
| _                 { lexeme lexbuf |> sprintf "Parsing error: %s" |> failwith }

In this part the actual tokenization process happens.

First, for readability, we define what a digit, operator and whitespace are. Then we have the actual tokenization function rule tokenize = parse followed by all the cases we support (with the final one _ handling all the undesired states by just returning an error). These cases are matching against a kind of regular expression.

This is what it does

In case of whitespace, ignore it. (get the next token)
In case of multiple digits even with a - in front then get that string ( lexeme lexbuf ) then parse it into a System.Int32 and then return that int32 as a Number token. (this Number token will be defined in our Parser.fsy file)
In case of a string matching any of our operators then get that string and return the OP symbol
In case of a left parenthesis then return the LPAREN symbol
In case of a right parenthesis then return the RPAREN symbol
When we reach the end of the input given then return the EOF symbol
In case we get a character that doesn't match any of the above rules then we raise an exception.

Remember: Everything between { and } is valid F# code, that's why we are able to use |> to cast to the Number and OP symbols.

As an example, if we gave (1 + 2) + -3 the symbols should be LPAREN NUMBER(1) OP("+") NUMBER(2) RPAREN OP("+") NUMBER(-3) EOF

That looks good, let's see how to do the parsing now!

Basic Parsing

Parsing is the process of reading a stream of tokens and attempting to match them to a set of rules with the end result being an abstract syntax tree.

In layman's terms, lexing is the process of defining the alphabet (the actual characters allowed) of your language while parsing is the process of defining the syntax (i.e. subject - verb - object)

The syntax that we want to be able to understand is based upon basic math rules.

perform an operation between two numbers: NUMBER OP NUMBER
perform an operation between a number and another operation that uses parentheses: NUMBER OP (NUMBER OP NUMBER)

Here's the end result:

%{
let getOp op = 
    match op with 
    | "+" -> ( + )
    | "-" -> ( - )
    | "/" -> ( / )
    | "*" -> ( * )
    | _ -> failwith "unknown operator"
%}

%token <int> Number
%token <string> OP
%token EOF LPAREN RPAREN
%start parse
%type <int> parse
%%

parse: expr EOF        	     { $1 }

expr: Number                 { $1 }
    | expr OP expr           { $1 |> (getOp $2) <| $3 }
    | LPAREN expr RPAREN     { $2 }

Like with the lexing above, let's go through it bit by bit.

The first part consists of the following F# code.

%{
let getOp op = 
    match op with 
    | "+" -> ( + )
    | "-" -> ( - )
    | "/" -> ( / )
    | "*" -> ( * )
    | _ -> failwith "unknown operator"
%}

Here, we are declaring an F# function that matches the operator symbols to actual F# mathematical functions and returns them. So it takes a string argument as input and returns a function of type: Int->Int->Int (i.e. it takes two Int arguments and returns a result of type Int)

Next, we have the token definitions. Notice that the Tokens Number and OP have .net types.

%token <int> Number
%token <string> OP
%token EOF LPAREN RPAREN

Right after that we specify to the parser what rule it should use as a start and what .net type the parsing operation will return:

%start parse
%type <int> parse
%%

Finally, we have the actual rules. These rules declare what syntax is valid in our language.

Let's go through them one at a time.

parse: expr EOF        	     { $1 }

We are parsing a single expression and we expect the EOF symbol right after. The part between the { and } is a sort of substitution. The parse rule expects an expression and an EOF symbol and we only care about the first argument, hence $1 (i.e. try to parse the expr)

expr: Number                 { $1 }
    | expr OP expr           { $1 |> (getOp $2) <| $3 }
    | LPAREN expr RPAREN     { $2 }

This is a bit more complicated. You can see that an expr can be different things. The rule is also recursive.

It basically states that an expression can be

a number
an expression followed by an operator symbol and another expression
a left parenthesis symbol followed by an expression followed by a right parenthesis symbol.

You can also notice that in the second case, we are calling the getOp function we declared earlier instead of just propagating the operator symbol. So in the generated code the + operator will not be a simple string type variable but an Int->Int->Int function.

Let's try and use the input from the lexing example.

The initial input was

(1 + 2) + -3

and the symbols we got were:

LPAREN NUMBER(1) OP("+") NUMBER(2) RPAREN OP("+") NUMBER(-3) EOF

The symbols are matched against the parse rule and they give us this abstract syntax tree.

                   expr op expr
                  /     |      \
                 /    OP("+")   NUMBER(-3)
                /            
       LPAREN expr RPAREN    
               |                
          expr op expr         
         /     |      \         
NUMBER(1)    OP("+")   NUMBER(2)

That would basically be translated and executed like this:

NUMBER(1) OP("+") NUMBER(2) translates to 1 |> (+) <| 2 and results in 3
the evaluation of that expression becomes the first argument for the next expression
NUMBER(3) OP("+") NUMBER(-3) translates to 3 |> (+) <| -3 and results in 0
the evaluation of that expression becomes the value that parse returns.

Tying it all together

We have the lexer and parser all ready. If's finally the time to use them!

Open Program.fs and replace the code with this:

open System
open FSharp.Text.Lexing
open Lexer
open Parser

let evaluate (input:string) =
  let lexbuf = LexBuffer<char>.FromString input
  let output = Parser.parse Lexer.tokenize lexbuf
  string output

[<EntryPoint>]
let main argv =

    printfn "Press Ctrl+c to Exit"

    while true do
        printf "Evaluate > "
        let input = Console.ReadLine()
        try
            let result = evaluate input
            printfn "%s" result
        with ex -> printfn "%s" (ex.ToString())

    0 // return an integer exit code

This is a very simple main function that will continue to loop until the user closes the program. It just takes the user's input and calls the evaluate function declared in the beginning of the program.

The evaluate function does a couple interesting things.

First, it creates a lex buffer from the input string given by the user: let lexbuf = LexBuffer<char>.FromString input

Next, it uses that buffer and the Lexer.tokenize function we declared in the lexer as input to the Parser.Parse function we declared in our parser : let output = Parser.parse Lexer.tokenize lexbuf

Finally, it converts the output from int to string

That's it. Now we can open our terminal and type dotnet run and we should be greeted with:

Press Ctrl+c to Exit
Evaluate >

Try entering: (1 + 2) + -3 and see if it will evaluate to 0. Try any number of complicated expressions and see if the result matches what you expect. Have a look at what happens if you use illegal characters.

Try replacing the expr with this equivalent:

expr: Number                 { $1 }
    | OP expr expr           { (getOp $1) $2 $3 }
    | LPAREN expr RPAREN     { $2 }

After we recompile, suddenly our parser will be expecting that we use polish notation!

If you want to understand this a bit better I would encourage you to start tinkering with the parser. Try coming up with your own rules!

As always,

Happy coding!

Some interesting sites to have a look

If you want to have a look at the final project, instead of typing it you can get it here

If you want to get into parsing and lexing and expand your understanding a bit more you can have a look at these sites:

F# programming wikibooks
OCaml's lexyacc examples (F#'s lexyacc is basically identical to the OCaml one)

If you want to understand a bit more about the abstract syntax trees then you can read wikipedia's entry on Backus-Naur form