This project has moved. For the latest updates, please go here.
 IronPython Blog News Feed 
Monday, March 17, 2008  |  From IronPython Blog

The Dynamic Language Runtime powers IronPython and IronRuby. It contains the following features:



  • Hosting APIs - allows embedding of any DLR language as a scripting language inside of a host application
  • Extensions to LINQ ExpressionTree - allows language compilers to generate higher level constructs instead of MSIL
  • DynamicSite - call-site caching to speed up the performance of dynamic languages
  • ActionBinder - utility code to facilitate .NET interop
  • IDynamicObject - interface for dynamic objects
  • Other compiler utility code

Mailing lists


You can currently ask questions on the IronPython (link) and IronRuby (link) mailing lists. There is currently no dedicated DLR mailing list. We are looking into it. Similarly, the sources for the DLR are bundled with the IronPython and IronRuby sources.


Specs, whitepapers,etc


http://msdn2.microsoft.com/en-us/magazine/cc163344.aspx - MSDN article on IronPython and DLR by Bill Chiles. It talks about DynamicSite and ExpressionTrees


http://compilerlab.members.winisp.net/dlr-spec-hosting.doc - Hosting API spec


http://langnetsymposium.com/talks.asp - Recordings of Lang.Net talks


Team Blogs


http://blogs.msdn.com/mmaly - Martin Maly, DLR dev (detailed discussion on DLR ASTs)


http://www.iunknown.com/ - John Lam, IronRuby PM (IronRuby and general blogs)


http://blogs.msdn.com/ironpython - IronPython team blog


http://blogs.msdn.com/hugunin - Jim Hugunin, DLR and IronPython architect (IronPython and dynamic language issues)


http://blogs.msdn.com/dinoviehland - Dino Viehland, IronPython dev


http://blogs.msdn.com/srivatsn - Srivatsn Narayanan, IronPython QA


http://devhawk.net/ - Harry Pierson, IronPython PM


http://blogs.msdn.com/jmstall/ - Mike Stall, DLR dev


http://jimmy.schementi.com/blog - Jimmy Schementi, Dynamic Silverlight PM

http://knowbody.livejournal.com/ - Dave Fugate, IronPython QA

DLR languages


http://codeplex.com/IronPython - IronPython


http://ironruby.rubyforge.org/ - IronRuby


http://blogs.msdn.com/jscript/archive/tags/Managed+JScript/default.aspx - Managed JScript


http://www.codeplex.com/IronScheme - IronScheme


http://www.codeplex.com/IronLisp - IronLisp


http://www.codeplex.com/Nua - Nua (Lua)


Other links


http://dynamicsilverlight.net/ - DLR for Silverlight 2


http://www.dotnetguru.org/us/dlrus/DLR2.htm - A walk-through of implementing a sample language MyJScript on top of the DLR.


http://www.codeplex.com/DLRScript - Using DLR languages in the Script tag in a HTML page


http://www.bitwisemag.com/2/DLR-Build-Your-Own-Language - A getting-started guide about implementing a new language using the DLR


http://www.codeplex.com/DlrPad - Script XAML with DLR languages


http://www.codeplex.com/chameleon - Use DLR languages with CGI

Monday, March 17, 2008  |  From IronPython Blog

The Dynamic Language Runtime powers IronPython and IronRuby. It contains the following features:



  • DynamicSite - call-site caching to speed up the performance of dynamic languages
  • Hosting APIs - allows embedding of any DLR language as a scripting language inside of a host application
  • Extensions to LINQ ExpressionTree - allows language compilers to generate higher level constructs instead of MSIL
  • ActionBinder - utility code to facilitate .NET interop
  • Other compiler utility code

Blogs


http://blogs.msdn.com/ironpython - IronPython team blog


http://blogs.msdn.com/hugunin - Jim Hugunin


http://www.iunknown.com/ - John Lam


http://blogs.msdn.com/mmaly - Martin Maly


Mailing lists


You can currently ask questions on the IronPython (link) and IronRuby (link) mailing lists. There is currently no dedicated DLR mailing list. We are looking into it. Similarly, the sources for the DLR are bundled with the IronPython and IronRuby sources.


Specs, whitepapers,etc


http://msdn2.microsoft.com/en-us/magazine/cc163344.aspx - MSDN article on IronPython and DLR by Bill Chiles. It talks about DynamicSite and ExpressionTrees


http://compilerlab.members.winisp.net/dlr-spec-hosting.doc - Hosting API spec


http://langnetsymposium.com/talks.asp - Recordings of Lang.Net talks


Other links


http://dynamicsilverlight.net/ - DLR for Silverlight 2


http://www.codeplex.com/DLRScript - Using DLR languages in the Script tag in a HTML page


http://www.codeplex.com/IronScheme

Monday, February 25, 2008  |  From IronPython Blog

We are bumping up our investment in these exciting new languages, and have openings for dev, test, and PM positions. Here are the job descriptions: 


 


Dev<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>


IronPython: http://members.microsoft.com/careers/search/details.aspx?JobID=8BEEE2C2-A95D-41C6-9075-CF6347EE07F1


IronRuby: http://members.microsoft.com/careers/search/details.aspx?JobID=7C2E33E8-5A9C-44F3-A1CE-DA2D66DC3C8B 


F#: http://members.microsoft.com/careers/search/details.aspx?JobID=85EDB9E1-4EBD-407A-BA59-969005AF5EA8


<o:p> </o:p>


Test (contact YAlvi at microsoft.com for more information)


IronRuby: http://members.microsoft.com/careers/search/details.aspx?JobID=FF36A073-D1E8-49A9-B942-AFA4AB2B437E


F#: http://members.microsoft.com/careers/search/details.aspx?JobID=8152347E-A14B-4F18-8440-A1CEE68EE357


<o:p> </o:p>


PM (contact MaheshP at microsoft.com for more information)


IronPython: Link not yet available


<o:p> </o:p>


Drop us a line if you are interested.

Monday, June 18, 2007  |  From IronPython Blog

Here they are:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>


<o:p> </o:p>


1.      Dev315 - IronPython and Dynamic Languages on .NET<o:p></o:p>


a.      mms://techedmsftwm.fplive.net/techedmsft/2007/DEV315.wmv <o:p></o:p>


2.      Web324 - Dynamic Languages on the Web<o:p></o:p>


a.      mms://techedmsftwm.fplive.net/techedmsft/2007/WEB324.wmv <o:p></o:p>


<o:p> </o:p>


thanks,
Mahesh<o:p></o:p>

Monday, June 18, 2007  |  From IronPython Blog

At TechEd, I (MaheshP@Microsoft.Com) said we'll make the demos available on our blog. Here they are:


 


Robotics Studio demos:



Powershell demo (tho I did not get to this):  



 


ASP.NET control for client script:


·         http://blogs.msdn.com/dmitryr/archive/2007/05/04/dynamic-client-script.aspx the blog entry has a ZIP file attached. It does not contain ‘fractulator’.


·         Fractulator is available at http://www.codeplex.com/dynamicsilverlight/Release/ProjectReleases.aspx?ReleaseId=3809


o   Download ipy-fraculator.zip


<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>


Web Services samples are available only for IronPython 1.x at:


·         http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=47


o   download IronPython-1.0.1-Samples-WebServices.zip

Monday, June 11, 2007  |  From IronPython Blog

I'll be posting the samples from TechEd 2007 later this week and wanted to let you know that this is still on my mind (tho it has slipped from EOD Monday) :)


Mahesh

Friday, May 25, 2007  |  From IronPython Blog

We have three very exciting talks (below) at TechEd 2007 in Orlando. In addition we are dynamic languages booth that will have folks from the team that can demo/answer questions you may have. Join us at TechEd!

WEB06-TLC - Developing Data Driven Applications Using the New Dynamic Data Controls in ASP.NET
    Tuesday, June 5 4:30 PM - 5:45 PM, Blue Theater 14 
Speaker(s): Mahesh Prakriya, Qing Ye
Track(s): Web Development and Infrastructure
Level: 300
ASP.NET dynamic data controls are part of a powerful, rich new framework that lets you create data driven ASP.NET applications very easily. ASP.NET dynamic data controls do this by automatically discovering the schema at runtime, deriving behavior from the database and finally creating an ASP.NET page. Anything that can be inferred from the schema works with almost no user effort. If needed, the page can then be further customized either by using static languages such as Microsoft Visual C# or Visual Basic .NET or dynamic languages such as IronPython, Visual Basic, Jscript, etc. In this talk, we show you how to build rich, database driven Web applications from scratch, such as TaskList along with other demos.
 
 
WEB324 - Dynamic Languages on the Web
    Thursday, June 7 9:45 AM - 11:00 AM, N220 F 
Speaker(s): Mahesh Prakriya, Dmitry Robsman
Track(s): Web Development and Infrastructure
Level: 300
After attending this talk you will learn how to use dynamic languages (such as IronPython, Jscript, VBx and IronRuby) in Silverlight and ASP.net. ASP.net and Silverlight are two great example hosts of Dynamic Language Runtime (DLR) and the languages listed above are implemented on DLR. We will first demo in Silverlight, then asp.net and will end with a combined demo of the two!
 
DEV315 - "IronPython" and Dynamic Languages on .NET
    Friday, June 8 10:45 AM - 12:00 PM, S210 B 
Speaker(s): Mahesh Prakriya
Track(s): Developer Tools and Technologies
Level: 300
"IronPython" is the codename for a new implementation of the Python programming language on the .NET Framework. IronPython is fast—in fact, up to 1.8 times faster than Python-2.4 on the standard pystone benchmark. It supports an interactive interpreter with fully dynamic compilation as well as static compilation to produce pre-compiled executables. It's well integrated with the rest of the framework and makes all .NET libraries easily available to Python programmers. This session shows how IronPython brings the power of .NET to Python and the power of Python to .NET. At OSCON 2004, the first public release of IronPython was announced. This session demonstrates the latest IronPython version in a range of situations from using GUI frameworks to driving Microsoft Office applications to working with a variety of external libraries. We also discuss other scripting languages on .NET.
 

Thursday, January 04, 2007  |  From IronPython Blog

We've discovered one issue caused by VS SP1 installation recently. After having upgraded to SP1, IronPython disappeared from language dropdown when trying to create a new web project.

The issue is due to a registry key for IronPython under NewProjectTemplate was removed by VS SP setup. Adding it back fixes the problem. To do that, the easiest way is to uninstall and then reinstall "IronPython for ASP.NET CTP".

This happens to Visual Web Developer SP1 as well. Similar work-around applies.

