Boo

Zero friction IoC: Auto registration is mandatory

Ayende Rahien — Tue, 13 May 2008 13:08:57 GMT

This is the entire Binsor config file for a real application:

import Castle.MonoRail.Framework
import Castle.MonoRail.WindsorExtension
import Rhino.Commons.Facilities from Rhino.Commons.ActiveRecord

facility MonoRailFacility
facility RhinoTransactionFacility
facility ActiveRecordUnitOfWorkFacility:
	assembly = "HibernatingRhinos"

for type in AllTypesBased of IController("HibernatingRhinos"):
	component type.Name, type
	
for type in AllTypes("HibernatingRhinos").WhereNamespaceEq("HibernatingRhinos.Services"):
	component type.GetServiceInterface(), type

And I am pretty confident that I am not going to have to do much in the future with those.

And yes, you can do it with the fluent registration API as well.

Binsor & Auto Registration - Making it even simpler

Ayende Rahien — Tue, 13 May 2008 05:21:51 GMT

Here is the syntax that I am getting at...

for type in AllTypesBased of IView("Rhino.Commons.Test"):
	component type
	
for type in AllTypesWithAttribute of ControllerAttribute("Rhino.Commons.Test"):
	component type
	
for type in AllTypes("Rhino.Commons.Test") \
	.WhereNamespaceEq("Rhino.Commons.Test.Binsor"):
	component type

for type in AllTypes("Rhino.Commons.NHibernate") \
	.Where({ t as System.Type | t.Name.Contains("NHRepository") }):
	component "nh.repos", type.GetSeriveInterface(), type

And this seems to cover just about any scenario that I can think of. Combine that with Binsor's extend facility, and we are more or less done.

Setting up MonoRail Windsor Integration with Binsor

Ayende Rahien — Tue, 13 May 2008 04:17:17 GMT

I think I'll let it stand on its own:

facility Castle.MonoRail.WindsorExtension.MonoRailFacility 
for type in AllTypesBased of Controller("HibernatingRhinos"):
	component type.Name, type

Done.

I didn't believe it, to be fair.

Course: Building Domain Specific Languages in Boo

Ayende Rahien — Tue, 06 May 2008 01:33:54 GMT

You can register here for a two days course in building DSL with Boo.

It is going to take place two weeks from today, in Austin. (19 - 20 May)

I know that this is short notice, but it wasn't something that was planned well in advance. It came out of the ALT.Net conference.

Topics:

Creating Domain Specific Languages
The Boo Language
Flexible compiler and malleable language
Creating applications with embedded DSL
Management, tracing and debugging
Tooling support
Testing and maintainability concerns

There are ten seats open for that.

I hope we would have fun.

I would also like to thank Jeffrey Palermo and Headspring for hosting the course.

DSL Article on InfoQ

Ayende Rahien — Mon, 21 Apr 2008 16:10:20 GMT

My DSL article has been published on InfoQ!

You can get it here

Loop unrolling in Boo

Ayende Rahien — Wed, 02 Apr 2008 10:05:58 GMT

// We create a class for the macro, the class name is
// meaningful, [macro name]Macro allows us to later refer
// to the macro using just [macro name].
// Note that we inherit from AbstractAstMacro
class UnrollMacro(AbstractAstMacro):

	// Here we perform the actual compiler manipulation
	// the compiler hands us a macro statement, and we have
	// to return a statement back, which will replace it.
	override def Expand(macro as MacroStatement) as Statement:
	
		// define a block of code
		block = Block()
		
		// extract the second parameter value
		end = cast(IntegerLiteralExpression, macro.Arguments[1]).Value
		
		for i in range(end):
			// create assignment statement, using the block: trick 
			// and add it to the output
			statements = [|
				block:
					$(macro.Arguments[0]) = $i
			|].Block
			block.Add(statements)
			
			// add the original contents of the macro
			// to the output
			block.Add(macro.Block)
			
		return block

And usage:

unroll i, 5:
	print i

Which will produce:

i = 0
print i
i = 1
print i
i = 2
print i
i = 3
print i
i = 4
print i

The quote generation DSL

Ayende Rahien — Sun, 30 Mar 2008 22:51:21 GMT

I am doing some work on the DSL book right now, and I run into this example, which is simple too delicious not to post about.

Assume that you have the following UI, which you use to let a salesperson generate a quote for your system.

This is much more than just a UI issue, to be clear. You have fully fledged logic system here. Calculating the total cost is the easy part, first you have to understand what you need.

Let us define a set of rules for the application, is will be clearer when we have the list in front of us:

