.NET port

[simoneb]

Hello Richard, sorry for using an issue but I couldn't find another way to get in touch with you. I am writing a .NET port of auger, not really a port but something which allows you do to pretty much the same, albeit with the somewhat limited flexibility that C# provides for creating internal DSLs.
I'll be hosting it here on github or some other open source hosting provider, and use augen as the not-so-original name, but of course I want to ask your permission first. Let me know what you think.

[rlister]

Simone, sounds great. I know nothing about .NET, but will be interested to see what it looks like.

[simoneb]

Hi Richard, great, thanks a lot. I spiked some code yesterday, mainly to come up with a meaningful syntax, I'll push it later today and send you a link.

[rlister]

As I say, I know nothing, but it might be cool if augen could take auger
configs by embedding a ruby interpreter to create .NET objects (
http://rubydotnet.sourceforge.net/). Then one could create augen plugins
(e.g. http) using native .NET libraries.

On Wed, Feb 13, 2013 at 2:15 PM, simoneb notifications@github.com wrote:

Hi Richard, great, thanks a lot. I spiked some code yesterday, mainly to
come up with a meaningful syntax, I'll push it later today and send you a
link.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-13511789.

[simoneb]

Hi Richard, let's not get ahead of ourselves :) My plan was to create
something in .NET which allows to do things similar to auger, but being
able to use the same scripts requires much more effort than I intend to put
on it. Actually the project you linked to seems to be dead since 2004,
although there is now IronRuby, but yet I'm not planning to make it able to
parse auger scripts for the time being.

On Wed, Feb 13, 2013 at 8:25 PM, rlister notifications@github.com wrote:

As I say, I know nothing, but it might be cool if augen could take auger
configs by embedding a ruby interpreter to create .NET objects (
http://rubydotnet.sourceforge.net/). Then one could create augen plugins
(e.g. http) using native .NET libraries.

On Wed, Feb 13, 2013 at 2:15 PM, simoneb notifications@github.com
wrote:

Hi Richard, great, thanks a lot. I spiked some code yesterday, mainly to
come up with a meaningful syntax, I'll push it later today and send you
a
link.

—
Reply to this email directly or view it on GitHub<
https://github.com/brewster/auger/issues/3#issuecomment-13511789>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-13512840.

[simoneb]

Hi Richard, I pushed the code here: https://github.com/simoneb/augen
You can see a sample of the syntax in augen.console/MyProject.cs

[rlister]

Most interesting, I like how you keep the spirit of the configuration
syntax.

I lean heavily on ruby's weak typing for handling return values from
'test'. This means the user can return any class of object and have the
client decide how to display it, e.g. checkmark for boolean, captures from
a regex match, other objects have .to_s method called. Even exceptions can
be returned like any other object and be formatted for output. It will be
interesting to see how you approach this in a strongly-typed language.

On Wed, Feb 13, 2013 at 9:04 PM, simoneb notifications@github.com wrote:

Hi Richard, I pushed the code here: https://github.com/simoneb/augen
You can see a sample of the syntax in augen.console/MyProject.cs

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-13529648.

[simoneb]

Hi Richard, I've just finished pushing the latest changes. I think the public API is almost stable now (and heavily inspired by auger, though not as nice, I admit). I've implemented Http and Tcp support so far, but the plumbing is there and adding more should be straightforward. The interesting aspects (IMO) are:

• the dynamic features I'm relying heavily on internally, which .NET gained in the recent past
• the C# language syntax normally used for dynamic code generation that I'm stretching a little bit by using lambda expressions as hashes to define options
• the way test results are handled. It's via lambda expressions, but rather than executable code it's the AST of the code. Right now I'm simply compiling it on the fly and executing, but you can do fancy stuff with it too.

Feel free to have a look and let me know what you think!