Note, you don't have to do anything if your IronPython web project still shows up after upgrading.

Thursday, October 19, 2006  |  From IronPython Blog

There are few upcoming talks that I’d like to announce: <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

First, at the ASP.Net Connections in Vegas, David Ebbo is giving a talk that'll be worth attending and will cover how to use IronPython in ASP.Net applications.<o:p></o:p>

AMS301: Developing ASP.NET Web Applications with IronPython
David Ebbo
IronPython is a new fast implementation of the Python programming language running on the .NET Framework. While it stays true to the beauty and simplicity of the Python language, IronPython offers Python programmers seamless access to the richness and power of .NET libraries and applications in a fully dynamic environment as well as static compilation to produce pre-compiled assemblies. This session focuses on utilizing the IronPython dynamic language to quickly build full-featured ASP.NET Web applications. You will learn how to use IronPython to add rich scripting support to existing .NET applications and extend new applications with custom Python code. We will also demonstrate how IronPython can be used to combine a wide variety of .NET components and services. This talk is targeted at Python programmers looking to take advantage of the power of ASP.NET and at ASP.NET programmers looking to learn how Python can make building Web applications easier. <o:p></o:p>

Overall agenda is at: http://www.devconnections.com/shows/aspfall2006/default.asp?c=1&s=82 <o:p></o:p>

Second, I’ll be giving two talks at Teched Europe in Barcelona. <o:p></o:p>

Nov 9th, 11:45am: Dev206: IronPython and .NET Scripting Languages<o:p></o:p>

'IronPython' is the codename for a new implementation of the Python programming language on the .NET Framework. IronPython is fast – in fact, up to 1.8 times faster than Python-2.4 on the standard pystone benchmark. It supports an interactive interpreter with fully dynamic compilation as well as static compilation to produce pre-compiled executables. It's well integrated with the rest of the framework and makes all .NET libraries easily available to Python programmers. This session shows how IronPython brings the power of .NET to Python and the power of Python to .NET. At OSCON 2004, the first public release of IronPython was announced. This session demonstrates the latest IronPython version in a range of situations from using GUI frameworks to driving Microsoft Office applications to working with a variety of external libraries. We also discuss other scripting languages on .NET.<o:p></o:p>

Nov 9th, 5:30pm: DEVWD26: ASP.NET: Developing ASP.NET Web Applications with IronPython<o:p></o:p>

description is same as above for David's web talk..

Thanks,

Mahesh Prakriya

Monday, October 02, 2006  |  From IronPython Blog

This sample, written by Lee Culver, provides a step-by-step, comprehensive tutorial on creating graphical applications using managed DirectX API(s) from IronPython. It will teach you how to:

  • Load and render DirectX meshes
  • Position, rotate, and move objects
  • Auto-track objects with cameras

The readme.htm in the download (download page: IronPython-1.0-Samples-Direct3D.zip) is quintessential to understanding this sample. It is written in tutorial format and walks you through various exercises that teach you DirectX API manipulation and usage. You do not need prior knowledge of DirectX or WinForms to follow the tutorial, although having some basic Python knowledge is highly advisable. By the time you finish with the tutorial, you should be able to comfortably work with basic Direct3D classes from Python.

Monday, October 02, 2006  |  From IronPython Blog

This sample shows developers how to create .NET executables directly out of IronPython scripts. The readme.htm in the download (download page: IronPython-1.0-Samples-Pyc.zip) will get you started.

IronPython’s Hosting APIs can be used to compile Python scripts into DLLs, console executables, or Windows executables. The pyc.py script included in this tutorial leverages these hosting APIs and can be used to compile other Python scripts. It provides a variety of flags such as the ability to specify the target platform of the .NET assembly (e.g., x64).

While the assemblies produced by the IronPython Hosting APIs are true .NET assemblies, the dynamic nature of the Python language makes it difficult to use these from other .NET languages. In short, this means that attempting to import Python types into other .NET languages such as C# is not recommended.

Thursday, September 14, 2006  |  From IronPython Blog

This sample shows how to use PowerShell commands from IronPython by invoking the PowerShell API(s) directly and also by using a nice Python helper class. The samples use both of these techniques to detect whether a host meets some of the minimum system requirements for playing Age of Empires III Trial edition.  The readme.htm in the download (download page: IronPython-1.0-Samples-IPPowerShell.zip) will get you started.

By utilizing managed PowerShell API(s) from IronPython, it becomes downright easy to perform a runtime inspection of the system. As an example, you can determine how much memory your video card has installed on it using only a couple lines of IronPython code. To make working with PowerShell even easier, the “powershell.py” module (included with this sample) allows you to run PowerShell cmdlets in a very elegant and object-oriented manner.

Thursday, September 14, 2006  |  From IronPython Blog

This sample, written by Brad Dodson, is a music player written in IronPython that uses DirectShow, Windows Presentation Foundation, and COM Interop.  The readme.htm in the download (download page: IronPython-1.0-Samples-IronTunes.zip) will get you started.

When launched, IronTunes presents you with a graphical interface from which you can load any number of music files and begin playing them.  Further, you can search through your loaded music collection by typing inside the search field and see your playlist filtered as you type.  IronTunes provides the basic playback functionality (play, pause, volume control) by using DirectShow COM APIs from IronPython via COM interop.

Thursday, September 14, 2006  |  From IronPython Blog

This sample, written by Matt Gruskin, is a frequency modulation synthesizer that uses DirectX and System.Windows.Forms.  The readme.htm in the download (download page: IronPython-1.0-Samples-FMsynth.zip) will get you started.

In the FMSynth UI you can quickly generate tones by clicking on the provided piano keyboard or take more control by specifying a precise frequency and wave type.  You can combine several carrier and modulator wave forms together to form more complex musical sounds and effects.  You can save your “synth” in an XML file.  FMSynth also comes with several sample synth files in the “synths” subfolder which you can load and experiment with.

Thursday, September 14, 2006  |  From IronPython Blog

This sample written by Ravi Chugh is an IronPython program that builds on top of System.Windows.Forms to create a fun slide puzzle game using maps.  The readme.htm file in the download (download page: IronPython-1.0-Samples-Puzzle.zip) will get you started.  The puzzle game comes with several maps (games) that you can start with.  If you want more challenging maps, Slide Local gives you the ability to choose or create your own map to play with.

The map tiles the program uses are pulled from Virtual Earth tile servers using the System.Net APIs.  If the caching option is selected, all downloaded map tiles are saved to the file system, allowing tiles to be rendered much faster the second time around.  Enabling caching also allows you to continue to play games when you don’t have a network connection.  Keep an eye on the size of the cache folder though since there is no size limit.

Thursday, September 14, 2006  |  From IronPython Blog

This utility written by Jocelyn Turcotte is an IronPython program that leverages Windows Presentation Foundation (WPF) and System.Windows.Forms to create a handy utility that graphically displays disk usage information.  The readme.htm file in the download (download page: IronPython-1.0-Samples-DiskUse.zip) will get you started.

When the application is first launched, a file dialog prompts you to pick a base directory.  This is the directory that will be analyzed.  Once a base directory is chosen, the application scans the file system to retrieve the names and sizes of subdirectories and files.  The utility displays the directory and file information with a treeview in the left pane and a graphical presentation of the relative file size information in the right pane.

Thursday, September 14, 2006  |  From IronPython Blog

This tutorial, written by Martin Schray, consists of a set of IronPython programs that show how to use the Windows controls found within System.Windows.Forms. These IronPython tutorial programs vary greatly in functionality and include:

  • Several “Hello World” applications showing how to leverage core Windows forms classes
  • An application with an embedded web browser
  • A small application based on Windows MapPoint Web Services that provides a map, given a location
  • Another application based on MapPoint that lets the user get a route map given start and end points

The tutorial.htm file in the download (download page: IronPython-1.0-Samples-WinFormsMapPoint.zip) will get you started.  This sample builds from simple "Hello World" applications to a web browser application and finally to a mapping application.

Thursday, September 14, 2006  |  From IronPython Blog

The screen cast videos of the various speakers at the Lang.Net 2006 Compiler Symposium are now available: http://www.langnetsymposium.com/speakers.asp

Thursday, September 14, 2006  |  From IronPython Blog

For a great introduction to IronPython and its integration with the .NET Framework and Libraries, please take a look at James Schementi’s article on MSDN - http://msdn.microsoft.com/msdnmag/issues/06/10/CLRInsideOut/<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

Tuesday, September 05, 2006  |  From IronPython Blog

IronPython is a project that implements the dynamic object-oriented Python language on top of the CLI.  IronPython is both well integrated with the .NET Framework and is a true implementation of the Python language.  .NET integration means that this rich programming framework is available to Python developers and that they can interoperate with other .NET languages and tools.  All of Python’s dynamic features (such as, an interactive interpreter and the ability to dynamically modify objects) are available.

If you're curious about the interesting history of IronPython, see Jim Hugunin's blog.  

Grab IronPython 1.0 today! 

 IronPython Blog News Feed 

 MSN Search: ironpython site:http:\/\/spaces.live.com\/ News Feed 

On behalf of the IronPython team, I'm happy to announce the final release of IronPython 2.7.4.

Wednesday, February 19, 2014  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

Now with the link to the release :) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday ...

Hello IronPython Community, We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be the first release of IronPython built upon a common dynamic language ...

Tuesday, February 04, 2014  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

This is the seventh release of IronPython Community Edition (IPCE). Download from SourceForge: http://sourceforge.net/projects/fepy FePy project aims to provide ...

Saturday, January 04, 2014  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

Even when I created them (IronPython.slvx > from IronPython.*.dll and Microsoft.Scripting.slvx from > Microsoft.Scripting.*) it still does not work.

Wednesday, January 01, 2014  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

Hello Python Community, The IronPython and Dynamic Language Runtime teams are proud to announce the release of IronPython 2.0 final. IronPython 2.0 is the culmination ...

Tuesday, December 31, 2013  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

This is the sixth release of IronPython Community Edition (IPCE). Download from SourceForge: http://sourceforge.net/projects/fepy FePy project aims to provide ...

Thursday, December 19, 2013  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

And I was completely wrong :) The change was to no longer wrap LCG delegates inside a MultiCast delegate removing the overhead of calling through the multicast delegate.

Thursday, December 05, 2013  |  From MSN Search: ironpython site:http:\/\/spaces.live.com\/

Thanks Dino, I think you're right about the second one - it looks like a misunderstanding on our part at some point. I'll remove it from our test suite!

 MSN Search: ironpython site:http:\/\/spaces.live.com\/ News Feed 

 Technorati Search for: ironpython News Feed 
