Tuesday, May 25, 2010

A Good Mix 36: Jim Hugunin, Selenium Two, Embedding IronPython & IronPython with Expression Blend

Another collection of IronPython and DLR related articles from recent weeks.

Jim Hugunin is a bit of a Python veteran. As well as being the creator of two implementations of Python (Jython and IronPython), he also started the Numpy project (back when it was called Numeric). Not long ago he was swallowed by Microsoft, who also took on the development of IronPython and turning it into the Dynamic Language Runtime.

In this video interview Jim explains not only how he got involved in Python, but also what he has been up to recently.
One of the ways that .NET helps you separate your visual design from your application logic is through XAML; an XML based declarative language that can be used with both Windows Presentation Foundation (WPF) and Silverlight.

Naturally there are design tools that will generate XAML. Visual Studio is one of them, but the best one is Expression Blend. XAML has features that make it particularly suited for integration with statically typed languages (statically binding events to your code in your XAML for example), but it can still be used with IronPython - slurping up the XAML dynamically at runtime (including generating or transforming XAML) with the XamlReader.

Simon Segal has been looking at how he can use both Expression Blend and Visual Studio with his IronPython projects:
Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.
...
Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.
By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.



Selenium is probably the best known / most widely used web testing tools and it supports a host of different languages. At Resolver Systems we've used the .NET Remote Control for Selenium from IronPython for quite a while. This article is a tutorial on using Selenium 2 with IronPython and Internet Exploder:
This tutorial is to show how to use the .NET Selenium 2 with dynamic languages that run on the .NET Common Language Runtime. This tutorial uses IronPython.
To complete this tutorial you will need to have IronPython installed and you will also need to download the .NET Bindings from Google Code
This tutorial will not be using the Remote Driver and it will be using the InternetExplorerDriver as this is the only complete browser at the moment that doesn't need to be built from the Repository.
Yes, over the years I've been making entries in this blog we've seen a whole host of blog entries showing examples of embedding IronPython in .NET applications, but it is always fun when another developer discovers just how easy it is:
A requirement I have in an app I am writing is to allow the administrator to set up formulas which can be calculated at runtime. The client app is completely disconnected from Enterprise Core Objects, it uses a (query/command)->response approach so I didn’t want to expose OCL on the client, I also didn’t want to use OCL because I didn’t want arbitrary browsing of the model.
So I have been looking at IronPython – and I like it! I’m not going to go into details of what this code does, I’m just going to paste it so that you may take a look. In short the requirement is for the Admin to be able to retrieve values from the DB by name and perform whatever logic they wish in order to return a decimal result.


Saturday, May 22, 2010

MonoDroid: IronPython on Android?

MonoTouch is a cross-compiler IDE and toolchain for the iPhone OS series. It allows you to write iPhone / iPod Touch / iPad applications with .NET languages like C# and take advantage of nice features of the .NET framework (actually Mono) like the extensive class libraries, proper garbage collection and so on.

Because of the rules against interpreters and code generators MonoTouch didn't include the System.Reflection.Emit apis that are needed for Dynamic Language Runtime languages like IronPython and IronRuby. Despite this restriction  MonoTouch was a victim of the controversial Section 3.3.1 of the iPhone developer agreement that requires iPhone apps to be written in objective-C, C or C++. (Modern developers who prefer the reliability of garbage collection based languages need not apply...)

Apple's main goal seems to be sticking two fingers up to Adobe and banning their Flash cross compiler, but other tools like MonoTouch are collateral damage. If there was ever any doubt about whether you could write iPhone apps in Python (Python and objective-C are both running fine on jailbroken iPhones) that question has been decisively answered. The Adobe Flash cross-compiler does introduce an intermediate layer between your application and the device - the UI won't look and feel native and using any new APIs introduced in OS updates will be dependent on Adobe updating the tool. This is the reason that has been cited as the motivating factor for section 3.3.1. Although MonoTouch has a "runtime" providing some of the .NET features you still compile directly against the iPhone OS APIs: your UI can be native and there is no intermediate layer. Despite section 3.3.1 MonoTouch is still allowed for companies distributing internal apps and not using the app store (something that became possible in a recent OS update), but it's use is now doubtful for general app creation.

Fortunately the iPhone isn't the only game in town, you may possibly have heard of the google mobile OS called Android. Novell, the folks behind Mono and MonoTouch, have been creating an equivalent tool for Android and Miguel de Icaza announced it in a recent blog entry:

We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
Most interesting is their feature list:

  Here is what you can expect from Mono on Android:
  • C#-ified bindings to the Android APIs.
  • Full JIT compiler: this means full LINQ, dynamic, and support for the Dynamic Language Runtime (IronPython, IronRuby and others).
  • Linker tools to ship only the bits that you need from Mono.
  • Ahead-of-Time compilation on install: when you install a Monodroid application, you can have Mono precompile the code to avoid any startup performance hit from your application. 
So, it looks like it will "soon" be possible to write applications for Android using IronPython - great!

Monday, May 03, 2010