The Salary module requires a machine per every 150 users.
The Taxes module requires a machine per 50 users.
The Vacations module requires the Scheduling Work module.
The Vacations module requires the External Connections module.
The Pension Plans module requires the External Connections module.
The Pension Plans module must be on the same machine as the Health Insurance module.
The Health Insurance module requires the External Connections module.
The Recruiting module requires a connection to the internet, and therefore requires a fire wall of the recommended list.
The Employee Monitoring module requires the CompMonitor component

Of course, this fictitious sample is still too simple, we can probably sit down and come up with fifty or so more rules that we need to handle. Just handling the second level dependencies (External Connections, CompMonitor, etc) would be a big task, for example.

Assume that you have not a single such system, but 50 of them. I know of a company that spent 10 years and has 100,000 lines of C++ code (that implements a poorly performing Lisp machine, of course) to solve this issue.

My solution?

specification @vacations:
	requires @scheduling_work
	requires @external_connections
	
specification @salary:
	users_per_machine 150
	
specification @taxes:
	users_per_machine 50

specification @pension:
	same_machine_as @health_insurance

Why do we need a DSL for this? Isn’t this a good candidate for data storage system? It seems to me that we could have expressed the same ideas with XML (or a database, etc) just as easily. Here is the same concept, now express in XML.

<specification name="vacation">
	<requires name="scheduling_work"/>
	<requires name="external_connections"/>
</specification>

<specification name="salary">
	<users_per_machine value="150"/>
</specification>

<specification name="taxes">
	<users_per_machine value="50"/>
</specification>

<specification name="pension">
	<same_machine_as name="health_insurance"/>
</specification>

That is a one to one translation of the two, why do I need a DSL here?

Personally, I think that the DSL syntax is nicer, and the amount of work to get from a DSL to the object model is very small compared to the work required to translate to the same object model from XML.

That is mostly a personal opinion, however. For pure declarative DSL, we are comparable with XML in almost all things. It gets interesting when we decide that we don’t want this purity. Let us add a new rule to the mix, shall we?

The Pension Plans module must be on the same machine as the Health Insurance module, if the user count is less than 500.
The Pension Plans module requires distributed messaging backend, if the user count is great than 500.

Trying to express that in XML can be a real pain. In fact, it means that we are trying to shove programming concepts into the XML, which is always a bad idea. We could try to put this logic in the quote generation engine, but that is complicating it with no good reason, tying it to the specific application that we are using, and in general making a mess.

Using our DSL (with no modification needed), we can write it:

specification @pension: 
	if information.UserCount < 500: 
		same_machine_as @health_insurance 
	else: 	
		requires @distributed_messaging_backend

As you can imagine, once you have run all the rules in the DSL, you are left with a very simple problem to solve, with all the parameters well known.

In fact, throughout the process, there isn't a single place of overwhelming complexity.

I like that.

A web server in 30 lines of code

Ayende Rahien — Sun, 30 Mar 2008 19:35:15 GMT

Just found myself writing that, and it was amusing.

import System.Net
import System.IO

if argv.Length != 2:
	print "You must pass [prefix] [path] as parameters"
	return

prefix = argv[0]
path = argv[1]

if not Directory.Exists(path):
	print "Could not find ${path}"
	return

listener = HttpListener()
listener.Prefixes.Add(prefix)
listener.Start()

while true:
	context = listener.GetContext()
	file = Path.GetFileName(context.Request.RawUrl)
	fullPath = Path.Combine(path, file)
	if File.Exists(fullPath):
		context.Response.AddHeader("Content-Disposition","attachment; filename=${file}")
		bytes = File.ReadAllBytes(fullPath)
		context.Response.OutputStream.Write(bytes, 0, bytes.Length)
		context.Response.OutputStream.Flush()
		context.Response.Close()
	else:
		context.Response.StatusCode = 404
		context.Response.Close()

Short yet interesting: in search of a sample

Ayende Rahien — Thu, 06 Mar 2008 16:38:43 GMT

One of the feedback points that I got about the book was that there need to be a fully working Boo program, before we start to introduce the DSL ones. The problem? I can't think of anything that will be both interesting and short enough to put into a book.

My limit is at about two pages, and I don't want a tedious example. Any suggestions?

One major point, it should have as little background assumptions as possible.

From BooBS to Bake

Ayende Rahien — Sat, 26 Jan 2008 21:11:48 GMT

Okay, I renamed Boo Build System to Bake. Now you can cut the jokes and actually integrate it into a PC environment.

The repository is here, although you can just grab the binaries.