Now diving into IronPython I decided to give blogpingr a GUI. I am lazy, just so you know and using a shell to execute the programm got me bored. Also this probably is a good oportunity to check out how you can use window forms from within IronPython.
Of course credit goes to Borislav Gizdov`s for coming up with blogpingr in the first place. I just hooked his code into IronPython structures.
I still got to add threads to this programm so the methods won`t lockdown the textbox on execution. Maybe I will add some inplace editing functions to add, edit or remove rpc servers from the .conf file. Once that is down I will release the source on this blog. So stay tuned for updates.
Saturday, February 28, 2009
The with statement makes resource initialization and clean up simpler, and it will be nice to start using it throughout the Resolver One code base. It can often be used to replace the use of decorators or explicit try finally blocks, and many objects in the Python standard library have the necessary context manager methods to be used with "with".
Luis Diego Fallas has written a great blog entry demonstrating 'with' with the XML classes provided by System.Xml:
__enter__ and __exit__ methods used by the context mangement protocol, so that he can use with and the XmlWriter for the creation of SVG files.
Friday, February 27, 2009
Various other publishers have been asking around the IronPython community for a while now (including O'Reilly which is ironic given that after promising to come back to me I never heard anything more from them when I first pitched them 2 1/2 years ago - ha! I've been very happy with Manning though and so glad things went the way they did), and finally Apress have announced an IronPython book. In the interests of balance (despite managing to make this blog entry entirely about my book so far) here are the details:
IronPython represents a unique direction for developers interested in working with dynamic languages within the .NET Framework. Whether you’re looking to develop applications from scratch or add functionality and maintainability to an existing application, IronPython opens many doors while providing a high–speed, high–performance language that integrates tightly with other .NET languages.According to Amazon the book will be out in June, in which case we'll beat it by a few months - but unless the book has been in progress for a while it is likely that it will be out later. I've not heard of Alan before and I'll definitely be reading the book when it comes out.
Learn to create applications using the benefits of a dynamically typed language.
Discover how to leverage the power of IronPython to improve existing applications.
Explore interacting with other .NET languages by invoking the common language runtime.
What you’ll learn
Who is this book for?
- Write IronPython console and forms applications.
- Integrate IronPython scripts into existing applications to increase their functionality.
- Implement complex data patterns and interact with databases.
- Use the common language runtime to take advantage of .NET’s existing framework within IronPython scripts.
- Understand how IronPython can be brought in to solve a variety of programming tasks through extensive exercises and recipes.
- Avoid the common pitfalls of working with a dynamically typed language.
This book is designed for .NET developers interested in expanding their IronPython skills and learning how to make use of them to improve their daily programming practices. It will introduce core concepts of IronPython programming using a .NET–centric approach. Additionally, it will speak to Python developers looking to expand into their skills into the .NET world. Experience with a .NET language is expected. Previous Python experience is not necessary.
Alan Harris is a web and application developer living in Arlington, VA. He has worked at more than a few organizations using .NET to create enterprise solutions since the glory days of version 1.1, and can still browse to some of the oldest ones. Aside from working at his desk, he spends most of his time studying Krav Maga and writing music.
Thursday, February 26, 2009
Meanwhile, the Mono guys have been busy creating a Mono version of Silverlight 2 for Linux called Moonlight.
Although Moonlight 2 hasn't yet been released, they are making great progress with it. The latest development version (build instructions here) is capable of running some of my IronPython demos:
Silverlight pages I have a series of articles and simple demos of developing Silverlight applications with IronPython. This includes my Web IDE which is a great tool for interactively exploring the Silverlight APIs and comes with several different demos preloaded. Due to the minor trials of completing IronPython in Action I've only belatedly updated my articles and demos to work with the final release of Silverlight 2:
now both products are at a stable release, it starts to make sense to actually use the technology".
Steve Gilham also blogs on his Tinesware blog, and has posted an example Silverlight app called astroclock written in IronPython:
Astroclock in F#
ArtyProg has also posted some example IronPython code for Silverlight, this one a port of a (very short) demo written by Scott Guthrie from C# to Python:
There are quite a lot of articles about how to use System.Net.Sockets from inside of Silverlight 2.0 with C#. However, I've not found any info on how to do it with IronPython. Here's what I've found out so you can hopefully avoid some of the pitfalls I've encountered:
What we're about to create:
- Silverlight 2.0
- Silverlight Dynamic Languages SDK to develop a Silverlight application with Python
- Python 2.5 or 2.6 to run the TCP server
- Visual Studio 2008 to compile the policy server
- A Silverlight app acting as a client (written in IronPython)
- A TCP server to accept client connections (written in Python)
- A policy server (written in C#)
Wednesday, February 25, 2009
Meanwhile, web2py is a Python web framework (yes, another one) created by Massimo Di Pierro as part of a course he teaches on Python. Amongst other things, it is being used to run the PyCon 2009 registration system.
The latest release of web2py is the recently announced 1.56 (56!?):
- Runs on Jython (although without db drivers)As far as I know web2py is the first Python web framework to include IronPython support out of the box.
- Runs on IronPython (although without CSV, db drivers and internal web-server)
IronPython in Action.
For fellow dilettante Python programmers, I recommend the book “IronPython in Action” by Michael Foord and Christian Muirhead. Soon to be published by Manning (I reviewed a preprint), the book is particularly strong in providing simple-but-not-simplistic illustrations and tables that clarify behind-the-scenes structural elements. Visual Studio screenshots may be a little more common than I’d like, but for those new to the VS environment, these may be welcome.
The cheek, there's maybe four or five screenshots of Visual Studio in total - making it one every hundred pages or so! They're mainly showing the IronPython integration and the designers, but if that is his worst criticism of the book then we've not done too badly. Anyway, he continues:
A common challenge for books involving technologies ported to new environments is balancing viewpoints. A strength of the Foord/Muirhead book is just such a balance, providing “Pythonic” topics such as test-driven development, mocks and metaprogramming, along with clear discussions of .NET’s CLR structure, Windows Presentation Foundation, and even programming PowerShell with Python.
Larry is also a fan of Resolver One, the Python powered spreadsheet created by Resolver Systems. I've been working with Resolver Systems for nearly three years, and it is how I got involved in IronPython, so it's nice to hear people say good things about it:
I can’t praise enough the combination of spreadsheet and programming models embodied in Resolver One: I truly believe that this is one of the best ways to do exploratory programming. Although it’s been 15 years since I’ve worked with fuzzy logic, I was able to put together the not-entirely-rudimentary building blocks of a fuzzy manifold editor (a tool for visualizing the response curve of a fuzzy system) in a matter of hours.
Saturday, February 21, 2009
Mark has been trying to learn Python for a while, and as he is a .NET programmer he found it easier to get into IronPython. His first experiment is a Windows Forms SQLite Administrative UI using System.Data.SQLite. The blog entry shows the code:
The need for this arises because of the lack of built in encryption in SQLite. There are hooks for creating your own, which is what the people who make the ADO.NET Provider, System.Data.SQLite, did. What this means is that the standard SQLite3 command line utility won't open a sqlite database encrypted using the System.Data.SQLite provider. From what I understand, if I REALLY wanted to, I could get the Provider's source and make it so that the SQLite3 library was NOT compiled into the data provider then I could get the library and probably get an existing UI to use it and all would be fine. But where's the fun in that??In this entry he also wonders about which IDE to use. IronPython Studio provides intellisense (autocompletion) for IronPython code, but amongst its deficiencies is the fact that it firmly depends on IronPython 1; making it hard to use with IronPython 2.
Pretty much all this does currently is execute a query against a database. But thats all the functionality I've needed so far so it's all good. This is like 20 minutes of my time but should improve as time passes.
Another thing IronPython Studio does for you is automatically add references to assemblies you're using. This means that projects created with IronPython Studio can't be run 'out of the box' with ipy.exe. In his second entry Mark looks at what you need to do to your code to run it with the IronPython console.
So why am I interested in a book about IronPython? Well I used to do some Python programming a number of years ago and found the language kind of nice to work with. Working with dynamic languages like IronPython relieves you from a lot of the code you have to write just to keep the compiler happy.The rest of the review presents a quick summary of the four parts of the book, with commentary. And his conclusion:
This book is a good read for all .NET developers who want to know about the new trend towards the dynamic languages and IronPython in particular. You get a good explanation what IronPython can do for you and how to go about solving every day programming problems. With the current push towards dynamic behavior, even in languages like C#, every experienced .NET developer should read this book!
Friday, February 20, 2009
He posted the following announcement:
I'm fairly pleased to announce the release of Ironclad v0.8.1; it's not an enormous technical leap above v0.8, but it does now enables you to import and use SciPy and Matplotlib with IronPython on Win32 (with some restrictions; see project page). Downloads of the source and binaries, plus more details, are available at the Ironclad Google Code Project Page -- please do play with it, and let me know if you have any problems.It's a fairly momentous release; the reason that William is only fairly pleased maybe because the release has been eclipsed by him becoming a father! Congratulations William. The list of C extensions that have now been tried with Ironclad has now been extended to:
Ironclad works with IronPython 2 and targets CPython 2.5 on 32-bit Windows; efforts to support other platforms are underway. If you're keen to see Ironclad work with Mono or on 64bit systems then contributions are welcomed!
Ironclad was included in the 1.4 Beta release of Resolver One (our IronPython powered spreadsheet) where it provides the capability of using numpy in the spreadsheet grid and in your spreadsheet user code. We have a 5 minute screencast showing how this works: NumPy in Resolver.
Although a lot of Ironclad is written in C# and uses both the IronPython API and the .NET FFI (Foreign Function Interface - on .NET this is P/Invoke and is what allows you to call into C), there is a core that could be reusable. This is mainly the dll bootstrap (the part that pretends to be the Python C API - which includes some assembly!). Once Ironclad is stable the intention is to factor this out so that other implementations of Python, like Jython and PyPy, only have to reimplement parts of Ironclad to also be able to use Python C extensions.
finally written another blog post! This post is on writing DLR binders, a core part of creating dynamic languages that use the Dynamic Language Runtime. DLR binders define the semantics of your language, and Dino explains them along with some C# example code implementing integer addition:
There’s a few key pieces you need to understand here. First you’re returning an expression tree back to the DLR to tell the DLR what to do. The DLR will compile this expression tree and run it. You’re also returning a set of restrictions. These will be evaluated by the DLR to see if it can re-use the same code for other objects in the future. You’re unlimited in what you can do with restrictions as they can be arbitrary Expression trees. But here I’m simply restricting based upon the arguments .NET types which is one of the most common restrictions. Both the expression tree and restrictions get packaged up in a DynamicMetaObject which is conveniently the same type of object you receive as your arguments.
Finally there’s the hash identity which is how the DLR knows if it can share rules or not amongst different binders. The base DLR binders override GetHashCode/Equals to hash on the operation, member name, etc depending on the binder type so I just return this here.
The article also covers the new language features in C# 4 and VB.NET 10, the focus on concurrent programming and F# (a functional programming language for .NET based on Ocaml) becoming a 'first class' .NET programming language.
Cobra update. Just a few improvements this time, but the language seems to be maturing nicely. It has survived quite a while - and for any new programming language surviving beyond a few months is a major achievement. Cobra is also a Python inspired .NET programming language, with static and dynamic binding and first class support for unit tests and contracts. Like Boo it runs on both .NET and Mono.
System.Data and MySql.Data.MySqlClient). The example reads data from a database and writes it to the console (although why use Console.WriteLine instead of print I have no idea).
last selection we read Darren Hawley's note to self number 6. Note 7 is als on IronPython - and this one is on naming Python modules and more exultation of SciTE as an IronPython editor.
Draw some simple shapes
>>> vi.Draw.Rectangle( 0, 0, 1,1 )
>>> vi.Draw.Oval( 2, 2, 3,3 )
>>> vi.Draw.Line( 4, 4, 5,5 )
Loading data from a CSV file exported from Excel.
The interactive shell extensively uses System.Data.DataTable to store tabular data
>>> data = ( ('Hello',1) , ('World',2) )
>>> datatable = ToDataTable( data )
>>> vi.Draw.Table( datatable )
create a CSV file in Excel
And then load it as a DataTable and let Visio Draw it
>>> datatable = vi.Data.ImportCSV( r"D:\saveenr\data1.csv" )
>>> vi.Draw.Table( datatable )
Of course, you can load an XLSX file. In this case, you’ll have to identify the name of the worksheet also…
>>> datatable = vi.Data.ImportExcelWorksheet( r"d:\\data1.xlsx" , "Sheet1" )
>>> vi.Draw.Table( datatable )
Drawing Hierarchical Data
Let’s draw a tree from a set of directory paths
items.Add( r'c:' )
items.Add( r'c:\windows' )
items.Add( r'c:\windows\system' )
items.Add( r'c:\windows\system32' )
items.Add( r'c:\windows\tasks' )
items.Add( r'c:\program files' )
items.Add( r'c:\program files\office live' )
items.Add( r'c:\baz' )
dir = Isotope.Drawing.CardinalDirection.Down
tree = vi.Data.PathsToTree( items )
vi.Draw.Tree( tree.Root , dir )
Automatic Layout Directed Graphs
Technical Note: the AutoLayoutDrawing class uses Microsoft’s Automatic Graph Layout library
c1 = d.Connect('c1',s1,s2)
c2 = d.Connect('c2',s1,s3)
r = VisioDOM.AutoLayout.AutoLayoutRenderer()
r.RenderToVisio( d , vi.visapp , True)
This was a simple example, you can draw much more complicated diagrams using the autolayout feature.
He also connects the shapes and then programmatically inspects the relationships between the objects:
In this diagram:
Let’s discover this programmatically
- Sheet.1 is connected to Sheet.2
- Sheet.1 is connected to Sheet.3
- Sheet.2 is connected to Sheet.3
- Sheet.2 is connected to Sheet.4
>>> pairs = vi.Connect.GetConnectedShapePairs()
>>> for pair in pairs:
>>> print pair.ConnectedShape0.Name, "is connected to", pair.ConnectedShape1.Name, “by way of”, pair.ConnectingShape.Name
This will print …
Sheet.1 is connected to Sheet.2 by way of Dynamic connector
Sheet.2 is connected to Sheet.3 by way of Dynamic connector.6
Sheet.4 is connected to Sheet.2 by way of Dynamic connector.7
Sheet.3 is connected to Sheet.1 by way of Dynamic connector.8
Using this information and looking up of the line endpoints for the connectors, you can identify create a directed graph. (QED)
Tuesday, February 17, 2009
Extension methods allow you to extend types and interfaces in C# by defining new methods in a *different* assembly. IronPython can only see these extension methods if they are decorated with the ExtensionType attribute.
This is fine if you have access to the source of the extension methods to and can recompile with this attribute. In part II Saveen shows how you can make the extension methods visible to IronPython without having to modify the assemblies containing the extensions - by creating a third assembly:
- The Isotope.IronPythonUtil is an assembly that contains a method CreateIronPythonExtensionMethodAssembly()
- CreateIronPythonExtensionMethodAssembly() loads an assembly from a DLL
- This loads all the assemblies to which that first assembly refers
- It finds all the extension methods in the first assembly
- builds a CodeDOM of all the ExtensionType attributes
- builds a placeholder class (see previous post about the need for this)
- and generates a DLL
- The original code generated a “C#” file and used CodeDOM to compile it to an DLL. This one generates a CodeDOM manually so it is faster to create the Dll.
- The source code is included as an attachment
IronScheme is a 'community-developed' language that also runs on .NET through the DLR. IronScheme includes a Visual Studio plugin (for VS 2008 SP1) and IronScheme 1.0 Beta 2 has just been released.
IronScheme aims to be a R6RS conforming Scheme implementation.
- Added a new LINQ library (ironscheme linq2) which implements all methods found under System.Linq.Enumerable. The new version also uses deferred execution
- Added a few more libraries
- Added (ironscheme unsafe) library
- Many bug fixes
- Added P/Invoke functionality, and a small FFI layer
- Many compiler optimizations added (TCE, lambda body hoisting, assignment elimination), more coming for beta 3!
- Rewrote fixnums and flonums in Scheme. Uses unsafe features.
- Memory optimizations (previous versions had many objects that could not be GC'd), much less GC's needed now
Monday, February 16, 2009
It’s very common for applications to have a way to extend them. Extensibility comes in various ways and have multiple names too – plug-ins, add-ins, addons, etc. It seems, though, that one kind of extensibility was left to the very few – application macros.
The concept is very simple – You don’t need to create a special Dll, implement a specific interface and register it somehow, you don’t even have to install an IDE. All you have to do is to open the relevant window, write some code and voila – you’ve extended the application.
This sample is very simple but it took me about 20 minutes to get it done. It’s just magic!
Of course, I could have simply re-compiled the assembly against the new bits, but that would mean every time I moved to a new version of IronPython, I’d have to recompile. Worse, it would limit my ability to run multiple versions of IronPython on my machine at once. I currently have three – count ‘em, *three* – copies of IronPython installed: 2.0 RTM, nightly build version 46242, and an internal version without the mangled namespaces of our public CodePlex releases. Having to manage multiple copies of my extension assembly would get annoying very quickly.If you're interested in this technique, then you may be interested in my article on a similar subject...
Instead of adding a reference to the compiled assembly, what if I could add a reference to a C# file directly? Kinda like how adding references to Python files works, but for statically compiled C#. That would let me write code like the following, which falls back to adding a reference to the C# file directly if adding a reference to the compiled assembly fails.
Sunday, February 15, 2009
Sylvain Hellegouarch has a Python library called headstock for communicating over XMPP:
For a while IronPython had severe shortcomings that prevented it running simple Kamaelia applications. Today I was able to run a simplechat demo using a vanilla IP2 on Windows with only one single modification to the logging module (thanks Seo). To be honest I didn’t expect it to go through :)
The chat demo is simple enough but means more complex examples using XMPP PubSub will work as well (they are all based on the same framework).
Now this isn’t production ready or anything. For instance the TLS support is broken (hopefully something easy enough to fix) so you won’t be able to connect to Google Talk for now.
Moreover I’m not sure the code is that fast considering how I had to simulate an incremental XML parser atop System.Xml (this allows for a XML stream to be parsed without requiring the full document or even fragment to be read first).
This is a great news for me because it means I’ll be able to move ahead with more work using IronPython 2.
Mark Bloodworth has been experimenting with WPF and IronPython:
Having scanned a few pages, I decided to create a very simple app that included databinding and an event handler. Armed with Notepad++, XamlPad and a command prompt I set out.WPF is also used by Silverlight - which was originally called WPF/E - and is one of the few Microsoft projects to go from a boring codename to an interesting final release name; WPF itself was originally codenamed Avalon. WPF has a new set of controls, although still nothing like as many as Windows Forms, and uses an XML dialect called XAML for describing user interfaces.
First step was a little C#. I created a class as detailed here that adds a little dynamic-ness to WPF.
WPF was new in .NET 3.0, which added several new libraries to .NET 2.0 and is the base version of .NET that comes with Vista. It isn't a new version of the CLR (Common Language Runtime), but instead extends .NET 2.0. Both .NET 3.5 and .NET 2.0 SP1 have been released since .NET 3.0. Although several of the 3.0 libraries are being brought into Mono (see the Olive project), the Mono team have said in the past that they have no interest in porting WPF to run on Mono.
As the Silverlight UI is based on WPF and Moonlight (the Mono Silverlight implementation) is well on the way (Moonlight 1 is released and Moonlight 2 is progressing well) perhaps this decision will be revisited.
Saturday, February 14, 2009
He's posted before on this project, for example his hello world in C#, F# and IronPython article. This entry provides lots more examples (with huge screenshots), this time on using the Powershell and IronPython interactive interpreters to drive Visio:
Demo 1 – Shape formatting
This will launch a new instance of Visio 2007 that is bound to the Interactive session. When Visio launches this way a new doc will be created with a single empty page. It will also load the Basic Shapes stencil – the interactive session depends on this stencil being loaded.
Draw some shapes in visio. Then select them all.
The selection is important – most of the VisioInteractive commands work on the active selection.
in the interactive shell, set the fill foreground color to red
Python: vi.Fill.ForegroundColor = 0xff0000
Powershell: $vi.Fill.ForegroundColor = 0xff0000
Of course through the Dynamic Language Runtime, other Mono supported languages includes IronPython and IronRuby:
After copying the necessary DLLs over to the phone, I was able to run the simple ipy.exe console application that comes with the DLR source code. The neat thing I discovered while perusing through the documentation is that IronRuby and IronPython are actually compiled into CIL byte code and thus eventually native code! Anyhow, as you can see, IronPython is working dandily on the phone.
Friday, February 13, 2009
The top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0. One of many notable areas we’ve improved upon is that float-integer comparisons are now 74% faster than they were in 2.0. A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at: Comparing IronPython 2 and 2.0.1 Performance
A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.
You can download the new release from:
- 20632: can't write a __len__ returning a uint
- 20492: TupleExpression.IsExpandable is internal, should be public
- 20605: Compiling with pyc and PySerial module
- 20616: wrong TypeError message when invoking str.join: implicit parameter 'self' not counted
- 20623: InitializeModule needs to add refs to mscorlib/System
On the desktop ArcMap is used to create map documents (.mxd file), whilst ArcCatalog is used to manage data sources. ArcGIS Server can (amongst other things) serve a map document, as a service for web client, Google Earth or remote ArcMap users.
ArcGIS may be automated to an extent, through an interface known as ArcGIS Geoprocessing. But this covers only some cases, delving deeper provides much greater opportunities.
ArcGIS is built on a COM object library named ArcObjects. Native ArcGIS files, such as an ArcSDE connection (.sde file) are the in memory COM object, serialised to disk as binary. It is difficult to edit or create such files in an automated fashion, without calling ArcObjects.
So, like the Java code CreateSDEConnFile.py calls ArcObjects directly. It can produce an ArcSDE connection file, suitable for ArcCatalog. It works by calling the .NET bindings, through Interop assemblies. Anything that can be done through VBA, or C# should be possible through IronPython.
Lawrence Oluyede is a Python developer who used to do C# development and has also used IronPython. He has been reviewing IronPython in Action, and has posted summaries of all fifteen chapters in Italian as he has read them. You can read all of his summaries from here.
He has now written a review in English. This also summarises the chapters, but is not as long as the Italian entries!
Recently I’ve had the opportunity to read Michael Foord’s upcoming book: IronPython in Action and let me say that I found it extremely interesting, and I suggest it to everybody needing (or wanting) to work with .NET from a dynamic perspective or to .NET developers interested in the world out there.
The book covers a lot of ground, sometimes deeply, sometimes just in the surface but it seems to talk about everything there’s to know to make that ground solid enough to build something lasting.
From the Python introduction to IronPython extension, from IronPython embedding to XML, Visual Studio, testing, metaprogramming, Windows Presentation Foundation (the .NET new UI), system administration, ASP.NET, databases, Silverlight and much more.
I personally found the book very enlightening and there’s much of interesting stuff in there for both Python and .NET developers. I guess it’s the first book on IronPython and anyway it’s a must have for everyone who needs to work on .NET.
It shows there are some unpolished parts with the integration and some differences between CPython and IronPython behavior but it can only become better in the future.
Tuesday, February 03, 2009
Resolver Systems also has exciting news about using NumPy inside the spreadsheet. We have a four minute screencast showing off both of these things:
The spreadsheet part of the screencast uses the new beta version of Resolver One, which is built on IronPython 2:
- We’ve moved over to IronPython 2.0. This brings you some immediate advantages, including bugfixes to the core scripting language, new supported core libraries like urllib2, and support for Python 2.5 syntax in your user code.
- Alpha support for numpy, Python’s flagship number-crunching library. This feature is very much at an “early access” level - but it’s certainly ready enough for you to try and to tell us what we need to add to make it ready for your needs.
- The first steps towards what we call “model-side scripting”. In Resolver One 1.4, you can set cell’s formulae from your button click handlers. While this is a small change in itself, it has big consequences - and should be a big help for people trying to write CRUD applications in Resolver One.
- A major upgrade to our support for statistical calculations, with 24 new statistics functions, from AVEDEV to VAPR.
Sunday, February 01, 2009
think this is the first one in Russian. This article shows how to use IronPython to provide macros for C# .NET applications. The example shows Python scripts adding menu items to a notepad style app.
I'm not sure of all the details, this is the best google translate could manage for part of the article:
Create your tongue + interpretor to him with an opportunity. NET interoperability - non-trivial task, leave it for the enthusiasts.The code is all shown though, so it should be easy to figure it out.
in my quest for a cross-VM (JVM and CLR), single code-base, polyglot language stack, which doesn't involve any more Java than can be helped.
To summarise where we are, and what we have discovered to date --
- Python can call Scala and Java happily
- Java calling into Python is funky and platform dependent; doubly so for Scala
- Scala cannot both call into java.* classes and compile on .net
- Low-level Scala pre-defs differ in the Byte type (signed in Java/J#/Scala-JVM, unsigned in Scala-msil)
- Ruby's predilection for Pascal-case namespaces (fudged in JRuby to match Java's lower-case convention) would require a lot of plumbing around in C# to mate IronRuby to J# or Scala-msil (as the rest of .net uses Pascal-casing).
IDynamicObject interface. Specifically it shows how to implement the GetMember method to provide dynamic behavior for objects declared as dynamic. GetMember is the equivalent of __getattr__ in Python.
OpenBabel (a .NET library described as "The Open Source Chemistry Toolbox") already supports IronPython (example) and Noel O'Blog is looking at explicitly supporting Linux and Mac OS X through Mono.