adodbapi 2.3.0 (the django version) released

Vernon Cole has announced the release of a new version of adodbapi, a Windows database driver that works with both CPython and IronPython.

  This version is all about django support.  There are two targets:
    A) MS SQL database connections for mainstream django.
    B) running django on IronPython
   Thanks to Adam Vandenberg for the django modifications.


A Python DB-API 2.0 module that makes it easy to use Microsoft ADO for connecting with databases and other data sources using either CPython or IronPython.
This version is highly refactored following the work of Adam Vandenberg, and also has all of the current user suggested patches. Both the Mercurial tree and the downloadable zip files are updated.  (There is no fancy installer, just copy the folder in your site-packages folder.) This has been tested using CPython 2.3, CPython 2.6, IronPython 2.6 (.NET 2) and IronPython 2.6(.NET 4), accessing .mdb, MS-SQL and MySQL databases.  There is a separate .zip for Python 3.1.

Features:
* 100% DB-API 2.0 compliant.
* Includes pyunit testcases that describe how to use the module. 
* Fully implemented in Python.
* Licensed under the LGPL license.
* Supports eGenix mxDateTime, Python 2.3 datetime module and Python time module.
* Supports multiple paramstyles: 'qmark' 'named' 'format'
............
Whats new in version 2.3.0    # note: breaking changes and default changes!
  This version is all about django support.  There are two targets:
    A) MS SQL database connections for mainstream django.
    B) running django on IronPython
   Thanks to Adam Vandenberg for the django modifications.
   The changes are:

1. the ado constants are moved into their own module: ado_consts
      This may break some old code, but Adam did it on his version and I like the improvement in readability.
      Also, you get better documentation of some results, like convertion of MS data type codes to strings:
       >>> ado_consts.adTypeNames[202]
       'adVarWChar'
       >>> ado_consts.adTypeNames[cursr.description[0][1]]
       'adWChar'
  ** deprecation warning: access to these constants as adodbapi.ad* will be removed in the future **

2. will now default to client-side cursors. To get the old default, use something like:
      adodbapi.adodbapi.defaultCursorLocation = ado_consts.adUseServer 
  ** change in default warning **

3. Added ability to change paramstyle on the connection or the cursor:  (An extension to the db api)
    Possible values for paramstyle are: 'qmark', 'named', 'format'. The default remains 'qmark'.
    (SQL language in '%s' format or ':namedParameter' format will be converted to '?' internally.)
    when 'named' format is used, the parameters must be in a dict, rather than a sequence.
       >>>c = adodbapi.connect('someConnectionString',timeout=30)
       >>>c.paramstyle = 'spam'
           <<>>
  ** new extension feature **

4. Added abality to change the default paramstyle for adodbapi: (for django)
    >>> import adodbapi as Database
    >>> Database.paramstyle = 'format'
 ** new extension feature **
 
Whats new in version 2.2.7
1. Does not automagically change to mx.DateTime when mx package is installed. (This by popular demand.)
   to get results in  mx.DateTime format, use:
      adodbapi.adodbapi.dateconverter =  adodbapi.adodbapi.mxDateTimeConverter
2. implements cursor.next()

Saturday, May 01, 2010

SQLite, zlib and XNA

Jeff Hardy has been at it again, and has just done releases of both IronPython.SQLite and IronPython.Zlib - ports of the Python zlib and pysqlite modules to IronPython.
IronPython.Zlib  implements the zlib module for IronPython using ComponentAce’s zlib.net, which is a purely managed implementation of the zlib library. IronPython.Zlib is entirely managed code and works with both 32-bit and 64-bit IronPython. It passes all of the Python 2.6 zlib and gzip tests and most of the zipfile tests.
IronPython.SQLite is a port of pysqlite to IronPython using C#-SQLite, which, similar to zlib.net, is a managed implementation of SQLite. Thus, IronPython.SQLite is also 100% managed code. It passes about 87% of the Python 2.6 sqlite3 tests; the remaining ones are mostly corner cases or rarely used functionality.
Carl Trachte also emailed me about a Japanese blog post on using XNA with IronPython. XNA is the Microsoft game creation framework that runs on the XBox 360 and Windows. 

To run the example code you'll at least need the Microsoft XNA Framework Redistributable installed.
This blog entry is almost entirely a translation of a C# XNA example to IronPython. The C# code is shown commented out alongside the IronPython equivalent. All it does it create a window with a cornflower blue background, but could be a useful introduction to programming XNA.


IronPython Tools for Visual Studio

Visual Studio is the Microsoft IDE for Windows and is virtually ubiquitous as a Windows development tool. Unfortunately Visual Studio has never had good support for languages like Python, which became more of a problem for Microsoft when they developed and released a distribution of Python themselves (IronPython).

Whilst there have been many good IDEs with IronPython support there has until now been lacking from Visual Studio - and adding support has been the highest voted Visual Studio feature request for some time.

