Monday, December 28, 2009

ArraySegment<T> Class

Somehow I missed such a useful class in .Net framework this now. This class is useful when we are working on one dimensional arrays and need to segment arrays.

One quick use case is network packets. Where we will allocate buffer upfront and fill segments to form a packet.

Good part of this class is multiple arraysegment objects can refer to same instance of array. Mean what we get is reference to original object rather than a copy. Any updates to segment will automatically update original array.

Isn’t useful? I feel so.

Saturday, December 19, 2009

Hosting IronRuby in MSBuild

This post builds on earlier post in this series and provides a mechanism to host IronRuby in MSBuild.

Basics of MSBuild

A very brief introduction of MSBuild is present here. MSBuild is a modern build file format built on XML technologies.
Important components of MSBuild are

  1. Project
  2. Target
  3. Task
  4. ItemGroup
  5. PropertyGroup
  6. Imports

Project stands as root element with a default namespace declaration. Find declaration in following example

<Project DefaultTargets = "HelloMSBuild"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

In this DefaultTargets attribute is of interest. Target is the set of actions that msbuild will perform against the project by default.

To understand better let us create a sample project by name “test.msproj”.

1) Create a new text file

2) Add Project element as shown above

3) Add target ‘HelloMSBuild’ as shown below

<Project DefaultTargets = "SayHello"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

<Target Name="SayHello">
<Message Text="Hello MSBuild" />
</Target>

</Project>

From visual studio command prompt run “msbuild test.msproj”. That is the simplest helloworld with MSBuild where target executes only task “Message”. “Message” is a built-in task. Built-in tasks are included by default. Thus we don’t find any declaration about where Message task is defined.

<Project DefaultTargets ="Lab02"

xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

<ItemGroup>

<
Items Include="Item1" />

<Items
Include="Item2" />

</
ItemGroup>


<
PropertyGroup>

<
PropertyA>Property1</PropertyA>

</
PropertyGroup>

<
TargetName="Lab02">


<
Message Text="$(PropertyA)"/>

<
Message Text="@(Items)"/>


</Target>

</
Project>

That gives a basic idea about using items and properties. A project can contain more than on ItemGroup elements. All items in ItemGroup must be of same type. In this case they are of “Items”. But a different ItemGroup can contain different kind of elements. We can only refer to items as a group. In this case we referred them @(Items). But properties can be referred individually. Actually we can refer to properties individually only. Format to access a property is $(PropertyName).

So far we have see built-in task “Message”. Now let us see how to build a custom task

Getting started with Custom Task

Here I describe the procedure to build a custom task by name SimpleTask. This task does nothing fancy, but this exercise provides some insight about working with custom tasks. Look at MyTasks01.dll custom task. And we are using UsingTask option to refer to custom task.

<Project DefaultTargets = "CreateDirectory"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
<
UsingTask AssemblyFile="D:\MsBuildTasks\MyTask01.dll" TaskName="SimpleTask"/>

<
ItemGroup>
<
Param Include="Param1" />
<
Param Include="Param2" />
</
ItemGroup>

<
PropertyGroup>
<
Param3>Param3</Param3>
</
PropertyGroup>

<
PropertyGroup>
<
Status />
</
PropertyGroup>


<
Target Name ="CreateDirectory">

<
SimpleTask MyProperty ="@(Param)" >
<
Output TaskParameter="MyMessage" PropertyName="Status"/>
</
SimpleTask>

<
Message Text="$(Status)"/>

<
SimpleTask MyProperty ="$(Param3)" >
<
Output TaskParameter="MyMessage" PropertyName="Status"/>
</
SimpleTask>
<
Message Text="$(Status)"/>

</
Target>

</
Project>

Alternative approach for UsingTask is importing external project as a whole. Sometimes this would be useful as the task needs more specific parameters or item groups. In such case all those parameters and item groups can be defined in external project and imported as a whole. To do this create a file by name “MyTasks.Targets” in same directory as task MyTask01.dll.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<
UsingTask AssemblyFile="D:\MsBuildTasks\MyTask01.dll" TaskName="SimpleTask"/>
</
Project>

And to import this file in project file replace UsingTask element with

<Import Project="D:\MsBuildTasks\MyTasks.Targets"/>

Building Custom Task

Now let us see how to write a custom task. Create a library and refer to libraries (You can choose version 2.0 or 3.5)


  1. Microsoft.Build.Framework
  2. Microsoft.Build.Utilities

Then update class file as shown below

