Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

Resolver One on Digipede Sample

As I noted recently, I have been working with Giles Thomas and Glenn Jones at Resolver Systems on a sample mixing distributed IronPython objects with Resolver One spreadsheets. 

I like those guys.  They are smart and do excellent work.

Anyway, they released the sample earlier today.  From their site:

As of version 1.5 (which is currently in beta), the world’s coolest spreadsheet can use Digipede Network grid computing to distribute and execute workbooks in parallel. The example on the Exchange is based on the excellent IronPython sample created by Robert W. Anderson of Digipede. The Digipede Network is a brilliant way to get distributed, parallel computation on Windows. It only took a few minor changes to convert Resolver One to run on the Digipede Network and to get the IronPython sample to execute Resolver One workbooks.

Giles gives some more background to the path that got us here on his recent post, Resolver One and Digipede.

The combination of our two products offers a pretty elegant solution.  Like I said before,

Try doing that with a spreadsheet or grid that isn’t based on .NET . . .

. . . like Excel and Windows HPC Server.  No, don’t. Trust me.  It is really hard, complex, and brittle.

Tags: , , , , ,

Resolver One on Digipede

deatle2r1 We had a call this morning with Giles Thomas and Glenn Jones of Resolver Systems.  They demonstrated Resolver One running on the Digipede Network.

They used my IronPython Worker sample and customized the front-end Python code, leaving the C# adapter as-is.  With very little coding they had an elegant grid-enabled spreadsheet.  Try doing that with a spreadsheet or grid that isn’t based on .NET . . .

Giles said they will have support for this in Resolver One 1.5, coming out in the next couple of weeks.

Very cool. 

I’ve just installed Resolver One to take a closer look.  Already I’m impressed, but I’ll leave that for a future post.

Tags: , , , ,

IronPython and Digipede Network 2.2

. . . or IronPython-ipede (Part II).

deatle2py22I have been playing with IronPython a little.  With the release of Digipede Network 2.2, I am now able to post the sample I wrote.  It shows how to distribute IronPython objects on the Digipede Network.  You can find it on the Digipede community site.  See the posting there for details and download instructions.

The sample uses IronPython 2.0.1 and the included version of the Microsoft Dynamic Language Runtime (DLR).  While I focused on IronPython in this sample, it would be pretty easy to expand it to support other DLR-based languages.

Comments welcome.  I am specifically interested in feedback on DLR integration and initializing ScriptScope objects for each worker thread.  It seems that I should be able to do some of this only once at global scope.

By the way, one thing I like about this sample is that it shows how to keep user code completely de-coupled from the Digipede Network while still taking advantage of our deployment and payload distribution model.  This has always been supported by the Digipede Network, and this makes a good example.

Tags: , , , ,

IronPython-ipede (Part I)

I have been taking a closer look at IronPython for a prospective customer.  Never being happy with “shoulds”, I am going to show how to distribute IronPython objects on the Digipede Network.

The first thing I did get our old Python sample running in IronPython.  This was the first user-contributed sample (thanks to Sean True).  That sample (see it here) uses Python COM libraries to invoke a job with the Digipede Network COM APIs.  This didn’t submit objects, just executed a command-line application.

I’m happy to say that the code required very little modification to run under IronPython.  The only difference is in the syntax of the “import” commands.  Kudos to the IronPython team.

I’ll post the working code once I get a little farther.

Next step: distribute IronPython objects.  Fairly straightforward, but I’ll write a reusable C# Executive to load the IronPython class definition.

Tags: , ,