Various things for the new year

Trying to catch up on things. It's easy to get swept up in the busy day-to-day activities so much that you get behind on the things you want to get to.

Last year, I became involved in the NAnt development and things were moving along nicely to the point that we were able to get NAnt to version 0.90. Since then, we tried to get going on 0.91 to support .NET 4.0 but that ran into a snag. A security exception began popping up with random users trying to use the latest alpha release. What's worse, I have been unable to reproduce these issues on any of my test systems. I have received help from a few users who have been kind enough to provide debugging details and I do have a couple of ideas on how to approach the issues but it's been put on the back burner due to higher priorities at the moment. I hope to get to it soon.

I just started using syntaxhighlighter in my blog to help format some of the code that I have posted in the past. I must say that it is pretty cool. Some directions that I used can be found here. So I may be going back and updating some of the posts to better format the code that I post.

The Iron(Python|Ruby) projects have been turned over to the Iron* communities which is a good thing. It seems that Microsoft is letting these projects fly on their own with people who are experienced and dedicated with these kinds of projects and are actively working on them. I am happy that Microsoft made this move rather than let these languages go stale.

Now that IronPython is in capable hands, I am wondering when the Django project will try to support it. I mean, why not, Django supports Jython. I can understand that it may be an undertaking but it would be very nice for Django to run on IronPython out of the box rather than applying patches.

I'm hoping to write more in the near future.

What will be the future of IronPython?

Long time, I know. I'm trying to get back into the swing things. Slowly but surely.

I've been reading about the latest progress regarding the Microsoft Irons (python, ruby, etc) and it has me a bit concerned. I started using IronPython at work awhile back to help me out with various tasks and it works pretty good. So I have some scripts that help me out that I now use often. A few weeks ago, Microsoft changed the license for both IronPython and IronRuby to the Apache Software Foundation License version 2.0. I thought that was a cool and inviting change to the open source community. Hell, when I heard that, I started planning on converting more projects to IronPython. That was until I read this article over at The Register. While the article targets IronRuby, it seems to hint that IronPython is not far behind. If Microsoft ends up dumping these dynamic languages, I really hope that they completely open up the source code for these languages. This includes allowing people outside of Microsoft to contribute code to the project. The ASF license is a good step forward but they need to open it all the way or these languages could fizzle out. And just when I started finding uses for ipy.

In the meantime, I'll keep my stuff as is while I watch the outcome of this as it unfolds.

Testing with IronPython

We all know that unit testing is important with software development. But the tests themselves are not always so black and white. IDEs like SharpDevelop or MonoDevelop have things like NUnit to help test a wide range of things like equality, identity, collection, and etc. These are great tools, but what happens when you don't know what the data being gathered/generated should be? How can we assert something when we don't know what it should be?

My situation was this, I wrote a C# library for work to pull customer information and create reports based on the customer's monthly fees. Since the fees vary between customers, it was difficult to make sure that the data being pulled was accurate. Since I have been losing time with this portion of the project, I decided it would be a good time to test the abilities of Iron Python.

Why use Iron Python? Couple of reasons. First, since this is a .NET project, Iron Python can load the library through the clr.AddReferenceToFile command. Second, it can be ran as a script rather than compiling a new C# project. This means that I can alter/update the script and rerun it when I need to. Nice convenience.

What I did was write a script to pull in the .dll library and call the various objects to display the information stored in them in an organized way. Like so...

import sys,clr

clr.AddReference("System")
from System import *

if __name__ == '__main__':

    dllPath = Environment.CurrentDirectory.ToString() + r'\bin\Debug'

    sys.path.append(dllPath)
    clr.AddReferenceToFile('nameOf.dll')

    from nameOfNamespace import *

    print "Start going through the objects..."

From here, I can create test objects from the dll and see if what data is being pulled and confirm it with external sources to make sure it is accurate. The first time I ran it, I found (and corrected) a few missteps on my part. Within the first 30 minutes of running it, I was able to fix problems that would have taken me much longer in the final product. Pretty cool.

