On my last post, it was commented that “If NinjaTrader could be used with Resolver One… now that would be awesome…”. I had never heard of Resolver One previously, so I took a quick look to see what it was. Resolver One is spreadsheet app that generates IronPython code, in real-time, from the spreadsheet contents. That part is pretty slick, but its spreadsheet features are a bit lacking. Right off the bat I was struck by the lack of the standard Edit->Fill feature and the inability to grab a cell or range of cells and drag it to a new location. These are both features I use constantly in Excel. Next problem was that an exported .py script (for a trivial spreadsheet) wouldn’t actually run their own interpreter RSIronPython.exe due to import failures. Found it was necessary to add:
import LoadRequiredAssemblies
to the top of the .py file before it would execute properly. Additional reference resolution hoop jumping would be necessary to get that same file to run using the standard IronPython interpreter (versions 1.1.1 is what Resolver One is currently based on), but once that is done and the .py file can be run from any working directory (rather then “C:\Program Files\Resolver One” as is needed with RSIronPython.exe) then the .py file could be compiled into an assembly and run from any process running in an environment with the correct system\assembly paths, so it could be referenced by a NinjaScript or an assembly plugged into NinjaTrader.
I’m not personally motivated to work through the remaining reference hoops to have a complete proof of concept at this time, as Resolver One’s lack of key (to me anyway) standard spreadsheet features means it isn’t going to replace Excel 2000 on my desktop anytime soon.
Yes, I’m still using Excel 2000, even though I could have had subsequent releases quite cheap from the MS company store. I used the more recent versions at work, and they didn’t provide any new features that motivated me to even want bother with process of installing an upgrade. In fact Office 2007 inspired me to take a look at OpenOffice, but didn’t see anything there that made me want to bother with switching over to it (although I seem to remember something about being able to script it in Python, so I may want to look back into for that reason in the future).
IronClad
IronClad is an open source project started by Resolver to get Python native extensions (i.e. native DLLs with Python interfaces) working with IronPython. I think it was over two years ago now that I asked the IronPython devs at MS when they would have that working and they didn’t want to give a time frame then. Since its now being done by a third party it looks like the answer is “never by us”. The second library they are targeting with IronClad is the numpy Python library, which happens to be a library I’ve been making extensive use of in my game development, and would be sorely missed if trying to do number crunching in IronPython.
I will definitely have to keep an eye on the progress of IronClad and of Resolver One’s feature set.
Josh Heitzman on Codecrafting 
Hi Josh,
Just saw your post on my Google alert for Ironclad.
Thanks for taking a look at Resolver One! Good points on the feature front; the next version (coming out next week) has some usability enhancements, including an improved cut/paste that would do what you want to do when you’re dragging and dropping, but the problem with the exported code is still there, as is the lack of fill down. It’s great to hear feedback like this, though, as it makes it clear to us that we need to bump these things up the priority list 🙂
Getting IronPython code into assemblies that you can call from C# or other .NET languages is a bit of a pain, BTW. The best way I’ve heard is to make your IP class a subclass of a C# one, then to create a C# factory that instantiates the IP engine, calls Python code to create an instance of your object, and then passes it back.
We’re thinking that an improved “export as Python class” option could be usefully augmented with an “export as .NET assembly”…
Cheers,
Giles
Hi Josh – resurrecting this old post to let you know that the RSIronPython path should be fixed in 1.3, so you won’t have to fiddle with the current directory any more.
Also, there is a first implemention of drag-fill, that we plan to extend in future versions.
Sneak peek: for 1.4 we’re planning to run on top of ipy 2.0, which supports compilation of whole Python packages to dlls. It shouldn’t be too hard to add an “export as DLL” feature that will setup the required machinery, so that C# code can call into Resolver One spreadsheets. Of course, customer requests is what dictates priorities, so please send us an email if you want this!
Regards,
Orestis