Sunday, April 05, 2009  |  From Technorati Search for: ironpython

Two podcasts on IronPython and dynamic languages on the .NET framework have gone live recently. .NET Rocks: Michael Foord Talks IronPython In this podcast I have a fifty minute conversation with the .NET Rocks guys on IronPython and dynamic languages in general. I'm even nice about Ruby! Apparently the .NET Rocks podcast has around 300 000 (!) regular listeners, so it was great to be able to promote Python and the book to the .NET community. CodeCast Episode 13: IronPython and Dynamic La

Friday, April 03, 2009  |  From Technorati Search for: ironpython

En el evento MIX09 realizado por Microsoft el mes pasado, se anunció la versión 1.0 de ASP.NET MVC .   Se trata de un framework que permite construir aplicaciones web de forma sencilla aplicando el patrón Model/View/Controller .  Según los entendidos, este framework de Microsoft implementa mejoras al estilo Ruby on Rails y Django en ASP.NET, permite además programar con completo control sobre el HTML generado, y facilita el uso de pruebas unitarias y la aplicación de un proceso de des

Thursday, April 02, 2009  |  From Technorati Search for: ironpython

IPY4SPD is a new project on Codeplex by Nathan Freeze - the iLoveSharePoint guy. It integrates IronPython scripting capabilities with SharePoint and made a release on March 31st. The tag line for the project is fun. The project page has some screenshots demonstrating how to use it. IPY4SPD - IronPython for SharePoint Designer Workflow IPY4SPD - When the need to get it done overwhelms the need to do it right! This project adds IronPython script activities to Sharepoint Designer allowing

Thursday, April 02, 2009  |  From Technorati Search for: ironpython

We've had a great time at PyCon and I'm still here in Chicago on the last day of the sprints. The whole event, from language summit through conference through sprints, was pure awesomeness and IronPython was right at the centre. There is also exciting news about IronPython in Action, but all of this will have to wait. In the meantime there are a couple of IronPython events happening soon : Geek Night @ Thoughtworks: IronPython, Ruby in C#, DVCS 4th April Geek Night at Thoughtworks. Three

Tuesday, March 31, 2009  |  From Technorati Search for: ironpython

Then you should check Mike Swanson’s blog post here . He has two batch files, the first downloads all MIX session recordings with in the format you like, the second renames them so it is easier to make sense of all the media file names. If you just want a list of all sessions with download links this page might be the thing for you. So much better than downloading them by hand. Not as good as going to the MIX itself but if you, like me, couldn’t go it is still a nice way to see all the

Monday, March 30, 2009  |  From Technorati Search for: ironpython

  .NET / Visual Studio Visual Studio 2010 Architecture Edition (Alexander Jung) The M Programming Language – Part 3 – Primer to MGrammar (Bart de Smet) Practical Oslo Examples Starting to Emerge… (Brian Loesgen) An IronPython Profiler (Curt Hagenlocher) WinForms - Change The Active Tab (Dave M. Bush) F#: Forcing type to unit for Assert.ShouldThrow in XUnit.NET (Mark Needham)   Design / Methodology / Testing Pitfalls for software architects (Simon Brown) Op

Monday, March 30, 2009  |  From Technorati Search for: ironpython

Si bien un plugin para navegadores de Microsoft puede que resulte algo extraño para un desarrollador PHP, existen muchas características de Microsoft Silverlight que lo hacen una buena alternativa para estas tecnologías. Por empezar, está diseñado para funcionar no sólo en Internet Explorer sino también en todos los grandes navegadores. Además es una herramienta poderosa para crear aplicaciones que pueden ir mucho más allá de las capacidades estándares del CSS y el HTML. Silverlight s

Monday, March 30, 2009  |  From Technorati Search for: ironpython