IronPython on non-Windows system!

Michael Foord went ahead and replied to my question:

Well, advantages IronPython has over CPython:

* AppDomains (restrict security priveleges of untrusted code)
* Access to .NET / Mono libraries
* Threading without the GIL (scale pure-Python code across multiple cores)
* Easily create applications with multiple isolated Python engines
* Easy to compile applications to binary and make binary distributions
* Much easier to extend with C# than CPython is with C
* Through the DLR you get interoperability with C# / F# / IronRuby / IronScheme...

Some of these are more compelling than others of course, YMMV. :-)

In addition to which IronPython can be used as an easy to embed scripting language for applications written in C#. *If* Mono is useful (which I think it is) *then* IronPython is useful...

This response really does give clarity on what I was trying to understand. Today, I use Ironpython for scripting projects that I need done quickly. I haven't had the chance to explore it further due to time constraints at work (when I get home, I don't wanna think about work :)). I bought the Ironpython book as well to help get me further along the road. So thanks Michael for your insight in this.

They should have these facts posted somewhere on the Ironpython site like a Iron vs C wiki or something like that. If they do, it should be easy to find.

Didn't expect that to happen

It's funny the way things work in life...

A few days ago, I wrote a post on Ironpython on non-windows systems, which is here, where I was trying to understand the benefits of having Ironpython on non-windows systems compared to cPython which is common on most of these systems. I didn't think much of it at the time because it was early in the morning when I wrote it and I figured it wouldn't really go anywhere. Well, I came back a couple days later to actually find comments to that post. I didn't realize anyone read my shit. That was a big surprise to me. The first comment was from guy named Michael Foord (whose name sounded familiar when I first read it) saying:

Because IronPython and IronRuby both work fine on Mono and are just as useful in environments using Mono as they are in environments using .NET.

This statement does make sense to me. I never thought that Ironpython doesn't work on Mono. In fact, I was able to compile Ironpython on my mac using Monodevelop a couple weeks ago which was pretty cool. However, I'm still trying to understand what benefits Ironpython has over cPython in a non-Windows environment. I responded to his comment yesterday in my comments section but I don't think that was the best method. Oh well. Live and learn I guess.

Well, today while at work. I was looking for a book in my desk when I saw the Ironpython in Action book in my desk with the name Foord on the spine. It took me a few minutes to remember where I saw that name before. After it sunk in, I slapped myself in the forehead. And to top it off, when I when to his blog, I found that he put a blurb of what I wrote on his blog. See here... The last thing I expected when I wrote that post was to get a comment and a link from the author of IronPython in Action. How'd that happen?

Just to reiterate. I'm not against Ironpython. I use it at work and it's good at the tasks I throw at it. I'm just trying to understand what benefits it has on a system like Debian or Redhat.

IronPython on non-Windows system?

I was reading a post on Monologue this morning and there was a post getting IronPython & IronRuby into Redhat (I'm assuming the rpm repositories) and it got me thinking about this. My biggest question to this is, WHY?

Don't get me wrong, I use both Python and IronPython at work for various tasks. But at work, I am on a Windows machine. They both have their advantages. With IronPython, the main advantage that I see is its use with the .NET Office Interop libraries for accessing Powerpoint, Word, and Excel for automation work. Yes, Python is capable of interacting with Office too but there is a bit more prep work involved. Other than this, there isn't much that IronPython can do that cPython can't do and vice-versa.

With that said, I go back to my original question. Why port IronPython (or Iron anything for that matter) to a non-Windows system. Both Python and Ruby are already ported to the vast majority of non-Windows systems including some of the lesser known systems. And since Microsoft Office is only on Windows (and Mac but I'm not sure that Mono can or will work with it on a mac), I don't see any reason to bother.

But those of you out there who may be reading this and may be interested in porting something like this for whatever reason, don't let me stop you... ;)