Adding good support for a dynamic language to an IDE is very different from supporting statically typed languages. The internals of Visual Studio rely on the static type information for the intellisense, designers, refactoring and so on. However, the IronPython team themselves have come to the rescue and built IronPython integration into Visual Studio 2010:


We are happy to announce the first broadly available release of IronPython Tools for Visual Studio.  IronPython Tools for Visual Studio (IPyTools) is a set of extensions available for Visual Studio 2010 which supports development of IronPython applications.  This release is still an early Community Technical Preview (CTP) and builds upon the preview release that we gave exclusively to attendees of PyCon 2010.  The release has been updated to run on the final version of Visual Studio 2010 and includes many bug fixes, performance improvements, and new features.

This release includes support for Intellisense including member completion, signature help, find all references, and goto definition.  It enables quick browsing of your code using the object browser and the editor navigation bar.  It has an interactive (REPL) window that enables the development of applications in an interactive way.  IPyTools supports lightweight development without a project as well as working with project files in the tradition of Visual Studio .  Opening a .py file causes IronPython Tools to model the code in the containing directory as an implicit project for Intellisense features.   There are project templates for console, WPF, WinForms, and Silverlight applications.  WPF applications support drag-and-drop UI development.  Debugging of Python applications works just like you debug other languages in Visual Studio.

Changes in this release touch on all the major features of IpyTools.  This includes updates to the interactive window, intellisense, the editor, and solutions and projects.  We’ve also made other small tweaks to improve the development experience.

The interactive window is one key focus of IpyTools.  This release continues to flush out the feature set of the interactive window.  We’ve added a new command to send a snippet of code from the editor into the file context containing the module's code.  We’ve added options to control evaluation of partial expressions for live-object intellisense in the REPL.  We’ve updated the key bindings to for explicitly navigating history in addition to the smart behavior of the arrow keys.  Also, the interactive window now supports calls to raw_input() and input().  Finding text in the REPL works now,in addition to a number of other bugs fixed to improve the overall experience.

This release also has many updates to intellisense.  We’ve increased the customization options for intellisense so you can now commit completions using enter.    There is an option to show the intersection or union of applicable members when multiple types can flow through the code where you are using completion.  Related to this, None no longer is considered to be in the intersection of members.  We’ve improved the analysis engine so that it now understands generators, yield expressions, calls to send on a generator, improved analysis of generic method calls, improved tracking of types through calls to list.append/pop/extend/insert, added support for * and ** args, improved analysis of imports, and significantly improved the performance of the analysis engine.  We’ve also cleaned up the display of a number of tooltips including more consistent display of signature completion.  We also better track calls on types vs. calls on instances.  Finally reference tracking has been improved to include accessing methods (not just calls), tracking references to built-in functions, and added support for some protocol methods such as __getattr__.  In addition to this a number of bugs have been fixed.

We’ve also improved the editing experience in this latest release.  This includes support for new commands such as comment/uncomment selection, goto matching brace, support for auto indentation, and highlighting matching braces based upon the current caret location.   We’ve added finer control over the editor experience, adding support for disabling outlining on file open.  And there are a number of small cleanups such as improving goto definition, making goto definition center the target line on the screen, and fixing method outlining which was improperly collapsing in some cases.

Finally we’ve made some small improvements to the solution and project experience.  This includes fixing basic issues such as double clicking on image files now opens them in the VS image editor, project and solutions no longer prompt for saving if they haven’t been modified, and we now properly hide hidden files in the solution explorer.  We’ve also improved the experience when invalid values are entered into project settings.  For the Silverlight templates we’ve fixed the issue where Firefox would be launched when IE was the default browser, and we now search for an empty port when launching Chiron for web projects.

Altogether this represents a significant improvement over the PyCon release in quality and functionality.  But this is still an early preview and as such you may run into issues, and we are looking forward to your feedback both on issues you encounter and the overall feature set.  Please see the spec doc for our current and planned features and feel free to comment on any of the contents.

We are still working on our final licensing terms for IronPython Tools, and as such this release is licensed under a temporary limited use license.  We hope to have nailed down the final licensing terms for the next CTP release.

- The IronPython Team

Updated Dynamic Languages in Silverlight Page

Silverlight is the Microsoft browser plugin that, amongst other things, allows you to run Python and Ruby in the browser with full access to the browser DOM. This is all through the magic of the Dynamic Language Runtime. With either Silverlight or Moonlight installed, the simplest DLR-based application can be contained in a single HTML file:

    <script src="http://gestalt.ironruby.net/dlr-latest.js" type="text/javascript">
</script>

    <script type="text/ruby">
window.alert "Ruby in the browser!"
</script>
    <script type="text/python">
window.Alert("Python works too!")
</script>

The introduction page on the silverlight.net site has now been updated.

Writing Silverlight applications in Ruby, Python, and other DLR-based languages only requires a local web server, a text editor, and a browser which supports Silverlight on Windows or Mac OS, or Moonlight on Linux systems.
The page has full details of how to get started with using Python and Silverlight including several examples and example applications.

Supported browsers include IE, Safari, Firefox and Chrome.