Last week, my RSS feeds were spinning wildly out of control. I’ve added feeds for all sorts of off-the-wall projects in the hope that I can deliver a wider variety of news. I’ve learned that some blog and wiki platforms are easily hacked; nothing like seeing the name of a feed becoming “You’ve been HACKED!” to drive that home. Lesson to developers: Close those stupid holes in your code — now!asp:menu patched to be standards and IE 8 compliantApparently, one of the standard ASP.NET WebControls (a

Monday, March 30, 2009  |  From Technorati Search for: ironpython

The SQLBits IV conference was very interesting, I’m now looking forward to the team behind the event releasing the videos of the sessions so I can see some of the sessions which clashed with others I was interested in. Software IronPython 2.6 Alpha 1 - Harry Pierson announces the release of IronPython 2.6 Beta 1 which further closes the gap in performance between IronPython and CPython Prototype 1.6.1 RC2: IE 8 Here we come - Ajaxian highlights the release of a second release candid

Sunday, March 29, 2009  |  From Technorati Search for: ironpython

Over the years the inadequacy of Ruby’s main implementation has led to the creation of several alternatives. The greatest common divisor between these is an attempt to improve the performance of Ruby, both in terms of time and space. But every Ruby implementation has another, deeper reason for being. For example, Ruby 1.9.1 is a refactoring of the language that provides the chance to incorporate several much needed features into a relatively fast virtual machine, whereas JRuby’s truest value lie

Saturday, March 28, 2009  |  From Technorati Search for: ironpython

  Web Development ASP.NET MVC Training Kit (MS Downloads) JavaScript for C# programmers: convert string to integer (Julian M. Bucknall) Tip #45: Did you know…How to change the DynamicData folder location? (Deepak Verma) Tip #46: Did you know… that Web Deployment “migrate” operation is “sync” operation with all migration rules enabled? (Kateryna Rohonyan) Tip #47 Did you know… that front page script remote debugging requires turning off IE’s Enhanced Security Configuration i

Friday, March 27, 2009  |  From Technorati Search for: ironpython

Microsoft Robotics Developer Studio 2008 Academic Edition Wi Microsoft.Robotics.Developer.Studio.2008.Academic. Edition.WinAll.Retail.PROPER-CRD nfo: Code:                                                                 ÜÜ                                                                            ßßÜ                                                                            Û                                                                          ÞÛ                     

Thursday, March 26, 2009  |  From Technorati Search for: ironpython

Dave Fugate has just announced the release of IronPython 2.6 alpha 1. IronPython 2.6 Alpha 1 Download Page There is also a page comparing performance of the IronPython release with Python 2.6.1. The performance shows a degradation because the new adaptive compilation techniques are very much a work in progress: IronPython 2.6a1 Performance The announcement: We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new

Thursday, March 26, 2009  |  From Technorati Search for: ironpython

  Design / Methodology / Testing Aspects Of Domain Driven Design (Vinay) Mockup design (Daniela Panfili) Getting serious about your meeting problem (Seth Godin) Scrum Gathering Agile Architecture Talk (Mike Cottmeyer) Isolate the data not just the endpoint (Mark Needham)   Silverlight / WPF Silverlight 3 and SEO (Brad Abrams) Virtual Earth Silverlight: Using MouseClick Event To Add “Pushpins” (Chris Pietschmann) XAML in .NET 4 Update (Rob Relyea) Silve

Wednesday, March 25, 2009  |  From Technorati Search for: ironpython

Amazon’s announcement for today, with timing presumably associated with EclipseCon, is an AWS toolkit for the Eclipse IDE . Eclipse, which is an open-source project under the aegis of IBM (who also offers a commercial version), is one of the most popular IDEs (the other is Microsoft Visual Studio). Originally designed for Java applications, it has since been extended to support many other languages and environments. Integrating with Eclipse is a useful step for Amazon, and hopefully other

Wednesday, March 25, 2009  |  From Technorati Search for: ironpython

Amazon’s announcement for today, with timing presumably associated with EclipseCon, is an AWS toolkit for the Eclipse IDE . Eclipse, which is an open-source project under the aegis of IBM (who also offers a commercial version), is one of the most popular IDEs (the other is Microsoft Visual Studio). Originally designed for Java applications, it has since been extended to support many other languages and environments. Integrating with Eclipse is a useful step for Amazon, and hopefully other

Wednesday, March 25, 2009  |  From Technorati Search for: ironpython

Software AgDLR 0.5 - Harry Pierson highlights the release of AgDLR 0.5, which is an integration between the Dynamic Language Runtime languages and Silverlight. These languages are currently IronRuby and IronPython, and this release includes support for Silverlight 3 beta Spice up your IE with spicIE - Writing IE7/8 Plugins in managed code in minutes (beta) - Greg Duncan highlights spicIE, a framework that makes it easy to create plug-ins for Internet Explorer 7 and 8 in Managed code

Wednesday, March 25, 2009  |  From Technorati Search for: ironpython

It has been a little over a year since we shipped VS 2008 and .NET FX 3.5.   Since then the team has been heads-down focused on the next version of our product line with VS 2010, VSTS 2010 and .NET FX 4.0.   In addition, we have been working on a number of interesting technologies that we have updated you with in various forms.   I have always been a big believer of continuous innovation and the work we have done in the last year to deliver ongoing value proves that.   Just last week, I

Tuesday, March 24, 2009  |  From Technorati Search for: ironpython

Sarah Dutkiewicz is the Coding Geekette , a .NET developer who also like Python and has presented at many .NET community events on IronPython. Sarah is speaking at PyCon 2009 on FePy , the community distribution of IronPython: Pumping Iron into Python: Intro to FePy . In a recent blog entry she reviews IronPython in Action : The Coding Geekette's Book Reviews: IronPython in Action Overall, I would recommend IronPython in Action for anyone wanting to learn IronPython. The examples in t

Tuesday, March 24, 2009  |  From Technorati Search for: ironpython

As you can see, the Intellipad editor that comes with the Oslo SDK can also be customized, including the color scheme used by the editor: The experience right now, however, is… not the best. You have to jump through 2 different hoops: Edit the ClassificationFormats.xcml file that is found in the Intellipad\Settings directory of your Oslo SDK installation. Write code (in IronPython, fortunately) to change stuff

 Technorati Search for: ironpython News Feed 

 ironpython - Google News News Feed 
Tuesday, September 26, 2017  |  From ironpython - Google News


Reinsurance News (registration)

Guy Carpenter enhances capital & hours clause modelling with MetaRisk 10
Reinsurance News (registration)
MetaRisk incorporates open-source IronPython scripting with its proprietary MetaRisk ModelBuilder to offer a better user experience and improved speed and efficiency, as well as enabling “hours clauses” modelling. It creates models via loading ...

Monday, September 25, 2017  |  From ironpython - Google News


Guy Carpenter Advances Capital Modeling Capabilities with MetaRisk® 10
GC Capital Ideas
While automation is not new to the platform, MetaRisk 10 builds on prior advances by incorporating innovative open-source IronPython scripting with its proprietary MetaRisk ModelBuilderTM to offer a better user experience (UX) and unparalleled speed ...

Monday, September 04, 2017  |  From ironpython - Google News


搜狐

谁说不能用Python开发企业应用?
搜狐
更进一步的编译过程,如果有的话, 取决于运行时环境, 不管是CPython,PyPy,Jython/JVM,IronPython/CLR,或是其它的进程式虚拟机(process virtual machine)。参考谬误#6 来了解更多。 一条在PayPal 以及其它地方的通用 ...

and more »

Tuesday, August 22, 2017  |  From ironpython - Google News


Хакер

А ты знал? 10 фактов о Python
Хакер
NET и CORBA (Common Object Request Broker Architecture). Для Java-разработчиков есть Jython — версия Python для JVM. Разработчики .NET могут воспользоваться Python for .NET или IronPython — реализацией Python для .NET от Microsoft.

Tuesday, August 22, 2017  |  From ironpython - Google News


Хакер

А ты знал? 10 фактов о Python
Хакер
NET и CORBA (Common Object Request Broker Architecture). Для Java-разработчиков есть Jython — версия Python для JVM. Разработчики .NET могут воспользоваться Python for .NET или IronPython — реализацией Python для .NET от Microsoft.

Monday, August 14, 2017  |  From ironpython - Google News


The Spokesman-Review

Beneath gray skies, Blue Waters Bluegrass Festival rolls on
The Spokesman-Review
After their set was finished, the band received a standing ovation, and several people immediately ran over to purchase copies of the book, which tells the story of Cotton Kingfisher, a “drifter and buck wild iron python rider,” according to the book's ...

Monday, August 14, 2017  |  From ironpython - Google News


The Spokesman-Review

Beneath gray skies, Blue Water Bluegrass Festival rolls on
The Spokesman-Review
After their set was finished, the band received a standing ovation, and several people immediately ran over to purchase copies of the book, which tells the story of Cotton Kingfisher, a “drifter and buck wild iron python rider known along the rails as ...

Monday, July 31, 2017  |  From ironpython - Google News


Le sei cose da sapere su Python
01Net
... modificano il linguaggio in sé ma lo corredano già in partenza di alcuni tool, caratteristiche e librerie per lo sviluppo in ambiti specifici. Alcuni esempi sono Anaconda per il machine learning, IronPython per gli ambienti .Net, Jython per gli ...

Tuesday, July 25, 2017  |  From ironpython - Google News


【資策會】Emgu CV影像處理與電腦視覺應用(台北8/30)
HiNet 新聞社群
... (中央社訊息服務20170725 17:57:46)EmguCV是一套.Net封裝OpenCV(Open Source Computer Vision)的影像處理開發套件,裡面包含許多影像處理、機械學習演算法及電腦視覺(Computer Vision)應用所需的函式庫(Library)。使用者透過本身熟悉的程式語言( ...

Thursday, July 20, 2017  |  From ironpython - Google News


All You Need to Know about Python | ReadItQuik
Read IT Quik
There are a number of options to work on, depending on the purpose of using Python.

and more »

Monday, July 17, 2017  |  From ironpython - Google News


Langages de développement : Java et .NET dominent toujours
Silicon
NET réside toutefois dans sa capacité à accepter de multiples langages de programmation. Dès ses débuts, C# (3,5 % des suffrages Tiobe, 5e) et Visual Basic .NET (3 %, 7e) se sont partagés la vedette. D'autres solutions sont accessibles : F#, IronPython ...

Sunday, June 18, 2017  |  From ironpython - Google News


Huffington Post Deutschland

Python Programmierung
Huffington Post Deutschland
Nehmen wir das Fazit vorweg, das Buch ist mächtig ! Wahnsinnig mächtig. Zum Python lernen für Einsteiger fast schon zu mächtig. Das Buch hat alles, was man über Python wissen will in sich. Ich habe schon einige Pythonkurse und Einführungen in Python ...

Monday, May 08, 2017  |  From ironpython - Google News


InfoWorld

Python 2 forever: 3 projects that will keep Python 2 alive
InfoWorld
The dormant IronPython project implemented a Python runtime on the .Net framework's Common Language Runtime. It's since kicked back to life after project oversight was handed off to different team members, and work has been proceeding at a snappy ...

Tuesday, April 18, 2017  |  From ironpython - Google News


Opensource.com

Grok the GIL: How to write fast and thread-safe Python
Opensource.com
I'll show examples to help you grok the GIL. You will learn to write fast and thread-safe Python, and how to choose between threads and processes. (For the sake of focus, I only describe CPython here—not Jython, PyPy, or IronPython. CPython is the ...

Monday, April 03, 2017  |  From ironpython - Google News


entwickler.de (Blog)

C# 6.0 und Visual Basic 14 in älteren .NET-Projekten
entwickler.de (Blog)
Dynamische Programmierung erleichtert die Arbeit mit COM-Objekten und die Zusammenarbeit mit dynamischen .NET-Sprachen wie IronPython. Zudem gibt es auch Situationen im Programmieralltag, wo dynamische Programmierung eine willkommene ...

Tuesday, March 21, 2017  |  From ironpython - Google News


PyPy2.7 e PyPy3.5 v5.7 estão disponíveis para download
iMasters
O PyPy é uma alternativa a outros interpretadores como CPython, Jython e IronPython. O novo PyPy2.7 inclui o upstream stdlib versão 2.7.13, e o PyPy3.5 (o primeiro na série 3.5) inclui o upstream stdlib versão 3.5.3. Segundo o anúncio oficial, a equipe ...

Tuesday, March 21, 2017  |  From ironpython - Google News


SYS-CON Media (press release)

Java vs. Python: Which One Is Best for You?
SYS-CON Media (press release)
Other groups have created their own implementations, such as IronPython, which is written in C# and offers close integration with the .NET runtime. Python is a general-purpose language built around an extensible object model. Its object-oriented core ...

and more »

Wednesday, February 08, 2017  |  From ironpython - Google News


InfoQ.com

Machine Learning and End-to-End Data Analysis Processes in Spark Using Python and R
InfoQ.com
Introduction to Machine Learning with Python · Google Solves CPython's Concurrency Issues with Grumpy · Python 3.6 Brings Better Dictionaries, Improved Async I/O, and More · New Leadership for IronPython · Scripting Eclipse with Python. Related Vendor ...

Sunday, January 08, 2017  |  From ironpython - Google News


Techworm

Transpile And Run Python Code Into Go Program With Google's Open Source 'Grumpy'
Techworm
The company's front-end server for YouTube and its YouTube API are mainly written in Python, and run on CPython 2.7, as opposed to other implementations (Jython, PyPy, or IronPython). The project began out of a need to improve Python execution on ...

Friday, January 06, 2017  |  From ironpython - Google News


Googles Grumpy oversætter Python til Go for at løse samtidighedsproblem
Version2
Det er Google selv, der står bag Go-sproget, og derfor er det oplagt for Google at basere en Python-oversætter på netop Go. CPython er skrevet i C, men er blot én af mange implementeringer af Python, hvor eksempelvis Jython er skrevet i Java og ...

 ironpython - Google News News Feed 

 Jim Hugunin's Thinking Dynamic News Feed 
Tuesday, April 14, 2009  |  From Jim Hugunin's Thinking Dynamic

I'm quite excited that IronPython in Action is published.  I had the chance to write the foreword to this book and wanted to share it here as well.

ironpythoninaction

Foreword to IronPython in Action

IronPython brings together two of my favorite things, the elegant Python programming language and the powerful .NET platform.

I've been a fan of the Python language for almost 15 years, ever since it was recommended to me by a fellow juggler while we passed clubs in a park.  From the start I found Python to be a simple and elegant language that made it easy to express my ideas in code.  I'm amazed by Python's ability to appeal to a broad range of developers from hard-core hackers to amateur programmers including scientists, doctors, and animators.  I've been teaching my ten year old son to program and even he tells me that, "Python is a great language to learn with."  Beyond teaching my son, I've tried to contribute back to the Python community that gave me this great language and continues to drive it forward.  Prior to IronPython I started both the Numeric Python and Jython open source projects.

It took a quite bit longer for me to become a fan of Microsoft's .NET platform and the Common Language Runtime (CLR) that forms its core execution engine.  I first learned about the CLR by reading countless reports on the web that said it was a terrible platform for dynamic languages in general and for Python in particular.  IronPython started life as a series of quick prototypes to help me understand how this platform could be so bad.  My plan was to prototype for a couple of weeks and then write a pithy paper titled, "Why the CLR is a terrible platform for dynamic languages".  This plan was turned upside down when these prototypes turned out to run really great – generally quite a bit faster than the standard C-based Python implementation.

After getting over my initial skepticism, I've grown to love the CLR and .NET as much as Python.  While no platform is perfect, this is the closest that we've ever come to a universal runtime that can cleanly support a wide variety of different programming languages.  Even more exciting to me is that the team is committed to the multi-language story and we've got great projects like the DLR, IronRuby and F# to keep extending the range of languages that can coexist on this platform.   I've even grown to like C# as by far the most enjoyable and versatile statically typed programming language I've used.

As the architect for IronPython, I like to believe that it's such a simple and elegant combination of the Python language and the .NET platform that it needs no documentation.  After all, who could possibly not know that they should use clr.Reference to pass an out parameter to a .NET method.  Well, I guess that it's assumptions like that one that make me a poor choice for writing a book teaching people about IronPython.  The best choice for writing a book like this would be a long-term user who's deeply engaged with the community and who has been trying to understand and explain the system to others for years.

Now, if only we could find such a person…

I first met Michael Foord in July of 2006.  I was preparing an IronPython talk for the OSCON conference in Portland, Oregon.  This was going to be an exciting talk where I'd announce that the final release of IronPython-1.0 was weeks away.  Of course, this was a terrible time to be preparing a talk since my mind and time were occupied with all the details of the actual release.  To further complicate things for me, this was the Open Source Convention, and I knew that I needed to show IronPython running on Linux to have true credibility with this audience.  Unfortunately, I didn't have the time to setup a Linux box and get some useful demos running.  Oddly enough, I also found that my coworkers (at Microsoft) didn't have any spare Linux boxes running in their offices that I could borrow for a few screen shots.

I did a desperate internet search for "IronPython Linux" and one of the places that led me was a blog called voidspace.  There I found a tutorial teaching how to use Windows Forms with IronPython.  The reason this tutorial showed up was that it included screen caps of the samples running under both Windows and Linux.  This was just what I was looking for!  By stealing these pictures for my talk I could both show people IronPython running on Linux and also point them to an excellent online tutorial to help them learn far more about using IronPython than I could ever cover in a 45 minute talk.

I had a few hesitations about including this reference in my talk.  I didn't know anything about the author except that his screen name was Fuzzyman and he had a personal blog that was subtitled, "the strange and deluded ramblings of a rather odd person."  However, I really liked the simple tutorial and I was incredibly happy to have some nice Linux samples to show the OSCON crowd.  I was most grateful at the time to this person that I'd never met for helping me out of this jam.

Fuzzyman turned out to be Michael Foord and one of the authors of the book you have in your hands now.  Since that first online tutorial, Michael has been helping people learn to use IronPython through more online samples, presentations at conferences and through active contributions to the IronPython users mailing list.  I couldn't think of anyone better to show people how to get started and how to get the most out of IronPython.

I've spent my career building programming languages and libraries targeted at other developers.  This means that the software that I write is used directly by a small number of people and it's incredibly hard for me to explain to non-developers what I do.  The only reason this kind of stuff has value is because of the useful or fun programs that other developers build using it.  This book should give you everything you need to get started working with IronPython.  I hope it will make your development more fun or at least more productive.  Now go out and build something cool.

Tuesday, April 14, 2009  |  From Jim Hugunin's Thinking Dynamic

I'm quite excited that IronPython in Action is published.  I had the chance to write the foreword to this book and wanted to share it here as well.

ironpythoninaction

Foreword to IronPython in Action

IronPython brings together two of my favorite things, the elegant Python programming language and the powerful .NET platform.

I've been a fan of the Python language for almost 15 years, ever since it was recommended to me by a fellow juggler while we passed clubs in a park.  From the start I found Python to be a simple and elegant language that made it easy to express my ideas in code.  I'm amazed by Python's ability to appeal to a broad range of developers from hard-core hackers to amateur programmers including scientists, doctors, and animators.  I've been teaching my ten year old son to program and even he tells me that, "Python is a great language to learn with."  Beyond teaching my son, I've tried to contribute back to the Python community that gave me this great language and continues to drive it forward.  Prior to IronPython I started both the Numeric Python and Jython open source projects.

It took a quite bit longer for me to become a fan of Microsoft's .NET platform and the Common Language Runtime (CLR) that forms its core execution engine.  I first learned about the CLR by reading countless reports on the web that said it was a terrible platform for dynamic languages in general and for Python in particular.  IronPython started life as a series of quick prototypes to help me understand how this platform could be so bad.  My plan was to prototype for a couple of weeks and then write a pithy paper titled, "Why the CLR is a terrible platform for dynamic languages".  This plan was turned upside down when these prototypes turned out to run really great – generally quite a bit faster than the standard C-based Python implementation.

After getting over my initial skepticism, I've grown to love the CLR and .NET as much as Python.  While no platform is perfect, this is the closest that we've ever come to a universal runtime that can cleanly support a wide variety of different programming languages.  Even more exciting to me is that the team is committed to the multi-language story and we've got great projects like the DLR, IronRuby and F# to keep extending the range of languages that can coexist on this platform.   I've even grown to like C# as by far the most enjoyable and versatile statically typed programming language I've used.

As the architect for IronPython, I like to believe that it's such a simple and elegant combination of the Python language and the .NET platform that it needs no documentation.  After all, who could possibly not know that they should use clr.Reference to pass an out parameter to a .NET method.  Well, I guess that it's assumptions like that one that make me a poor choice for writing a book teaching people about IronPython.  The best choice for writing a book like this would be a long-term user who's deeply engaged with the community and who has been trying to understand and explain the system to others for years.

Now, if only we could find such a person…

I first met Michael Foord in July of 2006.  I was preparing an IronPython talk for the OSCON conference in Portland, Oregon.  This was going to be an exciting talk where I'd announce that the final release of IronPython-1.0 was weeks away.  Of course, this was a terrible time to be preparing a talk since my mind and time were occupied with all the details of the actual release.  To further complicate things for me, this was the Open Source Convention, and I knew that I needed to show IronPython running on Linux to have true credibility with this audience.  Unfortunately, I didn't have the time to setup a Linux box and get some useful demos running.  Oddly enough, I also found that my coworkers (at Microsoft) didn't have any spare Linux boxes running in their offices that I could borrow for a few screen shots.

I did a desperate internet search for "IronPython Linux" and one of the places that led me was a blog called voidspace.  There I found a tutorial teaching how to use Windows Forms with IronPython.  The reason this tutorial showed up was that it included screen caps of the samples running under both Windows and Linux.  This was just what I was looking for!  By stealing these pictures for my talk I could both show people IronPython running on Linux and also point them to an excellent online tutorial to help them learn far more about using IronPython than I could ever cover in a 45 minute talk.

I had a few hesitations about including this reference in my talk.  I didn't know anything about the author except that his screen name was Fuzzyman and he had a personal blog that was subtitled, "the strange and deluded ramblings of a rather odd person."  However, I really liked the simple tutorial and I was incredibly happy to have some nice Linux samples to show the OSCON crowd.  I was most grateful at the time to this person that I'd never met for helping me out of this jam.

Fuzzyman turned out to be Michael Foord and one of the authors of the book you have in your hands now.  Since that first online tutorial, Michael has been helping people learn to use IronPython through more online samples, presentations at conferences and through active contributions to the IronPython users mailing list.  I couldn't think of anyone better to show people how to get started and how to get the most out of IronPython.

I've spent my career building programming languages and libraries targeted at other developers.  This means that the software that I write is used directly by a small number of people and it's incredibly hard for me to explain to non-developers what I do.  The only reason this kind of stuff has value is because of the useful or fun programs that other developers build using it.  This book should give you everything you need to get started working with IronPython.  I hope it will make your development more fun or at least more productive.  Now go out and build something cool.

Wednesday, October 29, 2008  |  From Jim Hugunin's Thinking Dynamic

clip_image002

I’m at the Microsoft Professional Developer conference in sunny LA where I’ve given an overview talk on the DLR. This was the first talk I’ve given on the DLR where I was able to really dig into some of the technical details underneath and paint a hopefully coherent picture of how the key features fit together. Prior to my talk, Anders Hejlsberg delivered an amazing talk on the Future of C# which he shows for the first time how we’ve added dynamic typing to that language with a static type called ‘dynamic’ – yes, you read that right. This work is all built on top of the DLR, and I’d strongly recommend it as great viewing prior to my talk.

Tuesday, May 15, 2007  |  From Jim Hugunin's Thinking Dynamic

I'd like to take a detour from discussing the DLR's type system to start talking about implementation. I hope that this will make it easier to talk about some difficult questions like what is the right meta-model for the DLR type system. Let's start by compiling the traditional factorial function for a DLR-based language - using JavaScript for today.

function factorial(n) {
    if (n <= 1) {
        return 1;
    } else {
        return n * fact(n - 1);
    }
}

The JavaScript compiler will take this code and compile it into the following tree form and pass the tree to the DLR. 

The key implementation trick in the DLR is using these kinds of trees to pass code around as data and to keep code in an easily analyzable and mutable form as long as possible. Anyone who's programmed in Lisp or Scheme knows this trick extremely well. Much more recently, this idea has resurfaced as one of the central features in C# 3 and VB.NET 9 that enable LINQ. Linq uses these "expression trees" to capture the semantics of a given block of code in a sufficiently abstract way that it can be optimized to run in different contexts. For example, the DLINQ SQL interfaces can convert that code into a SQL query that will be optimized by the database engine on the back-end. More radical projects like PLINQ are exploring how to take these same kinds of trees and rearrange the code to execute in parallel and on multiple cores when possible.

When we started building the DLR we knew that we wanted a shared tree form, but we believed that we wanted purely untyped and late-bound nodes in the tree that would always use dynamic actions for their operations. This matched what we had for IronPython where the only typed node in the tree was the ConstantExpression - which had the type of whatever its constant value was. Because our trees were untyped, we didn't believe that they shared much in common with the always strongly typed expression trees in C# 3 and we went about designing these trees as something completely independent.

As we started adding more language implementations, we found that it was difficult to capture different languages idiosyncratic concepts in the DLR tree. Examples of this range from Python's print statement to JavaScript's regular expression literals. We needed to support these language features, but we couldn't add explicit support for them into our trees.  Well, clearly we could have added explicit support for them in the tree, but where would that have ended? Ultimately, if the DLR is going to be successful it will have to be general enough that language implementations can represent their own concepts clearly even if there is no direct DLR equivalent.

For Python's print statement, we knew that IronPython already compiled this into a call to a static method that handled all of the implementation details of printing in Python - including the dreaded softspace. We could support this by adding a static method call node to the DLR tree and by converting the Python print statement into a static method call to this helper method. Similarly, when we went to support the special Python constant for an ellipsis, "...", we knew that the existing IronPython implementation compiled this into a static field access of the singleton ellipsis instance. We could support this by adding a static field access node to the DLR tree and converting the Python ellipsis instance into one of these nodes.

Pretty soon we realized that the nodes that we were adding mapped directly onto the statically typed and bound expression tree nodes from C# 3. This was a good thing, since it meant that there was less for us to create from scratch and more opportunity for us to steal from existing ideas. The DLR trees today in theory include all of the expression tree nodes from C# 3 and add to them several additional kinds of nodes to handle dynamic operations, variables and name binding, and control flow. If you look at the code you'll notice that in fact we only support a subset of the C# 3 nodes and that our APIs don't exactly match the existing expression trees. This is simply an artifact of our late realization that these trees were so closely related and we're now in the process of reconciling our trees with the existing expression trees.

The value of having dynamic languages target this tree form is that we can perform lots of optimizations in the DLR layer on behalf of the language implementations. Some of these optimizations include variable storage where we can often optimize local variables as CLR local variables that can be JITed into machine registers - but where we can also detect explicit meta-programming such as Python's locals() function or JavaScript's arguments feature and fall back to slower and more explicit storage mechanisms such as tuples or object fields when needed. Similarly for the dynamic action nodes we can use different implementation techniques to optimize these important but potentially slow operations.

This post is already too long and it's been over a week since my last post.  I'm going to finish up for today and save any more details about the optimizations we perform on these trees for the future. For those of you looking at code, the DLR trees can be found in Microsoft.Scripting.Ast.

Friday, May 04, 2007  |  From Jim Hugunin's Thinking Dynamic

The core of the DLR's type system is based on passing messages to objects. This isn't exactly a new idea, but focuses on what has always been the intellectual core of object-oriented systems. This simple notion doesn't explicitly talk about types at all, but instead focuses on objects and messages. Every dynamic and static language has its own notion of what a type is - from C#'s static single-inheritance types to Python's dynamic multiple-inheritance types to JavaScript's prototypes. Trying to reconcile all of these different systems at the type level is ridiculously complicated - although maybe something to tackle for DLR v2. Despite their differences at the type level, all of these languages share tremendous commonalities if you view them at the object-based message-passing level.

In order to support a broad range of languages in this kind of a type system, we need to have a standard set of clearly defined messages that all objects can respond to. The set needs to be rich enough to capture all of the unique properties of the different languages that we're working with while at the same time be sufficiently common so that code written in different languages can work together. This is a balance that I'm sure we're going to need to adjust as we bring more languages to the DLR - but I think we have an excellent start and lots of success with our initial four languages. Here is our current set of operations:

  • [Get|Set|Delete]Member(name, case-sensitivity) - gets, sets or deletes a named member on an object
  • Call/CreateInstance(argument modifiers) - standard call or 'new' call to an object with arguments.  Modifiers include parameter names, support for expanding argument list or keyword dictionaries and a marker for an argument representing an implicit this.
  • SimpleOperation(OperationKind enumeration) - catch-all for simple common operations like add and subtract as well as indexing, etc.
  • Convert(Type) - converts an object to a given static type if possible

Given this set of messages, we also need to have some mechanisms in place to allow objects of different types to respond to these messages. While the DLR lets developers treat objects uniformly whether they come from a static or a dynamic language, under the hood we need to use different mechanisms to implement this message passing for the two different cases.

Standard CLR static types

When an object is of a Type as defined by a statically typed language, the object's behavior is completely described by this Type. We use the runtime Type of the object to determine the correct behavior. For example, with the GetMember message, this will mean looking for a field, property or method with the given name on the object's Type and returning the approriate member for the object if found and otherwise throwing an exception.

The DLR will use all of the existing well known attributes specified in the Common Language Subset (CLS) in order to map members of a type onto a DLR operation. For example, we'll recognize add operator methods to use when responding to an add message. In addition, we will make standard objects behave as expected, for example, any delegate object will respond properly to a Call message.

In addition to these existing well-specified operators, the DLR adds some additional custom attributes that effectively extend the existing set of CLS operations to include support for overriding standard DLR messages. A good example of this is the static attribute that will let a type override member lookup to respond to a GetMember message. This lets a static type support name-based lookup when it is being called from a dynamic language. In our current DLR hosting work, we've found several excellent places to use this attribute. One good example is the FindControl method on page objects. With this attibute we can make working with pages feel more natural to a dynamic language:

page.FindControl("text1") --> page.text1

In fact, we use a slightly more complicated method to override the GetMember behavior of the ASP.NET page objects. We can't modify the actual types because we want to run on existing shipping versions of ASP.NET. This means that we need to extend these types externally. To do this we build on the new feature of extension methods that was added to C#3 and VB9 as part of the suite of features that support LINQ. Extension methods let developers define methods to be added to a type outside of the definition of that type itself. These extension methods can be imported like a standard namespace and will then behave as if they were originally defined on the types that they apply to.

The DLR uses a slightly extended version of extension methods. First, we add support for properties and operator methods. Second, we allow extension methods to be provided at other scopes than just the per-file scope used by C# and VB.NET. For example, we allow languages to choose to apply extension methods to a given type for all code written in that language. This is the way that we support the standard Python methods on core CLR types such as string so that Python programmers can call "s.title()" even though System.String has no method with that name. This same mechanism also allows us to support special Python members on objects such as "__class__" or "__getitem__" by modifying the view of the type from Python code - rather than modifying the type itself. This lets all of our languages that want to use an immutable string object share the same actual instances freely while using extension methods to customize the view of that type to be appropriate to each language.

Fully dynamic types

For types that are defined by a dynamic language, we provide a more dynamic way to respond these messages. These dynamic types will implement a special interface - IDynamicObject - that can provide customized handling for all dynamic operations. One of the key steps in implementing a dynamic language on the DLR is to implement this interface for the standard object type used by a given language. This means that the IronPython implementation implements this interface on Python-defined classes to support the correct dynamic behavior following Python's rules for multiple inheritance and method resolution order. Similarly, the DLR-based JavaScript implementation implements this interface on JavaScript functions/objects in order to implement the correct prototype-based inheritance for that language. Each language doesn't need to know anything about the details of the type system in the other languages, but just needs to know what messages to pass to those objects and counts on the other languages correctly implementing their side of the contract.

One very obvious thing missing from the current DLR is a standard default implementation of this interface. This would be useful to people who wanted to implement simple scripting languages on the DLR who weren't trying to precisely match the semantics of an existing language. This would also be useful for libraries that wanted to create a generic expando object to pass to consumers. I expect that we'll provide this in the future, but at the moment our attention remains focused on the cases where we need to capture the exact semantics of existing dynamic languages where the interface approach provides the needed flexibility.

Obvious things that we haven't gotten to yet

A few obvious questions at this point may be how the different languages can both use these standard messages and yet retain all of the details of their own unique semantics. The simple trick here is that while the messages are standard, each language has to decide which messages to pass for a given piece of source code. This gives sufficent flexibility - although I expect you'll want to hear more details about that. The second obvious question may be that the mechanisms as described above sound awfully slow with a lot of introspection and interface calls going on at runtime. This description tries to capture the semantics of message passing in the DLR - not the implementation. It's the DLR's job to make this run fast and we're quite confident that we do this well today and will keep doing better for many tomorrows, but there's a much bigger explanation owed here as well.

Note for those wanting to explore the source code

I'd still caution most people to wait a few months to really dive into these bits as our design is actively being refactored and documentation is still mostly non-existent. However, if you'd like to look at the code you can find the DLR bits in the IronPython 2.0alpha1 release under the Microsoft.Scripting and Microsoft.Scripting.Vestigial projects. In case it's not obvious, the one with "Vestigial" in its name isn't expected to be around for much longer. The set of standard messages described in this post are found in the Microsoft.Scripting.Actions namespace - where these "messages" are called "Actions". The interface IDynamicObject is currently misnamed. The current version of that interface will soon be removed and the oddly named interface IActionable will be renamed to IDynamicObject. For now, you should look at IActionable.

Wednesday, May 02, 2007  |  From Jim Hugunin's Thinking Dynamic

I'm very excited by the level of interest that I'm seeing from folks who want to better understand what the DLR is all about. I'm also sorry that we don't have a fully documented detailed story for you today. If you want a detailed whitepaper and documented APIs, you're going to have to wait a while.  If you're happy with source code and blog entries, then you can start messing about today. And if you just want to play with working code, download the silverlight bits and start exploring what you can do on top of the DLR with Python and JavaScript together today.

I'm starting my design notes blogging today with my first entry on the dynamic type system that is one of the three key components in the DLR - and the one that I think is most important.  The corner-stone of the DLR is support for a shared dynamic type system. This lets these dynamic languages easily and naturally talk to each other and share code. Equally important is that we want these dynamic languages to be able to work with the existing powerful static languages on the platform such as VB.NET and C#. We want to ensure that the huge wealth of both existing and to-be-written libraries designed for .NET all just work from dynamic languages. There's a standard pattern for achieving this kind of interoperability through wrappers and marshaling layers. Here's the pattern as I implemented it for Jython - Python running on the JVM.

Notice that with this pattern that the Python types exist in their own little world (they are in orange) and for every underlying type I need to put the objects into a Python-specific wrapper. This standard pattern is okay if you're only interested in supporting a single language. In my example above, so long as I'm only writing Python code then all of my objects will be PyObjects and they'll all work great together with all the Python-specific information on them. Where this pattern really breaks down is when you want to support integration with multiple languages.  In this case every time an object moves from one language to another it needs to be unwrapped from the source language and then rewrapped appropriately for the destination.  This can obviously have performance issues as these wrapper objects are created and discarded for any cross-language calls.

The wrapper approach can also have deeper problems. One challenge is just to figure out what object to pass. For example, if Python has a PyString and it calls a C# function that expects an Object, should it pass the PyString or should it unwrap it into a String? These kinds of subtle type issues never have a good answer. Even worse are the nasty problems that can be caused by loss of object identity when objects are silently wrapped and unwrapped behind the programmers back. 

This wrapper pattern is also the same one used by most of the popular dynamic languages implemented in C as well. When implementing a dynamic language in C, these kinds of wrappers make a lot of sense because a C pointer doesn't have any useful runtime type information so you need to decorate it with a layer that can provide the runtime type information that's needed. However, managed runtimes like the CLR provide rich type information for their standard objects, so it should be possible to use those objects directly without the confusion and cost of wrappers and marshalling. We exploit this in the DLR, and this is the type system that we actually use.

This means that all of the objects in the DLR are exactly the same as the objects in the CLR. We're adding capabilities to better support common dynamic operations, but we're still deeply rooted in the powerful existing libraries and languages on .NET. We need to have a single unified type system without marshaling and wrapper layers between our languages if we're going to have truly seamless integration between them.

Now that I've reached the end of this first entry, I fear that it might be a little unsatisfying. All that I've explained so far about the dynamic type system is that it uses exactly the same objects and metadata that are already used by the statically typed objects already running in the CLR.  Well, I'm not going to let that stop me from pushing this to the web today.  More details about how we get a dynamic type system into the CLR without wrapper layers will have come next.

Wednesday, May 02, 2007  |  From Jim Hugunin's Thinking Dynamic

First, my apologies for not posting my first entry on the type system yesterday. I was completely wiped out after preparing and delivering this talk and then talking to all the interested people here at MIX. For those of you who aren't at MIX, you can see a video of John's and my talk.

Also, for those of you who want a more frequently updated blog from an expert on the DLR, be sure to read John's blog.

Monday, April 30, 2007  |  From Jim Hugunin's Thinking Dynamic

Today, at MIX 07, we announced a new level of support for dynamic languages on .NET that we're calling the DLR.

From the beginning, Microsoft's .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR).  The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling.  Sharing these features has two huge benefits for languages on the CLR.  First, it's easier to implement a language because lots of difficult engineering work is already done for you.  Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

The CLR has good support for dynamic languages today.  IronPython-1.0 demonstrates this.  The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better.  It adds to the platform a set of services designed explicitly for the needs of dynamic languages.  These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code.  With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET.  More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

The DLR is about giving you the best experience for your language - true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system. It lets developers share code regardless of the language the code is implemented in and to use whatever language they prefer regardless of the language preferred by the environment they want to run in. Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration.  This means that developers building browser-based applications can now use their preferred language even for client-side code.

We're initially building four languages on top of the DLR - Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

In addition to the Silverlight release, we've also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License. All of that code can be downloaded today as part of the IronPython project at codeplex.com/ironpython. If you want to know more about the DLR, you should feel free to download the code.  However, you should understand that this is a very early release of these bits and we still have significant work left to do including refactoring, design changes, performance tuning - not to mention documentation.

For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community.  If you're building a language on top of .NET and are interested in supporting dynamic language features then we want your feedback on the DLR. However, I'd discourage you from trying to implement on top of the DLR today. I don't want you to get frustrated trying to work with these really early bits and then not be interested in working with us when we're better prepared to engage with the language community. We plan to kick off a broader engagement with language implementers at the upcoming lang.net conference in three months - at the end of July.  This will be the best place to really engage with the DLR and let us know what we got wrong.

In the meantime, I'll be using this blog to post our design notes for the DLR as they're written and any feedback you have on the design is welcomed. Tomorrow I'll talk more about the shared dynamic type system and the "One True Object".

Tuesday, September 05, 2006  |  From Jim Hugunin's Thinking Dynamic

I’m extremely happy to announce that we have released IronPython 1.0 today!

I started work on IronPython almost 3 years ago.  My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages.  I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages.  About 9 years ago I’d built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython.  This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use – testified to by the large number of Java projects that incorporate Jython today.

I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM.  My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages".  My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR – in many cases noticeably faster than the C-based implementation.  For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.

The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages.  At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into.  I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation.  After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.

The first few months at Microsoft were a challenge as I learned what was involved in working at a large company.  However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place.  The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform.  We began to take advantage of the great new features for dynamic languages already shipping in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

We were also able to release IronPython publicly from Microsoft with a BSD-style license.  In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project.  This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better.  We've had countless excellent discussions on the mailing list on everything from supporting value types to calling overloaded methods.  Without the drive and input of our users, IronPython would be a much weaker project.

IronPython is about bringing together two worlds.  The key value in IronPython is that it is both a true implementation of Python and is seamlessly integrated with the .NET platform.  Most features were easy and natural choices where the language and the platform fit together with almost no work.  However, there were challenges from the obvious cases like exception type hierarchies to the somewhat esoteric challenges concerning different methods on strings. We spent long days and sometimes weeks looking for the best answers to these challenging problems and in the end I think that we have stayed true to both Python and .NET.

To drive our Python compatibility, we run a large portion of the standard Python regression test suite in addition to a large custom test suite we added that runs IronPython and CPython side-by-side to test for identical behavior whenever possible.  Despite all of this work, there will still be differences between IronPython 1.0 and CPython.  The most obvious difference is that IronPython is missing a number of standard C-based extension modules so things like "import bsddb" will fail.  We maintain a detailed list of differences between the two implementations and aim to reduce the size of this list in every release.

IronPython has also striven for deep integration with the CLR.  For the implementation this is a great thing as it lets us take advantage of highly-tuned components developed for other languages such as the just-in-time compiler, garbage collector, debugging support, reflection, dynamic loading and more.  This integration is also valuable to IronPython developers as it lets them easily use any and all libraries built for .NET from their Python code.

This is the 1.0 release of IronPython.  It's more complete and well tested than any other 1.0 product I have personally released in my career.  However, like any other software product it's not perfect.  You can search for known issues and let us know about any new ones that you find in our public bug database.  We're continuing to work on IronPython and we want your input on how to make 1.1 and future releases even better.

It's been an exciting journey for me to see IronPython go from a rough prototype playing around with some ideas to a solid 1.0 release.  This never could have happened without all the people who've contributed to this project along the way.  My thanks go out to all the users who braved our early releases and passed along their problems and suggestions.  My thanks also go out to the amazing group of people here at Microsoft who've come to join this project and drive it to this quality 1.0 release.

Shipping IronPython 1.0 isn't the end of the road, but rather the beginning.  Not only will we continue to drive IronPython forward but we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it.  I'm excited about how far we've come, but even more excited by what the future holds!

Thanks - Jim Hugunin (for the IronPython Team)

Thursday, January 05, 2006  |  From Jim Hugunin's Thinking Dynamic

We’re looking for a few exceptionally talented individuals with dynamic language experience (Python, Ruby, PHP, JavaScript, etc.) to come join our efforts to make the Common Language Runtime (CLR) the world’s best platform for dynamic languages and dynamic scenarios. The CLR already has a lot of dynamic support with reflection, runtime code generation, and cross-language interaction. IronPython has shown that the CLR can be a great platform for building dynamic languages. We want you to help us take this support to the next level.

We have one developer (not yet posted), one program manager, one tester and at least one summer intern positions available. If you’re interested, please send me email (jimhug@microsoft.com) that clearly explains why you’d be the best choice for one of these jobs and attach a current resume.

Tuesday, January 03, 2006  |  From Jim Hugunin's Thinking Dynamic

I'm at least the third blogger to announce the release of IronPython 1.0 beta 1 after Martin LaMonica and Jeremy Jones.  Still, it's nice to be working on a piece of software that can be covered on onlamp, cnet and msdn.  The original announcement was sent just before the end of 2005.

This release marks a major milestone in that we think we have workable answers to all the major design issues for a 1.0 final.  Of course, we suspect that you'll have suggestions and issues we didn't anticipate, so we expect to see these "final" decisions change as we get feedback on the beta releases.  Since IronPython ships every 2-3 weeks, the differences between beta 1 and the last 0.9.x release aren't huge.  However, we did close on some fairly major design issues to finally reach 1.0beta.

  • We have a good solution for referencing .NET/CLI libraries and no longer modify the standard sys module
  • There's a new exception system for better Python compatibility and better .NET/CLI interoperability
  • We now take full advantage of the new DynamicMethods added in .NET 2.0 to dramatically improve exec and eval
  • We've made major strides in Python compatibility running a huge set of the standard regression test suite and no longer exposing any .NET/CLI methods to "pure Python" code that never references the CLI.

Tuesday, November 22, 2005  |  From Jim Hugunin's Thinking Dynamic

I recently taped a set of IronPython demos and they're now up on the MSDN web site.  It shows some interactive exploration and GUI building from the command-line along with a brief interlude on subclassing a C# class from Python.  It also shows how to simply embed a Python engine in a WPF application.  Take the MSDN folks seriously when they suggest disabling your pop-up blocker or you'll just get to see the fairly boring part of me talking and you'll miss out on the interesting part of the actual demos.  If you do watch the demos, please fill out the ratings as well as this helps MSDN decide what sort of content they want to present in the future.

Friday, November 18, 2005  |  From Jim Hugunin's Thinking Dynamic

We shipped the .NET Framework 2.0!  Okay, I know that I’m not close to the first person to announce this, but I’m still excited.  .NET 2.0 is a great platform for dynamic languages like IronPython to build on top of with several great features:

  • System.Reflection.Emit.DynamicMethod fills the biggest hole in the CLR for supporting dynamic languages.  It allows cheap generation of code on the fly and most importantly the code it generates doesn't need to live for the full life of the application but can be reclaimed when there are no more references.  This ability to generate is reclaimable code is one that the JVM has had for a long time at the ClassLoader level and it's vital to effectively building a dynamic language.  What I like particularly about DynamicMethods is that it supports generating code on the granularity of a single method and then exposing that with delegates, the CLR's strongly typed managed function pointers.
  • Speaking of delegates, 2.0 saw some major improvements to their performance bringing them extremely close to regular method calls in performance.  I've found delegates to be very valuable for implementing Python and these performance improvements are the main reason that IronPython is considerably faster on .NET 2.0 than it was on 1.1.
  • Finally, generics were added to the CLR in a deep and consistent way.  There are lots of interesting arguments pro and con as to whether or not the benefits of generics outweigh the price of their complexity.  However, if you are going to add generics to a system it’s vital to do it in a consistent way.  The key element for dynamic languages is that generics are not implemented via compile-time tricks of type erasure, but are deeply embedded in the runtime so that System.Reflection and other runtime mechanisms can just do the right thing.  This meant that many generic methods just worked automatically in IronPython with proper type checking with no changes and that it only took about a dozen lines of code to completely support instantiating generic types.

Of course, what I’m most excited about with shipping .NET 2.0 is that I now get to focus full time on the future dynamic language story for .NET.  In the short-term that will mean a push to resolve the last few design issues before an IronPython-1.0 release.  In the longer-term it should mean even more interesting things…

Tuesday, April 05, 2005  |  From Jim Hugunin's Thinking Dynamic

I'm excited to announce the public release of IronPython 0.7.1.  The community site is up on http://workspaces.gotdotnet.com/ironpython; however, you should know that most of the interesting discussions are happening on the old mailing list.  I find it really cool to go to a standard Microsoft download page and see a Python implementation, even if it is just an early alpha release.  Some of you might have already heard of and even downloaded this release.  Two weeks ago at PyCON I got to announce the first public release from Microsoft of IronPython 0.7.0.  I wasn't brave enough to start blogging again until we got 0.7.1 out the door.  The 0.7.1 release fixed over 80% of the bugs the community reported in 0.7.  Now that we've made two releases in two weeks I'm confident in our plan to make frequent releases of IronPython in response to community feedback and drive fast and hard to 1.0.

Nevertheless, this is still an early alpha release.  If you were at PyCON you'll know that I asked people to pretend that I released IronPython 0.6 and came to Microsoft only two months ago (instead of eight).  There hasn't been much technical work between 0.6 and 0.7 because I've only had two months to work on this and getting the details of the release together took most of that time.  Trust me, this is the easiest way to understand the 0.7 release.  This release doesn’t run any of the standard Python regression test suite out of the box.  There are several missing builtin functions from Python 2.3 and so far none of the new features in Python 2.4 have been implemented.  The path to fixing these issues is quite obvious and we’ve already started down it.  On our way to 1.0 we need to steadily run more and more of the standard Python regression tests so that by the time we reach 1.0 we’re running and passing almost all of this test suite.

Given the current early state of IronPython, who would want to use it right now?  Well, IronPython today is a pretty good platform for working with .NET libraries and for hosting inside of .NET applications.  I frequently use the IronPython interpreter when I want to experiment with a new .NET API and will often then move that interactive work to a .py file to save as a script for running again in the future.  This is also the area where early feedback is most important.  We know how all the standard Python features should behave and have good tests for this behavior in the standard Python test suite to make sure we get it right.  We still need to learn how best to interact with .NET libraries and code written in other .NET languages because this is new territory.  This is why this is the area we are looking for the most early feedback today.  If you use IronPython with your existing .NET code, let us know what works well and what is awkward.  If something feels awkward to you, it’s quite likely because you’ve discovered a case we didn’t consider and that we’d like to make work better.

Don’t take this current focus on .NET interaction to mean that Python compatibility isn’t important to us.  It is, and there will be a lot of work here as we proceed.  Before we can call IronPython 1.0, I think that it needs to run the standard Python test suite at least as well as Jython does.  Any tests that don’t pass will need to be carefully examined, understood and discussed in a similar way to how this was done for Jython.

I’m looking forward to a lot of fun as we work to build the best possible implementation of Python for .NET.

Monday, October 11, 2004  |  From Jim Hugunin's Thinking Dynamic

You may have noticed that I've been really bad about writing in this blog since I joined Microsoft two months ago.  A big part of my problem has been that there are a TON of interesting things going on around this company that touch on the dynamic language space.  All of these distractions have left me without the time to spend talking to the external community.

The good news is that I now get to hire another member to join the CLR team working full-time on dynamic languages.  Having another person working on this project should give us enough time to really make a big impact on this exciting space.


Make the Common Language Runtime (CLR) an outstanding platform for dynamic languages and environments. You will be a key developer working on the CLR managed services team. Your first task will be to help finish the implementation of Python for the CLR (see http://ironpython.com/) so that we can show other developers how a high-performance production-quality dynamic language is implemented for this platform. Future work will likely involve addressing difficult implementation challenges for other dynamic languages and environments. A central part of this job will be working with the developer community. You will work both with developers who are trying to use dynamic languages on the CLR and those who are trying to develop dynamic languages for this platform. You will also work to identify and implement improvements to the CLR to enable us to provide the best possible experience for dynamic languages in the future.

We're looking for a talented developer with exceptional programming ability and great communication skills. It's a plus if you have expertise in compiler implementation, reflection, VM implementation and/or dynamic languages. Applicants should have at least 4 years experience in software development and a BS/MS in computer science or related field.


http://www.microsoft.com/careers/search/details.aspx?JobID=6391a54a-bfd7-4384-b18f-cecb0acf86e0


If you're interested in this position, I'd encourage you to both apply through the official channels and to send me your resume directly (jimhug at you know what company.com).

Monday, August 23, 2004  |  From Jim Hugunin's Thinking Dynamic

For my first blog entry I wanted to write an article explaining what a dynamic language is. Since I prefer to think concretely about things, I'm going to start with an example of using a dynamic language (Python) to play with an interesting API. For now, my working definition of a dynamic language is any language which could be easily used for the following example.

I’m going to use Windows.Forms as a standard API for this demo. (Note: This probably won't work on Mono-1.0, but it shouldn't be hard to port this example to GTK#. Here's an example of using IronPython with GTK# for those who are interested.) If you want to follow along, you can download IronPython-0.6. Remember that IronPython is at a pre-alpha 0.6 release, so don’t be surprised if it has bugs.

Formatting note: I'm sorry if these examples are a little hard to read.  I'm having trouble talking my blog editor into showing PRE blocks correctly.  The extra lines are an artifact of the blog editor and are not intentional.

The first step is to bring up the interactive interpreter. This should be simple. See README.html in the IronPython zip file for a few more hints on different platforms.

C:\IronPython\bin> IronPythonConsole 
>>>

Whenever I bring up a new interactive interpreter I feel compelled to get it to do some tricky math to let me know that it's really working.

>>> 2+2 
4

Next we’ll create a new Form and show the window.

>>> from System.Windows.Forms import * 
>>> from System.Drawing import * 
>>> f = Form(Text="Experiment #1") 
>>> f.ShowDialog()

You should see a nice little window popup now. However, there’s a big problem. f.ShowDialog has taken over the main thread and it’s impossible to type anything more at the interpreter prompt. Let’s fix that by first closing the window (click on the ‘X’). You should then see:

Cancel 
>>> 

Now let’s start the ShowDialog method in its own thread so that it doesn’t block the interpreter

>>> from System.Threading import * 
>>> Thread(f.ShowDialog).Start() 
>>> 

Now we have our window showing and the interpreter is still “live” for us to keep typing at. We can change different properties of the form like this:

>>> f.MinimizeBox = False 
>>> f.Size = Size(200,200) 
>>> f.Text = "New Title"

It’s fun playing with the form, but we’d like to add a button to give it some more functionality.

>>> b = Button(Text="Push Me") 
>>> f.Controls.Add(b) 
System.ArgumentException: Controls created on one thread cannot be parented to a contro <snip>

Oops! That didn’t work as well as we might have liked. This is our second experience of the interactions between the threading model in Windows.Forms and the interactive interpreter. There are a number of creative solutions to this problem (see …) To keep things simple for this blog, we’re going to just close the window again, add the control, and then restart the main event thread. Don’t forget to close the window before proceeding with the next two lines.

>>> f.Controls.Add(b) 
>>> Thread(f.ShowDialog).Start()

Now we should see the form appear again with a button on it. We can play with the button to make it bigger and brighter.

>>> b.Size = f.ClientSize 
>>> b.BackColor = Color.Yellow

Let’s make the button do something interesting. In preparation for this we’re going to create a list of the named colors in the Color class. This is the one piece of code that includes the most Python specific code. If you’re unfamiliar with Python you should just treat most of this code as magic. Dive Into Python is a good first resource for an experienced programmer who wants to become familiar with Python. It also has a very short section on indentation of blocks in Python. To make this example work, the one thing you should be aware of is that for each line which begins with "..." you will need to type a TAB to create the correct indentation and get your program to run correctly.

>>> colors = [] 
>>> for name in dir(Color): 
...    c = getattr(Color, name) # Use TAB to indent this line and below 
...    if type(c) == Color: colors.append(c) 
... 
>>> colors 
[Color [AliceBlue], Color [AntiqueWhite], Color [Aqua], Color [Aquamarine], Colo 
<snip> 
ke], Color [Yellow], Color [YellowGreen]]

Now that we have this list of colors, we can set the background color of the button to these colors in sequence. This requires creating a function to do the work and then setting that function to be run on the Click event. (Note: def is used in Python to define a new function, and just like above you should use TAB to indent each line in the body of the function.)

>>> index = 0 
>>> def push(b, e): 
...    global index # Use TAB to indent this line and below 
...    b.BackColor = colors[index] 
...    b.Text = colors[index].Name 
...    index += 1 
... 
>>> b.Click += push 
>>> 

Click on the button to cycle through all of the named colors. Finally, we need to exit the interpreter. This is done with ‘Ctrl-Z’.

>>> ^Z 
C:\IronPython\bin>

Now that we’re done playing with the interactive shell, we can put the results of our experiment into a file for running stand-alone. Now that we’re done experimenting, we can simplify the code a little bit by moving some of the property settings into the Form and Button constructors. We can also leave out all of the separate Thread nonsense and just call f.ShowDialog at the end of setting everything up.

------ colors.py ------ 
from System.Windows.Forms import * 
from System.Drawing import * 
f = Form(Text="Playing with colors", MinimizeBox=False, Size=Size(200,200)) 
b = Button(Text="Push Me", Size=f.ClientSize) 
f.Controls.Add(b) 
colors = [] 
for name in dir(Color): 
    c = getattr(Color, name) 
    if type(c) == Color: colors.append(c) 
 
index = 0 
def push(b, e): 
    global index 
    b.BackColor = colors[index] 
    b.Text = colors[index].Name 
    index += 1 
 
b.Click += push 
f.ShowDialog() 
------

Now you can run this as a stand-alone program:

C:\IronPython\bin> IronPythonConsole colors.py

I hope that this has helpful to give newcomers a feel for what IronPython feels like to code in and to give even experienced Python programmers a few more concrete examples of how to work with the CLR. As one last recommendation to anyone new to IronPython, I’d like to pass on this advice overheard on the ironpython users mailing list. IronPython will sometimes look more like VB than C# in the way that it uses CLR libraries and you should look at both C# and VB examples if you’re confused about how to call something in IronPython.

Friday, August 13, 2004  |  From Jim Hugunin's Thinking Dynamic

Hi!  I’ve just finished my second week working at Microsoft. Now that I'm starting to settle in I can get to the fun work with the CLR and dynamic languages.  I’ve been fascinated by the power of programming languages and tools for many years, and I’ve built a number of tools in this space.  I’m the creator of Jython, a co-designer of AspectJ and the original lead for Numeric Python.  You can read more about these projects starting from my personal web site.

Over the past year, I’ve become a reluctant convert to the CLR.  My initial plan was to do a little work and then write a short pithy article called, "Why .NET is a terrible platform for dynamic languages". My plans changed when I found the CLR to be an excellent target for the highly dynamic Python language. Since then I've spent much of my spare time working on the development of IronPython.  The more time that I’ve spent with the CLR, the more excited I’ve become about its potential.  With my new position at Microsoft I have the pleasure of continuing to explore and extend this platform full-time surrounded by smart people who have a deep understanding of the CLR.

I announced the first public release of IronPython-0.6 during my talk at OSCon a couple of weeks ago.  The conference and the talk were great fun.  Before my talk at OSCon, IronPython had only ever run on my personal laptop under Windows XP.  Before my talk was even finished, Edd Dumbill had installed and run it successfully under Linux.  An hour later out in the halls I met several more people who had IronPython running successfully on Linux as well as two people who were running it under Mac OS X.  None of these people needed to make any modifications or even do a recompile to get it working on their systems.  Everyone could run exactly the same binary that I’d built using Visual Studio .Net on Win XP.  Of course, this is exactly how the CLR is supposed to work; nevertheless, it’s always a pleasant surprise when things work as advertised.

I'd like to thank all the people who've given me such positive feedback both about my IronPython announcement and my move to MS. 

This blog is going to give me an easy place to talk about technical issues with implementing languages for the CLR and about philosophical issues around how and where dynamic languages are most useful.  I’ve just started my new job and still have to work out my schedule and commitments, so don’t expect any comments from me about a next release for a little while.  Coming soon will be an entry similar to one of the live demos I gave during OSCon to show a little bit more about how IronPython can interact with interesting CLR libraries.

 Jim Hugunin's Thinking Dynamic News Feed 

Last edited Dec 7, 2006 at 10:16 PM by codeplexadmin, version 1

Comments

No comments yet.