using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace MyTasks
{
public class SimpleTask : Task
{
public override bool Execute()
{
//Parameters are semi column seperated values
string[] parameters = myProperty.Split(';');
foreach (string paramter in parameters)
myMessage += paramter + " - Done\n";
return true;
}

private string myProperty;
public string MyProperty
{
get { return myProperty; }
set { myProperty = value; }
}

private string myMessage;
[Output]
public string MyMessage
{
get { return myMessage; }
set { myMessage = value; }
}
}
}


Here observe that we added ‘Output’ attribute to MyMessage. And that is taken into status property in output element of SimpleTask. Then the value is printed through Message task.

With this background about MSBuild, we can move to hosting IronRuby in MSBuild source.

IronRuby Task

This part creates a new task to host IronRuby Task.

Create a new class library. Add references to MSBuild libraries and IronRuby libraries which include

IronRuby, IronRuby.Libraries, Microsoft.Build.Framework, Microsoft.Build.Utilities.v3.5, Microsoft.Dynamic, Microsoft.Scripting, Microsoft.Scripting.Core.

Then replace source contents with following

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using IronRuby;
using IronRuby.Runtime;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;

namespace ABB.INCRC.MSBuildTasks
{
public class IronRubyTask : Task
{
#region Properties

string script;

[Required]
public string Script
{

get { return script; }

set { script = value; }

}

string status;
[Output]
public string Status
{
get { return status; }
}


#endregion
public override bool
Execute()
{
try
{
ScriptEngine engine = Ruby.CreateEngine();

ScriptSource source = engine.CreateScriptSourceFromString(script, SourceCodeKind.Statements);

Object result = source.Execute();

status = result.ToString();
}
catch (Microsoft.Scripting.SyntaxErrorException syntaxError)
{
status = "SyntaxErrorException : " + syntaxError.Message;
return false;
}
catch (MemberAccessException maex)
{
status = "MemberAccessException : " + maex.Message;
return false;
}
return true;
}
}
}

Build this library and copy to folder like D:\MsBuildTasks\IronRubyTask. Note that execution of this task depends on referred libraries. Thus you need to copy all libraries to this folder. In last post we have seen how to refer a task with UsingTask element.

Here we take a better approach by using an external task definition.

External Project Reference

Create a new file by name MyMSBuildTasks and place following content. This script does lot of work


  • Makes a reference to IronRubyTask
  • Creates property group to hold script elements, which increment AssemblyFileVersion. This is done by updating AssemblyInfo.cs file in properties folder. BuildNumber is persisted in a separate BuildNumber.txt file
  • Creates tasks to execute scripts
  • Scripts are concatenated from multiple properties thereby keeping scripts modular
<?xml version="1.0" encoding="utf-8"?>
<
Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<
UsingTask AssemblyFile="D:\MsBuildTasks\IronRubyTask\IronRubyTask.dll" TaskName="IronRubyTask"/>

<
PropertyGroup>
<
GetBuild>
<![CDATA[
#Get Build

def getBuild(buildIndexFile)

begin

file = File.new(buildIndexFile, "r")

while (line = file.gets)
@token = line.split("=")
if (@token[0] == "build")
@build = Integer(@token[1])
end
if (@token[0] == "revision")
@revision = Integer(@token[1])
end
end

file.close

rescue => err

err
end

end

@build = -1
@revision = -1

getBuild("D:\\BuildNumber.txt")

]]>
</
GetBuild>

<
SetBuild>
<![CDATA[

#Set Build
def setBuild(buildIndexFile)
begin
buildIndex = "build=#{@build}\r\nrevision=#{@revision}"
File.open(buildIndexFile,"w") {|f| f.write(buildIndex) }

"Updated : #{buildIndexFile}"

rescue => err
err
end
end
]]>
</
SetBuild>

<
DefineFileVersion>
<![CDATA[

#update AssemblyVersion

def updateFileVersion(assemblyInfoFile)


if(@build > 65536)
@build = 0
end

if(@revision > 65536)
@revision = 0
end


assemblyInfo = File.read(assemblyInfoFile)

assemblyInfo = assemblyInfo.gsub(/AssemblyFileVersion\(\"1\.0\.(\d+)\.(\d+)\"\)/,
"AssemblyFileVersion(\"1.0.#{@build}.#{@revision}\")")
#puts assemblyInfo

begin
File.open(assemblyInfoFile,"w") {|f| f.write(assemblyInfo) }
"Updated : #{assemblyInfoFile}"
rescue => err
puts err
err
end


end
]]>
</
DefineFileVersion>

<
UpdateFileVersion>
<![CDATA[

#Execution Starts here

if @revision > 0
@revision = @revision + 1
else
@build = @build + 1
end

updateFileVersion("D:\\MsBuildTasks\\Properties\\AssemblyInfo.cs")

]]>
</
UpdateFileVersion>


<
SetBuildNumber>
<![CDATA[

#Execution Starts here

@build = @build + 1
@revision = 0

setBuild("D:\\BuildNumber.txt")

]]>
</
SetBuildNumber>

<
SetRevisionNumber>
<![CDATA[

#Execution Starts here

@revision = @revision + 1

setBuild("D:\\BuildNumber.txt")

]]>
</
SetRevisionNumber>

</
PropertyGroup>

<
Target Name="UpdateFileVersion">
<
IronRubyTask Script="$(GetBuild)$(DefineFileVersion)$(UpdateFileVersion)">
<
Output TaskParameter="Status" PropertyName="Status" />
</
IronRubyTask>
<
Message Text="$(Status)" />
</
Target>

<
Target Name="SetBuildNumber">
<
IronRubyTask Script="$(GetBuild)$(SetBuild)$(SetBuildNumber)">
<
Output TaskParameter="Status" PropertyName="Status" />
</
IronRubyTask>
<
Message Text="$(Status)" />
</
Target>

<
Target Name="SetRevisionNumber">
<
IronRubyTask Script="$(GetBuild)$(SetBuild)$(SetRevisionNumber)">
<
Output TaskParameter="Status" PropertyName="Status" />
</
IronRubyTask>
<
Message Text="$(Status)" />
</
Target>

</
Project>

Referring target file

Now create a test project file and refer above file.

<Project DefaultTargets = "Test"

xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

<
Import Project="D:\MsBuildTasks\ABB.INCRC.MSBuildTasks"/>

<
Target Name="Test" DependsOnTargets="UpdateFileVersion;SetBuildNumber;SetRevisionNumber" />

</
Project>

Here we use “DependsOnTargets” to call multiple targets from referred file.

Hope this post provided a use-case to host dynamic languages like IronRuby for useful tasks. Advantage of this approach is you need to build only one custom task. All other needs can be achieved using scripts. And scripts are part of msbuild project in the form of properties.

Tuesday, December 15, 2009

Hosting IronRuby in .Net applications - Part2

In last post of this series we have seen few examples of IronRuby. That is just a glimpse of IronRuby.
With this background we can take a look at integrating these snippets in a .Net application.

I would like to provide some basic introduction about Dynamic Language Runtime (DLR) and then present an example.

DLR Overview

DLR infrastructure provides solutions for different purposes which include

  1. port dynamic languages to .NET
  2. add dynamic features to existing language
  3. author libraries whose objects support dynamic operations
  4. employ (host) dynamic languages in applications and frameworks
But this post is oriented towards hosting scenarios only.

DLR is built on top of Common Language Runtime (CLR). Microsoft .Net framework is designed to support multiple programming languages on CLR. It provides common services like GC, JIT etc. for static languages like C#, VB.Net etc. The CTS and CLI infrastructure allows sharing libraries written in any language with any other language targeting CLR. And we rarely realize need to host CLR explicitly, as it is done automatically by various CLR executable modules due to modifications done to Portable Executable format.

DLR extends CLR with services required for dynamic languages like python, ruby. In similar lines it first extends type system to be dynamic. Then, incase of statically typed languages, meta data provides necessary relative virtual addresses at compile time for method invocations. These virtual pointers turn into realistic pointers during JIT compilation process and remain as is as long as execution engine is alive. This is not the case with dynamic languages which require a dynamic method dispatching mechanism. Also applications need to explicitly host Dynamic Runtime Engines. But DLR eases some effort here by providing a common hosting API for all dynamic languages targeting DLR. So if we summarize, key components of DLR would include

  1. dynamic type system
  2. dynamic method dispatching system
  3. common hosting API

Dynamic type system and dispatching system provide services for first three purposes mentioned at the beginning of ‘DLR Overview’. Common hosting API provide services for last purpose in that list.

Hosting Scenarios

As such there could be several scenarios in which DLR can be employed (hosted). Such scenarios include

  • executing a script in a given scope using default script-host
  • executing several scripts in multiple scopes using custom script-host
  • controlling on how to pre-compile and improve executing performance, an advanced scenario

This part of the series confines to first scenario in which one script is executed in a given scope.

Execution Overview

As mentioned above, this post is presenting the very basic mode of executing a script.
Steps involved in this process include

  • Create Script Engine for Ruby
  • Create Scope object from engine and set scope
  • Create code
  • Execute code within a given scope

Example

Following step by step procedure makes up a simple application to host IronRuby

  1. Start Visual Studio and create a new console application. Copy required
  2. Refer following dependent assemblies from ~\<Program Files>\IronRuby 0.9.2\bin
    IronRuby.dll
    IronRuby.Libraries.dll
    Microsoft.Dynamic.dll
    Microsoft.Scripting.Core.dll
    Microsoft.Scripting.dll
  3. Add following using statements
  4. using IronRuby;
    using Microsoft.Scripting.Hosting;
    using Microsoft.Scripting;

  5. Add following code in Main

  6. ScriptEngine engine;
    ScriptScope scope;

    String code;

    Int32 i1 = 20;
    Int32 i2 = 10;

    engine = Ruby.CreateEngine();
    scope = engine.CreateScope();

    scope.SetVariable("i1", i1);
    scope.SetVariable("i2", i2);

    code = @"def compareValues()
    return $i1 > $i2
    end

    $i1 = i1;
    $i2 = i2;

    comp = compareValues();

    puts comp";

    engine.Execute(code, scope);

    Console.WriteLine("Press any key to continue");
    Console.ReadLine();


  7. Build and run code.

If everything goes well you should see true on screen.


Friday, December 11, 2009

Wednesday, December 02, 2009

Hosting IronRuby in .Net applications - Part1

This post provides necessary information to host IronRuby in .Net applications. I assume no knowledge of Ruby or DLR from reader. It starts with basic introduction to IronRuby and then provides information on DLR and hosting options.

Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. IronRuby is a Open Source implementation of the Ruby programming language for .NET, heavily relying on Microsoft's Dynamic Language Runtime.

This is the first part of this series. This part familiarizes the ruby language as much required for this series. For better understanding of ruby language reader can refer to Ruby Programming, IronRuby Documentation, Ruby Learning Tutorial, Ruby Manual.

Getting started

Though prior knowledge of Ruby is an added advantage a novice can still follow this post to get started with Ruby.

Before we can start Download IronRuby 0.9.2 msi. After installing the msi you should find “~\IronRuby 0.9.2\IronRuby Console” in Start –> Programs. This is an interactive console. We can also run a script using “ir.exe <script>”. ir.exe can be found at “<installation path>\IronRuby 0.9.2\bin\ir.exe".

Enter following lines in a notepad and save the file with .rb extension.

ex01.rb

puts 'Hello World'
print "Hello World\n"
puts "Hello World"
puts "Hello World";

Now run this example from command prompt. “ir.exe ex01.rb”. You can test these three lines from interactive console also.

Observations from this example are


  • puts or print either one works to print a message

  • semi-colon at the end of a line is optional

  • Single quote or double quotes, either one works. There is subtle difference between them regarding allowed escape sequences line new line etc.

  • There is no need of main or class to start a hello world program

OK we have just written a ruby script. There is no main/Main here. OK that doesn’t mean we can’t have functions. Let us see them.

ex02.rb

def sayHello
puts 'Hello World'
end

sayHello
sayHello()
sayHello();

Place this code in ex02.rb and run “ir.exe ex02.rb”. All three statements produces same result.

Observations from this example are


  • functions are defined as def and end blocks

  • there is no return type specified. In ruby we don’t specify a return type

  • definitions must be declared prior to calling them

  • all definitions should start with small letter. Though a capital letter as starting character works sometimes, that is not a good practice. Avoid it

  • definition can be called is all three forms. It there are no arguments braces are optional. Again last semi-colon is optional

Fine. Let us pass an argument and get a return parameter.

ex03.rb

def getSQRT(arg)
Math.sqrt(arg)
end

sqrt = getSQRT(ARGV[0]);

puts sqrt

Place this code in ex03.rb and run “ir.exe ex03.rb 4”. Square root of 4, 2.0 is printed on screen.

Observations from this example are

  • command arguments are in ARGV array starting from index zero

  • arguments doesn’t take any type parameter

  • return call is optional. If no return statement is coded, result of last statement is passed as return value

  • sqrt parameter is a local variable, but there is no type specified. It hold return value of getSQRT call

  • Math is a module which is implicitly available. We didn’t write anything line using/import Math

Now let us see how comparison works.

ex04.rb

def compareValues()
return $i1 > $i2
end

$i1 = ARGV[0]
$i2 = ARGV[1]

comp = compareValues();

puts comp

Place this code in ex04.rb and run “ir.exe ex04.rb 2 1”. ‘true’ is printed on screen

Observations from this example are

  • return keyword is specified though it is optional

  • global variables as prefixed with $. This ‘$’ sign specifies that the variable is a global variable.

  • Variable scopes are

    • Local variable : Defined with a block. Starts with lower case letter or ‘_’. ex: var1, _var2

    • Instance variable : Defined within a class (classes are covered later) as a member. Starts with ‘@’ ex: @inst1, @inst2

    • Class variable: These are like static variable in a class. Only one instance is allowed and the same is shared among all objects. Starts with ‘@@’. ex: @@cls1, @@cls2

    • Global variables: These are accessible for all definitions. Starts with ‘$’. eg: $g1, $g2

    • Constants are started with a upper case letter. ex: PI, SpecificGravity

  • There are some commonly used built-ins as mentioned below

    • self - Execution context of the current method

    • nil - Expresses nothing

    • true - Expresses true

    • false – Expresses false. nil also is considered to be false, and every other value is considered to be true

Its time to take big bite.

ex05.rb

class ClassA
attr_accessor :dict

def initialize()
@dict = System::Collections::Generic::Dictionary[String,Object].new
self.dict.Add 'Argument', 12.243
end

def addElements
begin
if @dict['Argument'] == 12.243
@dict.Add 'Key1', 1
self.dict.Add('Key2','TWO')
@dict.Add('Key3', 8.765);
end
rescue StandardError => ste
puts 'StandardError occurred : ' + ste
end
end
end

clsA = ClassA.new

clsA.addElements



for i in clsA.dict.Keys
puts clsA.dict[i]
end

Place this code in ex05.rb and run “ir.exe ex05.rb”. Following results are printed on screen

12.243
1
TWO
8.765

We covered lot of ground here.

Let us start with a small pie

  • Class name to start with a capital letter.
  • attr_accessor creates a get set accessors like properties. We can declare multiple accessors in one statement like
    attr_accessor :dict, :hach, :lict
  • def initialize() is a paramterless constructor

Instance variable

  • As mentioned earlier instance variables are declared with prefix ‘@’. They can be accessed using ‘@’ notation or self.<variable> notation. Observe two lines in constructor and usage of either notation

Using CLR types and object creation

  • CLR types can be used in IronPython with syntax mentioned here.

    Observe minor difference in scope resolution operator ‘::’ and generic template notation with square brackets.

  • Also observe the notation to create objects with <Type>.new method. eg: Dictionary[String,Object].new and ClassA.new

  • We can use all methods of CLR type as is. Observe usage of ‘Keys’ property and ‘Add’ methods

Exception handling

  • ‘begin’, ‘rescue’, and ‘else’ sequences are exception handling blocks. Exceptions are raised using ‘raise’ keyword

  • rescue is like catch while raise is like throw. => operator provides a reference to current exception into the variable on right side.

  • there is option of else to catch all other exceptions

    begin
    raise 'Error occured'
    rescue Exception1 => ex1
    rescue Exception2 => ex2
    else
    Other exceptions
    end

for loop

  • Here for loop is used with iterator.
  • There is no need to specify type for iteration variable. eg. for i in clsA.dict.Keys

There is so much in it. Now let us see what ruby offers for delegation of control

ex06.rb

def AuthenticateUser(l)
if l.call('ruby', 'gem')
puts 'Authentication Successful'
else
puts 'Authentication Failed'
end
end

#Function pointer
fp = proc { |username, password|
if username == 'ruby' && password == 'gem'
return true
end
}

AuthenticateUser(fp)

#Method pointer
class Authenticate
def initialize(username, password)
@username = username
@password = password
end
def validateCredentials(username, password)
if username == @username && password == @password
return true
end
end
end

a = Authenticate.new('ruby','gem')

mp = a.method( :validateCredentials )

AuthenticateUser(mp)

Place this code in ex06.rb and run “ir.exe ex06.rb”. Two ‘Authentication Successful’ messages are printed on screen.

Here Authenticate method takes a delegate as argument. This argument is a pointer to a routine on which method can invoke a call. Above code demonstrates passing the routine as function pointer and method pointer within a class.

Observations from this example are

  • Invocation of a routine is done with .call method
  • Function pointers are obtained using ‘proc’ keyword. It can be done using keyword ‘lambda’ also. There is a subtle difference between them regarding invocation context. More details can be found at link
  • The usage within | | is arguments for routine being called followed by implementation using these arguments. It is like anonymous method in C#
  • To get the reference to a method within a class we use ‘.method’ function.

Some more examples in Part-2. And then part-3, I will cover about integrating ruby scripting feature in .Net applications.